Обслуживание кластера без потери доступности

Периодически кластер YDB необходимо обслуживать, например, обновлять его версию или заменять сломавшиеся диски. Работы по обслуживанию могут привести к недоступности кластера или имеющихся баз данных из-за:

• Превышения модели отказа затронутых групп хранения.
• Превышения модели отказа State Storage.
• Недостатка вычислительных ресурсов вследствие остановки слишком большого количества динамических узлов.

Для избежания таких ситуаций в YDB есть системная таблетка, которая следит за состоянием кластера — Cluster Management System (CMS). CMS позволяет ответить на вопрос, можно ли безопасно вывести в обслуживание узел YDB или хост, на котором работают узлы YDB. Для этого необходимо создать задачу обслуживания в CMS и указать в ней взятие эксклюзивных блокировок на узлы или хосты, которые будут задействованы в обслуживании. Компоненты кластера, на которые взяты блокировки, считаются недоступными с точки зрения CMS, и их можно безопасно обслуживать. CMS проверит текущее состояние кластера и возьмёт блокировки, только если работы по обслуживанию соответствуют ограничениям режима доступности и лимитам недоступных узлов.

Задача обслуживания

Задача обслуживания представляет собой набор действий, которые пользователь просит выполнить CMS для возможности проведения безопасного обслуживания.

Поддерживаемые действия:

• Взятие эксклюзивной блокировки на компонент кластера (узел или хост).

В задаче действия делятся на группы. Действия из одной группы выполняются атомарно. На данный момент группы могут состоять только из одного действия.

Если в момент запроса действие выполнить нельзя, CMS сообщает причину и время, когда стоит обновить задачу, и переводит действие в состояние ожидания (pending). При обновлении задачи CMS повторно пытается выполнить ожидающие действия.

У выполненных (performed) действий есть дедлайн, после которого они считаются завершёнными (completed) и прекращают оказывать эффект на кластер. Например, снимается эксклюзивная блокировка. Действие можно завершить досрочно.

Завершённые действия автоматически удаляются из задачи.

Режим доступности

В задаче обслуживания необходимо указать режим доступности кластера, который должен соблюдаться при проверке возможности выполнения действий. Поддерживаются следующие режимы:

• Strong: режим, минимизирующий риск потери доступности.
  • Допускается не более одного недоступного VDisk в каждой из затрагиваемых групп хранения.
  • Допускается не более одного недоступного кольца State Storage.
• Weak: режим, не позволяющий превысить модель отказа.
  • Допускается не более двух недоступных VDisk-ов для затрагиваемых групп хранения со схемой block-4-2.
  • Допускается не более четырёх недоступных VDisk-ов, три из которых должны находиться в одном датацентре, для затрагиваемых групп хранения со схемой mirror-3-dc.
  • Допускается не более (nto_select - 1) / 2 недоступных колец State Storage.
• Force: принудительный режим, модель отказа игнорируется. Не рекомендуется к использованию.

Приоритет

У задачи обслуживания можно указать приоритет. Меньшее значение означает более высокий приоритет.

Действия задачи не могут быть выполнены до завершения всех конфликтующих действий из задач с более высоким приоритетом. Задачи с одинаковым приоритетом не имеют преимущества друг перед другом.

Лимиты недоступных узлов

В конфигурации CMS можно настроить лимиты на количество недоступных узлов для базы данных (тенанта) или для кластера в целом. Поддерживаются относительные и абсолютные лимиты.

По умолчанию допускается не более 13 % недоступных узлов для каждой базы данных и кластера в целом.

Алгоритм проверки

Для того чтобы проверить, можно ли выполнить действия задачи обслуживания, CMS последовательно идёт по каждой группе действий в задаче и проверяет действие из группы:

• Если объектом действия является хост, то CMS проверяет, можно ли выполнить действие со всеми узлами, запущенными на хосте.
• Если объектом действия является узел, то CMS проверяет:
  • Есть ли блокировка на данном узле.
  • Можно ли взять блокировку на данный узел в соответствии с лимитами недоступных узлов.
  • Можно ли взять блокировки на все VDisk-и данного узла в соответствии с режимом доступности.
  • Можно ли взять блокировку на кольцо State Storage данного узла в соответствии с режимом доступности.
  • Можно ли взять блокировку на данный узел в соответствии с лимитом недоступных узлов, на которых могут запускаться кластерные системные таблетки.
• Если объектом действия является диск, то CMS проверяет:
  • Есть ли блокировка на данном диске.
  • Можно ли взять блокировки на все VDisk-и данного диска в соответствии с режимом доступности.

Если проверки прошли успешно, то действие можно выполнить, и на проверенные узлы, хосты или диски берётся временная блокировка. После этого CMS рассматривает следующую группу действий. Временные блокировки позволяют понять, конфликтуют ли запрошенные в разных группах действия между собой. После полного завершения проверки временные блокировки снимаются.

Практика

• Для кластеров, развёрнутых вручную