Heartbeat: как сделать STOP сервисов на выпавшей ноде?

Для разруливания таких коллизий и используется stonith. Ты его должен настроить так, чтоб вторая нода ЖЕЛЕЗОБЕТОННО опустила первую. Например - выключением питания (просто как пример). А ты уже потом ручками всё будешь разруливать.

в файле ha.cf на обеих нодах прописываешь: auto_failback on

Тогда как ток восстанавливается главная нода - все процессы сново переходят на нее а 2-я нода переходит в слейв

> Тогда как ток восстанавливается главная нода - все процессы сново переходят на нее а 2-я нода переходит в слейв

Ну за это время на второй ноде дрбд поназаписывает данных, которых нет на первой. А на первой-то drbd себя по-прежнему считает primary!

Парень.. почитай пожалуйста сначала что есть drbd.

Ты же делаешь HA кластер?

Слухай... Читай сам и не поднимай своё ЧСВ подобными постами :) Я с ним немного повозился и отказался в пользу внешнего хранилища :) А в описанной выше ситуации я написал что я предпочитаю дабы не огрести проблем. Тот же RHCS например вообще не перекидывает сервисы на вторую ноду пока не загасит первичную.

Вольному - воля

Я так подумал... по-моему просто нужно пользоваться не сетью TCP/IP, да ещё через коммутаторы (у меня именно так), а прямым соединением RS232 через COM-порты, тогда просто не будет ситуаций, когда Slave-ноде кажется, что её Master-нода «упала», а на самом деле Master продолжает работать, пусть даже там и произошло что-то.
Не пробовали сердцебиение через RS232?

Да, и насчёт убожества DRBD полностью согласен и очень сожалею, что у нас нет BSD'шного GEOM GATE.

вендекапец стремительно наступает

> по-моему просто нужно пользоваться не сетью TCP/IP, да ещё через коммутаторы (у меня именно так), а прямым соединением RS232 через COM-порты

А что, COM-порты никогда не ломаются?

>> по-моему просто нужно пользоваться не сетью TCP/IP, да ещё через коммутаторы (у меня именно так), а прямым соединением RS232 через COM-порты

А что, COM-порты никогда не ломаются?

Смысл делать через ком порты? ведь если первая нода отрывается от сети, но работает - вторая нода видя первую - не перехватит процессы.. смысл?

Предполагается, что вероятность полного отваливания сети на самом деле намного ниже, нежели вероятность смерти ноды от неисправности RAID-контроллера или банальных подвисаний модулей ядра (hello, кооперативная многозадачность в 0-м кольце!). Ну и собственно если нода жива и виртуалки на ней крутятся, то правильнее наверное восстановить сеть силами сисадмина, нежели убивать всё на одной ноде и поднимать на второй.

> Смысл делать через ком порты?

Я тоже не вижу смысла. По-моему, выход один - STONITH, он для этого и придуман. Программно-отключаемый UPS, например.

У меня просто подход другой несколько: я считаю, что сбой ноды кластера должен лечить человек, потому что реально никакая автоматика не способна просчитать все варианты, так что реально миграция сервисов с одной ноды кластера на другую нужна только после полного краха ноды, а не просто когда hertbeat, продираясь через стек tcp/ip, вдруг решит, что всё накрылось медным тазом. Да, и нуль-модемное соединение действительно надёжнее ИМХО.

> реально миграция сервисов с одной ноды кластера на другую нужна только после полного краха ноды

Насколько я понимаю, только STONITH обеспечивает полный крах. Без STONITH остается возможность того, что сбоящая нода не совсем мертва, и таки лезет к общим данным.

продираясь через стек tcp/ip, вдруг решит

нуль-модемное соединение действительно надёжнее ИМХО

Ну-ну... впрочем, ты отвечаешь за последствия, тебе и решать.

>>У меня просто подход другой несколько: я считаю, что сбой ноды кластера должен лечить человек, потому что реально никакая автоматика не способна просчитать все варианты, так что реально миграция сервисов с одной ноды кластера на другую нужна только после полного краха ноды, а не просто когда hertbeat, продираясь через стек tcp/ip, вдруг решит, что всё накрылось медным тазом.

Тогда я не врубаюсь нахрена тебе кластер?? 0_о Ведь суть в том, что даже если у тебя за сбоила главная нода - пользователи все-равно должны иметь доступ к файлам и программам установленные на 1-й ноде. А если она сбоит и не хрена не работает и 2-я нода видит первую и тоже ничего не делает - пользователи не имеют доступа к файлам и программам.

Смысл кластер ставить??0_о достаточно тогда обычного фаилсервера. самого премитивного и обычного.

Дело не в том, кластер это или нет, а в том, что те критерии, которые используют heartbeat для определени смерти ноды, в случае с tcp/ip - весьма несовершенны. Я совершенно не хочу, чтобы при пропадании сети на 5 минут у меня все виртуалки обрущивались на вторую ноду, предварительно убиваясь STONITH'ом с вероятным нарушением целостности файловых систем и прочими прелестями. То есть с моей точки зрения миграци сервисов нужна только тогда, когда это не heartbeat считает, что нода умерла, а когда она реально не работает. Для восстановления доступности сервисов мне достаточно получить SMS на телефон или письмо, не вижу ни малейшей необходимости пинать UPS на ноде, где всё работает, но, например, временно отвалился сетевой интерфейс.
Вы вообще представляете себе последствия UPS-опинания в случае с базами данных? Вообще кто сказал, что после рубания топором по мозгам куче виртуалок они все потом на второй ноде нормально поднимутся?

DRBD (от англ. Distributed Replicated Block Device — «Распределённое Копируемое Блочное Устройство») — это блочное устройство, предназначенное для построения отказоустойчивых кластерных систем на операционной системе с ядром Linux. Вопреки распространённому мнению, DRBD не является кластерной файловой системой, и вообще файловой системой.

Позволяет создать общее для кластера зеркальное дисковое пространство, грубо говоря, RAID 1 между накопителями на разных машинах в сети. Когда на одной машине производится запись на диск, DRBD сразу синхронизирует эти данные на дисках других машин. Один из узлов при этом является основным (primary), остальные резервным (secondary), соответственно только один из узлов кластера может работать с таким диском. Начиная с версии 8 DRBD поддерживает режим, когда все узлы являются основными, при этом необходимо использовать специализированную кластерную файловую систему, например GFS, GFS2 или OCFS2, которая позволяет выполнять одновременную запись на нескольких узлах.

Первая ссылка в google по запросу drbd

> с моей точки зрения миграци сервисов нужна только тогда, когда это не heartbeat считает, что нода умерла, а когда она реально не работает. Для восстановления доступности сервисов мне достаточно получить SMS на телефон или письмо

HA с ручным управлением, интересный подход. А тебе вообще Heartbeat нужен в таком случае? Похоже, ты ему категорически не доверяешь.

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

Насчёт DRBD вообще не понял - к чему это, я в курсе, уже надолбался с этой приблудой изрядно!

>все виртуалки с одной ноды переехали на другую

Сори.. что за виртуалки?0_о

Кстати, а почему сетевой интерфейс отваливается при прямом соединении компов кросс-линком, если один комп свой линк теряет? Можно как-то это обойти, сделать сетевой интерфейс перманентным?

Чего не знаю - того не знаю..

Насчёт DRBD вообще не понял - к чему это, я в курсе, уже надолбался с этой приблудой изрядно!

Я совершенно не хочу, чтобы при пропадании сети на 5 минут у меня все виртуалки обрущивались на вторую ноду

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