Вы думаете я забыл? Нет!

Сегодня обсуждался вопрос организации отказоустойчивого кластера Дедофорума. Скоро должны смонтировать оборудование, приступлю к развёртыванию, погоняю.

Планируемые вычислительные ресурсы:
- 2 узла
- 24 ядра
- 144 гб озу
- примерно 6 тб полезного дискового пространства в 5 рейде с хот спаре
- рейд контроллеры с батарейкой
- 10 гбит/с между узлами для миграции ВМ
- 200 мб/с канал в инет

Для виртуализации буду использовать, скорее всего, Альт виртуализацию. ( но ещё думаю по поводу Ред виртуализации, но она сложнее, более громоздкая, лишнее, наверное)Для гостевых ВМ - РедОС

Это обеспечит высокую доступность и минимизацию даунтайма при выполнении работ по обновлению ОС.

В целом по работам все понятно. Пока не знаю, только, как сделать схему primary standby с автопереключением для СУБД.

У меня венды нет под рукой. Щас с телефона вообще.

Да! Но это должно быть интересно!

Вот по этому вопросу, у кого-нибудь есть железобетонно рабочий пример схемы для MySQL, primary-standby, когда, standby мгновенно превращается в primary, при отказе, и репликация обратно? Или руками переключать только?

Погуглил примеры, в подобной реализации слишком большое усложнение и этих ресурсов тоже не хватит уже.

Вообще, хотелось бы на один писать, с другого читать. Но тоже усложнение. Пока думаю схему с переключением.

Хз, как добиться отказоустойчивость для Субд в случае 2-х узлов.

Ну, то есть, надо не сильно усложнять, чтобы при необходимости можно было съехать обратно на хостинг, как сейчас, но и использовать ресурсы для, так сказать, зеркалирования.

Например, обновляю гипервизор. Машины с одного отправил на другой, обновил первый, потом отправил со второго на первый, обновил второй, потом снова разогнал машины по двум. Вы ничего не заметили вообще.

С обновлением самих машин уже посложнее, но мне знакомо хорошо Но непонятки с субд. Если я обновляю primary - это даунтайм. нужно легким движением пальца пнуть MySQL, чтобы переключился primary в standby и переключился накат логов обратно. Чтобы вы опять ничего не заметили.

Все нормально. Ничего плохого не творится :)

Вот с DB надо понять. Иначе это место простоя и в реализации схемы нет смысла. Split read-write, конечно, очень хочется.

Остальное все знаю как закластеризовать и зафэйловерить.

Ну я тоже гуглил. Либо очень ресурсоемко, сложно, но полностью HA, либо на коленке, скриптами, с костылями.

Просто, на всякий случай спросил, может кто делал. Репликация понятно, дело не сложное, но смысл в ней, если нет автоматизированной схемы переключения в случае аварии.

Как говорится, дают - бери. Бьют - беги.

С БД жесть.

Может это и не сложно, но я никогда не делал.

https://docs.oracle.com/en/solutions/ha-mysql-innodb-cluster/index.html#GUID-9F8C3C85-FBA4-47D9-BEAA-036532076771

https://www.percona.com/blog/failover-mysql-utilities-part1-mysqlrpladmin/
https://www.percona.com/blog/failover-mysql-utilities-part-2-mysqlfailover/

Второй варик попроще, но точкой отказа становится сам mysqlfailover, либо надо понять, можно ли запустить 2 экземпляра на 2-х кластеризованных серверах веб-приложений. Если да, то подойдёт.

Ну а по правильному надо городить конструкцию по первой ссылке.

А вообще… знаешь же служивый юмор?
- от столба и до обеда
- главное, чтоб вы не снег очистили, а чтоб заебались

:)

Что-то вроде этого

Пока планирование следующее

Гипервизоры. Кластер (HA)
pve1
pve2

Будут соблюдены: Mgmt Plane, Control Plane, Data Plane

VM
#####

Роутеры (HA):
rt1
rt2

#
Абонентский пункт администратора:
srv-adm

#
Хранилище (shared storage) для инфраструктуры ВМ (HA)
gluster-arbiter
gluster-fs1
gluster-fs2

#
Веб-сервера доступа внешнего контура (HA) (LB)
nginx1
nginx2

#
Сервера приложений (Дедофорум и форумы) (HA) (LB)
apache1
apache2

#
Сервис монитторинга (HA)
zabbix
zabbix-proxy1
zabbix-proxy2

#
СУБД (???)
DB1
DB2

#
Сервер разработки
gitlab

#
Сервер Кролика
kroleg

Надо разобраться с субд.
Буду читать

Но взлететь мало! Потом ебанись это все поддерживать, бугога))