---
metadata:
  - name: generator
    content: Diplodoc Platform v5.50.6
alternate:
  - https://ydb.tech/docs/en/devops/deployment-options/manual/decommissioning.md?version=main
  - https://ydb.tech/docs/ru/devops/deployment-options/manual/decommissioning.md?version=main
sourcePath: ru/core/devops/deployment-options/manual/decommissioning.md
---
> **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt

# Декомиссия ЦОД

{% note info %}

Описанную процедуру можно применять только для декомиссии целого центра обработки данных (ЦОД).

{% endnote %}

Декомиссия — это процедура перемещения VDisk с PDisk, который требуется вывести из эксплуатации.

Данные перемещаются на PDisk кластера, на которых достаточно свободного пространства для создания новых слотов. Перемещение выполняется только в случае, когда есть возможность перемещения с хотя бы частичным сохранением модели отказа. Строгое соблюдение модели отказа во время декомиссии может быть нарушено, однако система стремится к обеспечению в процессе декомиссии отказоустойчивости не хуже, чем при штатной работе. Например, при кодировании `mirror-3-dc` может сложиться ситуация, когда группа находится в 4 ЦОД вместо 3.

Декомиссия выполняется асинхронно, то есть при обработке команды не происходит немедленного перемещения данных. Механизм SelfHeal в фоновом режиме, когда позволяет модель отказа, перемещает слоты по одному, добиваясь полного освобождения указанных PDisk.

## Управление декомиссией {#decommitstatus}

Управление состоянием декомиссии осуществляется заданием параметра `DecommitStatus` для PDisk. Параметр может принимать следующие значения:

* `DECOMMIT_NONE` — диск не участвует в декомиссии и работает штатно, согласно его состоянию.
* `DECOMMIT_PENDING` — запланирована декомиссия диска. Данные с диска не переносятся, однако слоты для новых групп создаваться не будут, а также не будут перемещаться слоты созданных ранее групп.
* `DECOMMIT_IMMINENT` — необходимо провести декомиссию диска. Данные переносятся в фоновом режиме на диски, которые имеют статус `DECOMMIT_NONE` и удовлетворяют модели отказа.

Значения `DECOMMIT_PENDING` и `DECOMMIT_IMMINENT` в случае штатной декомиссии снимать не нужно, т.к. оборудование удаляется из кластера через команду `DefineBox`.

Чтобы отменить декомиссию, достаточно изменить состояние дисков в `DECOMMIT_NONE`. При этом никаких дополнительный действий BS_CONTROLLER предпринимать не будет — уже перевезенные VDisk останутся на своих местах. Если требуется их вернуть, можно использовать команды для точечного перемещения слотов в зависимости от конкретной ситуации.

Управление состояниями `DECOMMIT_PENDING` и `DECOMMIT_IMMINENT` позволяют провести декомиссию кластера по частями.

Например, нужно переместить оборудование из ЦОД-1 в ЦОД-2:

1. В ЦОД-2 размещается буферное оборудование, на которое будет перемещена первая порция данных.
1. Все диски ЦОД-1 единовременно переводятся в состояние `DECOMMIT_PENDING`, чтобы исключить перемещение данных внутри ЦОД-1. Статус необходимо задать сразу на все диски датацентра: если перевести в `DECOMMIT_PENDING` только часть дисков ЦОД, это может привести к нарушению модели отказа групп хранения.
1. В ЦОД-1 все диски оборудования, эквивалентного буферному, переводятся в состояние `DECOMMIT_IMMINENT`.

    Необходимо дождаться освобождения всех дисков в состоянии `DECOMMIT_IMMINENT`.
1. Освободившееся оборудование из ЦОД-1 перемещается в ЦОД-2, его диски переводятся в состояние `DECOMMIT_NONE`.

Описанные шаги повторяются для следующего набора оборудования в ЦОД-1 до тех пор, пока все оборудование не будет перемещено.

Чтобы задать нужное состояние декомиссии диска, воспользуйтесь утилитой [YDB DSTool](https://ydb.tech/docs/ru/reference/ydb-dstool/index.md?version=main). Следующая команда задаст статус `DECOMMIT_IMMINENT` диску с ID `1000` на ноде с ID `1`:

```bash
ydb-dstool -e  <bs_endpoint> pdisk set --decommit-status DECOMMIT_IMMINENT --pdisk-ids "[1:1000]"
```