УПРАВЛЕНИЕ УЗЛАМИ И СЕРВЕРНЫМИ РОЛЯМИ Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство администратора Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Инструкция описывает добавление серверного узла, проверку его готовности, назначение и перенос ролей, а также безопасную подготовку узла к обслуживанию или удалению. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Control Center | Работоспособный Core Новый сервер | Поддерживаемая ОС, совместимая версия Node Runtime DNS | Прямое разрешение имени каждого узла NTP | Все узлы синхронизированы Сеть | Двусторонняя связность по требуемым портам [ТРЕБУЕТ УТОЧНЕНИЯ] Права | Permission на enrollment/узлы/роли Capacity | Проверен запас CPU/RAM/storage/network Backup | Актуален перед переносом stateful-критичных ролей АРХИТЕКТУРА Control Center рассматривает сервер как управляемый Node. На узле могут размещаться одна или несколько ролей, но допустимость размещения определяется compatibility, ресурсами, отказоустойчивостью и политикой. Node → Capabilities/Resources → Role Placement → Desired State → Job → Actual State/Health. Не следует привязывать роль к серверу только потому, что на нем есть свободная RAM. Учитывайте storage, IOPS, network path, fault domain и зависимости. ПЕРЕД ДОБАВЛЕНИЕМ УЗЛА 1. Установите поддерживаемую ОС. 2. Настройте постоянное имя и адрес. 3. Проверьте DNS и NTP. 4. Проверьте CPU/RAM/storage и свободное место. 5. Проверьте сетевую доступность между существующими узлами и новым сервером. 6. Убедитесь, что версия компонентов совместима. 7. Не назначайте production-роли до статуса Healthy. Для Linux: ```bash hostnamectl cat /etc/os-release nproc free -h lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS ip -br addr ip route getent hosts timedatectl status ``` Ожидаемый результат: Сервер однозначно идентифицирован, имеет стабильную сеть, разрешает имена и синхронизирует время. Шаг 1. Установка Node Runtime/Control Center компонента [ТРЕБУЕТ УТОЧНЕНИЯ: точный package и команда установки для дополнительного узла]. Не копируйте вручную ключи или внутреннюю БД с другого узла. Ожидаемый результат: Узел готов к штатному enrollment, но еще не считается членом инфраструктуры до завершения проверки. Шаг 2. Enrollment узла 1. Откройте раздел узлов [Уточнить название элемента интерфейса]. 2. Запустите «Добавить узел» [Уточнить название элемента интерфейса]. 3. Выполните штатную процедуру подтверждения/enrollment. 4. Проверьте идентичность узла и fingerprint/certificate, если он показывается. 5. Дождитесь окончания compatibility/preflight проверки. [ТРЕБУЕТ УТОЧНЕНИЯ: точный enrollment mechanism и срок действия bootstrap credential]. Риск: Подключение неизвестного узла может расширить trust boundary. Никогда не подтверждайте узел только по имени, если интерфейс предоставляет дополнительные идентификаторы. Ожидаемый результат: Новый узел отображается в Control Center и имеет известный Actual State. Шаг 3. Проверка Health нового узла До назначения ролей проверьте: - Health = Healthy; - версия совместима; - CPU/RAM/storage обнаружены; - network interfaces обнаружены; - DNS/NTP без ошибок; - нет Critical alerts; - discovery freshness актуален. Если узел Unknown/Degraded, устраните причину до placement. Шаг 4. Планирование роли Перед назначением роли: 1. определите требования роли; 2. откройте Capacity Planner; 3. оцените CPU/RAM/storage/IOPS/network; 4. проверьте зависимости и fault domain; 5. проверьте, не нарушит ли размещение HA/quorum; 6. выполните what-if, если доступно. Ожидаемый результат: Выбран узел, который имеет безопасный capacity headroom и соответствует политике размещения. Шаг 5. Назначение роли 1. Откройте узел или экран размещения ролей [Уточнить название элемента интерфейса]. 2. Выберите требуемую роль. 3. Проверьте preview/diff. 4. Проверьте зависимости и предупреждения. 5. Создайте Change. 6. Дождитесь Job. 7. После Job проверьте Actual State/Health роли. Что изменится: На узле появится новый управляемый workload/role и связанные с ним данные/сервисы в пределах роли. Риск: Неверное placement может перегрузить сервер или объединить отказоустойчивые копии в одном fault domain. Rollback: Используйте штатное Remove/Move Role через новый Change. Для stateful-ролей сначала выполните поддерживаемый drain/replication; не удаляйте данные вручную. Шаг 6. Перенос роли между узлами Для stateless роли: 1. проверьте capacity целевого узла; 2. создайте Change на placement; 3. дождитесь запуска новой копии/назначения согласно поддерживаемой модели; 4. проверьте Health; 5. только затем удаляйте старое placement. Для stateful роли: 1. создайте backup/recovery point; 2. проверьте состояние replication; 3. переведите исходный узел/роль в maintenance или drain, если требуется; 4. выполните поддерживаемую миграцию; 5. подтвердите данные и Health на целевом узле; 6. только затем снимите старую роль. [ТРЕБУЕТ УТОЧНЕНИЯ: какие роли stateful, способы миграции и RPO/RTO]. Шаг 7. Изменение роли узла Если сервер меняет назначение: - не меняйте одновременно hostname/IP, cluster membership и критические роли; - выполняйте изменения по одному Change; - после каждого Change подтверждайте Actual State; - используйте staged network configuration для сетевых изменений. Шаг 8. Подготовка к удалению узла Никогда не удаляйте активный узел напрямую, если на нем есть роли или данные. Порядок: 1. включите maintenance mode; 2. выполните drain; 3. убедитесь, что активные Jobs завершены/перенесены; 4. перенесите роли; 5. проверьте replicas/quorum; 6. убедитесь, что узел не является единственным владельцем нужных данных; 7. только после этого переходите к decommission (см. документ 06). ПРОВЕРКА - [ ] узел зарегистрирован ровно один раз; - [ ] FQDN/IP соответствуют плану; - [ ] NTP синхронизирован; - [ ] inventory/capacity обнаружены; - [ ] Health = Healthy; - [ ] назначенные роли видны в Desired и Actual State; - [ ] роли не нарушают HA/fault-domain правила; - [ ] нет orphaned/unknown role placement; - [ ] все операции отражены в Audit. ТИПОВЫЕ ОШИБКИ Симптом | Возможная причина | Проверка | Решение Узел не enrollment | DNS/NTP/firewall/version mismatch | preflight и connectivity | исправить причину и повторить штатно Узел Degraded | ресурс/сервис/сеть неисправны | Health evidence | устранить конкретную причину Роль не назначается | недостаточный capacity или policy conflict | Capacity Planner/Change error | выбрать другой узел или расширить ресурсы После переноса роль Unhealthy | зависимость/данные не готовы | Health/Actual/evidence | остановить удаление старого placement и восстановить service Узел нельзя удалить | на нем роли, Jobs или quorum dependency | placement/cluster state | drain/переносить зависимости до decommission РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - используйте FQDN и стабильные адреса; - разделяйте fault domains для HA-копий; - оставляйте capacity headroom; - не размещайте все критические роли на одном узле без осознанного single-node design; - перед stateful migration создавайте backup; - не выполняйте destructive removal, пока Actual State не подтверждает успешный перенос; - документируйте назначение каждого узла и роли. ИТОГ Узлы добавляются через контролируемый enrollment, проходят Health/capacity проверку, а роли назначаются и переносятся через Desired State → Change → Job → Actual State. Удаление узла начинается только после maintenance/drain и проверки зависимостей. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - package/Node Runtime install; - network ports; - enrollment mechanism; - каталог ролей; - stateful/stateless classification; - placement policies/fault-domain settings; - migration semantics и RPO/RTO.