У меня есть двухузловой кластер с пульсом и DRBD, управляющим ресурсом mysql. Аварийное переключение отлично работает, если я останавливаю основной, перезагружаю его или отключаю сетевое соединение.
Однако, если первичный страдает от паники ядра (моделируется запуском echo c > /proc/sysrq-trigger) вторичный не захватывает ресурсы.
Вот как выглядит журнал биений на вторичном сервере:
Jul 11 21:33:32 rad11 heartbeat: [7519]: WARN: node rad10: is dead
Jul 11 21:33:32 rad11 heartbeat: [7519]: info: Link rad10:eth0 dead.
Jul 11 21:33:32 rad11 heartbeat: [8442]: info: Resetting node rad10 with [Meatware STONITH device]
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: OPERATOR INTERVENTION REQUIRED to reset rad10.
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: Run "meatclient -c rad10" AFTER power-cycling the machine.
Кто-нибудь знает, почему в этой ситуации второстепенный не может взять верх? Обычно аварийное переключение работает отлично, но я пытаюсь имитировать панику ядра на основном узле.
РЕДАКТИРОВАТЬ: вот моя конфигурация сердцебиения, ha.cf
# /etc/ha.d/ha.cf
logfile /var/log/ha-log
keepalive 1
deadtime 10
udpport 695
ucast eth0 rad11
auto_failback on
stonith_host rad10 meatware rad11
stonith_host rad11 meatware rad10
node rad10 rad11
Когда узлы кластера теряют связь друг с другом, чтобы избежать раздвоение мозга сценарий, в котором оба узла думают, что они первичные, и пытаются одновременно запустить общий ресурс с потенциальной катастрофой в результате (это особенно большая проблема в кластерах с двумя узлами, потому что у кого есть кворум, если оба узла имеют по одному голосу каждый?), поэтому, чтобы смягчить это, некоторые кластеры реализуют различные формы ограждения.
Ограждение - это процесс блокировки ресурсов от узла, статус которого неизвестен.
Доступны различные техники ограждения.
Можно либо ограждать узлы - с помощью Node Fencing, либо ограждать ресурсы с помощью Resource Fencing. Некоторые типы ресурсов являются ресурсами самообороны, а некоторые не повреждаются при одновременном использовании и вообще не требуют ограждения.
Когда узел выполняет полное завершение работы, он спокойно покидает кластер, и, таким образом, остальные будут знать, что происходит, и, следовательно, просто возьмут на себя все службы, которые узел мог запускать, а затем продолжат работу. Когда узел вместо того, чтобы покидать кластер, получает панику ядра, другие члены кластера не будут знать статус другого узла. Это будет «неопределенным» с их точки зрения, поэтому вместо этого они будут выполнять сконфигурированные «ограждающие» действия, которые в случае STONITH означают попытку насильственного удаления фаули-узла из кластера (путем включения и выключения питания и т. Д.).
Глядя в свои журналы, кажется, что meatware STONITH механизм выбран для конфигурации вашего кластера. Как следует из названия, это подразумевает включение и выключение другого узла вручную, а затем выполнение указанной команды. Из док:
посуда
Странное название и простая концепция. для работы мясной посуды требуется помощь человека. При каждом вызове Meatware регистрирует сообщение о серьезности CRIT, которое должно отображаться на консоли узла. Затем оператор должен убедиться, что узел не работает, и выполнить команду meatclient (8), чтобы сообщить мясному ПО, что можно сообщить кластеру, что он может считать узел мертвым. См. README.meatware для получения дополнительной информации.
Есть и другие способы настройки ограждений. При создании кластера я обычно беру два коммутатора APC для блоков питания и настраиваю «ограждение APC» (stonith -t apcmaster -h). Таким образом, когда один узел выходит из строя, другой выполнит жесткую перезагрузку, выключив и снова выключив неисправный элемент, войдя в интерфейс APC и отправив команду выключения / перезагрузки в подключенные слоты блока питания (у меня есть два, чтобы избежать единой точки отказа) .