Ввод нового узла в работу

Кластер растят узлами. Монтаж, установка системы на узел и приём узла в состав кластера идут вне vStack Center — этим занимаются установочный контур и Cluster Manager. vStack Center вступает в сценарий позже: когда узел уже виден кластеру, но ещё не несёт нагрузку, не описан инвентарём и не отдал свои диски.

Ответственность разнесена жёстко. Состав кластера и статусы узлов ведёт Cluster Manager — vStack Center только показывает его картину и передаёт ему команды. Оборудование, версии пакетов и параметры системы присылает агент узла: они складываются в базу vStack Center и показываются на карточке узла.

Отсюда двухтактность всей работы с узлом. Сбор инвентаря и версий ПО — это команда агенту узла, и она ничего не говорит об исходе. Результат появляется на экране позже, когда узел отчитается. Ориентир свежести — колонка Last_seen: в ней время, когда узел последний раз отчитался.

Диски нового узла проходят два независимых шага, и путать их дорого. Вывод диска онлайн делает диск видимым всем узлам кластера. Членом ZFS-пула он от этого не становится: сборка пула выполняется на узле, в vStack Center её нет.

Этап ввода узла	Кто выполняет	Где выполняется
Монтаж, установка системы, приём в состав кластера	установочный контур и Cluster Manager	вне vStack Center — см. раздел «Планирование и установка»
Разрешение узлу принимать нагрузку	Cluster Manager по команде vStack Center	в веб-интерфейсе не представлено — через API
Сбор оборудования и версий ПО	агент узла	карточка узла: блок Hardware, кнопка Software
Выравнивание параметров системы	агент узла	карточка узла: кнопка Configure
Вывод дисков онлайн в кластер	агент узла	в веб-интерфейсе не представлено — через API
Сборка ZFS-пула из дисков узла	узел	в vStack Center не представлено
Запуск сервиса пула на узле	Cluster Manager	карточка пула: Actions → Start pool
Сверка ёмкости кластера	vStack Center	экраны Overview, Server Nodes, Storage Resources

Предусловия

• роль Cluster master (role_id=1) — её требуют все операции сценария, включая сбор данных о хостах;
• признак feature.hardware_inventory — без него не показывается собранный инвентарь и утилизация ядер;
• признак feature.physical_disc_management — без него закрыты операции с физическими дисками: список дисков, подсветка, вывод диска в кластер и метка запасного;
• признак feature.node_config_management — без него закрыты параметры узла и сбор версий ПО;
• узел уже принят кластером и виден в таблице Server Nodes;
• список серийных номеров дисков нового узла: сверка дисков идёт по серийному номеру;
• версия vStack Center — 3.0.5.

Включённые признаки лежат в опциях кластера — там же их и проверяют.

Шаг 1. Убедиться, что узел виден кластеру

Начинайте с чтения, а не с команды. Пока узел не появился в картине Cluster Manager, любая команда ввода уйдёт в пустоту.

1. Откройте Provider Data Center → Server Nodes. Новый узел появляется в таблице новой строкой с колонками ID, Name, Health, CPU (Cores), RAM (GB) и отдельным табом рядом с уже знакомыми node01…node05.
2. Выпишите ID узла: он понадобится дальше — и для команд, и для сверки.
3. Прочитайте Health. У узла две независимые оценки: что разрешено администратором и что происходит на самом деле. Как устроена эта пара, разобрано в «Кластер, узлы и сервисы».

Состав таблицы формирует Cluster Manager. Если таблица пуста и экран сообщает об ошибке получения статуса, данных о составе кластера взять негде — смотрите доступность Cluster Manager, а ввод не начинайте.

Шаг 2. Разрешить узлу принимать нагрузку

Ввод узла — административное разрешение, а не запуск. vStack Center передаёт Cluster Manager команду ввода, и дальше узел начинает принимать нагрузку.

Ввода и вывода узла в веб-интерфейсе нет: операцию выполняет администратор через API — см. Справочник API. Результат смотрите в таблице Server Nodes: введённый узел перестаёт быть помеченным как запрещённый к работе, а колонка Health показывает его фактическое состояние.

Принятая команда означает, что её получил Cluster Manager, а не что узел уже сменил состояние. Фактическую смену показывает Health — она обновится, когда узел отчитается. Идентификатор узла — число: значение с посторонними символами кластер отклоняет с кодом -20122 ещё до отправки команды.

