GUI «не принимает пароль»: сначала латентность модели

Симптом

• Вход в GUI https://<NODE_IP>:10443 не проходит: страница логина «крутится», затем форма возвращается, иногда с сообщением об ошибке аутентификации. Пароль при этом заведомо верный.
• Плитки/статусы в GUI выглядят зелёными — узел в модели ONLINE, ошибок по железу нет.
• Время от клика «Войти» до ответа — десятки секунд, а не мгновенно.
• После перезагрузки кластера или сброса питания узел может пускать одного оператора и не пускать другого; в браузере — «слишком долго» и обрыв соединения.
• В журнале веб-слоя модели видно, как запрос сгенерировал тело не сразу: generated 0 bytes in 30131 msecs и следом SIGPIPE от клиента, который уже закрыл соединение.
• S3 при этом может работать: подписанные запросы идут с самой ноды и не требуют интерактивного входа. То есть «GUI не пускает» и «S3 сломан» — разные симптомокомплексы, их нельзя смешивать.

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

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

1. Сколько длится ответ модели. Замеряется без разбора тела, только время: bash sudo curl -sk -o /dev/null -w '%{http_code} %{time_total}\n' \ --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ https://127.0.0.1:8443/model/_status/ Ожидается 200 и время в десятках миллисекунд (на исправном стенде мы видели ~20 мс). 200 за ~30 000 мс — это и есть «модель ждёт mongo», а не медленный браузер.

2. Реплики management_model — есть ли кворум: bash sudo mongo --quiet --port 27017 --tls --tlsAllowInvalidCertificates \ --tlsAllowInvalidHostnames \ --tlsCertificateKeyFile /opt/ampli/cfg/mongo/ssl/management_model/mongodb_node1.pem \ --eval 'db.adminCommand({replSetGetStatus:1}).members.forEach( function(m){print(m.name, m.stateStr, m.health)})' Ожидается: ровно один PRIMARY, два SECONDARY, у всех health=1. Если у соседей (not reachable/healthy) и health=0 — кворума нет.

3. Полнота состава служб на каждой ноде. marvinservices поднимает только то, что описано в services.cfg: bash sudo md5sum /opt/ampli/cfg/marvin/services.cfg sudo grep -c '^\[' /opt/ampli/cfg/marvin/services.cfg sudo grep -c '^\[arakoon_' /opt/ampli/cfg/marvin/services.cfg sudo grep -c '^\[mongodb_' /opt/ampli/cfg/marvin/services.cfg Ожидается на каждой ноде: одинаковый md5, arakoon ≥ 1, mongodb ≥ 3. Разные значения на нодах — признак неполного прогона установщика.

4. Провижининг arakoon на месте: bash sudo ls /opt/ampli/cfg/marvin/provision/arakoon/ | wc -l Ожидается не 0. 0 означает, что каталога нет вообще — службам нечего запускать.

5. Сколько mongod реально живёт на ноде: bash pgrep -fa '[m]ongod' | wc -l sudo ss -ltnp | grep -E '2701[789]' Ожидается 6 процессов на ноду (гейт приёмки — 6 mongod на каждой ноде) и слушающие порты 27017 (management), 27018 (environment_data), 27019 (federated). Меньше — та же картина «модель без кворума».

6. Общее состояние служб узла: bash service marvinservices groupstatus systemctl --failed --no-pager Ожидается: все группы в рабочем состоянии, failed units нет. Строка ...fail! у группы — прямое указание, что служба не стартовала, а не «висит».

Причина

Механизм: модель — тонкий клиент к mongo

/model/_status/ отвечает 200 быстро только тогда, когда у модели есть рабочая реплика management_model. Если реплик нет или кворум потерян, обработчик ждёт, пока драйвер выберет Primary, и отдаёт пустое тело по таймауту. Отсюда две вещи, которые путают оператора:

• HTTP-код всё равно 200 — «модель жива»;
• время ответа ~30 с — и GUI, который ходит в модель, выглядит как «неверный пароль»: форма отправляет запрос, ждёт, получает обрыв и показывает ошибку входа.

Почему реплик нет после перезагрузки

Типовой дефект неполного прогона установщика: на не-мастер нодах конфиги mongod проваживаются для всех трёх баз, но в services.cfg регистрируется только одна база (environment_data), а arakoon не проваживается вообще:

/opt/ampli/cfg/mongo/management_model/mongodb_<node>.yml     есть
/opt/ampli/cfg/mongo/federated_model/mongodb_<node>.yml      есть
/opt/ampli/cfg/mongo/environment_data/mongodb_<node>.yml     есть
/opt/ampli/cfg/marvin/provision/arakoon/                     каталога нет

