---
metadata:
  - name: generator
    content: Diplodoc Platform v5.50.6
alternate:
  - https://ydb.tech/docs/en/devops/concepts/maintenance-without-downtime.md
  - https://ydb.tech/docs/ru/devops/concepts/maintenance-without-downtime.md
sourcePath: ru/core/devops/concepts/maintenance-without-downtime.md
---
> **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt

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

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

- Превышения модели отказа затронутых [групп хранения](https://ydb.tech/docs/ru/concepts/glossary.md#storage-groups).
- Превышения модели отказа [State Storage](https://ydb.tech/docs/ru/reference/configuration/domains_config.md#domains-state).
- Недостатка вычислительных ресурсов вследствие остановки слишком большого количества [динамических узлов](https://ydb.tech/docs/ru/concepts/glossary.md#dynamic-node).

Для избежания таких ситуаций в YDB есть системная [таблетка](https://ydb.tech/docs/ru/concepts/glossary.md#tablet), которая следит за состоянием кластера — *Cluster Management System (CMS)*. CMS позволяет ответить на вопрос, можно ли безопасно вывести в обслуживание узел YDB или хост, на котором работают узлы YDB. Для этого необходимо создать [задачу обслуживания](#maintenance-task) в CMS и указать в ней взятие эксклюзивных блокировок на узлы или хосты, которые будут задействованы в обслуживании. Компоненты кластера, на которые взяты блокировки, считаются недоступными с точки зрения CMS, и их можно безопасно обслуживать. CMS [проверит](#checking-algorithm) текущее состояние кластера и возьмёт блокировки, только если работы по обслуживанию соответствуют ограничениям [режима доступности](#availability-mode) и [лимитам недоступных узлов](#unavailable-node-limits).

{% note warning "Поломки во время проведения работ" %}

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

{% endnote %}

## Задача обслуживания {#maintenance-task}

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

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

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

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

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

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

{% note info "Затянувшиеся работы" %}

Если работы по обслуживанию кластера продолжаются после завершения действий, которые были выполнены для безопасного проведения этих работ, то это расценивается как поломка в кластере.

{% endnote %}

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

### Режим доступности {#availability-mode}

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

- **Strong**: режим, минимизирующий риск потери доступности.
    - Допускается не более одного недоступного [VDisk](https://ydb.tech/docs/ru/concepts/glossary.md#vdisk) в каждой из затрагиваемых групп хранения.
    - Допускается не более одного недоступного кольца State Storage.
- **Weak**: режим, не позволяющий превысить модель отказа.
    - Допускается не более двух недоступных VDisk-ов для затрагиваемых групп хранения со схемой [block-4-2](https://ydb.tech/docs/ru/reference/configuration/domains_config.md#reliability).
    - Допускается не более четырёх недоступных VDisk-ов, три из которых должны находиться в одном датацентре, для затрагиваемых групп хранения со схемой [mirror-3-dc](https://ydb.tech/docs/ru/reference/configuration/domains_config.md#reliability).
    - Допускается не более `(nto_select - 1) / 2` недоступных колец State Storage.
- **Force**: принудительный режим, модель отказа игнорируется. *Не рекомендуется к использованию*.

### Приоритет {#priority}

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

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

## Лимиты недоступных узлов {#unavailable-node-limits}

В CMS есть абсолютные и относительные лимиты на количество недоступных узлов для каждой базы данных (тенанта) и для кластера в целом. Лимиты недоступных узлов настраиваются в [конфигурации CMS](https://ydb.tech/docs/ru/reference/configuration/cms_config.md).

## Алгоритм проверки {#checking-algorithm}

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

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

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

## Режим Bridge {#bridge}

Если кластер работает в [режиме brigde](https://ydb.tech/docs/ru/concepts/glossary.md#bridge), то для каждого [pile](https://ydb.tech/docs/ru/concepts/glossary.md#pile) независимо устанавливаются лимиты и выполняются проверки доступности.

## Приостановка обслуживания {#disable-maintenance}

{% note warning %}

Длительная приостановка обслуживания кластера может привести к потере доступности из-за поломок оборудования.

{% endnote %}

Во внештатных ситуациях, например при возникновении проблем с инфраструктурой, можно временно приостановить новые работы по обслуживанию кластера с помощью параметра `disable_maintenance` в [конфигурации CMS](https://ydb.tech/docs/ru/reference/configuration/cms_config.md).

Во время приостановки обслуживания:

- Новые работы по обслуживанию кластера будут приостановлены.
- Уже начатые работы по обслуживанию кластера продолжат выполняться.
- Остается возможность выполнять экстренные работы по обслуживанию вручную без использования CMS.

## Практика

* [Для кластеров, развёрнутых вручную](https://ydb.tech/docs/ru/devops/deployment-options/manual/maintenance.md)