Удаление узла из кластера

В этой статье описано удаление динамического или статического узла из кластера YDB, развёрнутого вручную на виртуальных машинах или физических серверах. Удаление узлов из кластера, развёрнутого в Kubernetes, в этой инструкции не рассматривается.

Удаление динамического узла

Для удаления динамического узла не требуется изменять конфигурацию кластера.

Чтобы удаление динамического узла не повлияло на выполнение запросов:

1. Выполните мягкий перенос таблеток с узла и дождитесь его завершения.
2. Остановите процесс YDB на узле. Сначала проверьте, что процесс можно безопасно остановить, а затем остановите его.

После остановки процесса проверьте на вкладке Nodes страницы мониторинга кластера, что удалённый узел больше не отображается активным. Динамический узел может исчезнуть из списка сразу или временно отображаться со статусом Disconnected до истечения аренды его идентификатора в NodeBroker. Если узел снова переходит в активное состояние, убедитесь, что процесс был остановлен именно на нужном хосте и не настроен на автоматический перезапуск, например службой systemd или супервизором.

Удаление статического узла

Статические узлы обслуживают систему хранения и перечислены в секции hosts. На дисках статического узла могут находиться VDisk динамических и статических групп, а на самом узле — реплики State Storage, Board и SchemeBoard. Поэтому сначала необходимо перенести эти ресурсы, а затем удалить узел из конфигурации.

Перед началом процедуры проверьте во встроенном UI, что затронутые группы хранения работоспособны, то есть все VDisk этих групп отображаются в состоянии Ok (выделены зелёным цветом), и ни один VDisk не находится в состоянии Error или Degraded.

На оставшихся узлах должно быть достаточно свободного места и слотов на PDisk для всех VDisk с удаляемого узла. Размещение VDisk по доменам отказа и областям отказа должно соответствовать используемой схеме кодирования, чтобы после удаления узла сохранялась отказоустойчивость групп. Расчёт необходимого запаса приведён в статье Оценка требуемого оборудования.

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

• Если на узле есть VDisk статической группы, включите SelfHeal статической группы. Как альтернативу можно перенести VDisk статической группы с узла вручную, см. Перемещение статической группы.
• Если узел содержит реплики State Storage, Board или SchemeBoard, включите SelfHeal подсистем распространения метаданных. Как альтернативу можно перенести эти реплики с узла вручную, см. Конфигурирование подсистем распространения метаданных State Storage, Board, Scheme Board.

Чтобы удалить статический узел:

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

2. Проверьте, что процесс можно безопасно остановить, затем остановите его.

3. Дождитесь, пока SelfHeal перенесёт VDisk с узла. С настройками по умолчанию перенос начинается приблизительно через час после остановки узла. Чтобы запустить перенос немедленно, сначала получите идентификаторы всех PDisk удаляемого узла с помощью YDB DSTool:

   ydb-dstool -e <bs_endpoint> pdisk list --columns NodeId:PDiskId FQDN Path
   

   <bs_endpoint> — точка подключения к любому доступному узлу хранения в формате [PROTOCOL://]HOST[:PORT], например http://node1.example.com:8765.

   Выберите все строки, в которых FQDN совпадает с именем хоста удаляемого узла. Проверьте пути к дискам в столбце Path и сохраните все соответствующие значения NodeId:PDiskId.

   Затем переведите все найденные PDisk в статус BROKEN одной командой:

   ydb-dstool -e <bs_endpoint> pdisk set --status BROKEN --unavail-as-offline --pdisk-ids "<pdisk_id_1>" ... "<pdisk_id_N>"
   

   Используйте ту же точку подключения <bs_endpoint>. Вместо "<pdisk_id_1>" ... "<pdisk_id_N>" перечислите через пробел все сохранённые идентификаторы дисков в формате [NodeId:PDiskId], например "[3:1]" "[3:2]" для двух дисков узла с NodeId, равным 3. Флаг --unavail-as-offline позволяет считать PDisk, недоступные через службу мониторинга Whiteboard, неработающими.

   Команда выполняется на переднем плане. Дождитесь её успешного завершения, затем проверьте завершение переноса данных на следующем шаге. Подробнее см. в статье Перенос VDisk с повреждённого или недоступного тома блочного хранилища.

4. Во встроенном UI проверьте, что на удаляемом узле не осталось VDisk, а затронутые группы хранения работоспособны (все VDisk находятся в состоянии Ok). Если с узла переносились реплики State Storage, Board или SchemeBoard, проверьте, что перенос завершён.

5. Получите актуальную конфигурацию кластера с помощью команды ydb admin cluster config fetch:

   ydb [global options...] admin cluster config fetch > config.yaml
   

6. Если запись удаляемого узла не последняя в списке hosts, при удалении позиции всех следующих узлов сместятся. Чтобы сохранить их идентификаторы, для каждой следующей записи без явно заданного node_id укажите её текущий идентификатор до удаления: для такой записи он равен текущей позиции в списке, начиная с 1. Если node_id уже задан явно, сохраните его существующее значение. Если удаляется последняя запись, этот шаг не требуется.

   Важно

   Корректная нумерация узлов критически важна для работоспособности кластера. Ошибка при назначении node_id может привести к тому, что VDisk, реплики State Storage, Board или SchemeBoard окажутся привязаны не к тому хосту, что может стать причиной необратимой потери данных.

   Например, дана следующая конфигурация, из которой удаляется узел node3:

   hosts:
   - host: node1
   - host: node2
   - host: node3 # удаляется
   - host: node4
   - host: node5
     node_id: 50
   

   Перед удалением node3 явно укажите node_id: 4 для node4, чтобы его идентификатор не изменился на 3. Для node5 сохраните уже заданное значение node_id: 50. После удаления node3 список будет выглядеть так:

   hosts:
   - host: node1
   - host: node2
   - host: node4
     node_id: 4
   - host: node5
     node_id: 50
   

7. Удалите запись узла из секции hosts.

8. Примените конфигурацию с помощью команды ydb admin cluster config replace:

   ydb [global options...] admin cluster config replace -f config.yaml
   
   Если команда завершилась с ошибкой

   Если на PDisk удаляемого узла остались VDisk, команда возвращает ошибку следующего вида:

   failed to remove PDisk# 1:1 as it has active VSlots
   

   В этом случае дождитесь, пока SelfHeal перенесёт оставшиеся VDisk. Продолжительность переноса зависит от объёма данных и производительности дисков. Следите за переносом на вкладке Storage удаляемого узла во встроенном UI. Когда на узле не останется VDisk, повторите команду config replace с тем же файлом.

   Если список VDisk не сокращается и репликация не идёт, перенесите оставшиеся VDisk вручную.

После успешного применения конфигурации сервер и его диски можно вывести из эксплуатации.