Базовая конфигурация виртуальной сетевой инфраструктуры подготовлена. Приступил к созданию шаблона для раскатки виртуалок.

По форуму. Тема про форум. А кто это и что он будет с ними делать, бугога?) шпион? Я сразу в фсб пойду.

Дедокластер синенькими лампочками горит :)

Потихоньку дело движется. Рабочее окружение почти подготовлено.

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

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

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

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

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

Вот дисковая подсистема сервера. Том с гипервизором не 480, а 400. Полезное место 370.
- проеб места на системных дисках. Я все отдал гипервизору, а он по факту сейчас жрет 5 гигов. Надо было гипервизору отдать ну максимум 32 гига, остальное место отдать тоже под данные, хотя бы под системные диски некоторых виртуалок. Скорее всего буду резать, уменьшать. Ну блять разбрасываться 300 гигов - жирно
- всего 22 виртуалки по плану (11 на каждом узле). у каждой виртуалки системный диск по 32 гига. Ну... можно после переразметки диска вприницпе все их впихнуть в raid1, вернее системные диски этих виртуалок. Испепеляющая надёжность не требуется, в системный диск пишутся максимум логи.. 32 гига места - тоже до куя так -то, для ОС 8 гигов вполне хватает, ну просто обычно что-о нужно скопировать, архив, туда сюда, а места нет. Думаю, пусть будет 32 у каждой
- из доступны примерно 3.5 тера raid5 у меня 1 тер под бэкапы виртуалок средствами гипервизора 2.5 тера на каждом сервере для данных, дисков, виртуальных машин
- в конструкции есть виртуальный сторэдж из 4 узлов с дополнительными виртуальными дисками по 256 каждый и 4 sql сервера в вышеописанном кластере с дополнительными дисками 512 каждый
- итого примерно на кждом сервере занято около 2 терабайт, ну 500 гигов пусть там остается снэпшоты, туда сюда, вдруг места куда докинуть надо
- самый жрущие сущности - виртуальный сторэдж и sql

Немного про сторэджи, почему нужно резать. Выше я приводил ссылку на поддерживаемые гипервизором типы хранилища. Внешней полки по FC у меня нет. только локальные диски сервера. В моем случае оптимальным сторэджем будет lvm-thin. Эта штука никуда не монтируется, в операционную систему, в гипервизоре создаётся хранилище с этим типом,пуликуется и на этапе создания дисков для каждой вм создаётся lv в подсистеме lvm. да, гипервизор может работать, создавая диски в файловой системе ОС, как файлы, но такая конструкция на сайтевендора рекомендована исключительно для ознакомления и тестирования.

В общем, наверное,всё-таки raid5 самый оптимальный выбор в данной ситуации.