Узел и кластер — разные действия

Отдельная диагностика: сохранить план подключения

1. Эта отдельная диагностическая форма /ui/nodes/check не является добавлением узла /ui/nodes/add или мастером кластера /ui/cluster/create. После результата «SSH проверен» нажмите «Подготовить план подключения». Этот этап доступен только при отдельно настроенном планировщике и заранее подготовленном оператором профиле. Если планировщик выключен, проверка SSH продолжает работать отдельно; установка сама не включается.
2. Проверьте узел, management IP и логин, SSH fingerprint, архитектуру, источник управляющего ключа, идентичность TLS агента и закреплённые контрольные суммы. Это неизменяемые требования плана, а не измеренная готовность хоста. Пароли, закрытые ключи и произвольные команды в форме отсутствуют.
3. Сохраните показанный номер задания, выберите «Подтверждаю сохранение указанного плана» и нажмите «Сохранить план подключения». Подтверждение «План сохранён; установка не начата» означает только запись намерения в закрытый журнал управляющего хоста. SSH-ключи, агент, Docker, почтовые данные и репликация не меняются.
4. Если ответ потерян, не повторяйте создание и не готовьте новый UUID. Нажмите «Уточнить состояние плана» для того же задания. После повторного входа откройте /ui/nodes/check и блок «Уточнить состояние ранее сохранённого плана», затем введите исходный номер. Нужна та же учётная запись создателя с неизменным auth epoch, текущими правами глобального системного администратора и входом не старше пяти минут; старый SSH challenge для чтения сохранённого плана не нужен.
5. Изменение профиля, полномочий, SSH-ключа или неизвестный исход требует разбора, а не автоматического повтора. Сохранение плана не выполняет установку или переключение роли. Для обычного подключения сервера используйте /ui/nodes/add с отдельной проверкой и явным подтверждением. Мастер /ui/cluster/create выбирает уже подключённые узлы. Наличие плана и доступного наблюдателя не является подтверждением HA, репликации или сохранности копии.

Отдельная проверка SSH-доступа

1. Системный глобальный администратор открывает «Инфраструктура → Узлы кластера → Отдельная проверка SSH» (/ui/nodes/check). Оператор предварительно подключает отдельный доверенный HTTPS API системной идентификации, CA, ожидаемое имя сертификата и политику разрешённых IP/портов. Без настройки форма недоступна. Куратор ИБ и администратор домена не могут проверять SSH-доступ.
2. Сначала укажите IP или DNS-имя сервера, SSH-порт и служебный логин. Это адрес сервера, не URL. DNS-имя разрешается сервером управления, полученный IP должен быть разрешён политикой. На первом шаге сервер получает только открытый ключ, без пароля и авторизации. Сверьте наблюдаемый IP и SHA256 fingerprint с консолью сервера или ответственным администратором по независимому каналу. Само отображение ключа не является доказательством доверия.
3. Введите ожидаемый fingerprint из независимого источника и явно подтвердите сверку. Только после повторной серверной проверки состояния появляется поле учётных данных. Перед каждым шагом API проверяет текущую системную роль и вход не старше пяти минут; при требовании повторного входа выйдите, войдите снова и начните новую проверку.
4. Учётные данные используются только для одной попытки SSH. В заданиях, сессиях и ответах формы пароль не сохраняется. Проверка действует 120 секунд и привязана к текущей сессии. После ошибки или неизвестного исхода не повторяйте отправку: используйте «Уточнить состояние проверки». Новая попытка требует нового явного действия и сверки ключа.
5. «SSH проверен» означает только проверенные ключ и учётные данные. Команды не выполнялись; ключ управления и агент не устанавливались; Docker, sudo, ресурсы, почтовая репликация и готовность переключения не проверялись. Установка является отдельным явным действием: обычный путь — «Добавить узел» (/ui/nodes/add). Если диагностическая форма показывает «Продолжить: установить агент», сначала проверьте её отдельное подтверждение и срок действия; результат SSH сам не запускает установку. Роли выбираются позже в /ui/cluster/create из уже добавленных узлов.

Узлы кластера: реальные показатели серверов

