В статье нет ни слова про RW-ФС, все решения тестировались исключительно в блочном режиме.
Классический LVM действительно умеет делать снапшоты, но они достаточно сильно влияют на производительность оригинального тома. По этой причине эта же возможность намеренно выпилена некоторыми вендорами в их софте.
Например Proxmox и LINSTOR не позволяют делать снапшоты на классическом LVM.
Я использую три раскладки: английскую, русскую и чешскую. Первые две переключаю по капслоку, постоянно.
А вот с чешской раскладкой всё немного сложнее. По умолчанию она как стандартная QWERTZ, но с дополнительным рядом букв вместо цифр.
Добавлять ещё одну раскладку в систему и переключать мне очень не хотелось. Поэтому решил замапить чешские символы на английскую раскладку. Таким образом Caps Lock стал для меня своего рода вторым шифтом для ввода чешских символов:
Есть, дажепарочка, правда они уже несколько устарели.
На самом деле я бы советовал обратиться к официальной документации LINSTOR. Там всё более-менее понятно расписано.
Я бы согласился работать по 10 часов в день вместо 8 ради четырёхдневной рабочей недели, но не согласился бы сокращать своё рабочее время, так как его и так всегда не хватает.
Ну а вообще лучше сразу установить 28-часовой день:
Так всё же опционально, опция allow-two-primaries по умолчанию не включена и не позволяет делать больше одного мастера в DRBD-кластере.
Тут ещё интереснее вопрос возникает. Если у нас бездисковый арбитр, то если у нас была авария (питание отключали), то при старте кто победит? Грубо говоря, чья реплика правильная?
Наличие кворума определяет разрешено ресурсу переходить в Primary или нет. Так же при потере кворума, блокируется весь I/O. Таким образом у нас просто не получится завести устройство, до того момента пока не будет восстановлен кворум.
Правильность устройств определяется с помощью DRBD-битмапа. Каждое устройство "помнит" о состоянии каждого. То есть при старте победит тот, кто находится в кворуме и тот кто был в UpToDate на момент инцидента с отключением питания.
Так же полагаю, но не могу быть точно уверен, что так как в нашем случае diskless-реплика потеряет своё состояние, она не сможет проголосовать в кворуме за того или иного кандидата. То есть кластер будет ждать обе diskful-реплики.
Это вы рассказываете, как отрезать гангренозные конечности.
Но ведь вопрос был как решить, а не как предотвратить split brain в условиях двух нод. В целом наличие кворума решает поставленную задачу.
давайте "два мастера" делать.
Мультимастер в DRBD существует всего-лишь для одной простой цели — лайфмиграция, использование опции allow-two-primaries для чего-то ещё на постоянной основе, крайне нерекомендуется даже самим LINBIT.
То есть включать allow-two-primaries и поднимать какой-нибудь OCFS поверх DRBD на двух нодах, как в большинстве статей на хабре — это ужасный антипатерн и так делать никогда не надо :)
Появление третьей ноды радикально решает проблему, но… На трёх нодах уже становится интересным поднять (условный) ceph и не мучать бабушку.
Вы немного застряли в прошлом, когда было принято делать одно большое DRBD-устройство и его нарезать на части, а так же холить и лелеять его.
С девятой версии DRBD поменял курс на "по отдельному DRBD-устройству на виртуалку", стал поддердживать diskless-реплики, появился оркестратор и в целом мазать его по большому кластеру стало намного проще и удобнее.
Считаю что выбирать технологию нужно исходя от задачи. Да, Ceph простой, но медленный, а также за него приходится много платить вычислительными ресурсами.
У DRBD есть несколько киллер-фич:
Во первых это сравнительно дешёвая производительность. В отличие от аналогов он реально быстрый и почти не потребляет ресурсов.
Дата-локалити. То есть мы можем запускать рабочую нагрузку там же где и хранятся данные, получая ещё большую производительность.
А отказ отдельных устройств или всей плоскости управления не приводит к отказу всей системы.
Дополнительные фичи вроде шифрования, снапшотов и дедупликации добавляются с использованием уже существующих технологий: LUKS, ZFS/LVM, VDO
К сожалению за всё это приходится платить удобством использования (обновлять модуль ядра на большом количестве нод - это то ещё удовольствие) и невозможностью создать блочное устройство размером большим чем пул хранения на одной ноде.
Для начала определим что такое split-brain. Каждая реплика может быть как connected так и disconnected по отношению к другой. Если реплика самопроизвольно переходит в StandAlone. Значит что она отказывается принимать состояние и синхронизироваться с другой. Это классический split-brain.
Решение split-brain для двух реплик производится точно так же, как и в случае с несколькими репликами.
Для начала определим с какой реплики мы хотим синхронизироваться. Для этого смотрим в
drbdadm status <res>
Если нужная нам реплика находится в состоянии StandAlone или Outdated/Inconsistent её нужно сначала перевести в UpToDate, для этого заходим на ноду с этой репликой и выполняем:
А для того чтобы заставить остальные реплики забыть о своём состоянии и синхронизировать данные с UpToDate-реплик, логинимся на ноду с ними и выполняем:
Стоит признать что в последних версиях LINSTOR включена по умолчанию функция auto-tiebreaker, которая при создании ресурса в двух репликах автоматически добавляет третью diskless-реплику, которая является своего рода арбитром для поддержания кворума. Таким образом решать split-brain в наши дни приходится всё реже.
Metal3 использует под капотом ironic. Что прикольно: IP адреса и ноды выделяются кластерам полностью в динамическом режиме. С другой стороны там по прежнему имеется процесс установки ОС на хост и, на мой взгляд, несколько переусложнённая логика. Чтобы разобраться и настроить всё это вам потребуется протратить не один день.
Спасибо за замечание, версии ZFS и LVM добавил в статью.
По поводу recordsize: изменялся параметр volblocksize, результаты и обсуждение здесь:
https://t.me/sds_ru/52676
del
LINSTOR позволяет делать это. Мы на каждый сетап генерим три StorageClass: linstor-r1, linstor-r2 и linstor-r3 (по количеству реплик)
Если приложению не нужна репликация на уровне стораджа можно использовать r1. А linstor-scheduler всегда отправит под на нужную ноду.
Проект OpenEBS использовал Longhorn в качестве основного бэкенда пока не появился cStor, который заимствовал код у ZFS и запускал его в user-space.
Судя по отзывам оба решения были достаточно медленными и Mayastor должен был решить все проблемы. По этой причине тестировался только он.
Нет, но было очень интересно посмотреть на результаты.
В статье нет ни слова про RW-ФС, все решения тестировались исключительно в блочном режиме.
Классический LVM действительно умеет делать снапшоты, но они достаточно сильно влияют на производительность оригинального тома. По этой причине эта же возможность намеренно выпилена некоторыми вендорами в их софте.
Например Proxmox и LINSTOR не позволяют делать снапшоты на классическом LVM.
Разумеется тесты проводились неоднократно, во всех случаях результаты были достаточно схожи.
Отлично, куда слать пулреквесты? 😃
Неплохая идея!
Скажите, а вы как-то решили проблему словарей? Ведь проверка правописания, как правило, работает только для одной раскладки - текущей.
Я использую три раскладки: английскую, русскую и чешскую.
Первые две переключаю по капслоку, постоянно.
А вот с чешской раскладкой всё немного сложнее. По умолчанию она как стандартная QWERTZ, но с дополнительным рядом букв вместо цифр.
Добавлять ещё одну раскладку в систему и переключать мне очень не хотелось. Поэтому решил замапить чешские символы на английскую раскладку. Таким образом Caps Lock стал для меня своего рода вторым шифтом для ввода чешских символов:
https://github.com/kvaps/dotfiles/blob/24b6407e90aedd1a762c98485d95a2fd981b94b2/skhd/.config/skhd/skhdrc#L8-L38
Есть, даже парочка, правда они уже несколько устарели.
На самом деле я бы советовал обратиться к официальной документации LINSTOR. Там всё более-менее понятно расписано.
Надёжность я воспринял by default, мы же сетевой сторадж выбираем :)
Я бы согласился работать по 10 часов в день вместо 8 ради четырёхдневной рабочей недели, но не согласился бы сокращать своё рабочее время, так как его и так всегда не хватает.
Ну а вообще лучше сразу установить 28-часовой день:
Так всё же опционально, опция
allow-two-primariesпо умолчанию не включена и не позволяет делать больше одного мастера в DRBD-кластере.Наличие кворума определяет разрешено ресурсу переходить в
Primaryили нет. Так же при потере кворума, блокируется весь I/O. Таким образом у нас просто не получится завести устройство, до того момента пока не будет восстановлен кворум.Правильность устройств определяется с помощью DRBD-битмапа. Каждое устройство "помнит" о состоянии каждого. То есть при старте победит тот, кто находится в кворуме и тот кто был в
UpToDateна момент инцидента с отключением питания.Так же полагаю, но не могу быть точно уверен, что так как в нашем случае diskless-реплика потеряет своё состояние, она не сможет проголосовать в кворуме за того или иного кандидата. То есть кластер будет ждать обе diskful-реплики.
del
Но ведь вопрос был как решить, а не как предотвратить split brain в условиях двух нод. В целом наличие кворума решает поставленную задачу.
Мультимастер в DRBD существует всего-лишь для одной простой цели — лайфмиграция, использование опции
allow-two-primariesдля чего-то ещё на постоянной основе, крайне нерекомендуется даже самим LINBIT.То есть включать
allow-two-primariesи поднимать какой-нибудь OCFS поверх DRBD на двух нодах, как в большинстве статей на хабре — это ужасный антипатерн и так делать никогда не надо :)Вы немного застряли в прошлом, когда было принято делать одно большое DRBD-устройство и его нарезать на части, а так же холить и лелеять его.
С девятой версии DRBD поменял курс на "по отдельному DRBD-устройству на виртуалку", стал поддердживать diskless-реплики, появился оркестратор и в целом мазать его по большому кластеру стало намного проще и удобнее.
Считаю что выбирать технологию нужно исходя от задачи. Да, Ceph простой, но медленный, а также за него приходится много платить вычислительными ресурсами.
У DRBD есть несколько киллер-фич:
Во первых это сравнительно дешёвая производительность. В отличие от аналогов он реально быстрый и почти не потребляет ресурсов.
Дата-локалити. То есть мы можем запускать рабочую нагрузку там же где и хранятся данные, получая ещё большую производительность.
А отказ отдельных устройств или всей плоскости управления не приводит к отказу всей системы.
Дополнительные фичи вроде шифрования, снапшотов и дедупликации добавляются с использованием уже существующих технологий: LUKS, ZFS/LVM, VDO
К сожалению за всё это приходится платить удобством использования (обновлять модуль ядра на большом количестве нод - это то ещё удовольствие) и невозможностью создать блочное устройство размером большим чем пул хранения на одной ноде.
Для начала определим что такое split-brain. Каждая реплика может быть как connected так и disconnected по отношению к другой. Если реплика самопроизвольно переходит в StandAlone. Значит что она отказывается принимать состояние и синхронизироваться с другой. Это классический split-brain.
Решение split-brain для двух реплик производится точно так же, как и в случае с несколькими репликами.
Для начала определим с какой реплики мы хотим синхронизироваться. Для этого смотрим в
Если нужная нам реплика находится в состоянии StandAlone или Outdated/Inconsistent её нужно сначала перевести в UpToDate, для этого заходим на ноду с этой репликой и выполняем:
А для того чтобы заставить остальные реплики забыть о своём состоянии и синхронизировать данные с UpToDate-реплик, логинимся на ноду с ними и выполняем:
Стоит признать что в последних версиях LINSTOR включена по умолчанию функция auto-tiebreaker, которая при создании ресурса в двух репликах автоматически добавляет третью diskless-реплику, которая является своего рода арбитром для поддержания кворума. Таким образом решать split-brain в наши дни приходится всё реже.
Хабр уже не торт
Спасибо за отзыв!
Metal3 использует под капотом ironic. Что прикольно: IP адреса и ноды выделяются кластерам полностью в динамическом режиме. С другой стороны там по прежнему имеется процесс установки ОС на хост и, на мой взгляд, несколько переусложнённая логика. Чтобы разобраться и настроить всё это вам потребуется протратить не один день.