Коротко. У ActiveScale три сети с разными задачами: management/public (управление и клиенты), storage/private (внутренний обмен данными между нодами) и BMC/IPMI (внеполосное управление). Смешать их в одну VLAN — значит получить MACHINE_DOWN при живых нодах и PXE, уходящий не туда. Планировать надо до выезда: адресация — по MAC, порядок выдачи адресов — management раньше storage.
1. Три сети и зачем каждая
| Сеть | Кто в ней | Что через неё идёт | Если её нет |
|---|---|---|---|
| Management / public | ноды, рабочая станция инженера, клиенты S3 | GUI, Model API, S3-трафик, задачи | систему не администрировать |
| Storage / private | только ноды кластера | обмен фрагментами, ремонт, репликация | MACHINE_DOWN при живой ноде |
| BMC / IPMI | BMC-контроллеры, админ-станция | питание, KVM, BootOrder, прошивки | нельзя перезагрузить узел удалённо |
Разделение — не формальность. Storage-сеть несёт самый тяжёлый и самый чувствительный к задержкам трафик: если она делит канал с клиентским S3, при ремонте диска просадка видна всем клиентам.
Дополнительно у X200 по вендорской схеме нужны два data-свича (или эквивалент заказчика) и отдельный IPMI-свич на стойку. Проектировать «в один свич» — заранее известный риск.
2. Что нужно знать про порты на ноде
Базовая конфигурация X200: три сервера 4U90, в каждом два compute-модуля; сзади на модуль — 2 × 25 GbE и IPMI. Минимальные требования клиентской сети для Z200 — 2 × 10/25 Gb на ноду, то есть минимум 6 × 10/25 Gb на кластер из трёх нод.
Практические следствия:
- Два UP-порта на ноду — рабочих. Один смотрит в management/public, второй — в storage/private.
Остальные порты, если они есть физически, в модели лучше не описывать: незадействованный NIC
в модели начинает сыпать событиями
NIC_DOWN— см. Лишние NIC. - Имена интерфейсов различаются. На одной и той же модели первый узел может отдать
enp3s0, остальные —enp3s0f0. Поэтому адресация — по MAC, а не по имени интерфейса. - Скорость и MTU — одинаковые на всех нодах. Разный MTU в storage-сети даёт плавающие проблемы, которые ищут неделю.
3. Адресация
Правила, которые снимают большинство проблем установки:
- Привязка MAC → IP, не «имя хоста → IP». Имя интерфейса и имя хоста меняются, MAC — нет.
- Management раньше storage. Если storage-порт поднимется первым и получит адрес из своей VLAN раньше, PXE может уйти не в ту сеть и узел «не найдётся» на ожидаемом адресе.
- Статические привязки внутри подсети установки. Адрес, выданный из чужой подсети, узел получит, но установка до него не достучится.
- Никаких дублирующихся MAC в очереди установки и в модели — иначе два узла будут спорить за один адрес.
- Резерв адресов под BMC и под будущие ноды — минимум по одному свободному на сеть.
Типовые ошибки, которые видно уже на этапе подготовки:
| Симптом | Что не так |
|---|---|
| узел не идёт по PXE, DHCP-запросы видны | storage-порт получил адрес первым |
| PXE прошёл, но установщик не находит ноду | адрес вне подсети установки |
| два узла «мигают» в модели | дубль MAC |
MACHINE_DOWN при живой ноде |
storage-сеть разрезана (VLAN/порт) |
Последний пункт разобран отдельно: MACHINE_DOWN при живой ноде.
4. VLAN: сколько и какие
Минимум — три VLAN: management/public, storage/private, BMC/IPMI. Часто добавляют четвёртую — для S3-клиентов, если они должны быть изолированы от управления.
Что учитывать:
- Шлюз в каждой VLAN, где он нужен. Storage-сеть обычно живёт без маршрутизации наружу — и это правильно.
- S3-домен и DNS. Если клиенты ходят по FQDN, нужна зона и (для virtual-hosted стиля) wildcard-запись; сертификат — с SAN. Подробнее: S3-домен и TLS.
- NTP. Сервер времени должен быть доступен из management-сети до установки: расхождение
часов позже проявится как
403у всех S3-клиентов сразу — см. NTP и время. - BMC отдельно. BMC в клиентской VLAN — лишняя поверхность атаки и лишний шум в мониторинге.
- Jumbo frames — только если весь путь поддерживает одинаково; иначе не включать вовсе.
5. Чек-лист перед выездом
- [ ] Три VLAN (минимум) с адресными планами и шлюзами.
- [ ] Таблица MAC → IP по каждой ноде, снятая с железа, а не из спецификации.
- [ ] Имена интерфейсов сняты с каждой ноды отдельно.
- [ ] Порядок выдачи адресов: management первым, storage вторым.
- [ ] Два data-свича (или эквивалент) и отдельный IPMI-свич.
- [ ] NTP-сервер доступен из management-сети.
- [ ] DNS-зона для S3/IAM (если клиенты ходят по FQDN), wildcard — если нужен virtual-hosted.
- [ ] Свободные адреса под BMC и будущие ноды.
- [ ] Одинаковый MTU на всех портах одной сети.
Полный список подготовки — Чек-лист подготовки к установке.
6. Проверка на живом железе
ip -br addrна каждой ноде — какие адреса реально получены и на каких интерфейсах.ip route— default route смотрит в management-сеть, а не в storage.ping <MGMT_IP>между нодами и с рабочей станции — отвечает.ping <STORAGE_IP>между нодами — отвечает; из клиентской сети — не должен.curl -sI https://<MGMT_IP>/— отвечает (код307на логин или200).- BMC:
curl -sk -u <USER>:<PASS> https://<BMC_IP>/redfish/v1/Systems/system/— отвечает.
Если storage-сеть не пингуется между нодами, дальше идти нет смысла: установка всё равно встанет, только позже и менее понятно.
7. Источники
- X200 Getting Started Guide (доступ 2026-11-07)
- P200 Site Planning (доступ 2026-11-07)
- ActiveScale Z200 Datasheet (доступ 2026-11-07)
- Наша практика: разделение сетей и порядок выдачи адресов на лабораторных стендах из трёх нод.
- Обновлено: 2026-11-07.