install-ng: No suitable management server found

Коротко. install-ng падает на configuring machines failed: No suitable management server found, когда федеративная БД есть физически, но не смоделирована: кластера federated_model в модели нет, /federated/ не отрендерен, а federated.cfg указывает на локальный порт, где на двух нодах из трёх никто не слушает. Типичная причина — первая нода поставлена с флагом -S. Для кластера в одном окружении нужен путь A: первая нода без -S.

Симптом

Прогон install-ng останавливается на фазе configure машин с текстом configuring machines failed: No suitable management server found; код возврата при этом может быть 0 — доверять ему нельзя.
GET /federated/_status/ с узла отвечает 404 (в nginx нет location /federated/) либо висит ~30 секунд.
В модели кластеров есть только management_model и environment_data; federated_model отсутствует, приложения federatedhaproxy тоже нет; в документе environment base_system=false и поля federateddbconnection нет.
Узлы остаются NOTCONFIGURED, часть подзадач — в QUEUED.
В group_vars/all/marvin.yml может лежать federated_mongo_connection_string на локальный порт — след ручной подпорки с прошлых сессий.

Что проверить первым (read-only)

Модель — по mTLS, сертификаты продукта root-only, поэтому запросы на узле, root.

Есть ли федеративный кластер в модели: bash sudo curl -sk --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ https://127.0.0.1:8443/model/mongocluster/ | jq -r '.mongocluster[].name' Ожидается три имени, включая federated_model. Если его нет — федерация не смоделирована.
Что в environment: bash sudo curl -sk --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ https://127.0.0.1:8443/model/environment/ | jq '{base_system, federateddbconnection}' Ожидается согласованность с выбранным путём: для пути A федерация локальна; для пути B — base_system=true и заполненный federateddbconnection.
Отвечает ли федеративный endpoint (на узле, root): bash sudo curl -sk --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ https://127.0.0.1:8443/federated/_status/ -w '\nHTTP=%{http_code} time=%{time_total}s\n' Ожидается 200 и < 50 мс. 404 — location не отрендерен; 30 000 мс — федерация/порт не та.
Куда смотрит федерация: bash sudo grep -E 'port|replicaset|host' /opt/ampli/cfg/marvinweb/federated.cfg sudo grep -n 'federated_mongo_connection_string' /opt/ampli/provision/group_vars/all/marvin.yml Ожидается порт 27019 и репликасет federated_model. Адрес 127.0.0.1:27019 допустим только там, где федеративный mongod действительно слушает.
Слушает ли порт на каждой ноде: ss -ltnp | grep 27019 → процесс есть на всех трёх нодах, а не на одной. Ожидается три слушателя (по одному на ноду).
История модели (только чтение): были ли когда-либо документы кластера federated_model — если нет ни одной ревизии, федерация не создавалась моделью, а поднималась руками.

Причина

Как это получается

install-ng при конфигурировании машин ищет management server через федерацию. Федерацию строит модель — и только если её создание не отключено флагом.

Цепочка на чистом прогоне выглядит так:

Первая нода ставится с -S (is-scale-out). В коде: is_scale_out = options.is_scale_out and options.install_type in ["combined"], дальше management.initialize(..., skip_federated_db=is_scale_out).
skip_federated_db=True убирает кластер federated_model из списка создаваемых — это штатное поведение флага -S: одиночная scale-out установка не строит федерацию локально.
Штатная федерация для scale-out идёт другим путём: добавляется приложение federatedhaproxy и переконфигурируется marvinweb (включается /federated/). Гейт для этого — environment.federateddbconnection («connection info for a non-local federated database»).
Если federateddbconnection не задан (и base_system=false), шаг 3 не срабатывает: federatedhaproxy удаляется как взаимно исключающий, /federated/ не рендерится.
Add-node остальных нод расширяет существующие кластеры модели. Кластера federated_model нет — расширять нечего. Федерация остаётся там, где её подняли руками: federated.cfg на всех нодах указывает на 127.0.0.1:27019, а на двух нодах по этому адресу никто не слушает.