Шаг 3. Собрать инвентарь оборудования

Инвентарь нужен сразу: по нему сверяют поставку с ведомостью и находят диски по их месту в корзине. Работает он в два такта — сначала сбор, потом чтение.

1. Запустите инвентаризацию нового узла. Сбор адресуется одному узлу или всему кластеру, а также сужается до одного класса устройств. На вводе узла разумен полный проход: класс не выбирайте и дайте агенту собрать всё.

   Класс устройств	Что собирает
   ifnet	Сетевые интерфейсы
   ses	Корзины дисков
   cam	Дисковая подсистема
   nvme	Устройства NVMe
   smbios	Данные SMBIOS
   класс не выбран	Полная инвентаризация

2. Откройте карточку узла и разверните блок Hardware. Таб Inner view показывает состав узла таблицей Manufacturer / Description / Product / Serial number / Version; вложенные табы Node data, CPU и RAM переключают срез.

3. Проверьте процессорную часть на табе Utilization: он показывает загрузку ядер по NUMA-доменам, данные там свежие — не старше десяти минут. Сетевую часть показывает таб Portgroup с колонками Name, Hash, Last_seen, MAC, Proto, Status.

4. Размещение дисков смотрите в блоке Disks, таб Placement: колонки Enclosure_device, Enclosure_id, Dev_index, Device — именно по ним диск потом ищется в корзине.

Пустой таб Utilization на только что введённом узле — норма: агент ещё не успел отчитаться. Откройте карточку заново позже.

Шаг 4. Выровнять версии ПО с остальным кластером

Разъезд версий между узлами — частая причина странного поведения кластера. Новый узел приезжает с той версией, что была в образе, и почти всегда её нужно сверить.

1. Нажмите Software — кнопка есть и на списке узлов, и на карточке узла. Откроется таблица Name / Version / Last_seen: по каждому пакету видно версию и время последнего обнаружения. Отдельно показываются версии узловых пакетов и версии самого кластера.
2. Смотрите на Last_seen. Старое значение означает, что узел давно не отчитывался, и показанная версия может не совпадать с установленной. В этом случае запустите сбор версий ПО и откройте таблицу заново.
3. Сравните новый узел с любым работающим. Расхождение версий обязательных пакетов — повод остановить ввод и обновить узел.

Часть пакетов необязательна: vStack-vm-prio, vStack-storage-san и vStack-zpool могут отсутствовать в таблице. Их отсутствие на новом узле — не сбой сбора и не повод откатывать ввод.

Шаг 5. Применить конфигурацию узла

Параметры системы группируются, и у каждого есть класс — профиль, в рамках которого значение применяется. Новый узел получает те же значения, что уже стоят на рабочих узлах, поэтому сначала читаем эталон, потом пишем.

1. Откройте карточку рабочего узла и нажмите Configure. Параметры показаны по группам, с текущими значениями и временем последнего обнаружения. Выпишите значения, которые должны совпасть у нового узла.
2. Прежде чем править значение, посмотрите, числовой параметр или строковый: от этого зависит, что примет форма.
3. Откройте Configure на карточке нового узла, укажите значения и выберите класс, в котором они должны действовать. Изменение адресуйте одному узлу — на вводе рассылка по всему кластеру не нужна.
4. Подтвердите изменение. Команда передаётся агенту узла, поэтому результат виден не сразу: откройте параметры заново — у изменённого параметра обновятся значение и время обнаружения.

Числовые параметры vStack Center проверяет по диапазону сам: значение ниже минимума отклоняется с кодом -23124, выше максимума — с кодом -23125, и на узлы такое значение не уходит. Неизвестный параметр отклоняется кодом -23121, параметр без запрошенного класса — кодом -23123.

Шаг 6. Вывести диски узла в кластер

Диски нового узла сначала «сырые»: узел их видит, кластер — нет. Вывод диска онлайн делает его видимым всем узлам. Операция деструктивная и не идемпотентная: повторный вывод уже выведенного диска отклоняется с кодом -24706.

Вывод диска в кластер, метка запасного и снятие диска с кластера в веб-интерфейсе не представлены: их выполняет администратор через API — см. Справочник API. Там же задаются размер блока и серийный номер, под которым диск попадёт в кластер.

