Чек-лист подготовки к установке

1. Железо

• [ ] Модель и профиль железа (hardware type) известны для каждого узла.
• [ ] Профиль лежит в /opt/ampli/cfg/product/hardware/types/ (на live-ISO или в образе).
• [ ] Имена интерфейсов сняты с каждой машины отдельно: в одной модели они могут различаться (enp3s0 на первой, enp3s0f0 на остальных).
• [ ] Диски пусты; нет остатков прошлых прогонов.
• [ ] BMC доступен, пароль известен, BootOrder понятен.
• [ ] NTP настроен до установки.
• [ ] Серийник стойки известен (без него GUI может дать пустую страницу «Ресурсы»).

Почему это важно. Профиль железа задаёт раскладку дисков и фильтр вентиляторов: без него установщик берёт generic-шаблон, и модель получает несуществующие устройства, которые потом приходится чистить руками. Имена интерфейсов нужны потому, что установка переименовывает порты (remap systemd), а привязка адресов делается по MAC — но записать MAC неверного порта легко именно из-за путаницы в именах. Остатки прошлых прогонов дают «уже размеченные» диски и непредсказуемый reuse existing filesystems.

2. Сеть

• [ ] VLAN: management/public, storage/private, BMC/IPMI — с шлюзами.
• [ ] Адреса по MAC, не по именам интерфейсов.
• [ ] Storage-порт подключается в свою VLAN; mgmt-IP выдаётся раньше storage-IP (иначе PXE может уйти не туда).
• [ ] DNS: минимум один сервер; зона для S3/IAM (если нужен FQDN).
• [ ] NTP-сервер доступен; время на всех узлах совпадает.
• [ ] Нет дублирующихся MAC в модели/очереди.

Почему это важно. Если storage-порт поднимается в своей VLAN раньше management, DHCP-запрос уходит в storage-подсеть: узел получает адрес, но не тот, и PXE встаёт на «чужой» сети. Дубли MAC в очереди дают фантомные NIC в модели — установка проходит, а потом порты не совпадают с физическими. Расхождение времени ломает подписи S3: клиент получает 403 при полностью здоровом узле и зелёном GUI.

3. PXE / live (если ставите по сети)

• [ ] HTTP-раздача ISO отвечает: curl -sI http://<ADMIN_NODE>:8080/<IMAGE>.iso → 200.
• [ ] url= в загрузчике оканчивается на .iso (иначе casper молча игнорирует).
• [ ] ProxyDHCP: dhcp-boot и pxe-service настроены (UEFI сначала спрашивает ProxyDHCP).
• [ ] /pxe/ отдаёт реальный файл (~480 байт), а не LOCALBOOT.
• [ ] bootmode=PXE в модели (или BootOrder с сетевым портом первым).
• [ ] BootOrder: storage-NIC не мешает; сетевой порт — первым для установки.
• [ ] BMC умеет UEFI; после установки переключить на Hdd + UEFI.

Почему это важно. casper матчит url=*.iso; любое другое расширение игнорируется без сообщения — узел молча уходит в 60-секундное сканирование дисков и ребут, и это выглядит как «железо не грузится». ProxyDHCP нужен целиком: UEFI-стек сначала спрашивает его, и одного dhcp-boot без pxe-service не хватает. Раздачу ISO и dnsmasq после ребута admin-узла надо поднимать вручную — они не юниты.

4. Очередь и модель

• [ ] Очередь взята с рабочего узла и поправлена, а не написана с нуля.
• [ ] В config-ng.ini: model_data_path — абсолютный путь до queue/<node>/, nr_of_nodes=0 (если ставите один узел и не ждёте второй).
• [ ] machine.json: роль, ipmi.address, только 2 UP-NIC (mgmt + storage по реальным MAC), остальные убрать.
• [ ] column.json: column_deployment_id = deployment_id; без поля status.
• [ ] environment.json: deployment_id, имя, домен.
• [ ] network.json: PUBLIC/PRIVATE сети.
• [ ] policy_type под итоговое число блоксторов; проверить, что ветка существует.
• [ ] authorized_keys не 15 байт (иначе ключ не сработает).
• [ ] Профиль в additional_packages (если доставляется пакетом).
• [ ] Раскладка профиля валидна (validate_profile_layout.py → PASS).

