Добавление ноды в кластер: scale-out без переустановки и без сюрпризов

1. Когда scale-out, а не scale-up

Расширение добавлением нод — штатный путь роста. Вендор заявляет раскладку без обязательного rebalance (Dynamic Data Placement), то есть данные не нужно переливать целиком: система перераспределяет размещение по мере работы и ремонта.

Практический смысл: ёмкость и производительность растут добавлением нод, а не заменой полок. Ограничения по платформам: минимум три ноды для P200 и Z200, четыре для X200 (два twin-сервера, каждый с двумя compute-модулями).

Расширение — плановая работа с окном. Добавление ноды меняет модель, а модель рендерит конфиги всех нод кластера.

2. Требования, которые проверяются до окна

1. Не меньше трёх ONLINE management-нод. Продукт считает машины со статусом ONLINE и при их числе меньше трёх отказывается расширять кластер.
2. Рост на нечётное число. Попытка вырасти на две ноды даёт отказ: кластер расширяется на одну, три, пять.
3. Одинаковый deployment_id. Все машины в очереди — из одного развёртывания. Нода со своим deployment_id в кластер не войдёт.
4. Сеть. Storage-сеть должна быть доступна новой ноде; без неё machine.initialize падает или heartbeat не идёт.
5. Роли. Новая нода получает ту роль, которая нужна кластеру; не смешивать роли «на глаз».

3. Подготовка новой ноды: только stage-1

Ключевое правило: нода ставится только через stage-1 (установка ОС на диски), затем перезагружается в дисковую ОС. Никакого stage-2 (--init-federated) на добавляемой ноде.

Почему: stage-2 создаёт локальную федерацию, у ноды появляется собственный deployment_id. Внешне она будет видна в модели, но machine.initialize упадёт, heartbeat не пойдёт, и нода останется NOTCONFIGURED. Лечится только переустановкой stage-1 без stage-2.

После stage-1 у ноды часто storage-порт в состоянии admin-DOWN — его надо поднять и дать адрес. Проверка линка:

ip link set <storage-dev> up
cat /sys/class/net/<dev>/carrier        # ожидается 1

4. Очередь: что в ней должно быть

Очередь add-node собирается по тем же правилам, что и первичная установка, но с одним отличием: machine.json описывает все машины кластера, а не только новую.

Требования к содержимому:

• machine.json — ровно реальные машины (новая + существующие), без фантомных записей;
• NIC описываются по MAC-адресам, nictype: "ether" (значение ethernet даёт ValidationError);
• один management-IP не должен появляться на двух портах — иначе duplicate NIC network;
• deployment_id — тот же, что у ведущей ноды.

Отдельная ловушка: nr_of_nodes в config-ng.ini. Если ставится один узел, а установщик ждёт второй, прогон висит на ожидании удалённых PXE-нод. Значение nr_of_nodes = 0 отключает это ожидание.

5. Запуск расширения на ведущей ноде

Расширение запускается на ведущей ноде — той, что владеет федеративной моделью. Перед запуском снять старый маркер завершения:

sudo rm -f /tmp/.unattended_install_finished
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/<QUEUE>/config-ng.ini --product activescale \
  -t combined -I -m -x -a -AST -C -ASC -D -d \
  > /tmp/ingX.log 2>&1 & echo LAUNCHED=\$!"

Флаги, которые важны именно для расширения:

-e машины не импортирует: они попадают в модель через инициализацию или Model API.

Окно. -x переконфигурирует все ONLINE-ноды кластера, а не только новую. Это не «тихая» операция: часть служб перезапускается, конфиги перерендериваются. Совмещать её с апгрейдом или заменой диска нельзя.

6. Что делает -x внутри

extend_clusters() проходит по существующим кластерам модели и добавляет недостающие ноды. Ключевой момент: расширять можно только то, что уже есть в модели.

Для федерации это выглядит так: если кластер federated_model создан при первичной установке (путь A — первая нода ставилась без -S), расширение само добавит приложения mongodb_federated_node2 и mongodb_federated_node3 на новые ноды и сконфигурирует их.

Обратный случай: если первая нода ставилась с -S (scale-out без локальной федерации), кластера federated_model в модели нет — расширять нечего, и федерация останется одиночной. Это не «баг расширения», а следствие выбранного пути установки; подробно — в статье Федерация: путь A и путь B.

7. Проверка

Критерии закрытия стадии:

Статус 200 и «меньше 50 мс» — не формальность: 30-секундный таймаут на этом запросе означает зависание топологии клиента и обычно указывает на несмоделированную федерацию.

8. Грабли

Отдельно: в 7.1 появился автоматический scale-out через GUI. Он удобен, но требует сервисного passcode и опирается на те же требования (три ONLINE ноды, нечётный рост). Если модель несогласована, GUI-путь упадёт так же, как CLI.

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

• Проверять статусы всех нод и состояние федерации до окна, а не в окне.
• Держать один deployment_id на кластер и не «собирать» ноды из разных развёртываний.
• Не описывать NIC шаблонными именами: только реальные интерфейсы по MAC.
• После расширения — сверить число нод в модели, приложения федерации, реплика-сет и ответ /federated/_status/; только потом закрывать окно.
• Фиксировать в журнале обслуживания, каким путём ставилась первая нода: от этого зависит, будет ли федерация расширяться автоматически.

Источники

• Z200 Datasheet — бесшовное расширение, минимум нод (2026-11-07)
• Software Documentation Center (2026-11-07)
• Наша практика (обезличено): add-node и расширение кластера на 3-нодных стендах, разбор «No suitable management server» из-за несмоделированной федерации.
• Обновлено: 2026-11-07.