Обслуживание кластера без потери доступности
Периодически кластер YDB необходимо обслуживать, например, обновлять его версию или заменять сломавшиеся диски. Работы по обслуживанию могут привести к недоступности кластера или имеющихся баз данных из-за:
- Превышения модели отказа затронутых групп хранения.
- Превышения модели отказа State Storage.
- Недостатка вычислительных ресурсов вследствие остановки слишком большого количества динамических узлов.
Для избежания таких ситуаций в YDB есть системная таблетка, которая следит за состоянием кластера — Cluster Management System (CMS). CMS позволяет ответить на вопрос можно ли безопасно вывести в обслуживание узел YDB или хост, на котором работают узлы YDB. Для этого необходимо создать задачу обслуживания в CMS и указать в ней взятие эксклюзивных блокировок на узлы или хосты, которые будут задействованы в обслуживании. Компоненты кластера, на которые взяты блокировки, считаются недоступными с точки зрения 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
По умолчанию, будет использован режим доступности strong
, минимизирующий риск потери доступности. Его можно переопределить с помощью параметра --availability-mode
.
Утилита ydbops
автоматически создаст задачу обслуживания на рестарт всего кластера, используя указанный режим доступности. По ходу продвижения ydbops
будет обновлять задачу обслуживания и получать эксклюзивные блокировки на узлы в CMS, пока все узлы не будут перезапущены.
Вывести хост для обслуживания
Чтобы вывести хост для обслуживания, выполните следующие шаги:
-
Cоздать задачу обслуживания с помощью команды:
$ ydbops maintenance create --hosts=<fqdn> --duration=<seconds>
Эта команда создаст задачу обслуживания, в рамках которой на хост с полным доменным именем
<fqdn>
будет взята эксклюзивная блокировка на<seconds>
секунд. -
После создания задачи необходимо обновлять ее состояние, пока блокировка не будет взята, с помощью команды:
$ ydbops maintenance refresh --task-id=<id>
Эта команда обновит задачу с идентификатором
<id>
и попытается взять требуемую блокировку. При получении ответаPERFORMED
можно переходить к следующему пункту. -
Провести обслуживание хоста пока взята блокировка.
-
После завершения работ необходимо отпустить блокировку на хост с помощью команды:
$ ydbops maintenance complete --task-id=<id> --hosts=<fqdn>