Я, конечно, доверяю и присулшиваюсь к мегабайту, тебе. Мнение учёл. думал месяц, читал много доки и реализаций.... Опыта то у меня нет в этом никакого и знакомых в этой области нет, и на работе никто с mysql, mariadb не работает

Ну, решил, что имеет смысл попробовать отправится в морское путешествие. Пуско-наладочные работы, сопровождение, шторм с восстановлением и уже можно наняться матросом на галеру.

А на ком тренироваться то? Только на скульщиках, бугога. Тут хоть какая-никакая нагрузка, ответственность, реальный веб-сервис.

Форум работает под MySQL и MSSQL

У вас какое-то странное мнение o mysql вариациях. У меня не будет хостинга, у меня два реальных, железных сервака HP DL360 Так что, я MSSQL туда смогу воткнуть, но! на куй она мне всралась? Тут чисто линуксовое с упором на импортозамещение всё, что можно.

+ из СУБД я знаком только с MySQL. Изучать MSSQL во времена санкций - это надо быть экстремальным долбеёбом.

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

Я уже много чего сделал, больше половины, наверное. СУБД просто откладываю и откладываю до принятия окончательного решения, но вроде уже решил окончательно, как выше написал: попробуем такую схему, 4 хоста СУБД, по 2 на каждом из физических узлов.

Орм - это оперативно-розыскные мероприятия?

Ну в таких условиях только скриптом проверять доступность и перестартовывать.

у него один обычный хостинг и одна виртуалка. Я так понял, кот2 расширятся не планирует.

Будешь расширятся?

Тогда с твоим веб-сервисом достаточно двух + протокол VRRP и третий айпишник.
То есть, у тебя будет две виртуалки и три белых айпишника. По протоколу VRRP будешь гонять один белый failover IP между ними. Для веб сервиса достаточно. Если одна отваливается, айпишник съезжает на другой, на второй доступен. Обращаться должны на этот айпишник.

Виртуалки в этом слуае должны быть у одного провайдера, но я не уверен, что провайдер разрещит тебе гонять трафик vrrp в своем сегменте.

всё у одного провайдера? именно виртуалки или хостинг? какая виртуализация? KVM подобное или что-то вроде XEN?

в описанных тобой условиях - только скриптом проверять. Какие тут ещё варианты могут быть.

selinux теперь (((((

Не стартует кластер галеры с mcast адресом

Ааааа

Нет! Надо политику написать.

Странно, обычным образом нормально все, не стартует именно с multicast адресом

Галера взята!

Настроил следующим образом:
- 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 Гб.

Нет, не поднимается. При полном отключении всех узлов кластер перестают существовать и его надо инициализировать заново. Но это нормально и не деструктивно при корректном выключении. Просто снова инициализировать кластер. А вот если все вырубить одновременно с ноги, понадобится проводить процедуру восстановления кластера.

Уже краш тест проводился.

Там 6 дисков на данные. 5 дисков по терабайту в 5 рэйде + 1 hot spare

Каковы шансы на отключение сразу двух серверов, подключенных к разным ИБП и даже разным линиям электропитания? Они есть, но не особо высокие.

Sparrow [игнорируется] 

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

Это абсолютно нормально, как иначе? А для полноценного кластера и HA как положено нам нужен, как минимум, третий узел и СХД с двумя контроллерами, основной и резервный, подключённые через дублированные оптические свитчи (как минимум три, ядро + 2 доблирующих свитча).

Все в курсе сколько это будет стоить? :)

+ теперь все работы по обновлению ОС и ПО можно проводить без остановки форума. Вы их не заметите.
+ исчезнет ночная надпись о работах с 2 до 4

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

Ну потом я подробно хочу написать статью с описанием и некоторыми конфигами, настройками.

менее подробно отвечу. :)

Всё задублировано, Но это не тупое дублирование, когда один физический узел простаивает. В штатном режиме помимо работы ещё распределяется нагрузка между двумя физическими серверами.

Ну например, как проводи обновление, есть nginx1 и nginx2. Обновляем первый, второй работает. Первый обновили, запустили, обновляем второй, первый работает. Все айпишники плавают по VRRP. Для "тупых" сервисов, когда нужно просто запросить инфу с айпи:порта и получить ответ - более чем достаточно. Для "интеллектуальных" вроде субд - не проканает, поэтому тут кластер.

В конструкции две интеллектуальные сущности
- виртуальное хранилище, на glusterfs, оттуда будет форум читаться, вложения и т.д
- субд

Тут везде, грубо говоря, 4-way replication. По два виртуальных сервера на каждом из физических.

Как обнволять физический узел. Выключить все ВМ на одном физическом узле. Обновить. перегрузить. Выключить на втором,обновить, перезагрузить. Один из узлов останется работать и форум будет работать.

+ балансировка внешних запросов через DNS записи по roundrobin. Дальше уже умный nginx через алгоритмы балансировки и upstream channel раскидает запросы на серверы приложений апач, он понимает, что работает, что не работает и запоминает состояния.

Дык всё в финансы упирается. Если я вдруг не смогу платить - придётся переезжать как щас.

денег не надо. у меня с донатами связаны неприятные воспоминания. Слишком много претензий.

Так он из 5 дисков. Всего 6 дисков. 5 в рейде и один хот-спаре.

Ну блин, куёво. Думал ещё 6 со всеми дисками или 5 с хот спаре. Не помню почему я решил 5 сделать.