Карта портов ActiveScale: что на каком порту и чем проверять

Коротко. У ActiveScale три плоскости портов: управление (10443 GUI, 8443 Model API по mTLS), данные (443 S3-фронт, 11060/11000-11003 DSS, 10000-10003 AXM) и метаданные (27017/27018/27019 mongod, 8180/8190 iamd). Отдельно — установка (8080 раздача ISO, 67/69 DHCP/TFTP) и лента (443+14512 Tape Connector). Частая причина — запрос не на ту плоскость.

1. Три плоскости — и почему это важно

Порты разделены по назначению; у каждой плоскости свой способ проверки.

Плоскость	Кто ходит	Как проверять
Управление	браузер оператора, автоматизация	HTTPS, для Model API — с клиентским сертификатом
Данные	S3-клиенты, демоны DSS	HTTP/HTTPS на `443`, thrift на `11060`
Метаданные	службы самого продукта	только с ноды, `ss -ltnp`

2. Таблица «порт → что → откуда → проверка»

Порт	Что на нём	Откуда доступен	Чем проверить (read-only)
`10443/tcp`	GUI samurai: nginx, TLS 1.2, HTTP/2 — единственная точка входа интерфейса	management-сеть, браузер	`curl -sk -o /dev/null -w '%{http_code}' https://<MGMT_IP>:10443/` → `200` или `307` (редирект на логин)
`8443/tcp`	Model API (mTLS), тот же nginx	с клиентским сертификатом; практически — с ноды под `root`	`sudo curl -sk --cert <CERT> --key <KEY> https://127.0.0.1:8443/model/machine/` → `200`
`443/tcp`	S3-фронт (haproxy, virtual-hosted стиль)	клиентская сеть; снаружи — через DNAT	`curl -sI http://127.0.0.1/` → `307` и `Server: Quantum-ActiveScale`
`8080/tcp`	HTTP-раздача установочного ISO	установочная сеть, admin-узел	`curl -sI http://<ADMIN_NODE>:8080/<IMAGE>.iso` → `200`
`67/udp`, `69/udp`	proxyDHCP и TFTP (dnsmasq)	установочный сегмент	`ss -lunp \\| grep -E ':(67\\|69) '` → по одному владельцу на адрес
`27017/tcp`	mongod `management_model`	localhost продукта	`ss -ltnp \\| grep 27017`; `pgrep -c mongod`
`27018/tcp`	mongod `environment_data`	localhost продукта	`ss -ltnp \\| grep 27018`
`27019/tcp`	mongod `federated_model`	localhost продукта	`ss -ltnp \\| grep 27019`
`11060/tcp`	DSS thrift (`dss-ng-client-daemon`)	localhost	sherpa с `port=11060`; дефолт `23510` даёт `connection-refused`
`11000–11003/tcp`	DSS client data	storage-сеть, адрес из колонки	`column.json`: `http://<STORAGE_IP>:11000-3`
`10000–10003/tcp`	AXM (ActiveScale eXtended Management)	storage-сеть	там же: `http://<STORAGE_IP>:10000-3`
`8180/tcp`, `8190/tcp`	iamd: REST и gRPC	localhost / management	`8180` на пустой GET отвечает `400` — признак «жив»
`4001`, `4003`, `16100`	samurai UI, bapi (long-poll), corleone gRPC	только localhost, за nginx	снаружи не проверяются, идут через `10443`
`25/tcp`	SMTP для уведомлений (зашит в продукт)	наружу, к почтовому релею	`554` в ответе = релей требует AUTH, продукт шлёт анонимно
`443/tcp`	Tape Connector: SWS (медиа/классы) и AML (логин, RAS)	из нод продукта в сеть коннектора	`curl -sk https://<CONNECTOR>:443/sws/v2/media/fsmedlist/state?format=JSON`
`14512/tcp`	Tape Connector: DTT (данные)	из нод продукта	`curl -s http://<CONNECTOR>:14512/version`
BMC	Redfish (HTTPS) и IPMI	сеть BMC/IPMI	`curl -sk -u <BMC_USER>:<BMC_PASS> https://<BMC_IP>/redfish/v1/Systems/system/ \\| jq .Boot`

Порты BMC здесь не нумеруются: доступ идёт по адресу BMC, а не через порты ноды.

3. Управление: `10443` и `8443`

10443 — то, что видит оператор. Это nginx (server-samurai.conf), который проксирует запросы внутрь: /, /ui/, /api/, /upload/, /ws — на samurai (127.0.0.1:4001), /bapi/ — на bapi (127.0.0.1:4003) с long-poll таймаутом 900s, /activescale.bapi.v1 — на gRPC corleone (16100). Наружу публикуется только 10443; внутренние порты GUI не открываются.

8443 — Model API. Тот же nginx, но с mTLS: без клиентского сертификата запрос не проходит. Сертификаты продукта лежат в /opt/ampli/cfg/marvin/ssl/machine.cert|key и доступны только root. Отсюда две классические ловушки:

curl с ноды без sudo даёт HTTP=000 — это не «API лежит», а «не предъявлен сертификат».
503 No replica set members match "Primary()" — транзиент клиента; повторить запрос или переждать, а не искать поломку модели.

Через 8443 читаются коллекции модели, /federated/_status/ и задачи.

4. Данные: `443`, `11060`, `11000`, `10000`

443 — S3-фронт. Здесь терминируется TLS и работает haproxy в virtual-hosted стиле (<bucket>.<domain>). Признак живого фронта — 307 с заголовком Server: Quantum-ActiveScale. 11000 — не S3-endpoint: это внутренний канал DSS, и клиент на него ходить не должен.

11060 — DSS thrift. Через него sherpa управляет политиками, неймспейсами и барометром. У CLI-демона дефолт 23510; обращение без явного port=11060 даёт connection-refused и выглядит как «DSS недоступен».

11000–11003 и 10000–10003 — адреса серверов DSS и AXM, которые попадают в column.json при установке. Если колонка не поднимается, сверяют эти адреса со storage-адресами нод.

5. Метаданные: mongod и iamd

Три mongod-кластера на каждой ноде: 27017 — management_model, 27018 — environment_data, 27019 — federated_model. На собранном 3-нодном стенде это шесть процессов mongod на ноду (по два на кластер) — число проверяется через pgrep -c mongod, а не по статусу приложения.

Федерация — отдельная ловушка: /opt/ampli/cfg/marvinweb/federated.cfg и group_vars/all/marvin.yml должны указывать на 27019 с репликасетом federated_model. Указание на 27017 даёт 30-секундный таймаут и No suitable management server found в install-ng — это портовая ошибка, а не «федерация сломана».

iamd слушает 8180 (REST) и 8190 (gRPC). Пустой GET на 8180 отвечает 400 — так и должно быть: служба жива и ждёт корректный запрос.

6. Установка: `8080`, `67`, `69`

8080 — обычная HTTP-раздача ISO на admin-узле (например, python3 -m http.server). Проверка раздачи — единственный способ отличить «PXE не настроен» от «образ не отдаётся».

67/udp и 69/udp — proxyDHCP и TFTP на том же admin-узле (dnsmasq запускается вручную, а не как systemd-юнит, и после ребута его нужно поднимать заново). В сегменте должен быть один DHCP и один TFTP: второй ответчик — роутер, чужой PXE, старый стенд — создаёт гонку, и узел уходит не туда.

7. Лента и BMC

Tape Connector — отдельное устройство со своим адресом. У него два рабочих порта: 443 (SWS — медиа, классы, состояния; AML — логин, медиа, RAS-тикеты) и 14512 (DTT — данные). Продукт исторически строит URL проверок без порта, то есть они всегда попадают на 443. Если коннектор живёт на адресе ноды продукта, 443 занят фронтом S3 — и проверки получают 501, а в событиях поднимается COLD_STORAGE_TAPE_CONNECTOR_UNAVAILABLE. Штатное решение — свой адрес коннектора в приватной сети, где 443 свободен.

Проверки коннектора (с ноды продукта, read-only):

curl -sk https://<CONNECTOR>:443/sws/v2/media/fsmedlist/state?format=JSON
curl -s  http://<CONNECTOR>:14512/version

Первая возвращает классы as_*_d_0, as_*_p_0, genscratch со свободными кассетами.

BMC — отдельная сеть: Redfish отдаёт питание и загрузку, IPMI — датчики и FRU. Порт BMC в карту портов продукта не входит.

8. Как проверять и чего не делать

Сначала плоскость, потом firewall. «Не открыт порт» подтверждается только после успешной проверки с самой ноды (ss -ltnp) и с соседней ноды по нужной сети.
mTLS-проверки — под root. Иначе получите HTTP=000 и ложный вывод «API недоступен».
Не путать 443 и 11000. Клиент S3 ходит только на 443; 11000 — внутренний канал.
Не занимать 443 ноды коннектором ленты. Это лабораторный обход, а не штатная схема: при первой же проверке продукт получит 501. Внутренние порты GUI (4001–4003, 16100) наружу не публикуются: они слушают localhost.

Минимальный набор read-only команд на ноде:

ss -ltnp | grep -E ':(443|8443|10443|11060|27017|27018|27019|8180|8190) '
pgrep -af mongod
pgrep -af haproxy

Ожидаемо: по одному слушателю на порт, mongod — по числу кластеров, один рабочий haproxy.

Источники

Software Documentation Center (7.3) (дата доступа 2026-11-07)
Наша практика (обезличено): карта портов и проверки на 3-нодных стендах, разбор коннектора ленты.

Карта портов ActiveScale

1. Три плоскости — и почему это важно

2. Таблица «порт → что → откуда → проверка»

3. Управление: 10443 и 8443

4. Данные: 443, 11060, 11000, 10000