1. Откройте «Инфраструктура → Узлы кластера» (/ui/nodes). Каждая карточка относится к одному явно подключённому узлу. Нажмите название или «Показатели узла», чтобы открыть его отдельную страницу; «Обновить показания» повторяет чтение, но не перезапускает службы.
2. Проверьте время измерения и срок свежести. Устаревший снимок сохраняет исходное время и не выдаётся за текущее состояние. При отказе одного агента остальные узлы остаются видны. «Нет данных» означает отсутствие измерения; известное нулевое значение, например свободное место 0, показывается как ноль.
3. CPU, память, время работы и раздел /srv относятся к хосту, а счётчики Docker — ко всему Docker Engine на этом хосте. Они не подтверждают здоровье отдельного почтового контейнера. Версию сообщает агент: это не проверка совместимости образов или готовности обновления.
4. Просмотр требует глобального права security.configuration.read: он доступен глобальному администратору и куратору ИБ. Делегирование администрирования одного домена не открывает мониторинг всех серверов. Права проверяются при каждом запросе.
5. Если реестр узлов не настроен, интерфейс прямо сообщает об этом и не создаёт вымышленные серверы. Оператор отдельно устанавливает агент, проверяет его TLS-идентичность и подключает закрытый реестр фиксированных HTTPS-адресов с доверенным CA и клиентским сертификатом. Адреса агента и закрытые ключи в браузере не показываются.
6. Доступность наблюдателя не означает готовность репликации, сохранность копии или разрешение переключения. Если на агенте включён закрытый список компонентов, кнопка «Компоненты этого узла» открывает отдельное наблюдение за ними. Установка агента через SSH и переключение роли из страницы мониторинга не выполняются; пароль SSH здесь не запрашивается. Для решения о переключении нужны отдельные проверки данных, прекращения записи на прежнем узле и плана возврата.

Компоненты выбранного узла: healthcheck, версии и ресурсы

1. Откройте «Компоненты этого узла» на карточке сервера: /ui/nodes/{node-id}/components. Показан только закрытый список служб, разрешённых оператором для этого агента, не весь Docker. Старый агент без этой возможности продолжает показывать показатели хоста, а страница компонентов сообщает «не настроено».
2. Карточка показывает состояние Docker отдельно от healthcheck. «Запущен» не означает, что проверка здоровья пройдена. Ошибка healthcheck остаётся видна даже при успешно прочитанном снимке. Отсутствие healthcheck или версии отмечается явно; данные не подставляются из имени или тега образа.
3. Нажмите имя компонента или «Открыть мониторинг»: /ui/nodes/{node-id}/components/{component-id}. CPU 100% соответствует одному ядру и может превышать 100%. Память включает файловый кэш, лимит Docker не является квотой почтового ящика. PIDs — процессы и потоки; сеть и блочный ввод-вывод — накопленные байты, не скорость, не объём писем и не свободное место.
4. Сверяйте время наблюдения, срок свежести и время измерения Docker. Снимок действителен 5 секунд; статистика могла быть измерена до 30 секунд до наблюдения. Это не история мониторинга. Просроченные данные не показываются как текущие. «Нет данных» отличается от измеренного нуля.
5. В разделе версий отдельно указаны версия ПО, релиз Blackhole, OCI-версия и revision из меток конкретного образа. «Неизвестна» означает отсутствие подтверждённой метки, а не ошибку установки. ID образа — локальная идентичность Docker, не digest манифеста реестра. Метки не доказывают версию работающего бинарника или совместимость обновления.
6. Метрики привязаны одновременно к полным ID контейнера и образа; при изменении идентичности их нельзя смешивать со старой карточкой. Для просмотра требуется то же глобальное security.configuration.read. URL агента, секреты, окружение, журналы и содержимое томов не раскрываются. Кнопок перезапуска, установки и переключения роли здесь нет; готовность репликации не подтверждается.

Переименовать существующую локацию

1. Откройте «Инфраструктура → Локации», затем карточку нужной локации и «Переименовать локацию».
2. Введите отображаемое название и нажмите «Сохранить название». Меняется только название: IP, hostname, узлы, хранилища и службы остаются прежними; перезапуска нет.
3. Нужен глобальный администратор либо глобальное право system.location.manage. Запрет имеет приоритет; доменное право и роль куратора ИБ не разрешают изменение. Если кнопки нет, проверьте права и наличие миграции location_management.sql.
4. При конфликте версии заново откройте карточку и проверьте чужое изменение. Переименование записывается в аудит как admin.location.rename. Эта форма не создаёт локацию и не подключает новый узел.

Проверить топологию

1. Откройте инфраструктуру и сверьте расположения, узлы, компоненты и хранилища с утверждённой схемой развёртывания. Не путайте отсутствие метрики с исправным состоянием.
2. При регистрации хранилища проверьте тип, путь или адрес, профиль, доступность и права сервисных процессов. Используйте согласованный идентификатор и не помещайте пароль в название ресурса.
3. После сохранения проверьте доступ с узла, который фактически читает и записывает данные. Создайте тестовый ящик в предназначенном профиле и проверьте запись и чтение письма.
4. Зафиксируйте зависимость от DNS, базы, прокси, хранилища и сети. Для каждого критического компонента должен быть понятен способ восстановления.

Ограничения интерфейса

Отказоустойчивость и резервирование

Проверка и ошибки

Экран инфраструктуры

Экран создания хранилища