mongod не поднялся: модель тормозит, GUI молчит

Коротко. Model API и GUI читают модель из MongoDB; если mongod после включения не собрал реплика-сет, каждый запрос висит до таймаута и GUI выглядит «сломанным», а форма пароля отвечает через десятки секунд. Сначала проверяется, есть ли mongod и PRIMARY, затем — сеть между нодами и время. Переустановка не нужна: порядок восстановления — питания/BMC → mongod → модель → сеть → NTP.

Симптом

Админский GUI (порт 10443) открывается, но страницы грузятся долго или показывают ошибку; иногда «GUI не принимает пароль».
Model API (https://<MGMT_IP>:8443/model/) отвечает крайне медленно или отдаёт 500/таймаут.
События модели сыпятся пачкой: MONGO_REPLICA_STATUS_FAILED, MODEL_MARVINWEB, MODEL_MGMTSERVERS, TASKMANAGER_STALLED.
Часто всё это — после полного пропадания питания стойки или после включения ноды раньше сети.

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

Все команды — с ноды, root/sudo; сертификаты продукта root-only, поэтому без sudo mTLS-запрос даёт HTTP=000.

Процессы mongod на ноде: bash pgrep -af mongod sudo ss -ltnp | grep -E ':2701[789]' Ожидается три процесса и листенеры на 27017, 27018, 27019 (порты env/fed могут быть переставлены местами — см. «Причина»). Ноль процессов — дальше пункт 2.
Карта реплика-сетов из конфигов продукта: bash for f in /opt/ampli/cfg/mongo/*/*.yml; do echo "== $f"; sudo grep -E 'port|replSetName|bindIp' "$f" done Ожидается по одной записи на management_model, environment_data, federated_model.
Есть ли PRIMARY. replSetGetStatus читается только через venv продукта (py2 + TLS, PEM /opt/ampli/cfg/mongo/ssl/<rs>/mongodb_node1.pem) — нужен инженер: у L1 такого доступа обычно нет. Ожидается myState=1 (PRIMARY) хотя бы на одной ноде и три члена реплики. Если члены есть, но один помечен (not reachable/healthy) h:0 — процесс жив, но недоступен по сети, см. MACHINE_DOWN при живой ноде.
Латентность модели (главный признак): bash sudo curl -sk --cert <CERT> --key <KEY> https://127.0.0.1:8443/model/ \ -w '\nHTTP=%{http_code} time=%{time_total}s\n' Норма — сотни миллисекунд и 200. Значение порядка 20–30 с на простом запросе означает ожидание mongod (pymongo ждёт Primary до serverSelectionTimeoutMS), а не проблему GUI.
Службы узла и время: bash systemctl --failed --no-pager timedatectl | grep -E 'synchronized|NTP' sudo ntpq -p Ожидается пустой список failed, synchronized: yes, в ntpq -p строка с * и стратум < 16.

Причина

1. Модель — это MongoDB, а не «GUI»

Model API и samurai GUI читают документы машины/окружения/события из modeldb в реплика-сете management_model. Пока реплика-сет не выбрал PRIMARY, pymongo ждёт его до 30 секунд и только потом возвращает ошибку. Отсюда два классических симптома: «GUI не принимает пароль» (форма реально ждёт ответа модели) и «модель тормозит» (каждый запрос длинный, а не один).

2. После потери питания порядок включения нарушен

Нода, включённая раньше, чем BMC и сеть готовы, стартует службы в окружении без соседей: mongod поднимается в одиночку, кворум не собрать, PRIMARY не выбирается. Симметричная проблема — нода выключилась первой и потеряла кворум, из-за чего переизбрание прошло без неё.

3. Сеть хранения — часть кворума

Члены реплики видят друг друга по storage-сети (<STORAGE_NET>). Разрыв кольца (VLAN порта свича, кабель) даёт ровно ту же картину «модель молчит», хотя нода ONLINE по mgmt. Это отдельный класс — разбирается в статье про MACHINE_DOWN.

4. Время

Сертификат и служебные подписи требуют согласованного времени. Уехавшие часы проявляются не 403 в S3, а медленными отказами внутри кластера; проверка NTP идёт в том же списке, потому что «починили GUI, а через неделю снова» — типично для несведённого времени на ноде.

5. Гипотеза: порты env/fed разъезжаются

На части инсталляций environment_data и federated_model занимают порты не в привычном порядке 27017/27018/27019, а меняются местами — это следствие порядка создания приложений в install-ng (гипотеза; доказательство — конфиги cfg/mongo/*/*.yml и services.cfg на нескольких чистых прогонах, которых у нас нет). Практический вывод один: не «угадывать» порт по номеру, а читать его из конфига (пункт 2 в списке проверок).

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

Питание и BMC. Включить BMC (IPMI) у всех нод, дождаться ipmitool chassis power status → Chassis Power is on, затем включать сами ноды. Для одного узла — ipmitool chassis power on.
Дать реплике собраться. Не запускать install-ng и не трогать модель на первой минуте: mongod выбирает PRIMARY, когда доступны все члены. Проверять пунктом 3 и только после этого переходить дальше.
Если mongod не стартовал — службу поднимает продукт, а не ручной systemctl start mongod. Штатный путь: перезапуск службы продукта на ноде (marvinservices) либо прогон configure машины из Model API (POST /model/machine/<MGUID>/action/configure/) — он переприменяет конфигурацию приложений ноды.
Модель. После появления PRIMARY проверить /model/ (200, быстро) и затем GET /model/machine/ — все ноды в ожидаемых статусах.
Сеть. С ноды ping до storage-адресов остальных нод; если недоступно — см. статью про storage-кольцо, до этого модель не стабилизируется.
NTP. Синхронизация включена, стратум < 16; при расхождениях время сводится штатно — см. NTP и время, до этого модель и S3 остаются нестабильными.
Догнать install-ng, если прогон был оборван потерей питания: догон без -S (-t combined -A -T -d), дождаться маркера /tmp/.unattended_install_finished с exit code 0.

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

Временная мера, не штатно. Если configure ловит 423 LOCKED — снять залипшую задачу: POST /model/task/<TASK_GUID>/action/terminate/ и повторить. Если 503 No replica set members match "Primary()" — это транзиентный кэш сервера (клиент помнит старый адрес), повторять через curl на 127.0.0.1:8443 с sudo, а не через GUI. Обе меры — только чтобы разблокировать разбор; причину (кворум, сеть, время) они не устраняют.

Проверка

pgrep -af mongod → 3 процесса; ss -ltnp → три листенера mongod.
Реплика: myState=1 на одной ноде, остальные 2, ALL_HEALTHY.
https://127.0.0.1:8443/model/ → 200 за доли секунды (не десятки секунд).
GUI 10443 отвечает на вход без паузы; форма пароля возвращает ответ сразу.
systemctl --failed пуст, timedatectl → synchronized: yes.
Новых MONGO_REPLICA_STATUS_FAILED нет за 20–30 минут.

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

Порядок включения площадки зафиксировать в регламенте: BMC/сеть → ноды → проверка кворума → задачи.
Держать в мониторинге метрику латентности /model/: рост до секунд — ранний сигнал кворума.
Следить за storage-кольцом (см. MACHINE_DOWN) до того, как оно превратится в «модель молчит».
Не переустанавливать ноду из-за медленного GUI: сначала проверка кворума и времени.

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

Software Documentation Center (доступ 2026-11-07).
Наша практика (обезличено): восстановление 3-нодного кластера после полной потери питания — по шагам, без переустановки; наблюдение латентности модели ~20–30 с при неподнявшемся mongod против долей секунды в норме.
Обновлено: 2026-11-07.