Узел красный / NOTCONFIGURED: с чего начать

Симптом

• Плитка узла в GUI samurai красная; в модели status: NOTCONFIGURED.
• Часть приложений узла тоже NOTCONFIGURED, часть ONLINE; у здоровых узлов рядом в том же состоянии — только штатно выключенные (DISABLED).
• Узел отвечает по mgmt-IP, SSH работает, диски видны — то есть машина жива, «красный» только статус.
• Задачи configure в очереди висят QUEUED с пустым executor_machine либо одна из них FAILURE.
• Иногда к этому добавляются события вида MODEL_*, TASKMANAGER_STALLED — это шум, порождённый тем же моментом, а не отдельные проблемы.

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

Все mTLS-запросы к модели — на узле и только под root: клиентские сертификаты продукта root-only, без sudo curl даёт HTTP=000. Удобный эквивалент — консоль продукта sherpa (cli.ha.get(...) возвращает JSON-строку).

1. Статус машины и приложений: bash sudo /opt/ampli/apps/marvintaskmgr/venv/bin/python \ -c "import json; from marvin_lib.network import ha; \ d=json.loads(ha.get('/model/machine/')); \ print [(m['name'], m['status']) for m in d['machine']]" Ожидается ONLINE у всех, кроме узла, который разбираем. Для самого узла — какие application[].status не ONLINE и не DISABLED.

2. Последняя цепочка configure и её упавший шаг: bash sudo /opt/ampli/apps/marvintaskmgr/venv/bin/python \ -c "import json; from marvin_lib.network import ha; \ d=json.loads(ha.get('/model/task/?limit=200')); \ print [(t.get('status'), t.get('action'), t.get('date_created')) \ for t in d['task'] if t.get('action') == 'configure'][:20]" Ожидается: у последней задачи status: SUCCESS; если FAILURE — в parameters.configuration.applicationname написано имя виновника (например nic, disk, scalerd). Это и есть предмет разбора.

3. Что раскатывалось на узле (лог плейбуков, только чтение): bash sudo grep -nE 'failed|FAILED|fatal' /opt/ampli/var/log/taskmgr/playbooks.log | tail -20 Ожидается: строки с failed=0 у успешных шагов; последняя пачка — с конкретной пьесой и её выводом (например networkinterfaces.yml → failed=1).

4. Не запустилась ли служба (агент узла): bash sudo grep -nE "couldn't launch|Exit code" /opt/ampli/var/log/marvin/service_debug.log | tail -10 Ожидается: пусто. Строка couldn't launch <служба> … Exit code: 1 прямо называет службу, из-за которой приложение не поднялось.

5. Журнал самой службы — настоящая причина: bash sudo ls -t /opt/ampli/var/log/<служба>/ | head -3 sudo tail -30 /opt/ampli/var/log/<служба>/<служба>_<GUID>.log Ожидается: нормальный старт. Частый пример — set_lock: could not lock file "/opt/ampli/var/run/<служба>//.lock": Resource temporarily unavailable (is the server already running?): служба не стартует из-за занятого замка, оставшегося от прежнего процесса.

6. Что узел вообще собирается применить (без применения): 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/machine/<NODE_GUID>/action/has_unapplied_changes/" Ожидается JSON вида {applied_version, model_version, has_unapplied_changes}. Значение has_unapplied_changes: true = в модели есть правки, не доехавшие до узла.

⚠️ Если has_unapplied_changes не отличается от зелёных соседей, а расхождение applied_version / model_version у красного узла даже меньше — версии к «красноте» отношения не имеют, гипотезу «узел отстал по версии» строить не нужно.

Причина

1. NOTCONFIGURED — это флаг операции, а не результат проверки

Продукт ставит машине NOTCONFIGURED перед тем, как менять её конфигурацию, и возвращает ONLINE по завершении. Смысл: пока статус такой, другие операции над узлом не должны вмешиваться. Прерывание (сессия упала, задачу сняли, правили руками) оставляет флаг включённым — узел «красный», хотя с ним всё в порядке.

2. «Красная» машина обычно красная не сама по себе

machine.configure проходит по всем приложениям узла по одному (порядка десятков секунд на приложение). Если падает хотя бы одно, узел заканчивает цепочку в NOTCONFIGURED — даже если остальные приложения настроены. Поэтому искать надо конкретное приложение и конкретную службу, а не «почему красная машина».

3. Причины на уровне приложения — типовые

• Занятый замок: служба не может стартовать, потому что замок держит чужой/старый процесс.
• Битый конфиг: значение в файле не соответствует модели, и рендер конфигурации падает (пример ниже). Продукт при этом подхватывает текущие значения с узла, поэтому лабораторные правки в конфигах не затираются — но и несовпадение не исправляется само.
• Нет исполнителя: задача не находит машину, которая может её выполнить; в задаче executor_machine: [], а не «забитая очередь». Проверяется по числу задач в QUEUED — если при executor_machine: [] остальные задачи нормально отрабатывают, очередь чистая и дело в адресации.

4. Узел в NOTCONFIGURED не может сконфигурировать сам себя

Машина, у которой статус NOTCONFIGURED, не исполняет machine.configure для себя: её собственный агент ещё не настроен. Задача в такой ситуации падает за секунды с executor_machine: []. Это петля, а не ошибка входа.

5. Класс «битый конфиг сети» — показательный пример