Итог: конфигурация «первая нода -S, затем add-node» для кластера в одном окружении не создаёт моделируемую федерацию — и configure не находит management server.

Что это не лечит

Перезапуск служб, «догон» фаз -m -a и правка federated.cfg руками не создают кластер в модели. Они могут временно снять симптом на одной ноде, но модель остаётся без федерации, и следующий configure вернёт ту же ошибку.

Решение (штатное)

Выбрать путь до прогона, а не после. Разница путей — не в «свежести» установки, а в том, где живёт федеративная БД; подробно — Федерация: путь A и путь B.

Путь A — федерация внутри окружения (один кластер, одна площадка).

Первую ноду ставить без -S: тогда кластер federated_model создаётся в модели и конфигурируется локально, marvinweb получает /federated/.
Остальные ноды — add-node, затем догон с -x: расширение кластеров само добавит приложения mongodb_federated_node2/3 и разгонит федерацию на все ноды.
Требование: не меньше трёх ONLINE MGMT-нод, иначе расширение не выполнится.

Путь B — федерация в отдельной базовой системе (несколько окружений, performance scale-out).

Одна инсталляция помечается base_system=true и владеет федеративной БД.
Остальные ставятся с -S и подключаются через federateddbconnection.
Данные подключения штатно добываются на базовой системе скриптом /opt/ampli/scripts/supportability/pre_scaleout_info.py — он отдаёт JSON с endpoints федерации, ssl-ключом/сертификатом, именем политики DSS и deployment_id.

Общее для обоих путей. Перед стартом снять старый маркер /tmp/.unattended_install_finished и убедиться, что в group_vars нет .orig/.bak-файлов: ansible грузит все файлы каталога, и бэкап побеждает. Запуск — полной командой с --product activescale (см. install-ng: фазы и флаги).

Если штатный путь недоступен

Не штатно, временная мера. Поднять федеративный mongod на одной ноде вручную и прописать строку подключения в group_vars — это лабораторная подпорка, а не модель. Она объясняет, почему /federated/ иногда «работает» на одной ноде и не работает на остальных. Пометка обязательна: такая конфигурация не переживёт чистый прогон и не должна переноситься на площадку; план замены — путь A или B с переустановкой.

Проверка

GET /federated/_status/ → 200, время < 50 мс (30 000 мс — topology-hang, порт/адрес не тот).
replSetGetStatus для federated_model: один PRIMARY + два SECONDARY.
ss -ltnp | grep 27019 → слушатель на каждой из трёх нод.
pgrep -af mongod → три процесса на ноду.
В services.cfg есть секции федеративных mongodb.
install-ng догон фазы configure машин завершён: узлы CONFIGURED/ONLINE, подзадач в QUEUED нет.
В модели присутствуют federated_model и federatedhaproxy; в environment согласованы base_system и federateddbconnection.

Профилактика

Флаг первой ноды — решение, а не привычка. -S на первой ноде пути A — прямая причина этой ошибки.
Чек-лист до старта: есть ли federated_model в модели (или base_system+federateddbconnection для пути B), нет ли в group_vars ручной строки подключения и бэкапов, снят ли маркер прошлого прогона.
Не переносить лабораторные подпорки на площадку: ручной mongod на 27019 и строка в group_vars маскируют отсутствие модели.
Код возврата не доказательство. Проверять фактом: список кластеров, список приложений, /federated/, состояние машин.
Порты федерации (27017 management, 27018 environment_data, 27019 federated) проверить живьём, а не угадывать: конфликт портов на ноде с environment_data даёт тот же симптом.

Источники и дата

Quantum, Software Documentation Center (ActiveScale 7.3): https://qsupport.quantum.com/kb/flare/Content/ActiveScale/Software/Content/Index_Files/Index_Software.htm (дата доступа: 2026-11-07).
Наша практика, обезличено: разбор федерации на 3-нодном стенде — первая нода ставилась с -S, федерация поднималась вручную на одной ноде, install-ng падал на configure машин.
Обновлено: 2026-11-07.