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