Сердцебиение мясной посуды STONITH на ядре паники
У меня есть двухузловой кластер с биением и 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
1 ответ
Когда узлы кластера теряют связь друг с другом, чтобы избежать сценария разделения мозга, когда оба узла думают, что они являются первичными, и в результате пытаются одновременно запустить общий ресурс с потенциальной катастрофой (это особенно большая проблема в кластерах с двумя узлами). потому что у кого есть кворум, если оба узла имеют по одному голосу?), поэтому для смягчения этого некоторые кластеры реализуют различные формы ограждения.
Ограждение - это процесс блокировки ресурсов от узла, состояние которого является неопределенным.
Есть множество доступных методов фехтования.
Можно либо ограждать узлы - используя Node Fencing, либо ограждать ресурсы, используя Resource Fencing. Некоторые типы ресурсов являются Самозащитными Ресурсами, а некоторые не повреждаются при одновременном использовании и вообще не требуют ограждения.
Когда узел выполняет чистое завершение работы, он приятно покидает кластер, и, таким образом, другие будут знать, в чем дело, и, следовательно, просто получат все службы, которые могли работать на узле, и затем продолжат работу. Когда узел вместо того, чтобы покинуть кластер, получает панику ядра, другие члены кластера не будут знать состояние другого узла. Это будет "неопределенным" с их точки зрения, поэтому вместо этого они будут выполнять сконфигурированные "ограждающие" действия, что в случае STONITH означает попытку удаления узла с ошибкой силой из кластера (путем включения и выключения питания и т. Д.).
Глядя в ваши журналы, кажется, что meatware Механизм STONITH выбран для конфигурации вашего кластера. Как следует из названия, это подразумевает ручное выключение и включение другого узла, а затем выполнение указанной команды. Из документа:
meatware
Странное имя и простая концепция. мясная посуда требует помощи от человека для работы. Всякий раз, когда вызывается, meatware регистрирует сообщение о серьезности CRIT, которое должно отображаться на консоли узла. Затем оператор должен убедиться, что узел не работает, и выполнить команду meatclient(8), чтобы сообщить программному обеспечению, что все в порядке, чтобы сообщить кластеру, что он может считать узел мертвым. См. README.meatware для получения дополнительной информации.
Есть и другие способы настройки ограждения. При создании кластера я обычно получаю два коммутатора APC для блока питания и настраиваю "ограждение APC" (stonith -t apcmaster -h). Таким образом, когда один узел выходит из строя, другой выполняет предварительную перезагрузку путем включения и выключения питания неисправного элемента путем входа в интерфейс APC и отправки команды выключения / перезагрузки на подключенных разъемах блока питания (я получаю два, чтобы избежать одной точки отказа),