services.cfg на ноде: только [mongodb_<node>] -> environment_data

marvinservices не знает служб, которых нет в services.cfg, поэтому старт их не поднимает (groupstatus → …fail!). В итоге management_model остаётся с одной живой репликой на мастере. Пока процессы живы с момента установки, всё работает; после любой перезагрузки кластера или сброса питания реплик становится меньше, и модель начинает ждать.

Почему это выглядит как проблема пароля

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

Что здесь гипотеза

Механизм кворума и services.cfg подтверждён живыми запросами и логами (uwsgi-model.log, groupstatus). Если латентность высокая при полном кворуме (PRIMARY + 2 SECONDARY, health=1) — это другая причина, и её надо искать отдельно; в таком случае гипотеза «перегруженный диск/сеть на стороне mongo» проверяется временем ответа replSetGetStatus и загрузкой диска модели.

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

Правильный путь — привести состав служб к штатному, а не «поднять mongo руками навсегда».

1. Зафиксировать состояние и бэкап (до любых работ): bash sudo cp -a /opt/ampli/cfg/marvin/services.cfg \ /root/services.cfg.bak-$(date -u +%y%m%d-%H%M) Ожидается: копия вне каталога продукта.

2. Прекратить ручные правки и запуски. Если mongod уже запускали руками — записать, что именно запускали: ручной процесс живёт до перезагрузки и маскирует дефект.

3. Переустановить ноду в рамках чистого прогона — это штатный путь для неполного services.cfg. Правка файла руками дефект маскирует и не переживёт переустановку. При прогоне обязательны фазы установки ОС на остальные ноды (-I -n <N>) и полный набор ключей для многонодового кластера; сокращать набор «чтобы быстрее» нельзя.

4. После прогона пройти гейт приёмки (см. «Проверка») — на каждой ноде, а не на одной.

5. Проверить вход в GUI уже после гейта: 200 на /model/_status/ в десятках мс, вход оператора без задержки.

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

Временная мера, не штатно, с планом замены: поднять недостающие mongod вручную из их конфигов, чтобы вернуть кворум до окна переустановки:

sudo -u mongodb /usr/bin/mongod \
  -f /opt/ampli/cfg/mongo/management_model/mongodb_<node>.yml
sudo -u mongodb /usr/bin/mongod \
  -f /opt/ampli/cfg/mongo/federated_model/mongodb_<node>.yml

Пометки к этому пути:

• процессы живут до перезагрузки — это аварийная мера, а не решение;
• запускать по одному, проверяя replSetGetStatus после каждого, чтобы не устроить вторую проблему из-за конфликта портов;
• параллельно готовить окно переустановки; после неё ручные процессы должны исчезнуть.

Отдельно: не менять пароль и не пересоздавать учётные записи в этот момент. Это лишняя запись в больную модель; сначала кворум, потом пароль.

Проверка

• /model/_status/ → 200, time_total в десятках миллисекунд (не 30 000).
• replSetGetStatus → один PRIMARY, два SECONDARY, у всех health=1.
• services.cfg: одинаковый md5 на всех нодах, arakoon ≥ 1, mongodb ≥ 3 на каждой.
• pgrep -fa '[m]ongod' | wc -l → 6 на ноде; порты 27017, 27018, 27019 слушают.
• service marvinservices groupstatus → без fail!; systemctl --failed пуст.
• Вход в GUI оператором → форма принимает пароль, ответ без заметной задержки.
• В uwsgi-model.log новых строк generated 0 bytes in … msecs нет.

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

• Гейт приёмки после каждой установки/переустановки: кворум модели, 6 mongod на ноде, полный и одинаковый services.cfg, /federated/_status/ = 200.
• Не сокращать фазы установщика для многонодового кластера: именно пропущенная фаза установки ОС на остальные ноды даёт неполный services.cfg.
• Не править services.cfg руками — это маскировка; дефект вернётся после переустановки.
• Проверять после каждого ребута кластера вход в GUI и время ответа модели: это дешёвая проверка, которая ловит потерю кворума раньше заказчика.
• Не путать с NTP и сертификатами: «GUI не пускает» ≠ «S3 403». Сначала латентность модели, потом часы, потом TLS. Полевой health-check за 30 секунд проверяет и то, и другое.

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

• Вендор: Управление системой (GUI) (дата доступа 2026-11-07)
• Вендор: Software Documentation Center 7.3 (дата доступа 2026-11-07)
• Наша практика (обезличено): класс «GUI не принимает пароль» — модель ждёт mongod, латентность ~30 с вместо ~20 мс; восстановление после полной потери питания шло порядком BMC → mongod → модель → сеть → NTP.
• Обновлено: 2026-11-07.