MULTI-NODE, КЛАСТЕР И ОТКАЗОУСТОЙЧИВОСТЬ CONTROL CENTER Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по HA и кластерной эксплуатации Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Инструкция описывает переход от одного узла к нескольким, базовые правила отказоустойчивого размещения, quorum/replication проверки, отказ одного узла, последовательное обслуживание и восстановление после потери нескольких серверов. ВАЖНО Single-node установка не является HA. Наличие двух серверов само по себе также не доказывает отказоустойчивость: HA определяется поддерживаемой схемой ролей, данных, quorum, replication и подтвержденными failover-тестами. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Узлы | Не менее поддерживаемого HA-минимума [ТРЕБУЕТ УТОЧНЕНИЯ] Версия | Совместимые версии на всех узлах DNS | Устойчивое прямое разрешение имен NTP | Синхронизация всех узлов Сеть | Низкая потеря пакетов и доступность требуемых cluster ports [ТРЕБУЕТ УТОЧНЕНИЯ] Storage | Достаточный capacity/IOPS для stateful ролей Backup | Актуальный и проверенный restore Права | Cluster/Node/Role administration АРХИТЕКТУРА +------------------+ | Admin / Web/API | +--------+---------+ | Cluster view | +--------------+--------------+ | | | Node A Node B Node C | | | roles/data roles/data roles/data \______________|______________/ replication/quorum Точная топология зависит от версии и набора ролей. ПЕРЕД НАЧАЛОМ 1. Прочитайте документ 04 и убедитесь, что все узлы Healthy. 2. Сделайте backup и выполните последний известный restore-test. 3. Проверьте, что HA-копии не находятся в одном физическом fault domain без осознанного решения. 4. Зафиксируйте текущий placement ролей. 5. Проверьте capacity каждого узла после моделируемой потери одного сервера. 6. Не меняйте одновременно cluster membership, адреса узлов и storage topology. Шаг 1. Проверка базовой связности На Linux-узлах: ```bash hostnamectl ip -br addr ip route getent hosts getent hosts timedatectl status ``` Для дополнительной сетевой проверки используйте разрешенные вашей политикой инструменты, например ping только если ICMP разрешен: ```bash ping -c 4 ``` Ожидаемый результат: Имена разрешаются в ожидаемые адреса, время синхронизировано, routing не содержит неожиданного пути. Шаг 2. Добавление дополнительных узлов Выполните enrollment по документу 04. Добавляйте узлы последовательно. После каждого узла проверяйте: - identity/fingerprint; - совместимость версии; - Health; - Actual State; - discovered resources; - connectivity. Не добавляйте несколько неизвестных узлов одновременно, если это усложняет диагностику. Шаг 3. Формирование отказоустойчивого placement Для каждой критической роли определите: - требуемое число экземпляров/реплик; - stateful/stateless характер; - quorum requirement; - зависимости; - fault-domain ограничения; - RPO/RTO; - capacity при отказе одного узла. [ТРЕБУЕТ УТОЧНЕНИЯ: официальный каталог ролей, replication factors и quorum rules]. Используйте Capacity Planner для what-if «Node X unavailable». Ожидаемый результат: После потери одного разрешенного fault domain оставшиеся узлы имеют достаточный capacity и не нарушают правила quorum. Шаг 4. Проверка quorum Если конкретный кластерный компонент использует quorum, Control Center должен отображать его состояние [Уточнить название элемента интерфейса]. Перед обслуживанием узла проверьте: - число голосующих участников; - текущий leader/primary, если применимо; - число доступных реплик; - наличие lag/ошибок replication; - возможность потерять еще один узел во время maintenance. Никогда не выводите узел, если это оставит кластер без требуемого quorum. [ТРЕБУЕТ УТОЧНЕНИЯ: точная quorum model каждого stateful компонента]. Шаг 5. Тест отказа одного узла Production HA нельзя считать подтвержденным без контролируемого failover-test. Безопасная процедура: 1. создайте backup/recovery point; 2. убедитесь, что нет активных критических Changes; 3. выберите некритическое окно; 4. переведите тестируемый узел в maintenance, если сценарий проверяет planned failover; 5. выполните drain; 6. остановите/изолируйте узел штатным способом для выбранного теста [ТРЕБУЕТ УТОЧНЕНИЯ: сертифицированный способ test failure]; 7. подтвердите доступность management plane; 8. подтвердите Health и placement ролей; 9. выполните разрешенные read/write функциональные проверки; 10. верните узел; 11. дождитесь reconciliation и replication catch-up. Ожидаемый результат: Критические функции остаются доступны в пределах заявленного HA profile, а после возврата узла кластер восстанавливает Healthy без ручной правки внутренних данных. Rollback: Если кластер деградирует сильнее ожидаемого, прекратите тест, верните узел в исходное состояние, дождитесь восстановления quorum/replication и расследуйте причину. Шаг 6. Плановое обслуживание одного узла 1. Проверьте quorum/replication. 2. Включите maintenance mode. 3. Выполните drain. 4. Дождитесь завершения/переноса Jobs. 5. Убедитесь, что роли перенесены или остановлены безопасно. 6. Выполните обслуживание. 7. Верните узел. 8. Дождитесь Healthy и актуального Actual State. 9. Выключите maintenance mode. 10. Проверьте replication/freshness. Никогда не обслуживайте одновременно все узлы одной HA-группы. Шаг 7. Rolling update Для multi-node/HA: 1. проверьте backup и compatibility plan; 2. выберите первый узел, который можно вывести без потери quorum; 3. maintenance → drain; 4. обновите только этот узел; 5. верните его в Healthy; 6. проверьте version skew policy; 7. убедитесь, что replication догнала; 8. переходите к следующему узлу. Если новая версия вызывает деградацию, остановите rollout и используйте поддерживаемый rollback/recovery. Не продолжайте обновление остальных узлов «для выравнивания» при неизвестной причине отказа. Шаг 8. Отказ одного незапланированного узла 1. Не удаляйте исчезнувший узел сразу. 2. Определите, это временная сеть/питание или окончательная потеря. 3. Проверьте quorum, replication и Health оставшихся узлов. 4. Не запускайте replacement, пока не понятен риск возвращения старого узла и split-brain. 5. Если узел можно восстановить — верните его через штатный reconciliation. 6. Если узел утрачен — используйте replacement/decommission согласно документу 06. Шаг 9. Потеря нескольких серверов Это аварийный режим. 1. Зафиксируйте какие узлы и fault domains реально доступны. 2. Не пытайтесь принудительно «создать quorum» неизвестными командами. 3. Определите, существует ли поддерживаемый survivors recovery path. 4. Изолируйте потенциально разделенные старые узлы, чтобы исключить split-brain. 5. Используйте последний согласованный backup/recovery point при невозможности безопасно восстановить состояние из surviving replicas. 6. Восстанавливайте management plane и stateful данные по официальному recovery runbook. 7. После восстановления выполните полную reconciliation Desired/Actual, Audit и functional checks. [ТРЕБУЕТ УТОЧНЕНИЯ: официальные disaster quorum recovery procedures]. Риск: Принудительная запись в разделенный кластер может создать две расходящиеся версии данных. Rollback: В disaster-сценарии rollback означает возврат к доказанному consistent recovery point, а не попытку объединить две неизвестно расходящиеся БД вручную. ПРОВЕРКА HA - [ ] все узлы Healthy; - [ ] DNS/NTP исправны; - [ ] cluster membership ожидаемый; - [ ] quorum Healthy, если применимо; - [ ] replication без критического lag; - [ ] роли распределены по fault domains; - [ ] capacity выдерживает потерю одного узла согласно profile; - [ ] backup актуален; - [ ] restore протестирован; - [ ] отказ одного узла протестирован; - [ ] rolling maintenance протестирован; - [ ] runbook потери нескольких узлов доступен операторам. ТИПОВЫЕ ОШИБКИ Симптом | Причина | Проверка | Решение После вывода узла потерян quorum | maintenance начат без capacity/quorum проверки | cluster state | вернуть узел; восстановить quorum; пересчитать procedure Возвращенный узел не Healthy | replication/version/config drift | Health/Actual | дождаться catch-up или выполнить штатный repair Два узла считают себя primary | partition/split-brain | cluster evidence | изолировать стороны; прекратить writes; официальный recovery HA есть на бумаге, сервис падает | реплики в одном fault domain или зависимости не HA | placement/dependency map | перераспределить роли/зависимости Rolling update остановился | несовместимый version skew | compatibility plan | не обновлять остальные; rollback/repair первого узла РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - проектируйте HA по failure domains, а не только по количеству серверов; - регулярно выполняйте контролируемые failover tests; - держите запас ресурсов N+1 или иной требуемый profile; - разделяйте planned maintenance и disaster recovery; - не удаляйте Offline node до решения о recovery/replacement; - не допускайте одновременного изменения сети и cluster membership; - измеряйте фактические RPO/RTO на restore/failover tests. ИТОГ Отказоустойчивость Control Center строится на совместимых узлах, корректном placement, quorum/replication, capacity headroom и проверенных failover/recovery процедурах. Multi-node конфигурация считается HA только в пределах подтвержденного profile и испытанных отказов. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - минимальный HA node count; - cluster ports; - конкретные quorum algorithms/rules; - role replication factors; - supported version skew; - failover certification procedure; - disaster quorum recovery; - заявленные RPO/RTO по ролям.