1. Посмотрите, что узел вообще нашёл. Откройте карточку узла, блок Disks. Табы делят один и тот же список по срезам: Disk props — ID, Model, Size (GB), Status; ZFS props — Pool name, Vdev_pool_name, Vdev_guid, Vdev_pool_guid; Placement — место в корзине; LED on panel — Led_fault и Led_locate.
2. Различайте три независимые оси: Status — здоровье диска, роль диска (свободен, размечен, в пуле, запасной) и признак «выведен в кластер». Ни одна не выводится из другой; признак вывода в кластер показывает только API.
3. Выведите нужные диски онлайн и перечитайте список. Роль диска при этом не меняется — вывод в кластер её не трогает.
4. Часть дисков имеет смысл сразу пометить запасными, чтобы аварийная замена нашла донора. Метка запасного пишет на диск служебную метку, поэтому на диске с живыми данными узел откажет, пока операцию не потребуют принудительно.

предупреждение

Вывод диска в кластер не добавляет его в ZFS-пул. Сборка пула из выведенных дисков выполняется на узле, в vStack Center её нет. До появления пула диски узла не дадут кластеру ни одного байта ёмкости.

Подсветить диск в корзине можно прямо из интерфейса: на табах Front view и Inner view блока Disks у каждого диска есть кнопки подсветки и индикации отказа, а результат виден на табе LED on panel.

Шаг 7. Поднять сервис пула на новом узле

Пул живёт на узле как сервис кластера. Пока сервис не разрешён и не запущен, пул не отдаёт ёмкость, даже если диски выведены и пул собран.

1. Откройте Provider Data Center → Storage Resources. Таблица ZFS pools показывает пулы кластера с колонками GUID, Name, Health, Consuming, Scrubbing, Resilvering, Current node и Capacity (RAW). Колонка Current node говорит, какой узел несёт пул сейчас.
2. Откройте пул из таблицы и в меню Actions выберите Start pool.
3. Вернитесь к Storage Resources и убедитесь, что пул показан живым, а Current node указывает на новый узел.

У сервиса две независимые оси: разрешение — допущен ли сервис к работе, и состояние — работает ли он сейчас. Запрещённый сервис не поднимется, сколько бы раз его ни запускали. Разрешение и запрет сервиса в веб-интерфейсе не представлены — их выполняет администратор через API. Порядок операций и типовые отказы разобраны в «Как управлять сервисами кластера».

Принятая команда подтверждает, что её получил Cluster Manager, а не фактический старт. Имя сервиса пула состоит из букв, цифр и подчёркиваний — например zpool_ssd01; дефисы, точки и пробелы кластер не примет.

Шаг 8. Сверить ёмкость кластера

Последний шаг отвечает на вопрос «узел действительно работает или только включён». Ресурсы узла должны появиться и в разрезе по узлам, и в суммах кластера.

1. Откройте Provider Data Center → Overview. Экран собирает ёмкость, провизионирование и фактическое потребление по процессору, памяти и пространству — суммы должны вырасти на ресурсы нового узла.
2. Перейдите на таб Resources: таблица покажет узлы с колонками Node name, Node health и Consuming. Новый узел должен быть в списке.
3. Сверьте построчную картину в Server Nodes по колонкам CPU (Cores) и RAM (GB), а пулы узла — в Storage Resources.

Пустые CPU (Cores) и RAM (GB) у только что введённого узла означают, что метрик по нему ещё нет. Провизионированные величины при этом достоверны. Пулов узла тоже не будет, пока пул не собран и его сервис не поднят.

Завершение работ

1. Погасите индикацию, если зажигали её при монтаже: карточка узла → блок Disks → табы Front view или Inner view. Проверьте результат на табе LED on panel по колонкам Led_fault и Led_locate.
2. Перезапустите инвентаризацию после последних физических изменений — классы ses и cam.
3. Зафиксируйте эталон: откройте Configure и Software нового узла. Это картина, с которой вы будете сверять узел в следующий раз.
4. Если ввод откатывается — снимите узлу разрешение принимать нагрузку и уберите его диски из кластера. Обе операции идут через API. Диск-член живого пула так выводить нельзя: пул деградирует, и узел вернёт отказ.

Проверка результата

