Дедокластер Z
#773825
Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
|
||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
Галера взята! Настроил следующим образом: - 4 виртуальных сервера объединены в mariadb galera cluster multi-master (по 2 виртуальных сервера на каждом из 2-х физических серверов) - 2 galera arbitrator (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Можно иметь только один арбитр, но арбитр включается на каком-либо из виртуальных серверов по триггеру при смене состояния VRRP с BACKUP на MASTER - 2 haproxy (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Что всё это значит. У меня 2 физических сервера. Каждый из них подключен в свой ИБП и в разные линии подачи электропитания. При аварийном падении, либо при обслуживании одного физического сервера, в кластере галеры остаются 2 виртуальных сервера sql. Кворум сохранён, галера работает с двумя узлами. Тут же, если галера арбитр был на другом физическом узле, он переключается при смене состояния VRRP на MASTER на рабочий узел и присоединяется к кластеру. Таким образом, полностью соблюдено требование к нормальному полноценному функционированию кластера - минимум 3 узла. Все запросы к БД отправляются на виртуальный ip haproxy, который выполняет балансировку по алгоритму leastconn. На скрине пример с roundrobin Что печально - накладные расходы на место. На 500 гигов данных БД расходуется ещё 1.5 тера репликации. Итого, в работе этой схемы участвуют 8 виртуальных серверов на 2-х физических. Я сейчас уперся в лимит по памяти, с overhead не хочется дело иметь, заказал расширение. Обещали увеличить объем ОЗУ до 288 Гб. ... |
||||||||||||||||
:
Не нравится:
|
||||||||||||||||
06.05.2024, 13:40 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Галера взята! Настроил следующим образом: - 4 виртуальных сервера объединены в mariadb galera cluster multi-master (по 2 виртуальных сервера на каждом из 2-х физических серверов) - 2 galera arbitrator (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Можно иметь только один арбитр, но арбитр включается на каком-либо из виртуальных серверов по триггеру при смене состояния VRRP с BACKUP на MASTER - 2 haproxy (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Что всё это значит. У меня 2 физических сервера. Каждый из них подключен в свой ИБП и в разные линии подачи электропитания. При аварийном падении, либо при обслуживании одного физического сервера, в кластере галеры остаются 2 виртуальных сервера sql. Кворум сохранён, галера работает с двумя узлами. Тут же, если галера арбитр был на другом физическом узле, он переключается при смене состояния VRRP на MASTER на рабочий узел и присоединяется к кластеру. Таким образом, полностью соблюдено требование к нормальному полноценному функционированию кластера - минимум 3 узла. Все запросы к БД отправляются на виртуальный ip haproxy, который выполняет балансировку по алгоритму leastconn. На скрине пример с roundrobin Что печально - накладные расходы на место. На 500 гигов данных БД расходуется ещё 1.5 тера репликации. Итого, в работе этой схемы участвуют 8 виртуальных серверов на 2-х физических. Я сейчас уперся в лимит по памяти, с overhead не хочется дело иметь, заказал расширение. Обещали увеличить объем ОЗУ до 288 Гб. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:13 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
а воощето надо один диск. реальный извлечь, потом засунуть туда запасной ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:15 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Галера взята! Настроил следующим образом: - 4 виртуальных сервера объединены в mariadb galera cluster multi-master (по 2 виртуальных сервера на каждом из 2-х физических серверов) - 2 galera arbitrator (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Можно иметь только один арбитр, но арбитр включается на каком-либо из виртуальных серверов по триггеру при смене состояния VRRP с BACKUP на MASTER - 2 haproxy (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Что всё это значит. У меня 2 физических сервера. Каждый из них подключен в свой ИБП и в разные линии подачи электропитания. При аварийном падении, либо при обслуживании одного физического сервера, в кластере галеры остаются 2 виртуальных сервера sql. Кворум сохранён, галера работает с двумя узлами. Тут же, если галера арбитр был на другом физическом узле, он переключается при смене состояния VRRP на MASTER на рабочий узел и присоединяется к кластеру. Таким образом, полностью соблюдено требование к нормальному полноценному функционированию кластера - минимум 3 узла. Все запросы к БД отправляются на виртуальный ip haproxy, который выполняет балансировку по алгоритму leastconn. На скрине пример с roundrobin Что печально - накладные расходы на место. На 500 гигов данных БД расходуется ещё 1.5 тера репликации. Итого, в работе этой схемы участвуют 8 виртуальных серверов на 2-х физических. Я сейчас уперся в лимит по памяти, с overhead не хочется дело иметь, заказал расширение. Обещали увеличить объем ОЗУ до 288 Гб. Уже краш тест проводился. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:20 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
а воощето надо один диск. реальный извлечь, потом засунуть туда запасной ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:21 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Галера взята! Настроил следующим образом: - 4 виртуальных сервера объединены в mariadb galera cluster multi-master (по 2 виртуальных сервера на каждом из 2-х физических серверов) - 2 galera arbitrator (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Можно иметь только один арбитр, но арбитр включается на каком-либо из виртуальных серверов по триггеру при смене состояния VRRP с BACKUP на MASTER - 2 haproxy (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Что всё это значит. У меня 2 физических сервера. Каждый из них подключен в свой ИБП и в разные линии подачи электропитания. При аварийном падении, либо при обслуживании одного физического сервера, в кластере галеры остаются 2 виртуальных сервера sql. Кворум сохранён, галера работает с двумя узлами. Тут же, если галера арбитр был на другом физическом узле, он переключается при смене состояния VRRP на MASTER на рабочий узел и присоединяется к кластеру. Таким образом, полностью соблюдено требование к нормальному полноценному функционированию кластера - минимум 3 узла. Все запросы к БД отправляются на виртуальный ip haproxy, который выполняет балансировку по алгоритму leastconn. На скрине пример с roundrobin Что печально - накладные расходы на место. На 500 гигов данных БД расходуется ещё 1.5 тера репликации. Итого, в работе этой схемы участвуют 8 виртуальных серверов на 2-х физических. Я сейчас уперся в лимит по памяти, с overhead не хочется дело иметь, заказал расширение. Обещали увеличить объем ОЗУ до 288 Гб. Уже краш тест проводился. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:28 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Галера взята! Настроил следующим образом: - 4 виртуальных сервера объединены в mariadb galera cluster multi-master (по 2 виртуальных сервера на каждом из 2-х физических серверов) - 2 galera arbitrator (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Можно иметь только один арбитр, но арбитр включается на каком-либо из виртуальных серверов по триггеру при смене состояния VRRP с BACKUP на MASTER - 2 haproxy (по 1 виртуальному серверу на каждом из 2-х физических серверов) с виртуальным ip адресом, который плавает по виртуальным серверам по протоколу VRRP. Что всё это значит. У меня 2 физических сервера. Каждый из них подключен в свой ИБП и в разные линии подачи электропитания. При аварийном падении, либо при обслуживании одного физического сервера, в кластере галеры остаются 2 виртуальных сервера sql. Кворум сохранён, галера работает с двумя узлами. Тут же, если галера арбитр был на другом физическом узле, он переключается при смене состояния VRRP на MASTER на рабочий узел и присоединяется к кластеру. Таким образом, полностью соблюдено требование к нормальному полноценному функционированию кластера - минимум 3 узла. Все запросы к БД отправляются на виртуальный ip haproxy, который выполняет балансировку по алгоритму leastconn. На скрине пример с roundrobin Что печально - накладные расходы на место. На 500 гигов данных БД расходуется ещё 1.5 тера репликации. Итого, в работе этой схемы участвуют 8 виртуальных серверов на 2-х физических. Я сейчас уперся в лимит по памяти, с overhead не хочется дело иметь, заказал расширение. Обещали увеличить объем ОЗУ до 288 Гб. Уже краш тест проводился. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:29 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
... Уже краш тест проводился. а плохой вечно в суете, это им нравится ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:40 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Данная конструкция должна пережить падение одного физического сервера по каким-либо причинам, питание, аппаратные проблемы и продолжить предоставление сервиса. Падение двух - естсественно, потребуется участие одмина, само оно не запустится. + исчезнет ночная надпись о работах с 2 до 4 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:40 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
... Уже краш тест проводился. а плохой вечно в суете, это им нравится ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:43 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
теперь все работы по обновлению ОС и ПО можно проводить без остановки форума. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:46 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Данная конструкция должна пережить падение одного физического сервера по каким-либо причинам, питание, аппаратные проблемы и продолжить предоставление сервиса. Падение двух - естсественно, потребуется участие одмина, само оно не запустится. + исчезнет ночная надпись о работах с 2 до 4 сей час вообще гласно, спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 10:46 |
|
Дедокластер Z
|
|
---|---|
#18+
теперь все работы по обновлению ОС и ПО можно проводить без остановки форума. менее подробно отвечу. :) Всё задублировано, Но это не тупое дублирование, когда один физический узел простаивает. В штатном режиме помимо работы ещё распределяется нагрузка между двумя физическими серверами. Ну например, как проводи обновление, есть nginx1 и nginx2. Обновляем первый, второй работает. Первый обновили, запустили, обновляем второй, первый работает. Все айпишники плавают по VRRP. Для "тупых" сервисов, когда нужно просто запросить инфу с айпи:порта и получить ответ - более чем достаточно. Для "интеллектуальных" вроде субд - не проканает, поэтому тут кластер. В конструкции две интеллектуальные сущности - виртуальное хранилище, на glusterfs, оттуда будет форум читаться, вложения и т.д - субд Тут везде, грубо говоря, 4-way replication. По два виртуальных сервера на каждом из физических. Как обнволять физический узел. Выключить все ВМ на одном физическом узле. Обновить. перегрузить. Выключить на втором,обновить, перезагрузить. Один из узлов останется работать и форум будет работать. + балансировка внешних запросов через DNS записи по roundrobin. Дальше уже умный nginx через алгоритмы балансировки и upstream channel раскидает запросы на серверы приложений апач, он понимает, что работает, что не работает и запоминает состояния. ... |
|
:
|
|
07.05.2024, 10:59 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Данная конструкция должна пережить падение одного физического сервера по каким-либо причинам, питание, аппаратные проблемы и продолжить предоставление сервиса. Падение двух - естсественно, потребуется участие одмина, само оно не запустится. + исчезнет ночная надпись о работах с 2 до 4 сей час вообще гласно, спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 11:01 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Данная конструкция должна пережить падение одного физического сервера по каким-либо причинам, питание, аппаратные проблемы и продолжить предоставление сервиса. Падение двух - естсественно, потребуется участие одмина, само оно не запустится. + исчезнет ночная надпись о работах с 2 до 4 сей час вообще гласно, спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 11:09 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
теперь хорошо сплю ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 11:18 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
наоборот, на пенсии мозг не загружен, всякая фигня показывалась, типа белочки, теперь стабильно, кодю во сне ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 11:32 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
... + исчезнет ночная надпись о работах с 2 до 4 сей час вообще гласно, спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 11:38 |
|
Дедокластер Z
|
|
---|---|
#18+
Что-то не выровненный рейд. Лишние iops сделал, которых мог бы избежать... 5 рейд уж делал бы из 5 дисков 4 данные один четность контрольный бит. Или рейд6 - 4 данные и 2 диска под четность все 6 бы задействовал, полезного места меньше на 20% но скорость выше да и 6 рейд не деградирует при отказе одного харда ... |
|
:
|
|
07.05.2024, 12:05 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Что-то не выровненный рейд. Лишние iops сделал, которых мог бы избежать... 5 рейд уж делал бы из 5 дисков 4 данные один четность контрольный бит. Или рейд6 - 4 данные и 2 диска под четность все 6 бы задействовал, полезного места меньше на 20% но скорость выше да и 6 рейд не деградирует при отказе одного харда ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 12:12 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
Что-то не выровненный рейд. Лишние iops сделал, которых мог бы избежать... 5 рейд уж делал бы из 5 дисков 4 данные один четность контрольный бит. Или рейд6 - 4 данные и 2 диска под четность все 6 бы задействовал, полезного места меньше на 20% но скорость выше да и 6 рейд не деградирует при отказе одного харда ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 12:14 |
|
Дедокластер Z
|
|||
---|---|---|---|
#18+
кто-то ещё использует в наше время RAID пятого уровня? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2024, 12:14 |
|
Дедокластер Z
|
|
---|---|
#18+
basename [игнорируется] Кстати .. теория 95% чтение 5% запись норм 5 рейд так себе... Помню в инфотекс теровая база на 5 рейде подтормаживала... Даже файлы с данными. В общем перевели на 10й рейд и перформанс сильно вырос - лаги ушли. Ну и... Общие рекомендации транлог бд на одни физ диски типа рейд1 причем можно все транлоги на 1 рейд1 одного сервера бд, а файлы бд с данными на отдельный/отдельные. Понятно затратное... Может щас и не актуально https://intuit.ru/studies/courses/68/68/lecture/1992 ... |
|
:
|
|
07.05.2024, 12:19 |
|
Start [/forum/topic.php?fid=8&tid=16227&msg=774367&do_citate=774367]: |
0ms |
get settings: |
0ms |
get forum list: |
6ms |
check forum access: |
0ms |
check topic access: |
0ms |
track hit: |
25ms |
get topic data: |
2ms |
get forum data: |
0ms |
get page messages: |
83ms |
update_topic_read_status (16227): 07.05.2024 12:21:11: |
0ms |
get tp. blocked users: |
0ms |
get online users: |
48ms |
check new: |
1ms |
others: | 64ms |
total: | 229ms |
0 / 0 |