Я хотел бы настроить двухузловой кластер высокой доступности с помощью corosync / pacemaker / drbd. Для этого, конечно, понадобится фехтование. Насколько я понимаю, все решения IPMI / iLO / ... выполняют свою работу, но только до тех пор, пока на шасси подается питание. В случае, если узел B теряет питание, узел A не имеет никаких шансов использовать STONITH против узла B.
Какое оборудование решает эту проблему? Существует ли (стандартная стойка) сервер, который обеспечивает работу оборудования IPMI / iLO / ... от батареи? Следует ли мне использовать ИБП, подключенный к сети?
Насколько мне известно, для этого нет стандартного аппаратного (или программного) решения.
Вы не можете выстрелить в другой узел в голове, если его там нет.
Вы можете справиться с этим несколькими способами. Я могу предложить один из них: Умный PDU - В крайнем случае, когда никакая другая техника STONITH не работает, подайте команду на его выходы питания «выключить», и вам не нужно беспокоиться о том, что он вернется, пока кто-нибудь снова не даст команду «включить» питание. (На самом деле это всего лишь гарантия от случайного выдергивания силовых кабелей ...)
Аналогичное решение можно также реализовать с помощью управляемых коммутаторов, отключающих порты, к которым подключен компьютер, или перетаскивания их в «фиксирующую» VLAN, чтобы вы могли подключиться к блоку и подготовить его для повторного присоединения к кластеру.
Обе приведенные выше идеи полагаются на то, что ваши центры обработки данных подключены к питанию (PDU, коммутатор и т. Д. Должны работать, и необходимо наличие подключения, чтобы вы могли отправлять команды инфраструктурному оборудованию).
Если вы не можете полагаться на мощность, классическое решение - это настройка серверов. НЕ для автоматического включения после сбоя питания (IPMI / iLO / и т. д. все равно появится, когда шасси подключено к питанию, поэтому вы можете вызвать его позже как шаг вручную, возможно, после изоляции сетевых портов, как описано выше).
Это позволяет избежать возврата «плохого» узла в оперативный режим, но добавляет к процессу ручной (или автоматический) шаг.
Если ваша проблема связана с подключением, а не с питанием, у вас гораздо более серьезная проблема - отключенные узлы должны стрелять самих себя в голове. (Эта проблема заключается в том, почему мои конфигурации кластера не активируют автоматически отказавший член: когда ящик выходит из строя и возвращается, он находится в частично подключенном состоянии и ждет, когда я скажу ему, чтобы он снова присоединился. Это ручной шаг, но это один это не должно происходить с какой-либо частотой.)
Вы можете настроить ограждение на основе iLO / IPMI, а затем использовать, например, агент ограждения забор_apc с переключателем питания APC в качестве вторичного устройства ограждения. Таким образом, если сервер теряет мощность, то вторичный агент ограждения все еще может STONITH сервером способом, который имеет смысл для кластера.
как описано Вот:
Узел может иметь несколько методов ограждения, и каждый метод ограждения может иметь несколько устройств ограждения.
Для резервирования / страхования установлены несколько методов ограждения. Например, вы можете использовать метод ограждения управления основной платой для узла в вашем кластере, такой как IPMI, или iLO, или RSA, или DRAC. Все это зависит от сетевого подключения. Если это соединение не удастся, ограждение не может произойти, поэтому в качестве резервного метода ограждения вы можете объявить второй метод ограждения, который использует выключатель питания или что-то вроде ограждения узла. Если первый метод не смог защитить узел, будет использован второй метод ограждения.
Вы также можете рассмотреть возможность добавления забор_мануал как вторичный fencing agent, таким образом вы всегда сможете восстановить свой кластер, но тогда, конечно, потребуется ручное вмешательство.