Чек-листы: установка, приёмка, обслуживание, авария

1. Как пользоваться

• Пункт считается закрытым только по живому выводу: код ответа, статус, число процессов.
• «Сделали» без числа не считается. «Должно работать» — не гейт.
• Порядок пунктов не менять: следующий слой опирается на предыдущий.
• Чек-лист не заменяет статьи: он говорит что проверить, статья — почему и как чинить.

2. Подготовка (до выезда и до первого запуска)

Полный разбор: Чек-лист подготовки к установке.

1. Профиль железа известен для каждого узла и лежит в /opt/ampli/cfg/product/hardware/types/.
2. Имена интерфейсов сняты с каждой машины отдельно (ip -br link) — они различаются между узлами.
3. Адреса по MAC, а не по именам портов; в модели нет дублей MAC.
4. VLAN и шлюзы: management, storage, BMC — по одному шлюзу на сегмент.
5. PXE-инфра: curl -sI http://<ADMIN_NODE>:8080/<IMAGE>.iso → 200; /pxe/ отдаёт реальный файл, а не LOCALBOOT; в сегменте один DHCP и один TFTP.
6. BootOrder/BootMode: сетевой порт первым на установку, UEFI включён; после установки — Hdd + UEFI.
7. NTP настроен до установки; время на узлах совпадает.
8. Серийник стойки известен — без него страница «Ресурсы» может быть пустой.
9. Очередь взята с рабочего узла и поправлена, а не написана с нуля; model_data_path — абсолютный путь, nr_of_nodes задан осознанно.
10. Политика DSS под реальное число блоксторов: w + s ≤ N (см. Формула политики DSS).

3. Установка (stage 0 → 3)

Подробно: install-ng: фазы, флаги и маркер, Флаги install-ng, PXE не грузится, Федерация: путь A и путь B.

1. Вайп дисков (если железо не чистое): swapoff -a → mdadm --stop --scan → zero-superblock → wipefs → partprobe. Гейт: /proc/mdstat = unused devices: <none>, blkid пуст, /proc/swaps пуст.
2. Stage 1 (ОС): узел грузится в live, iso_installer ставит ОС на диск. Гейт: findmnt -o SOURCE / ≠ overlay; узел пингуется по management-адресу.
3. Stage 2 (initialize): marvin_install доходит до конца. Гейты: /usr/bin/marvin_install исчез, /tmp/marvin_initialize.rc есть, initial_environment.json создан, в deploy.log — Done.
4. install-ng -e: импорт очереди и профиля железа. Гейт: rc=0 и в environment появились additional_packages.
5. install-ng -i -m: ведущая ONLINE, свой DHCP/PXE поднят.
6. install-ng -I -n <N>: ноды получают ОС по PXE. Гейт: pgrep -c mongod и статусы нод меняются с NOTCONFIGURED на ONLINE.
7. install-ng -m -a -AST -C -ASC: блоксторы, arakoon, аккаунты, колонка. Гейт: колонка CONFIGURED + ACTIVE, connections = 3.
8. install-ng -x: mongod раскатан на все management-ноды. Гейт: pgrep -c mongod на каждой ноде равен числу кластеров.
9. Маркер финала: /tmp/.unattended_install_finished удалён перед прогоном и появился после; pgrep -f "[i]nstall-ng.py" пуст.

4. Приёмка (11 проверок)

Подробно: install-ng: фазы, флаги и маркер §6 и Коды возврата и маркеры.

Дополнительные гейты, без которых приёмка не закрыта: машины ONLINE и bootmode=DISK; приложения — NOTCONFIGURED = 0; каждый mongod-кластер по 3 приложения; блоксторы — число партиций равно числу маунтов по плану раскладки.

5. Обслуживание

Полные разборы: Словарь событий, Карта портов. Периодичность задаёт регламент эксплуатации; ниже — обязательный минимум при каждом визите.

1. Полевой health-check (около 30 секунд на узел, только чтение): время и NTP, S3-фронт, haproxy, blockstore-маунты и заполнение, failed units. Код 0 — нет FAIL; 1 — есть.
2. События: просмотреть LIVE за период; отдельно — рост occ у MACHINE_DOWN, DISK_NOT_FOUND, PSU/FAN_NOT_FOUND, ленточных.
3. Диски: smartctl -H по проблемным, mdstat — все массивы [UU].
4. Лента: сверить каталог библиотеки с реестром продукта, проверить форму штрихкодов (продукт отбрасывает LTO-суффикс) и tape safety в метриках.
5. Сертификаты: срок действия SSL; продукт предупреждает об истечении за 6 месяцев.
6. Резервные копии конфигурации — до любых изменений, вне каталогов продукта.
7. После любого изменения — повторить п. 1 и убедиться, что новых CRITICAL нет.

6. Авария: первые 15 минут

Порядок — только чтение, ничего не менять до объяснения причины.

1. Зафиксировать симптом: что именно не работает — GUI, S3, узел, лента. Один симптом — одна гипотеза, а не «всё сломалось».
2. Проверить узел по management-сети: ping <MGMT_IP>, вход по SSH, uptime.
3. Проверить storage-кольцо: ping <STORAGE_IP> со всех нод. При MACHINE_DOWN при живой ноде это первое, что смотрят.
4. Проверить часы: ntpq -c rv, наличие * в ntpq -p. Уехавшие часы дают S3 403 всем клиентам при зелёном GUI.
5. Проверить S3-фронт: curl -sI http://127.0.0.1/ → 307 и Server: Quantum-ActiveScale.
6. Проверить процессы: pgrep -c mongod, pgrep -af haproxy, ss -ltnp по ключевым портам.
7. Прочитать события: какие LIVE, какие details, что говорит mona.log.
8. Только теперь — штатное действие: догон фазы, правка модели, замена диска, правка VLAN.

Если на шаге 2–3 узел и сеть живы, а симптом остаётся — не переустанавливать. Переустановка стирает улики и почти всегда удлиняет простой.

7. Анти-чеклист (чего не делать)

• Не переустанавливать узел до разбора: часть «поломок» — сеть, часы и модель.
• Не менять статусы в модели «на глаз»: NOTMANAGED — штатный инструмент, но только для портов/дисков, которые действительно не используются.
• Не править рендер конфигов руками: следующий -m вернёт битое или затрёт правку.
• Не гонять полный прогон install-ng, пока причина падения не понятна.
• Не закрывать события ignore до проверки: событие — единственная улика.
• Не менять VLAN на свиче без write memory и проверки startup-config.
• Не выдавать лабораторный обход за штатный путь: обход — временная мера с планом замены.

8. Источники

• X200 Getting Started Guide (дата доступа 2026-11-07)
• Software Documentation Center (7.3) (дата доступа 2026-11-07)
• Наша практика (обезличено): приёмка 3-нодных кластеров по 11 проверкам, полевой health-check.