Я тестирую двухузловой кластер и тестирую различные сценарии разделения мозга.
Все работает нормально, ресурсы делают то, что я ожидал, за исключением того, что меня интересует время в конкретном случае.
Я бегу с
auto_tie_breaker: 1
auto_tie_breaker_node: lowest
в моем случае самым низким будет узел 1.
В случае, когда ресурсы находятся на узле 1, и я вызываю сценарий разделения мозга, все кажется прекрасным.
Однако, когда ресурсы находятся на узле 2, и я вызываю разделение мозга, ресурсы отключаются на узле 2 и запускаются на узле 1, что имеет смысл.
Но меня интересует время. Каков механизм теперь, когда два узла не могут взаимодействовать друг с другом, который гарантирует, что ресурс на узле 1 запускается после отключения ресурса на узле 2?
Я могу представить себе, что засыпаю в сценарии запуска для ресурса, но мне было интересно, есть ли официально одобренный способ справиться с этим временем?
Или, возможно, я ошибаюсь. Возможно, мне следует использовать какую-то липкость. Указание узлам продолжать то, что они делали, при обнаружении состояния расщепления мозга. Другими словами, на обнаруженном расщепленном мозге ничего не меняется.
tl; dr - получите третий голос за свой кластер через corosync-qdevice
Проблема с OP (я являюсь автором OP) заключается в довольно большом количестве деталей, которые не содержатся в исходном вопросе.
После еще пары дней тестирования и чтения мне стало ясно, что существует множество неправильных способов построения двухузлового кластера высокой доступности, описанных в Интернете.
Должно быть довольно легко понять проблему с моим первым вопросом, касающимся остановки службы на одном узле и запуска ее на другом. По определению узлы находятся в ситуации разделения мозга и не могут знать состояние другого, поэтому никакие задержки или ожидания не исправят ситуацию с высокой степенью надежности. Кроме того, как только кластер находится в режиме разделения мозга, узел 2 думает, что служба запускается только на узле 1. Он не знает, есть ли это. Таким образом, когда узел 2 отключается, служба может быть недоступна.
Второй пункт заканчивается предположением, что, возможно, будет работать какая-то система токенов. Другими словами, ничего не делать. Он работает менее чем оптимально, потому что, если система с токеном умирает, возникает разделение мозга, и совершенно хороший резервный сервер бездействует, потому что он предпочитает ничего не делать.
В конце концов я остановился на стороннем устройстве кворума, которое лишь немного отличается от кластера с 3 узлами или кластера с нечетным номером. Я использовал corosync-qdevice и corosync-qnetd.
Теперь у меня есть третий голос в моем кластере из двух узлов. Он решает проблемы разделения мозга, упомянутые в моем OP, и устраняет все невозможные для решения двухузловые граничные случаи.
Остается STONITH, могучий молот, которым владеют все боги кластера. Если бы мне нужно было построить кластер с нуля, я бы использовал STONITH в дополнение к блокировке ресурсов.
Однако я унаследовал этот конкретный кластер, и он находится на общем оборудовании, и хотя у него есть IPMI и другие полезности, мне не разрешено отключать питание.
Что касается виртуального STONITH, я не уверен, что это действительно отличается от блокировки ресурсов, но это должен быть другой вопрос.
Итак, если вы здесь, пытаясь настроить двухузловой кластер высокой доступности с ограничением ресурсов, прочитайте статью о corosync-qdevice и добавьте третий голос в свой кластер.
В идеале вы должны настроить и включить устройства STONITH для использования с кардиостимулятором. В противном случае нет гарантии, что службы фактически остановятся на узле 2 до того, как узел 1 попытается взять на себя управление. Спящий режим / задержка может дать службе дополнительное время для остановки, но если она не может остановиться по какой-либо причине, узел 1 все равно попытается взять на себя управление службами.
Устройства STONITH настроены на использование внеполосного канала связи для принудительного удаления не отвечающего или отключенного однорангового узла из кластера (обычно путем его отключения).
После того, как вы внедрили STONITH в кластер Pacemaker, вы устранили почти все случаи, когда вы могли остаться с зависшим / разделенным кластером.