Может ли веб-сервер определить, является ли он активным узлом системы аварийного переключения HA без жесткого кодирования чего-либо на самом сервере?

Question

Я могу вспомнить несколько хаков с использованием ping, имени ящика и общего имени HA, но я думаю, что они приводят к утечке данных.

Должен ли ящик даже знать свою часть кластера высокой доступности или как называется это кластерное имя? Это больше функция DNS? Существует ли какой-либо API для ящиков для присоединения к кластеру HA и запроса идентификатора текущего активного узла?

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

ЛЕГКО РЕШЕНИЕ: опрос сервер от внешнего агента, который подключается через сеть делает любую оболочку игры, кто является активным узлом спорным вопроса. Чтобы прояснить это, единственное, что будет отображаться на странице, - это удаленный агент, отслеживающий реальное. Каждая коробка может отправлять электронные письма в течение всего дня, несмотря на все мои заботы.

Answer 1

Это действительно зависит от системы HA, которую вы используете.

Например, если ваша система использует общий IP-адрес, а трафик управляется некоторым аппаратным блоком, тогда может быть трудно определить, является ли определенный блок ведущим или ведомым. Это будет зависеть от конкретного решения ... Пока вы можете добавить собственный скрипт в супервизор, у вас все будет в порядке - например, контроллер может пинговать демон на главном сервере каждую секунду. В сценарии оповещения просто проверьте, является ли время последнего пинга <2 сек ... </p>

Если в вашей системе нет узла супервизора / контроллера, но каждый узел пытается определить состояние самостоятельно, у вас могут возникнуть дополнительные проблемы. Если происходит разделение мозга, вы можете в конечном итоге использовать оба ведомых или обоих мастеров, поэтому ваше программное обеспечение для оповещения будет неверным в обоих случаях. Гаджеты, которые могут обеспечить только один действующий узел (STONITH и другие), могут помочь.

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

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

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

Я не уверен, почему вы упомянули DNS - из-за его времени обновления он не должен быть источником какой-либо информации о кластере «в реальном времени».

Answer 2

без жесткого кодирования ....? Я предполагаю, что вы имеете в виду какой-то родной запрос сердцебиения, не уверен. Однако вы можете использовать ifconfig, HA создает виртуальный интерфейс на любом интерфейсе, на котором он настроен для работы. Например, если HA настроен на eth0, он создаст виртуальный интерфейс eth0: 0, но только на активном узле.

Поэтому вы можете выполнить простой запрос вывода ifconfig, чтобы определить, является ли сервер активным узлом или нет, например, является ли eth0 настроенным интерфейсом:

ACTIVE_NODE=`ifconfig | grep -c 'eth0:0'`

При этом для переменной $ ACTIVE_NODE будет установлено значение 1 (для активного) и 0 (в режиме ожидания). Надеюсь, что это может помочь.

http://www.of -networks.co.uk

Answer 3

Как правило, машины в кластере высокой доступности не должны знать, какая из них активна. Есть одно исключение, ум, и это с cronjobs. На работе у нас есть кластер высокой доступности, поверх которого работают некоторые довольно важные сервисы. У некоторых из этих сервисов есть cronjobs, и мы хотим, чтобы они работали только на активной коробке. Для этого мы используем этот скрипт:

#!/bin/sh
HA_CLUSTER_IP=0.0.0.0
if ip addr | grep $HA_CLUSTER_IP >/dev/null; then
    eval "$@"
fi

(Обратите внимание, что это работает в Debian.) Что он делает, проверяет, является ли текущий блок активным в кластере (замените 0.0.0.0 на внешний IP вашего кластера высокой доступности), и если это так, выполняет команду, переданную в качестве аргументов скрипту. Это гарантирует, что один и только один ящик действительно выполняет cronjobs.

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

ОБНОВЛЕНИЕ: Наш кластер высокой доступности использует Пульс , чтобы назначить внешний IP-адрес кластера в качестве вторичного адреса для активного компьютера в кластере. Программно вы можете проверить, является ли ваша машина текущим активным ящиком, вызвав gethostbyname() и перебирая возвращаемые данные, пока вы не доберетесь до конца или не найдете IP-адрес кластера в списке.

Answer 4

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

Другой вариант - отслеживать активную систему с помощью псевдонима DNS (или каким-либо другим способом обращения к активной системе) и просматривать страницу об этом. Затем также отслеживайте все системы, как активные, так и неактивные, и отправляйте по электронной почте сообщения об этом. Это приведет к дублированию предупреждений для активной системы, но это, вероятно, нормально.

Трудно быть более конкретным, не зная больше о вашей настройке.