ActiveScaleинженерная практика

install-ng: фазы, флаги и маркер завершения

Установка installinstall-ngphasesflagsacceptance

Коротко. install-ng.py разворачивает модель и сервисы после initialize. Запускается от пользователя marvin, с обязательным --product activescale, набором флагов и очередью. Код возврата ничего не доказывает: единственный надёжный признак завершения — /tmp/.unattended_install_finished с exit code внутри. Провал одной фазы оставляет узел NOTCONFIGURED, а остальные подзадачи — в QUEUED.

1. Перед запуском

  • Очередь готова (queue/<node>/, 8 файлов).
  • Старый маркер удалён: rm -f /tmp/.unattended_install_finished.
  • --product activescale — обязателен (иначе возьмётся mcore и упадёт get_default_role).
  • Запуск от marvin, cwd=/home/marvin, в фоне (setsid nohup).
sudo -u marvin bash -c "cd /home/marvin && setsid nohup \
  /opt/ampli/apps/marvinbase/venv/bin/python \
  /opt/ampli/apps/marvinbase/tools/install-ng.py \
  --config /opt/ampli/apps/marvinbase/queue/<NODE>/config-ng.ini \
  --product activescale -t combined -e -i -m -a -ASC -AST -D -d \
  > /tmp/ing.log 2>&1 & echo LAUNCHED=\$!"

2. Флаги (смысл)

Флаг Что делает Ловушка
-t combined тип установки роль по умолчанию; не путать с mcore
-e импорт environment без него модель пустая
-i импорт initial (machine/network/column) ошибки в JSON → отказ
-m management (marvinweb, arakoon) долгая фаза
-a applications samurai и др.
-ASC configure storage column политика/ёмкость
-AST configure storage targets S3/AXM
-D DSS блоксторы
-d deploy/configure dss долгая фаза
-S scale-out (skip federated db) только для первой ноды пути B; для пути A — НЕ использовать

-A/-T — догон отдельных фаз после сбоя; полный набор зависит от задачи.

3. Фазы (что происходит)

  1. management.initialize — создаёт кластеры модели, окружение, приложения.
  2. configure — рендерит конфиги, поднимает службы.
  3. arakoon/columns — метаданные, колонки.
  4. marvinweb/samurai — GUI/API.
  5. dss — блоксторы, политика, барометр.
  6. storage targets — S3/AXM endpoints.

Фазы могут занимать часы. Не считать «зависшим» раньше времени; смотреть /opt/ampli/var/log/marvin/install.log, а не только /tmp/ing.log.

Порядок фаз и почему его нельзя менять

Флаги в командной строке — не «галочки что поставить», а последовательность. Каждая следующая фаза читает артефакты предыдущей; пропуск шага не ускоряет установку, а переносит отказ на следующий шаг, где причина уже не видна.

Фаза Что оставляет после себя Кто потребляет результат
-e environment окружение с deployment_id, environments в management_model все последующие фазы
-i initial machine/network/column/role в модели -m, -D
-m management marvinweb, arakoon, mongodb-кластеры -a, GUI, API
-a applications samurai, uwsgi-приложения -ASC, -AST
-ASC column колонки, привязка блоксторов -D, -d
-D DSS dss-демоны, барометр -AST, S3
-d deploy dss финальная раскладка, политики приёмка
-S scale-out пропуск federated-БД только первая нода пути B

Практические следствия:

  • -i без -e. Модели ещё нет — импорт initial падает на отсутствующем окружении, а в логе это выглядит как «ошибка JSON», хотя JSON корректен.
  • -D без -ASC. Колонки не созданы, DSS нечего раскладывать: барометр остаётся пустым, S3 отвечает 507.
  • -AST раньше -D. Storage targets ссылаются на dss-эндпоинты, которых ещё нет.
  • -S на второй ноде. Федеративная БД уже развёрнута, повторный scale-out ломает картину федерации — отсюда No suitable management server found.

Поэтому догон — это всегда хвост последовательности, а не произвольный набор флагов.

4. Как читать /opt/ampli/var/log/marvin/install.log

/tmp/ing.log содержит только то, что скрипт печатает в stdout. Реальный ход работ пишется в install.log, а детализацию по плейбукам — в taskmgr/playbooks.log. Смотреть надо три вещи.

TASK [...] — имя выполняемой задачи. По нему видно, на каком шаге узел стоит сейчас. Если последняя строка TASK не меняется 20–30 минут, это ещё не зависание: часть задач (раскладка экстентов, инициализация БД) долгая сама по себе. Сравнивать надо не с «должно быть быстро», а с активностью: растёт ли лог, идёт ли I/O (iostat -x 5).

PLAY RECAP — итог плейбука. Значимые поля: ok, changed, failed, unreachable. Норма — failed=0, unreachable=0. changed в больших числах на повторном прогоне означает, что фаза реально что-то переделывала, а не просто «прошла».