Что проверяем	Где смотреть	Ожидаемо
Узел в составе кластера	Server Nodes	Новая строка с ID и Name узла
Узел разрешён и жив	Server Nodes, колонка Health	Узел не помечен запрещённым к работе и показан живым
Оборудование описано	Карточка узла, блок Hardware	Таб Inner view заполнен, Last_seen свежий
Версии совпадают с кластером	Кнопка Software	Версия ядра и обязательные пакеты как на рабочем узле
Конфигурация применена	Карточка узла, Configure	Значения совпадают с эталоном, время обнаружения свежее
Диски видны кластеру	Карточка узла, блок Disks	Нужные диски есть в списке; признак «выведен в кластер» показывает API
Сервис пула работает	Storage Resources	Пул в таблице ZFS pools, Current node — новый узел, Health = ONLINE
Ёмкость учтена	Overview	Суммы по процессору, памяти и пространству выросли

Если не получилось

Что видите	Почему	Что делать
Узла нет в таблице Server Nodes	Cluster Manager ещё не принял узел в состав кластера	Ввод в vStack Center не начинайте, вернитесь к установочному этапу
Таблица узлов пуста, код ошибки -2	Не удался обмен с Cluster Manager	Проверьте доступность Cluster Manager: данных о составе кластера взять негде
Код ошибки -713 у команд узла и сервиса	Команду не удалось передать Cluster Manager	То же; до узлов команда не дошла
Код ошибки -20122	Идентификатор узла не прошёл проверку	Укажите идентификатор узла числом, без посторонних символов
Код ошибки -20512, -20522	Имя сервиса или идентификатор узла не прошли проверку	Возьмите имя сервиса из колонки Name таблицы ZFS pools, узел — из Server Nodes
Код ошибки -403 «Access denied»	Операция открыта только роли Cluster master	Войдите под ролью уровня кластера
Код ошибки -26001, -26101	Выключен признак feature.hardware_inventory	Включите признак в опциях кластера
Код ошибки -23110 или -23301	Выключен признак feature.node_config_management	То же для управления конфигурацией
Код ошибки -24201	Выключен признак feature.physical_disc_management	То же для управления физическими дисками
Код ошибки -200	Карта состояния кластера недоступна, собирать данные не от кого	Дождитесь возврата узлов в ONLINE и повторите
Код ошибки -23203	Выбран недопустимый класс устройств	Выберите класс из таблицы шага 3
Код ошибки -23124 или -23125	Числовое значение параметра ниже минимума либо выше максимума	Приведите значение к границам параметра
Код ошибки -24702, -24704	Путь устройства или серийный номер диска не прошли проверку формата	Сверьте путь и серийный номер с тем, что показывает блок Disks
Код ошибки -24703	Недопустимый размер блока	Укажите 512 или 4096
Код ошибки -24706	Диск уже выведен онлайн в кластер	Повтор не нужен, проверьте признак вывода в кластер
Код ошибки -24707	Запрошенный серийный номер уже занят другим диском узла	Выберите другое значение или не задавайте — узел назначит сам
Код ошибки -24504	Над диском уже идёт деструктивная операция	Дождитесь ответа узла по предыдущей команде
Код ошибки -24503	Диск уже помечен запасным	Повтор не нужен
Команда принята, но данные не изменились	Сбор и запись выполняются асинхронно: команда только передана агенту узла	Откройте экран заново; свежесть значений смотрите по Last_seen
Диск выведен, но ёмкости в кластере не прибавилось	Вывод диска в кластер не собирает ZFS-пул	Соберите пул на узле, затем разрешите и запустите его сервис
Узел введён, но CPU (Cores) и RAM (GB) пустые	По узлу ещё нет данных в хранилище метрик	Дождитесь сбора метрик, проверьте блок Perfdata на карточке узла

См. также

• Устройство кластера, пара статусов у каждого объекта и признаки возможностей — «Кластер, узлы и сервисы».
• Полный набор операций над узлом — «Как управлять узлами кластера».
• Сервисы пулов и их привязка к узлам — «Как управлять сервисами кластера».
• Плановая замена диска в введённом узле — «Плановая замена диска в узле».

Методы API

Операции этой страницы в API: node-list, get-statusmap, cluster-node-enable, cluster-node-disable, node-inventory, host-inventory, node-hw-list, node-cpu-cores, node-software-inventory, node-software, node-config-map, node-config-get, node-config-set, pd-list, pd-status-map, pd-use, pd-unuse, pd-spare, pd-led, cluster-service-enable, cluster-service-start, cluster-overview, cluster-totals — см. Справочник API.