Роли нод: SPXMGMT, SPXCTRLSTORAGE, SPXCTRLSTORAGEMGMT

1. Зачем роль вообще нужна

Роль — не ярлык для человека, а вход в конфигурацию продукта. По ней:

• выбирается набор приложений (application[] в документе машины): management, control, storage, мониторинг;
• раскладываются сервисы через Mona при configure;
• называется секция привязки интерфейсов в config-ng.ini (<роль в нижнем регистре>_nic_network_map);
• проверяется, достаточно ли mgmt-нод для федерации.

Поэтому ошибка в роли не «косметическая»: она меняет то, что продукт вообще ставит на железо.

2. Допустимые значения

Валидатор модели принимает фиксированный список:

SPX  SDB  SPXMGMT  CTRL  CTRLMGMT  CTRLSTORAGE  CTRLSTORAGEMGMT
STORAGE  SPXCTRLSTORAGEMGMT  SPXCTRLSTORAGE  BASE  MGMT

Логика имён читается по частям: MGMT — management-слой, CTRL — control-слой (управление S3/storage), STORAGE — данные, комбинация частей — совмещённая нода. Точную семантику для своей сборки сверяйте с cfg/product/activescale.yml: там же лежит install_type.combined.default_role.

3. Три роли, которые встречаются в жизни

Для типового кластера из трёх нод в одном окружении используется SPXCTRLSTORAGEMGMT на всех трёх. Это же значение по умолчанию для combined-установки.

Схема «одна mgmt-нода плюс две чисто storage» для трёхнодного кластера не подходит: федерации нужно минимум три ONLINE management-ноды, а storage-ноды без management-составляющей не смогут держать реплики федеративной БД. Такая раскладка уместна только при явно выделенном management-слое и большем числе нод — и тогда её надо проектировать целиком, а не собирать по одной ноде.

4. Ловушка с названием

Соблазнительно написать SPXMGNTCTRLSTORAGE («management + control + storage» по смыслу). Такой роли в продукте нет. Валидатор отвечает:

incorrect value SPXMGNTCTRLSTORAGE for role

Правильное combined-значение — SPXCTRLSTORAGEMGMT. Проверять роль лучше валидатором модели (install-ng.py -V) до запуска: model data validation successful означает, что значения полей приняты, а не только что JSON прочитался.

5. Пустая роль: почему это дорого

Если роль не задана (role=None), продукт ведёт себя предсказуемо и тихо:

• ОС ставится «generic» — без профильных приложений;
• application[] пуст, моделировать нечего;
• на configure нода не получает сервисов;
• в модели машина может появиться как PM-<mac> (регистрация по MAC), hardwaretype=None.

Снаружи это выглядит как «нода NOTCONFIGURED» и «GUI пустой». Лечение — не переустановка, а задание роли: PUT /model/machine/<MACHINE>/role/SPXCTRLSTORAGEMGMT/, затем initialize и configure этой ноды. Но сначала надо понять, почему инвентаризация железа не дала тип: без hardwaretype роль есть, а раскладка дисков всё равно будет не той.

Причина пустой роли чаще всего одна: промпт Machine role (optional) в stage-1 пропущен (он появляется только при reuse=y). Подробнее — Stage-1.

6. Роль и сеть

Секция привязки NIC→сеть в config-ng.ini называется по роли:

[spxctrlstoragemgmt_nic_network_map]
enp3s0   = <PUBLIC_NET>
enp5s0f1 = <PRIVATE_NET>

Если роль в machine.json одна, а секция названа по другой роли, установщик напишет в лог no nic mapping entry for role ... — и это надо читать буквально: секция не найдена, mgmt-адрес на ноду не приедет, хотя модель зелёная. Смена роли требует и правки имени секции.

7. Смена роли на живой ноде

install-ng при инициализации проставляет роли только машинам, у которых роли нет. Уже заданную роль он не трогает — поэтому «перевести» management-ноду в combined автоматически не получится.

Порядок при ручной смене роли:

1. Выгрузить модель (/model/machine/, /model/environment/, /model/column/) — бэкап вне каталога продукта.
2. PUT /model/machine/<MACHINE>/role/SPXCTRLSTORAGEMGMT/.
3. Остановиться и посмотреть, какие приложения появились в документе машины.
4. Только потом initialize и configure этой ноды; по одной ноде за раз, не параллельно.

Смена роли на ноде, которая уже несёт management, — операция с риском для живого кластера. Откат — PUT с прежней ролью.

8. Сколько mgmt-нод нужно

Федерация пути A (внутри окружения) требует не менее трёх ONLINE management-нод: продуктовый код расширяет реплика-сет федеративной БД на ноды 2 и 3, и на меньшем числе отказывает. Поэтому в 3-нодном кластере все три ноды несут management-составляющую, а не одна.

Практическое следствие: на каждой ноде должны работать свои mongod-процессы (management, environment data, federated). Если mongod есть только на первой ноде, остальные висят в CONFIGURING, а GUI показывает пустоты. Это же и проверка равноправия после установки: 8443 должен отвечать с каждой ноды.

Путь B (федерация в отдельной базовой системе) отличается тем, что одна инсталляция помечается base_system=true и владеет федеративной БД, а остальные подключаются к ней. Детали — Федерация: путь A и B.

9. Проверка (read-only)

1. GET /model/machine/<MACHINE>/ → role равно ожидаемому, status = ONLINE (после configure).
2. GET /model/machine/<MACHINE>/ → application[] содержит management/control/storage-приложения, а не пустой список.
3. GET /model/machine/<MACHINE>/ → hardwaretype не None; иначе роль есть, а профиль не распознан.
4. На каждой ноде pgrep -af mongod → свои процессы; curl -sk https://localhost:8443/model/_status/ → 200 с каждой ноды.
5. В config-ng.ini имя секции *_nic_network_map совпадает с ролью из machine.json.

10. Источники

• Software Documentation Center (дата доступа 2026-11-07)
• Наша практика (обезличено): сборка 3-нодных кластеров, разбор пустой роли и смены роли на живой ноде.
• Обновлено: 2026-11-07.