Почему это важно. Очередь — это и есть описание будущей модели: установщик не проверяет правдоподобность, он импортирует JSON как есть. Поле status в column.json даёт column NOTINITIALIZED, чужие MAC — фантомные NIC, nr_of_nodes без нуля — вечное ожидание второго узла, которого нет. Относительный путь в model_data_path ломается, потому что install-ng работает из /home/marvin, а не из каталога запуска.

5. Политика DSS

• [ ] w + s ≤ N для итогового числа блоксторов.
• [ ] Политика не занимает «ровно N» (нужен запас).
• [ ] selectedstoragepolicy будет задан (иначе durability-метрики пусты).
• [ ] Для малых конфигураций — ветка custom, а не стоковый balanced/lowest_overhead.

Почему это важно. Генератор экстентов требует w + s ≤ N; при равенстве запас нулевой, и первый отказ диска останавливает запись. Стоковые ветки рассчитаны на большие полки — на малом числе дисков они не раскладываются, и S3 отвечает 507 Storage is full при свободных дисках. Пустой selectedstoragepolicy не мешает записи, но оставляет GUI без durability-метрик, и приёмку пройти не получится.

Подробнее: Формула политики DSS.

6. Аккаунты и доступ

• [ ] sysadmin + ключ (или пароль) доступны на live и на диске.
• [ ] hgstsupport известен как fallback.
• [ ] Пароли BMC/ILO известны.
• [ ] Доступ к management-сети с рабочей станции проверен.

Почему это важно. iso_installer на части образов копирует /etc/passwd.orig поверх живого — учётная запись, созданная в live, исчезает на диске, и узел остаётся без входа по SSH. Проверять надо обе стороны: live и установленную систему. hgstsupport — второй путь входа, если ключ не сработал; без него остаётся только KVM.

7. Что взять с собой на площадку

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

Железо и кабели

• Патч-корды под каждую VLAN: management, storage, BMC. Отдельно — пара запасных.
• Консольный доступ: USB-UART/RS-232 адаптер с переходником под порт узла.
• Ноутбук/рабочая станция с портом Ethernet (не только Wi-Fi) — нужно воткнуть в management-VLAN.
• Удлинитель/питание, если стойка не даёт свободных розеток.
• Маркировка портов: наклейки или бирки — MAC нужно сверять с физическим портом, а не с именем.

Доступы

• Пароли BMC/IPMI на каждый узел; способ входа в KVM проверен заранее.
• Учётные данные management-сети, шлюза, коммутатора (хотя бы просмотр).
• sysadmin + ключ и hgstsupport как fallback; ключ проверен на живом узле, не только локально.
• Доступ к admin-узлу (раздача ISO/PXE) и право запускать там http-сервер и dnsmasq.

Образ и артефакты

• ISO нужной сборки — целиком, локально на носителе, а не только «есть на admin-узле».
• Контрольная сумма ISO и записанный размер: сверить на месте, до загрузки.
• Профиль железа (hardware type) в виде файла — на случай, если в образе его нет.
• Очередь с рабочего узла целиком (все 8 файлов), а не «перепишу на месте».
• Рабочий конфиг dnsmasq/загрузчика из предыдущего прогона.

Лицензии и бумаги

• Лицензионные ключи/файлы, если поставка их требует — до первого запуска, а не после.
• Схема сети площадки с VLAN и адресами (или хотя бы таблица MAC → адрес).
• Контакты ответственного за сеть на площадке: половина проблем PXE решается на коммутаторе.

Смысл списка простой: на площадке нет ни интернета «на всякий случай», ни склада. Отсутствующий патч-корд в нужной VLAN стоит часов простоя, а не минут.

8. Гейт: что должно быть верно перед первым запуском

Это не «чек-лист ещё раз», а короткий набор проверок с ожидаемым ответом. Проходить на узле, а не по памяти, и записывать вывод. Если ответ не совпал — установку не запускать.

Три ответа, которые чаще всего оказываются неверными и которые нельзя «додумать»:

1. /pxe/ отдаёт LOCALBOOT — загрузчик не настроен; установка начнётся и упадёт на ребуте.
2. w + s = N — политика занимает всё; запись встанет при первом отказе диска.
3. pgrep показывает «жив» — почти всегда это ваша же команда; проверять с [i]nstall-ng.py.

Правило гейта: час проверок дешевле дня разбора. Установка, прошедшая с rc=0 и пустой моделью, обходится дороже, чем отменённый запуск.

9. Источники

• X200 Getting Started Guide
• Внутренняя практика (обезличено): прогоны установки на 3-нодных стендах.