failed= — единственный надёжный признак поломки. Строка failed=1 вместе с fatal: [host] выше даёт точное место: имя задачи, файл плейбука, номер строки. По этому фрагменту и надо искать причину, а не по коду возврата всего install-ng.

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

  • unreachable — узел не отвечает по SSH. Это не логическая ошибка установки, а сеть или ключи; правится до повторного запуска, иначе догон упадёт там же.
  • Пустой install.log после полуночи — не поломка: сработал logrotate. Смотреть install.log.YYYY_* и taskmgr/playbooks.log.
  • dpkg -l | grep samurai на ранней фазе пуст — норма: пакет появляется на -m -a.

5. Догон после сбоя: какие флаги и когда

Догон запускается той же командой с тем же --config и --product, но с хвостом флагов. Перед запуском: убрать старый маркер (rm -f /tmp/.unattended_install_finished), иначе первая же проверка покажет «уже готово».

Типовые наборы:

Что упало Набор для догона Почему так
Плейбук в -m (marvinweb/arakoon) -m -a -ASC -AST -D -d сервисы без management-слоя не поднимутся
Приложения (samurai, uwsgi) -a -ASC -AST -D -d модель уже есть, GUI нужен до storage
Колонки / column NOTINITIALIZED -ASC -AST -D -d пересборка колонок тянет DSS и targets
DSS (-D/-d) -D -d только storage-слой, без переинициализации модели
Только storage targets -AST самый узкий набор, если DSS здоров
Сеть/роль на второй ноде -t combined -A -T -d без -S: федерация уже развёрнута

Правила, которые экономят прогоны:

  • Не запускать полный набор «на всякий случай». Повторный -e -i перезаписывает окружение и обнуляет то, что уже отработало; на живой ноде это дороже, чем аккуратный хвост.
  • Один сбой — один догон. Если после догона упало в том же месте, менять надо конфиг (очередь, group_vars, column.json), а не набор флагов.
  • -A/-T — точечные фазы. Их смысл зависит от задачи: -A относится к приложениям, -T — к targets; в отчётах о сбое указывать, что именно догоняли, иначе следующий инженер повторит неверный набор.

6. Сколько это длится

Ориентир по времени — часы, не минуты. Полный прогон на одном узле с раскладкой блоксторов укладывается в диапазон от нескольких десятков минут до нескольких часов; отдельные фазы (-m, -D, -d) идут дольше остальных. Точное время зависит от числа дисков, скорости BMC-сканирования и того, первый это прогон или догон.

Как не принять живой прогон за зависший:

  1. Процесс жив: pgrep -f "[i]nstall-ng.py" (скобки обязательны — без них команда матчит саму себя и всегда «жив»).
  2. Лог растёт: wc -l /opt/ampli/var/log/marvin/install.log дважды с интервалом 10 минут. Тот же размер — повод смотреть I/O, а не сразу убивать процесс.
  3. Диски работают: iostat -x 5 — ненулевые %util/wkB/s на блочных устройствах означают, что фаза реально пишет.
  4. TASK меняется или, на долгой задаче, обновляются счётчики внутри неё.
  5. Маркер появился — только тогда прогон закончен: cat /tmp/.unattended_install_finished.

Чего не делать: не убивать процесс по «долго висит», не запускать второй install-ng параллельно (две очереди на одном узле дают непредсказуемую модель), не ребутать узел до появления маркера. Если процесс убит посередине — следующий запуск начинается с догона, а не с нуля, но часть артефактов может остаться в промежуточном состоянии: тогда смотреть failed= в taskmgr/playbooks.log, а не запускать полный набор вслепую.

7. Мониторинг

tail -f /opt/ampli/var/log/marvin/install.log
pgrep -f "[i]nstall-ng.py"        # жив (скобки — чтобы не матчить свою команду)
cat /tmp/.unattended_install_finished   # exit code
  • Строки DONE_RC в выводе нет.
  • pgrep -f install-ng.py без скобок матчит вашу же команду → ложное «жив».

8. Если фаза упала

  • Узел остаётся NOTCONFIGURED; приложение, на котором упало, — NOTCONFIGURED.
  • Остальные подзадачи — QUEUED.
  • Смотреть taskmgr/playbooks.log: TASK [...], PLAY RECAP, failed=.
  • Догон: те же флаги без уже пройденных фаз (например, -m -a -AST -ASC -D -d).
  • Не дёргать полный прогон, пока причина не понятна.

9. Проверка после

  • /federated/_status/ → 200 < 50 мс.
  • Барометр ok; NS status: ok.
  • selectedstoragepolicy не null; w+s ≤ N.
  • S3 PUT/GET round-trip.
  • GUI без пустот.
  • События: нет новых CRITICAL.

10. Грабли

  1. --product забыт → падение на get_default_role.
  2. -S не на той ноде → федерация не смоделирована, No suitable management server.
  3. column.json со status → column NOTINITIALIZED.
  4. Бэкапы .orig/.bak в group_vars → ansible грузит все файлы, бэкап побеждает.
  5. Одновременная установка двух узлов → nr_of_nodes=0 или ждать оба по очереди.

11. Источники

  • Software Documentation Center
  • Внутренняя практика (обезличено): прогоны install-ng на 3-нодных стендах.

Связанное

Нужен инженер? Разберу вашу ситуацию и скажу, что делать — по шагам, с проверками.

Обсудить задачу