Комментарии 14
В двух словах, а как split brain решается в условиях двух нод?
Для начала определим что такое split-brain. Каждая реплика может быть как connected так и disconnected по отношению к другой. Если реплика самопроизвольно переходит в StandAlone. Значит что она отказывается принимать состояние и синхронизироваться с другой. Это классический split-brain.
Решение split-brain для двух реплик производится точно так же, как и в случае с несколькими репликами.
Для начала определим с какой реплики мы хотим синхронизироваться. Для этого смотрим в
drbdadm status <res>Если нужная нам реплика находится в состоянии StandAlone или Outdated/Inconsistent её нужно сначала перевести в UpToDate, для этого заходим на ноду с этой репликой и выполняем:
drbdadm primary --force <res>
drbdadm secondary <res>А для того чтобы заставить остальные реплики забыть о своём состоянии и синхронизировать данные с UpToDate-реплик, логинимся на ноду с ними и выполняем:
drbdadm disconnect <res>
drbdadm connect <res> --discard-my-dataСтоит признать что в последних версиях LINSTOR включена по умолчанию функция auto-tiebreaker, которая при создании ресурса в двух репликах автоматически добавляет третью diskless-реплику, которая является своего рода арбитром для поддержания кворума. Таким образом решать split-brain в наши дни приходится всё реже.
Это вы рассказываете, как отрезать гангренозные конечности.
Мой вопрос был, как вы живёте со split brain. Ответ: отрезая всё, что испортится. Лично мне, и по опыту работы в drbd, и по опыту работы с более устойчивыми решениями, дико представлять себе СХД, которая может принять операцию записи, будучи в неконсистентом состоянии. В тот момент, когда вы отрезаете split brain, вы нарушаете гарантии целостности у базы данных, которая на этой конструкции лежит. База данных думала, что она обновила журнал, но на самом деле ей не повезло, и её ответ ушёл на ноду, которая потом обнаружила себя в disconnected состоянии и ей пришлось сделать discard-my-data. Вместе с журналом от базы данных. После чего база данных из вершины консистентности превращается в обычную овсянку. Липкая, бесформенная, и точно не являющаяся базой данных.
Сама идея DRBD "давайте сделаем две равноправные копии" наткнулась на простой факт: для двух копий единственный метод сделать partitioning tolerance - это умирать при отваливании соседней головы. Достойный метод, кстати (т.к. данные в двух копиях), но жадность сгубила - давайте "два мастера" делать. Получается, что партиционирование в полный рост и единственный выход из него - нарушение консистентности (`--discard-someones-data`).
Появление третьей ноды радикально решает проблему, но... На трёх нодах уже становится интересным поднять (условный) ceph и не мучать бабушку.
TL;DR; Негодная технология. Закапывайте.
Это вы рассказываете, как отрезать гангренозные конечности.
Но ведь вопрос был как решить, а не как предотвратить split brain в условиях двух нод. В целом наличие кворума решает поставленную задачу.
давайте "два мастера" делать.
Мультимастер в DRBD существует всего-лишь для одной простой цели — лайфмиграция, использование опции allow-two-primaries для чего-то ещё на постоянной основе, крайне нерекомендуется даже самим LINBIT.
То есть включать allow-two-primaries и поднимать какой-нибудь OCFS поверх DRBD на двух нодах, как в большинстве статей на хабре — это ужасный антипатерн и так делать никогда не надо :)
Появление третьей ноды радикально решает проблему, но… На трёх нодах уже становится интересным поднять (условный) ceph и не мучать бабушку.
Вы немного застряли в прошлом, когда было принято делать одно большое DRBD-устройство и его нарезать на части, а так же холить и лелеять его.
С девятой версии DRBD поменял курс на "по отдельному DRBD-устройству на виртуалку", стал поддердживать diskless-реплики, появился оркестратор и в целом мазать его по большому кластеру стало намного проще и удобнее.
Я рад, что они задумались о кворуме, но сам факт существования состояния в СХД, когда есть две активные копии... Даже в контексте миграции. Вот у нас VISA'вская база переезжала. Там постоянно транзакции. Очень важные транзакции. Сделали вы master-master на время переезда, и вот виза записала транзакцию №665 на устройство 1, в момент переключения активной головы, записала транзакцию №666 на устройство 2, и тут миграция обломилась по независящим от нас причинам.
Что мы будем дискардить? Транзакцию № 666 или транзакцию № 665? Сама постановка вопроса делает базу данных не базой данных.
Тут ещё интереснее вопрос возникает. Если у нас бездисковый арбитр, то если у нас была авария (питание отключали), то при старте кто победит? Грубо говоря, чья реплика правильная?
В таких условиях, условный ceph, например, просто не будет работать. Осталась одна копия данных? Всё, остановка в обслуживании. Данные важнее, чем сиюминутность их доступности. Для надёжного хранения нам надо кворум мониторов (хотя бы два монитора из трёх, которые договорились о том, кто главный) и хотя бы два хранилища, способные подчиняться мониторам, чтобы в случае разногласий при старте с третьим хранилищем, разобраться, чьи данные правильнее.
сделали вы master-master на время переезда
Так всё же опционально, опция allow-two-primaries по умолчанию не включена и не позволяет делать больше одного мастера в DRBD-кластере.
Тут ещё интереснее вопрос возникает. Если у нас бездисковый арбитр, то если у нас была авария (питание отключали), то при старте кто победит? Грубо говоря, чья реплика правильная?
Наличие кворума определяет разрешено ресурсу переходить в Primary или нет. Так же при потере кворума, блокируется весь I/O. Таким образом у нас просто не получится завести устройство, до того момента пока не будет восстановлен кворум.
Правильность устройств определяется с помощью DRBD-битмапа. Каждое устройство "помнит" о состоянии каждого. То есть при старте победит тот, кто находится в кворуме и тот кто был в UpToDate на момент инцидента с отключением питания.
Так же полагаю, но не могу быть точно уверен, что так как в нашем случае diskless-реплика потеряет своё состояние, она не сможет проголосовать в кворуме за того или иного кандидата. То есть кластер будет ждать обе diskful-реплики.
Честно говоря DRBD так себе инструмент. Я пытался поднять кластер на этой штуке несколько раз, но тщетно. Перерыл кучу доков в том числе от Рэдхата. Друг посоветовал ceph, а точнее коробочное решение PetaSAN. Все поставилось без проблем. Ноды, вольюмы и прочее добавляются на лету. Дальнейшего смысла в использовании DRBD не вижу.
Считаю что выбирать технологию нужно исходя от задачи. Да, Ceph простой, но медленный, а также за него приходится много платить вычислительными ресурсами.
У DRBD есть несколько киллер-фич:
Во первых это сравнительно дешёвая производительность. В отличие от аналогов он реально быстрый и почти не потребляет ресурсов.
Дата-локалити. То есть мы можем запускать рабочую нагрузку там же где и хранятся данные, получая ещё большую производительность.
А отказ отдельных устройств или всей плоскости управления не приводит к отказу всей системы.
Дополнительные фичи вроде шифрования, снапшотов и дедупликации добавляются с использованием уже существующих технологий: LUKS, ZFS/LVM, VDO
К сожалению за всё это приходится платить удобством использования (обновлять модуль ядра на большом количестве нод - это то ещё удовольствие) и невозможностью создать блочное устройство размером большим чем пул хранения на одной ноде.
Кому нужна дешёвая производительность, просто набивают сервер NVME'шками без рейда, и имеют самую большую производительность, какую могут.
Дальше у людей, обычно, запрос на надёжность.
может у вас есть рабочий пошаговый мануал по развертыванию простейшего DRBD кластера?
Есть, даже парочка, правда они уже несколько устарели.
На самом деле я бы советовал обратиться к официальной документации LINSTOR. Там всё более-менее понятно расписано.
del
Траблшутинг DRBD9 в LINSTOR