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

Периодически кластер 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 рассматривает следующую группу действий. Временные блокировки позволяют понять, конфликтуют ли запрошенные в разных группах действия между собой. После полного завершения проверки временные блокировки снимаются.

Примеры

Утилита ydbops использует CMS для проведения обслуживания кластера без потери доступности. Также CMS можно использовать напрямую через gRPC API.

Rolling restart

Чтобы выполнить rolling restart всего кластера можно воспользоваться командой:

$ ydbops restart --endpoint grpc://<cluster-fqdn> --availability-mode strong

Если используемое имя systemd unit отличается от стандартного, его можно переопределить с помощью флага --systemd-unit.

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

Вывести узел для обслуживания

Чтобы вывести узел для обслуживания можно воспользоваться утилитой ydbops. При выведении узла ydbops возьмет эксклюзивную блокировку на этот узел в CMS.