проблемы с кардиостимулятором - стонит
TL;DR: Мне нужна помощь в настройке ограждения моего кластера кардиостимуляторов.
У меня есть кластер из трех машин, на которых работает кардиостимулятор. Это в моей домашней лаборатории, это не рабочая установка.
Два из них — физические серверы Dell. R720xd и R710. Третья — виртуальная машина, работающая в бежевом ящике под libvirtd/qemu. Физические серверы и виртуальная машина — это Ubuntu Server 22.04.
Эти три машины также являются членами кластера innodb. Виртуальная машина продолжала перезагружаться, вызывая повреждение базы данных mysql, с которым кластер innodb не мог справиться.
Существует три ресурса-стимулятора — VIP для haproxy, сам haproxy и VIP для mysqlrouter, выходящих на кластер innodb. Два ресурса для haproxy расположены рядом и настроены на предпочтение R720xd, а VIP-сервер innodb настроен на предпочтение R710. Все ресурсы имеют приоритет -1000 для виртуальной машины. Роль виртуальной машины заключается в том, чтобы служить решающим голосом в обоих кластерах, а не обрабатывать соединения.
Причиной нестабильности был sbd. Я наткнулся на sbd, когда проверял посылки. Я установил его и настроил с помощью программного сторожевого таймера с использованием модуля ядра softdog и обнаружил, что его запуск и повторное включение stonith в кластере убрало предупреждение кластера об отсутствии ограждения.
На виртуальной машине у сторожевого таймера постоянно возникали проблемы при проверке связи с шлюзом по умолчанию, которым является маршрутизатор, на котором работает DD-WRT. Затем я изменил его на коммутатор Cisco уровня 3, также расположенный в сети, и увеличил количество пингов с 2 до 10. Он по-прежнему не получал ответов, поэтому один из сторожевых таймеров или sbd выполнял полную перезагрузку виртуальной машины.
Тогда я удалил пинг. Но у него ВСЕ ЕЩЕ была проблема - я настроил его на просмотр /var/log/syslog с интервалом последнего обновления 900 секунд... и он продолжал обнаруживать, что файл журнала меняется недостаточно быстро, поэтому перезапуск продолжался. происходит.
Затем я изменил его на /var/log/auth.log, что ОЧЕНЬ меняет из-за части кардиостимулятора — crm_mon. Постоянно возникала проблема с перезапуском, которая нарушает устойчивость HA в кластере innodb.
Итак, на данный момент я удалил sbd со всех трех серверов. Что оставляет меня без какого-либо камня.
У меня есть idrac на серверах Dell, и я пытался использовать для них модуль ограждения idrac. Но я не мог заставить его работать. Я также попробовал модуль ограждения ssh на всех трех, но тоже не смог заставить его работать.
Даже если бы мне удалось заставить работать модуль ограждения idrac, это привело бы к принудительному отключению серверов Dell, что привело бы к возникновению проблемы с кластером innodb. Поэтому я думаю, что лучший вариант — это настроить модуль ограждения ssh на всех трех серверах. Я прочитал все предупреждения о том, что он не предназначен для производства, что если сервер действительно окажется в плохом состоянии, он не сможет его должным образом защитить.
У меня есть скриптовая процедура для исправления кластера innodb после возникновения проблемы, но восстановление требует ресурсов, особенно на виртуальной машине. Копирование 17 ГБ данных MySQL занимает некоторое время.
У меня все серверы отслеживаются с помощью zabbix, с шаблоном кардиостимулятора для трех упомянутых серверов, а на двух серверах Dell также запущен сценарий, который отправит мне электронное письмо в случае, если кластер innodb когда-либо достигнет состояния, отличного от «ОК», поэтому У меня есть несколько электронных писем, в которых сообщается, что статус OK_NO_TOLERANCE_PARTIAL при полной перезагрузке виртуальной машины. Я внимательно слежу за ними обоими в течение каждого дня. Итак, я собираюсь узнать, есть ли проблемы с кластерами.
ТЛ;ДР:
Если кто-то может объяснить, как настроить модуль ограждения ssh, чтобы он работал правильно, я был бы признателен. Все три сервера имеют ssh-ключи для SSH без пароля от имени пользователя root. Не существует другого устройства аппаратного ограждения, кроме idrac, но любое ограждение, приводящее к принудительному отключению сервера, вызовет те же проблемы, что и плохое состояние программного обеспечения... и у меня есть мониторинг, который предупреждает меня, когда происходит проблема, требующая ручного ремонта.