MAINTENANCE, DRAIN, REPLACEMENT И DECOMMISSION Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Runbook жизненного цикла узлов Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Документ описывает безопасный жизненный цикл сервера: временное обслуживание, вывод нагрузки, замена вышедшего из строя узла и окончательное удаление из Control Center. РАЗЛИЧИЯ РЕЖИМОВ Режим | Назначение | Обратимость Maintenance | плановое временное обслуживание; запрещает/ограничивает новое размещение и операции на узле | да Drain | перенос/завершение workload/Jobs/ролей перед выводом | да, до завершения decommission Replacement | замена утраченного или выводимого сервера новым | да до финального подтверждения старого узла Decommission | окончательное удаление membership/placement/доверия после очистки зависимостей | обычно destructive/финальный ПЕРЕД ЛЮБОЙ ОПЕРАЦИЕЙ - проверьте Health и Actual State; - проверьте активные Changes/Jobs; - проверьте роли и данные на узле; - проверьте quorum/replication; - проверьте capacity оставшихся узлов; - создайте актуальный backup для stateful/cluster-changing операций; - убедитесь в наличии recovery plan. MAINTENANCE MODE Что изменится: Узел остается членом инфраструктуры, но переводится в режим планового обслуживания. Точная политика новых Jobs/placements определяется версией и ролью. Риск: Если оставшийся кластер не имеет capacity или quorum, включение maintenance может вызвать деградацию. Шаг 1. Предварительная проверка 1. Откройте узел [Уточнить название элемента интерфейса]. 2. Проверьте активные роли. 3. Проверьте незавершенные Jobs. 4. Запустите Capacity Planner what-if «узел временно недоступен». 5. Для HA проверьте quorum. Шаг 2. Включение maintenance 1. Выберите [Уточнить название действия Maintenance]. 2. Просмотрите предупреждения и blast radius. 3. Создайте Change. 4. Дождитесь подтверждения Desired/Actual maintenance state. Ожидаемый результат: Узел явно помечен Maintenance, новые операции не нарушают его режим. Rollback: Если maintenance включен ошибочно и drain не начал destructive migration, отмените режим штатным Change и подтвердите Healthy. DRAIN Drain выполняется после maintenance, если требуется освободить узел от workload/Jobs/ролей. Шаг 3. Запуск drain 1. Проверьте целевые узлы для переноса. 2. Убедитесь в наличии capacity. 3. Запустите [Уточнить название действия Drain]. 4. Следите за каждым Change/Job переноса. 5. Для stateful ролей контролируйте replication/data consistency. Ожидаемый результат: На исходном узле нет активных workload, которые должны продолжать работу после его остановки, и нет незавершенных Jobs, привязанных только к нему. Проверка: - role placement пуст или содержит только разрешенные maintenance-компоненты; - Jobs = завершены/перенесены; - quorum сохранен; - replicas Healthy; - Actual State актуален. Если drain не может завершиться: Не форсируйте decommission. Определите блокирующую роль, Job, local-only data или policy и устраните причину. PLANNED REPLACEMENT Используется при профилактической замене оборудования. Шаг 4. Подготовка нового узла 1. Подготовьте новый сервер по документу 04. 2. Выполните enrollment. 3. Дождитесь Healthy. 4. Проверьте capacity и совместимость. Шаг 5. Перенос 1. Старый узел: maintenance. 2. Выполните drain. 3. Перенесите stateful роли согласно поддерживаемой процедуре. 4. Убедитесь, что новый узел имеет корректный Actual State. 5. Выполните функциональную проверку сервисов. Шаг 6. Пауза безопасности Перед decommission старого сервера убедитесь: - новый узел стабильно Healthy; - replication завершена; - старый сервер не содержит единственную копию данных; - нет ссылок/placement на старый Node ID; - новый backup после миграции создан, если это требуется политикой. UNPLANNED REPLACEMENT ПОСЛЕ ОТКАЗА Если сервер потерян внезапно: 1. Не удаляйте его запись сразу. 2. Определите возможность возвращения старого оборудования. 3. Исключите split-brain: если старый узел потенциально может вернуться с сетью, изолируйте его до решения о replacement. 4. Проверьте surviving replicas/quorum. 5. Создайте новый узел. 6. Выполните поддерживаемый replacement/rebuild для утраченных ролей. 7. После восстановления проверьте Desired/Actual и данные. [ТРЕБУЕТ УТОЧНЕНИЯ: exact node replacement identity/rejoin semantics]. DECOMMISSION ПРЕДУПРЕЖДЕНИЕ: decommission является потенциально destructive операцией. Он не должен использоваться вместо временного Offline/Maintenance. Что изменится: Узел перестает быть управляемым членом инфраструктуры; его membership, role placement и/или trust relationship удаляются согласно реализации. Риски: - потеря единственной копии данных; - потеря quorum; - orphaned placement; - невозможность штатного повторного подключения старого Node ID; - сохранение секретов/сертификатов на физическом сервере после удаления из Control Center. Шаг 7. Pre-decommission checklist - [ ] Maintenance включен; - [ ] Drain завершен; - [ ] активных Jobs нет; - [ ] ролей, требующих переноса, нет; - [ ] stateful data подтверждены на других узлах/backup; - [ ] quorum останется Healthy; - [ ] Capacity Planner подтверждает оставшийся capacity; - [ ] зависимости на Node ID удалены; - [ ] Audit/reason указан; - [ ] физический/виртуальный сервер доступен для последующей sanitization либо отмечен как физически утраченный. Шаг 8. Выполнение decommission 1. Откройте действие [Уточнить название Decommission]. 2. Просмотрите итоговый dependency report. 3. Если есть blocker — отмените процедуру и устраните его. 4. Подтвердите Change. 5. Дождитесь завершения Job. 6. Проверьте, что узел исчез из active membership, но его Audit/history сохранены согласно retention policy. Rollback: До финального decommission — отменить/вернуть узел штатным способом. После финального удаления обычно требуется новый enrollment как нового/заменяющего узла либо recovery procedure. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемая undo window]. Шаг 9. Sanitization старого сервера После подтвержденного decommission удалите с выведенного оборудования учетные данные, сертификаты и данные только по принятой организации процедуре уничтожения/переиспользования. Не выполняйте sanitization до подтверждения, что данные восстановлены/реплицированы. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемая команда node uninstall/sanitize]. ПРОВЕРКА ПОСЛЕ DECOMMISSION - [ ] cluster membership корректен; - [ ] quorum Healthy; - [ ] все нужные роли Healthy; - [ ] Desired/Actual не содержат orphaned ссылок; - [ ] capacity безопасен; - [ ] backup после изменения создан при необходимости; - [ ] Audit содержит decommission reason/actor; - [ ] старые credentials/certificates отозваны; - [ ] старое оборудование обработано по security policy. ТИПОВЫЕ ОШИБКИ Симптом | Причина | Проверка | Решение Drain завис | активная stateful роль/Job/нехватка capacity | blockers/placement | устранить blocker; не форсировать удаление После maintenance сервис деградировал | недостаточно remaining capacity | Capacity/Health | вернуть узел, восстановить Healthy, перепланировать Replacement создал duplicate node | неверная identity semantics | Node IDs/certificates | остановить процедуру; использовать штатный replacement flow Decommission заблокирован | роль/quorum/dependency | dependency report | перенести/удалить зависимость безопасно Старый узел вернулся после replacement | риск split-brain | network/cluster evidence | немедленно изолировать старый узел; recovery runbook РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - всегда используйте maintenance перед плановой остановкой; - drain должен завершиться до destructive decommission; - для replacement различайте «старый узел может вернуться» и «узел физически утрачен»; - храните аппаратный inventory и Node ID mapping; - отрабатывайте planned replacement заранее; - не уничтожайте диск старого узла до верификации данных; - сохраняйте Audit/history после удаления активного объекта. ИТОГ Maintenance временно защищает узел от обычной эксплуатации, drain освобождает его от нагрузки, replacement переносит инфраструктурную функцию на новый сервер, а decommission завершает жизненный цикл только после доказанного отсутствия зависимостей и риска потери данных/quorum. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - точные действия/экраны Maintenance/Drain/Replacement/Decommission; - блокирующие условия state machine; - node identity replacement rules; - undo window; - sanitize/uninstall procedure; - retention удаленных Node records.