Узел думает, что он в сети, когда его сетевой кабель отключен. Кардиостимулятор/Коросинк

Я пытаюсь объединить 2 компьютера вместе с Pacemaker/Corosync. Единственный общий ресурс — это ocf:heartbeat:IPaddr, в этом основная проблема:

Поскольку есть только два узла, отработка отказа произойдет только в том случае, если no-quorum-policy=ignore.

Когда сетевой кабель вытягивается из узла A, corosync на узле A привязывается к 127.0.0.1, и кардиостимулятор считает, что узел A все еще находится в сети, а узел B находится в автономном режиме.

Pacemaker пытается запустить IPaddr на узле A, но ему не удается запуститься из-за отсутствия сетевого подключения. Узел B, с другой стороны, распознает, что узел B находится в автономном режиме, и если служба IPaddr была запущена на узле A, он успешно запустит ее на себе (узле B).

Однако, поскольку сервису не удалось запуститься на узле A, он переходит в неустранимое состояние и должен быть перезагружен для повторного присоединения к кластеру. (вместо этого вы можете перезапустить некоторые из необходимых служб.)

1 обходной путь — это набор start-failure-is-fatal="false", который заставляет узел A продолжать попытки запустить службу IPaddr до тех пор, пока это не будет успешным. проблема заключается в том, что после успешного завершения у вас возникает конфликт IP-адресов между двумя узлами до тех пор, пока они не объединятся в кластер и один из них не откажется от ресурса.

Я играю с идеей иметь атрибут узла, который отражает cat /sys/class/net/eth0/carrier, который равен 1, когда кабель подключен, и ноль, когда он отключен, а затем иметь правило местоположения, которое говорит, что если «подключен» == ноль, не запускайте вид службы вещь, но мы увидим.

Любые мысли или идеи будут очень признательны.


person andrewmkeller    schedule 27.11.2013    source источник


Ответы (2)


После разговора с Эндрю Бекхофом (автором Pacemaker) и Digimer в irc-сети freenote.net/#linux-cluster я узнал, что фактическая причина этой проблемы заключается в неправильном ограждении кластера.

Ограждение или включение stonith абсолютно необходимы для успешного кластера высокой доступности. Следующая страница обязательна к прочтению по этому вопросу:

Учебное пособие по работе с кластерами: концепция — ограждение

Большое спасибо Digimer за предоставление этого бесценного ресурса. Раздел о кластеризации отвечает на этот вопрос, однако вся статья полезна.

В основном фехтование и S.T.O.N.I.T.H. (Выстрелите другому узлу в голову) — это механизмы, которые кластер использует, чтобы убедиться, что неработающий узел действительно мертв. Это необходимо сделать, чтобы избежать повреждения разделяемой памяти, состояния разделенного мозга (несколько узлов, использующих общие ресурсы), а также убедиться, что ваш кластер не застревает в процессе восстановления или аварийного сбоя.

Если вы не настроили и не включили stonith/fencing в своей кластерной среде, вам это действительно нужно.

Другими проблемами, на которые следует обратить внимание, являются Stonith Deathmatch и петли фехтования.

Короче говоря, проблема потери сетевого подключения, вызывающая расщепление мозга, была решена путем создания нашего собственного устройства Stonith и написания агента stonith в соответствии с руководством /usr/share/doc/cluster-glue/stonith/README.external, а затем написанием запуска. скрипт, который проверяет, поддерживает ли узел поддержку присоединения к кластеру, а затем запускает corosync или ждет 5 минут и снова проверяет.

person andrewmkeller    schedule 01.04.2014

Согласно вашей конфигурации, сердцебиение между двумя узлами будет использовать «127.0.0.1», я думаю, что это совершенно неправильно. Обычно corosync необходимо привязывать к частным IP-адресам, а ресурсный сервис IPaddr должен использовать другой IP-адрес, который называется IP-адресом трафика.

Например:

Узел A: 192.168.1.00 (для пульса); 10.0.0.1 (IP-адрес трафика)

Узел B: 192.168.1.101 (для пульса) ; 10.0.0.2 (IP-адрес трафика)

Если я правильно понимаю, служба ipaddr запустит базу виртуальных IP-адресов на основе IP-адреса трафика, мы предполагаем, что это 10.0.0.3.

person Merlin    schedule 04.12.2013
comment
Настоящей причиной этой проблемы было неправильное ограждение. Подробности размещены ниже. Кроме того, даже если у вас правильно настроен corosync для IP-адреса подключенного сетевого адаптера, если на сетевом адаптере нет активного подключения, corosync будет привязан к IP-адресу локального хоста. - person andrewmkeller; 01.04.2014