Кейс: федерация не смоделирована — install-ng падает на management server

Коротко. Кластер из трёх нод ставили с нуля. Первую ноду запустили с флагом scale-out — «на всякий случай, потом добавим остальные». Установка дошла до конфигурирования и упала с No suitable management server found. Причина не в сети и не в паролях: флаг scale-out убрал федеративную базу из списка создаваемых кластеров, а без неё искать management server негде.

1. Ситуация

Задача: чистый кластер ActiveScale из трёх нод, одно окружение, одна площадка. План — путь A: первая нода создаёт окружение и федерацию, остальные добавляются к ней.

Фактически первую ноду запустили с набором флагов, в который попал -S (scale-out). Логика была такая: «нод будет три, значит ставим как масштабирование». Это самая частая подмена понятий в установке: scale-out — это добавление к существующей федерации, а не «кластер из нескольких нод».

2. Что видели

install-ng прошёл импорт и часть фаз, затем остановился на конфигурировании.
В логе — configuring machines failed: No suitable management server found.
Маркер /tmp/.unattended_install_finished появился с ненулевым кодом.
Узел остался в NOTCONFIGURED, часть приложений — в NOTCONFIGURED, остальные подзадачи — в QUEUED.
/federated/_status/ не отвечал: ни 200, ни ошибки приложения — просто некуда идти.

Первая мысль была про сеть (management-порт, DNS) и про пароли. Проверка сети показала норму: адреса, маршруты, доступность — всё на месте. Это важный момент: сообщение про «management server» не означает «проблема с сетью управления».

3. Механизм

В install-ng флаг scale-out превращается в skip_federated_db:

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 из списка создаваемых кластеров модели. Дальше при конфигурировании продукт ищет management server через федерацию — а её в модели нет. Отсюда и текст ошибки: он честный, просто указывает не туда, куда кажется.

Ключевой момент для понимания: федерация — не «настройка», а сущность модели. Её отсутствие нельзя дописать руками после прогона: модель уже собрана без этого кластера, и расширять нечего.

4. Как это доказали

Read-only проверки, которые отделяют «сеть» от «модели»:

# какие кластеры модели реально существуют
sudo -n 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/ | head -c 2000

В ответе не было federated_model — только management и environment. Это и есть корень.

Дополнительно:

ss -ltnp | grep 27019 — федеративный mongod не слушает, потому что его не должно было быть;
в выводе установщика видно, что фаза конфигурирования пошла дальше импорта без федерации;
флаги запуска сохранены в истории команд на ноде — -S присутствовал.

Три независимых признака, один вывод. Гадать не пришлось.

5. Что сделали

Чистый повторный прогон без -S, в правильном порядке:

Импорт окружения и начальных сущностей.
Инициализация модели — на этом шаге создаётся federated_model.
Проверка, что федерация есть в модели (тот же GET к /model/mongocluster/).
Только после этого — фазы приложений, storage column, storage targets.
Добавление остальных двух нод и расширение кластеров.

Дожима после падения не делали сознательно: субъект (федерация) не создан, поэтому «продолжить с места» означает «продолжить без него». Проверено практикой: догон тех же фаз на таком состоянии даёт ту же ошибку, только позже.

После успешного прогона: /federated/_status/ → 200 за единицы миллисекунд, три приложения в каждом монгокластере ONLINE, машины ONLINE, ни одного NOTCONFIGURED.

6. Проверка результата

Гейт	Ожидаемое значение
`/federated/_status/`	`200`, время ответа единицы миллисекунд
Монгокластеры в модели	management, environment, federated — по три приложения `ONLINE`
`replSetGetStatus` для федерации	один `PRIMARY`, два `SECONDARY`
Машины	все `ONLINE`, `bootmode: DISK`
Приложения	0 в `NOTCONFIGURED`
Колонка	`CONFIGURED` / `ACTIVE`

Если время ответа федерации измеряется десятками секунд — это уже другой класс проблемы (порт, конфиг, топология), а не «федерации нет».

7. Уроки

-S — это «я добавляюсь к чужой федерации», а не «нас много». Много нод в одном окружении — это путь A, первая нода без -S.
Текст ошибки указывает на следствие. «No suitable management server» в этом сценарии значит «нет федерации в модели», а не «не тот адрес».
Отсутствие сущности в модели не догоняется флагами. Проверять состав кластеров до конфигурирования дешевле, чем переустанавливать.
Флаги запуска надо фиксировать в журнале прогона. В этом разборе именно сохранённая строка запуска дала ответ быстрее всего остального.
Сначала read-only проверка модели, потом сеть. Сеть проверялась первой и была в порядке — это стоило времени.

8. Что не стоит делать

Дописывать federated_mongo_connection_string в group_vars «чтобы пошло». Это лабораторный костыль, который потом конфликтует со штатной логикой.
Переиспользовать mongo_federated_replicaset от management-кластера: модель ожидает отдельный репликасет.
Класть в каталог переменных бэкапы .orig/.bak: ansible читает все файлы, и бэкап побеждает актуальный конфиг.
Пытаться «починить» федерацию на живой системе, если она не создавалась: её там нет.

Источники

Software Documentation Center (доступ 2026-11-07)
Наша практика (обезличено): прогоны установки на 3-нодных стендах, разбор падения No suitable management server; версия и сборка — из журнала прогона, здесь не приводятся.
Обновлено: 2026-11-07.