Назад | Перейти на главную страницу

Corosync HA предотвращает сценарий разделения мозга

Я настраиваю тестовую систему для самообучения по балансировке нагрузки и высокой доступности, и мне интересно узнать о параметрах конфигурации в Corosync, и я хотел бы знать, что вы, ребята, имеющие в этом опыт, можете сказать.

То, что я сейчас исследую и изучаю, - это кворум голосования Corosync и способы работы с упавшими узлами. Во время небольшого сеанса исследования я обнаружил разговоры о STONITH и сценариях с разделенным мозгом, где оба узла будут считать себя единственным выжившим и думают, что он является хозяином, пытается остаться хозяином и т. Д. Это, конечно, нежелательный сценарий.

В конфигурации Corosync я увидел конкретную конфигурацию:

quorum {
        ...
        auto_tie_breaker: 1
        auto_tie_breaker_node: lowest
}

Может ли auto_tie_breaker предотвратить такой сценарий разделения мозга, или я ошибаюсь?

Если я правильно понял документацию, установка ее на самый низкий означает, что узел с наименьшим nodeid будет ответственным?

nodelist {
          node {
          ring0_addr: primary_private_ip
          name: primary
          nodeid: 1
          }

          node {
          ring0_addr: secondary_private_ip
          name: secondary
          nodeid: 2
          }
}

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

Спасибо за вклад и руководство и удачного дня! :)

Вы правы в предположении, что auto_tie_breaker попытается устранить сбой узла в конфигурациях четных узлов (1/1, 1/1/1/1 и т. д.), «заставляя» кластер оставаться подключенным к правильному набору узлов (или одному узлу в двухузловых кластерах ).

Общее поведение votequorum допускает одновременный отказ узла до 50% - 1 узел, предполагая, что каждый узел имеет 1 голос.

Когда включен ATB, в кластере могут одновременно выходить из строя до 50% узлов детерминированным образом. По умолчанию раздел кластера или набор узлов, которые все еще находятся в контакте с узлом, имеющим наименьший идентификатор узла, сохранят кворум. Остальные узлы будут без текста. Это поведение можно изменить, также указав

Голосование кворума для кластеров обычно должно было использоваться либо в сценариях n + 1 узла, либо с two_node параметр, где expected_votes нужно было установить на 2 и аппаратное ограждение / STONITH должен был быть включен.

auto_tie_breaker_node: lowest|highest|<list of node IDs>

По умолчанию используется «самый низкий», «самый высокий» аналогичен тому, что если текущий набор узлов содержит наивысший идентификатор узла, то он останется с квотой. В качестве альтернативы можно указать конкретный идентификатор узла или список идентификаторов узлов, которые потребуются для поддержания кворума. Если дан список (разделенный пробелами), узлы оцениваются по порядку, поэтому, если первый узел присутствует, он будет использоваться для определения раздела квотирования, если этот узел не находится ни в одной из половин (т. Е. Не был в кластер перед разделением), тогда будет проверяться второй идентификатор узла и так далее. ATB несовместим с устройствами кворума - если auto_tie_breaker указан в corosync.conf, устройство кворума будет отключено.

Помните: нет STONITH устройство, и вы не можете использовать его с two_node директива.

two_node: 1

Включает операции кластера с двумя узлами (по умолчанию: 0).

«Двухузловой кластер» - это вариант использования, требующий особого рассмотрения. В стандартном кластере с двумя узлами, каждый узел с одним голосом, в кластере 2 голоса. Используя простой расчет большинства (50% голосов + 1) для расчета кворума, кворум будет 2. Это означает, что оба узла всегда должны быть активными, чтобы кластер мог кворумировать и работать.

При включении two_node: 1 кворум устанавливается искусственно на 1

Таким образом, новый метод перехода к кластерам даже без аппаратного ограждения или STONITH - это auto_tie_breaker.

В кластерах n + 1 голосование кворума по-прежнему достаточно надежно, но для высокопрофессиональной высокой доступности linux аппаратное ограждение / STONITH должно оставаться главным.

Как всегда, обязательно протестируйте все возможные сценарии, такие как сбой сети, отказ оборудования, потеря питания, одновременная ошибка ресурса, ошибки DRBD (если используются) и т. Д. И прочтите этот документ о «новых» функциях corosync.