Если в /etc/network/interfaces.d/marvin у порта есть address, но нет netmask, рендер падает с ValueError: Insufficient settings to configure interface → networkinterfaces.yml failed=1 → приложение nic FAILURE → machine.configure FAILURE → все дочерние подзадачи остаются QUEUED → узел NOTCONFIGURED. Снаружи это выглядит как «все приложения NOTCONFIGURED и нет исполнителя» — а настоящая причина в одной строке лога плейбука. Проверка has_unapplied_changes и getconfig показывает, что узел собирается применить, и расхождение видно до запуска.

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

Причина №5 подтверждена конкретным логом; №1–№4 — механизм продукта, подтверждённый чтением кода продукта и живыми задачами. Если в вашем случае ни одна из них не видна в логах, остаётся гипотеза «служба не поднялась по причине, не покрытой логами продукта» — доказать её можно только журналом службы и ps/ss по её порту.

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

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

1. Бэкап конфигурации перед любыми изменениями (вне каталога продукта): bash sudo tar czf /root/bak-configure-$(date -u +%Y%m%d-%H%M)/cfg.tgz -C /opt/ampli cfg Ожидается: непустой архив. Практика показала: продукт при настройке подхватывает текущие значения с узла и не затирает точечные правки — бэкап нужен на случай падения цепочки.

2. Убрать причину из списка выше, если она названа логом: освободить замок (после остановки зависшего процесса по журналу службы), исправить значение конфига значением из модели (не выдуманным). Делается до запуска configure, иначе цепочка упадёт на том же шаге.

3. Настроить узел штатным действием — это ровно то, что делает кнопка Configure в GUI: bash sudo curl -skL --post302 --post303 \ --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ -X POST "https://127.0.0.1:8443/model/machine/<NODE_GUID>/action/configure/?auto=True" Ожидается: задача configure в db.task со status: QUEUED → STARTED; машина уходит в CONFIGURING. Цепочка проходит приложения по одному — на узел 15–40 минут.

4. Дождаться конца и проверить, что задача SUCCESS, а не просто «статус сменился». Если падает на другом приложении — вернуться к п.1–2 с новым именем из parameters.configuration.applicationname.

5. Снять зависшую задачу, если configure отвечает 423 LOCKED: bash sudo curl -sk --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ -X POST "https://127.0.0.1:8443/model/task/<TASK_GUID>/action/terminate/" Ожидается 200; после этого повторяется п.3.

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

• Узел не может конфигурировать сам себя (п.4 «Причины»). Адресуйте задачу другой машине: нода, которая была NOTINITIALIZED, переходит в NOTCONFIGURED (исполнитель нашёлся), а мастер при этом разгружается. В all-in-one (один узел несёт управление и данные) такой машины нет — тогда нужен внешний вызов по Model API, как в п.3.
• Установщик не может догнать machine.configure по той же петле: внутри он адресует конфигурацию роли управления, которая в all-in-one и есть мастер. Временная мера — тот же прямой вызов по NODE_GUID; штатный путь — полный прогон установщика с правильно выбранными фазами. Пометка: это не штатно, план замены — штатная цепочка.
• Ручная правка файлов службы или модели «чтобы быстрее» — не решение: рендер конфигов привязан к модели, а ручные правки в файлах переживут только до следующего configure. Временная мера, только для аварийного подъёма, с фиксацией того, что именно поменяли.

Проверка

• status машины → ONLINE.
• Все приложения узла: ONLINE или DISABLED; число NOTCONFIGURED = 0.
• Последняя задача configure → SUCCESS со всеми дочерними шагами SUCCESS.
• GET …/action/has_unapplied_changes/ → has_unapplied_changes: false (или расхождение версий не больше, чем у зелёных соседей).
• /opt/ampli/var/log/marvin/service_debug.log → новых строк couldn't launch нет.
• /opt/ampli/var/log/taskmgr/playbooks.log → у пьесы, падавшей с failed=1, теперь failed=0.
• Плитка узла в GUI зелёная, и это следствие модели, а не наоборот.

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

• Не оставлять операции наполовину. Каждую configure-цепочку доводить до SUCCESS или явно снимать, а не закрывать сессию.
• Не править конфиги и модель руками на живой ноде. Ровно этот класс правок даёт следующий залип, а продукт перерисовывает свои входы сам.
• Перед массовыми работами — бэкап модели и конфигов; бэкап хранить вне каталога продукта.
• Каждое «мы это уже настроили» перепроверять после прогона установщика: продукт может переписать собственные входы (порядок загрузки, ключи, interfaces.d).
• Ставить гейт приёмки: NOTCONFIGURED приложений = 0, все машины ONLINE, у каждой ноды одинаковый и полный набор служб в services.cfg. Проверяйте это по модели, а не по зелёной плитке: зелёная плитка может отражать устаревший кэш GUI.
• Полевой health-check — 30-секундная read-only проверка узла (службы, failed units, время, S3-фронт), чтобы ловить залипы раньше, чем о них спросит заказчик.

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

• Вендор: Управление системой (GUI) (дата доступа 2026-11-07)
• Вендор: Software Documentation Center 7.3 (дата доступа 2026-11-07)
• Наша практика (обезличено): класс «узел красный / NOTCONFIGURED» — остаток ручного процесса держит блокировку службы, битые конфиги сети; разборы на лабораторных стендах из трёх нод.
• Обновлено: 2026-11-07.