Comments 9
Модель DRBD с _двумя_ узлами в кластере с самого начала полна шизофрении и split-brain'а. Как бы с ним не боролись, без кворума никак. А какой кворум у DRBD? Ну… Вот такой вот кворум, из двух, всегда друг с другом согласных узлов.
Под небольшой нагрузкой и с определенной осторожностью — вполне себе работал DRBR 8 с Dual Primary.
Но да — конструкция ненадежная была.
Но да — конструкция ненадежная была.
Разумеется, она работает, когда всё хорошо.
Все кластерные системы надо смотреть не в том, как они работают (happy path), а как они обрабатывают ошибки (sad path). У drbd такой sad path, что он, скорее, bad path по всем признакам.
UPD: И дело не только в primary/primary. Даже модель primary/secondary с автопромоутингом secondary на primary — всё равно шизофренична.
Pacemaker в такой конфигурации не работает даже со STONITH, потому что из-за сетевого сбоя «плохая» нода может прибить хорошую, и нет никакого арбитра понять кто прав, а кто баг.
Все кластерные системы надо смотреть не в том, как они работают (happy path), а как они обрабатывают ошибки (sad path). У drbd такой sad path, что он, скорее, bad path по всем признакам.
UPD: И дело не только в primary/primary. Даже модель primary/secondary с автопромоутингом secondary на primary — всё равно шизофренична.
Pacemaker в такой конфигурации не работает даже со STONITH, потому что из-за сетевого сбоя «плохая» нода может прибить хорошую, и нет никакого арбитра понять кто прав, а кто баг.
Если мне не изменяет память, для STONITH было «замечательное» решение с рандомным таймаутами на убийство второй ноды для решения этой проблемы :)
Рандомный таймаут не решает проблемы, от слова «совсем».
Если у нас происходит partitioning, то для двух нод не существует метода понять, какая половинка «в сети». node1 думает, что она в сети, node2 думает, что она в сети. Не важно кто кого первым прибъёт, т.к. каждая из них может ошибаться, есть 50% шанс, что умрёт не та нода.
Чтобы такого не было, нужен кворум. А кворум требует большинства. Большинство для двух нод — это две ноды, т.е. неудобно. Чтобы было удобно, нужна третья нода — арбитр.
Если у нас происходит partitioning, то для двух нод не существует метода понять, какая половинка «в сети». node1 думает, что она в сети, node2 думает, что она в сети. Не важно кто кого первым прибъёт, т.к. каждая из них может ошибаться, есть 50% шанс, что умрёт не та нода.
Чтобы такого не было, нужен кворум. А кворум требует большинства. Большинство для двух нод — это две ноды, т.е. неудобно. Чтобы было удобно, нужна третья нода — арбитр.
Кворум можно сделать например, на дешёвой VPS'ке. Это будет дешевле, чем решение с тремя стораджами в ряде случаев, нужных для ceph
ceph не требует три стораджа, он требует три монитора. Избыточность данных контролируется уже настройками в процессе. Хочешь — 3, хочешь — 5, хочешь — 2. Или даже 1, как я часто делаю в лабораторных условиях.
А drbd научилась делать кворум с третьим участником?
А drbd научилась делать кворум с третьим участником?
Конечно, о том то и речь, drbd9 уже давно умеет кворум.
По умолчанию он всегда будет принимать решения исходя из большинства нод в кластере.
Но так же есть есть широкие возможности для конфигурации поведения при потере кворума.
Sign up to leave a comment.
Надежное хранилище с DRBD9 и Proxmox (Часть 1: NFS)