Перейти к содержанию

Раздел 1. Общие сведения о системе

Настоящий раздел даёт администратору эксплуатационное представление о BOX5-DIT-MGSN: какие функции выполняет система, из каких доменов состоит промышленный контур, какие подсистемы являются критичными и где искать подробные регламенты.

Полная архитектура решения приведена в ПД, разделе 3, реестр сервисов - в ПД, приложении Г, карта данных и хранилищ - в В7, разделе 1, порядок развёртывания и восстановления - в И2, разделе 2 и И2, разделе 3.

1.1. Назначение и логика работы системы

BOX5-DIT-MGSN предназначена для промышленной видеоаналитики в промышленном контуре. Система получает видеопотоки и архивные записи, применяет NRI-сценарии и модели компьютерного зрения, формирует события и нарушения, предоставляет web-интерфейс для работы пользователей и передаёт согласованные статусы во внешние системы заказчика.

В промышленном контуре пользователи входят через внешний контур авторизации Keycloak/OpenID Connect. После входа BOX5-DIT-MGSN работает с прикладным профилем пользователя: ролью, объектными правами доступа, доступными производственными площадками, журналом действий и доступом к камерам, событиям, сценариям, моделям и отчётам.

flowchart LR user["Пользователь
администратор, эксперт, аналитик, ОТиПБ"] keycloak["Keycloak / OIDC"] ui["ui-nginx + Web UI"] gateway["ui-rest-to-gprc
REST / GraphQL / WebSocket"] stat["statistics
пользователи, камеры, события, отчёты, аудит"] inf["inference
медиасервер, балансировщик, NRI"] svr["severstal
ПК-КОТ, CSVN/VMS, АСУ ТП, сценарии"] ds["data-storage
MinIO / DTS"] kafka["Kafka
события, команды, heartbeat"] obs["elk-log
Prometheus / Loki"] user --> keycloak --> ui --> gateway gateway --> stat gateway --> inf gateway --> svr stat <--> kafka inf <--> kafka svr <--> kafka stat --> ds inf --> ds svr --> ds stat --> obs inf --> obs svr --> obs

Исходный Mermaid-код схемы: И3-MER-001. 1.1. Назначение и логика работы системы.

Основная логика работы:

  1. Камеры, виртуальные камеры и внешние видеоисточники передают видеоданные в контур inference.
  2. inf-load-balancer назначает камеры на медиасерверы, inf-mediaserver получает поток и передаёт кадры в inf-nri-inference.
  3. NRI-сценарии и модели формируют события, heartbeat и диагностические сообщения, которые публикуются в Kafka.
  4. Сервисы statistics сохраняют события, нарушения, статусы, медиа, отчёты, аудит и данные доступа пользователей.
  5. Интеграционный контур severstal синхронизирует предметные справочники, сценарии и внешние системы заказчика, включая ПК-КОТ, CSVN/VMS и АСУ ТП.
  6. Web UI отображает пользователю камеры, события, отчёты, роли, журналы и мониторинг через единый API-шлюз.

Административная логика разделяется на два уровня:

Уровень Что администрируется Где выполняется
Прикладное администрирование Пользователи, роли, объектные права, камеры, объекты, сценарии, модели, отчёты и журналы действий. Web UI BOX5-DIT-MGSN и REST API за ui-nginx.
Системное администрирование Дистрибутив, Docker-домены, .env-параметры, логи, метрики, резервное копирование, восстановление, обновления и состояние узлов. Серверы поставки, ~/CODE/box3, compose.sh, Docker, каталоги данных и журналы.

PROD является промышленным контуром с полным набором камер и штатной интеграцией с ПК-КОТ. TEST используется для проверки версии, сценариев, конфигурации и моделей перед переносом в PROD, но не является источником промышленных данных. Изменения в PROD выполняются только в согласованное окно, после фиксации исходного состояния и проверки резервного копирования.

1.2. Ландшафты и схема размещения

Для эксплуатации BOX5-DIT-MGSN используются три контура. DEV и TEST применяются для подготовки и проверки изменений, PROD является рабочим контуром заказчика.

Контур Адрес Назначение Примечание
DEV 10.114.47.6 Разработка и первичная проверка изменений. Контур исполнителя.
TEST 10.114.47.2 Функциональное и регрессионное тестирование перед переносом в PROD. Контур проверки поставки.
PROD 10.97.145.147 Рабочая промышленная эксплуатация. Рабочий контур заказчика.

Сравнение контуров по эксплуатационному составу:

Окружение Назначение Состав компонентов Отличия от PROD Ограничения
DEV Разработка и первичная проверка изменений исполнителем. Одна машина 10.114.47.6; роли db, rest, inference и служебные функции совмещаются на одном сервере; используется сокращённый профиль поставки по фактической конфигурации разработки. Не является Docker Swarm-кластером; количество камер, объём данных, внешние интеграции и производительность не соответствуют PROD. Не используется для промышленной эксплуатации; промышленные данные не размещаются; результаты переносятся далее только в составе подготовленной поставки.
TEST Функциональное и регрессионное тестирование версии, сценариев, моделей и конфигурации перед PROD. Docker Swarm: 1 мастер-нода 10.114.47.2 и 2 вычислительные ноды; состав доменов соответствует PROD: ui-rest, statistics, inference, extended-inference, severstal, data-storage, kafka-domain, elk-log, node-red-sandbox, БД и хранилища. Сокращённый набор камер и данных; интеграция с ПК-КОТ выполняется через тестовый источник или заглушку; нагрузочный профиль ниже PROD. Не является источником промышленных данных; перенос результатов в PROD выполняется только после согласования и резервного копирования.
PROD Рабочая промышленная эксплуатация BOX5-DIT-MGSN заказчиком. Docker Swarm: 1 мастер-нода ctd-sova-cpu02.severstal.severstalgroup.com (10.97.145.147) и 11 вычислительных GPU-нод; полный состав доменов, БД, ClickHouse, MinIO/DTS, Kafka, Prometheus/Loki, песочница Node-RED и штатные интеграции. Базовый контур сравнения. Изменения выполняются только в согласованное технологическое окно после проверки на TEST; требуется контроль резервных копий, лицензирования, GPU-нод и внешних интеграций.

Состав узлов контуров:

Контур Топология Узлы
DEV Один сервер, Docker Swarm-кластер не формируется. 10.114.47.6; роли db, rest, inference и служебные функции совмещаются на одной машине.
TEST Docker Swarm: 1 мастер-нода и 2 вычислительные ноды. Мастер-нода доступна по 10.114.47.2; имена вычислительных нод фиксируются эксплуатационной конфигурацией TEST.
PROD Docker Swarm: 1 мастер-нода и 11 вычислительных GPU-нод. Состав PROD-сегмента приведён ниже.

Состав PROD-сегмента:

Роль Узел
Мастер-нода ctd-sova-cpu02.severstal.severstalgroup.com
Вычислительная GPU-нода ctd-sova-gpu01.severstal.severstalgroup.com
Вычислительная GPU-нода ctd-sova-gpu02.severstal.severstalgroup.com
Вычислительная GPU-нода ctd-sova-gpu03.severstal.severstalgroup.com
Вычислительная GPU-нода ctd-sova-gpu04.severstal.severstalgroup.com
Вычислительная GPU-нода ctd-sova-gpu05.severstal.severstalgroup.com
Вычислительная GPU-нода ctd-sova-gpu11.severstal.severstalgroup.com
Вычислительная GPU-нода metiz-sova-gpu1.severstal.severstalgroup.com
Вычислительная GPU-нода blg-sova-gpu01.severstal.severstalgroup.com
Вычислительная GPU-нода blg-sova-gpu02.severstal.severstalgroup.com
Вычислительная GPU-нода blg-sova-gpu03.severstal.severstalgroup.com
Вычислительная GPU-нода blg-sova-gpu04.severstal.severstalgroup.com

Размещение данных и инфраструктурные отличия:

Контур БД, шины и хранилища Runtime-данные inference Внешние подключения и балансировка
DEV Размещаются на одной машине вместе с сервисами; ${COMPOSE_DATA} локален для DEV. Модели, /converted, IPC/tmpfs и временные media-каталоги локальны для одной машины. Внешние подключения используются только в объёме, необходимом для разработки; внешний инфраструктурный балансировщик не фиксируется.
TEST БД, ClickHouse, Redis, Kafka, MinIO/DTS и elk-log размещаются на мастер-ноде TEST; вычислительные ноды используют локальные runtime-каталоги. Runtime inference работает на 2 вычислительных нодах; модели и временные каталоги синхронизируются по регламенту TEST. Используются тестовые подключения или заглушки; перед PROD проверяются UI/API, мониторинг, inf-load-balancer и внешние интеграции.
PROD PostgreSQL/Redis, ClickHouse, Kafka, MinIO/DTS и elk-log размещаются на мастер-ноде PROD; перечень хранилищ раскрыт в В7, разделе 1. Runtime inference распределён по 11 GPU-нодам; per-node /converted, /mnt/ram0, /tsm_tmpfs, IPC и временные media-данные являются локальными для вычислительной ноды. Внешние подключения: Keycloak/OIDC, SMTP, ПК-КОТ, CSVN/VMS, АСУ ТП, GitLab/Registry для поставки и внешняя Grafana заказчика. В составе BOX5-DIT-MGSN показывается только inf-load-balancer; внешние и инфраструктурные балансировщики заказчика не описываются, если они не входят в поставку исполнителя.

Движение изменений между контурами:

flowchart LR dev["DEV-контур
10.114.47.6
1 машина, без кластера"] test["TEST-контур
10.114.47.2
1 мастер + 2 вычислительные ноды"] prod["PROD-контур
10.97.145.147
1 мастер + 11 вычислительных нод"] dev -->|"перенос версии и конфигурации"| test test -->|"после проверки"| prod

Исходный Mermaid-код схемы: И3-MER-002. 1.2. Ландшафты и схема размещения, схема 2.

Схема размещения PROD показывает фактический состав узлов Docker Swarm и основные группы сервисов рабочего контура заказчика. Различия DEV, TEST и PROD отражены в таблицах выше, поэтому отдельные схемы подготовительных контуров в разделе не дублируются. Сетевые зоны на схеме не разделяются: для данного контура используется единая зона площадки заказчика, а контроль сетевого доступа выполняется средствами площадки заказчика. Внешние системы, источники артефактов и внешние потребители эксплуатационных данных отображаются за пределами контура BOX5-DIT-MGSN. Из балансировщиков в составе BOX5-DIT-MGSN отражён inf-load-balancer; внешние и инфраструктурные балансировщики заказчика не показываются, если они не входят в поставку исполнителя. БД, Kafka и файловые хранилища показаны как группа мастер-ноды; детализация состава данных приведена в В7, разделе 1. Внешняя Grafana заказчика получает показатели работы системы из согласованных источников BOX5-DIT-MGSN; на схеме основной поток показан от аналитических витрин ClickHouse.

flowchart TB classDef external fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#0d47a1; classDef node fill:#e8f5e9,stroke:#2e7d32,stroke-width:3px,color:#1b5e20; classDef container fill:#c8e6c9,stroke:#388e3c,stroke-width:1px,color:#1b5e20; classDef backend fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px,color:#4a148c; classDef lb fill:#fff8e1,stroke:#f9a825,stroke-width:2px,color:#e65100; classDef storage fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#bf360c; classDef monitor fill:#eceff1,stroke:#37474f,stroke-width:2px,color:#263238; classDef network fill:#fce4ec,stroke:#c62828,stroke-width:2px,color:#b71c1c,stroke-dasharray:5 5; classDef sandbox fill:#fff7ed,stroke:#c2410c,stroke-width:2px,color:#7c2d12; subgraph EXTERNAL["Внешние системы"] direction TB EXT_USERS["Пользователи, камеры,
CSVN/VMS, ПК-КОТ,
АСУ ТП, OIDC, SMTP"]:::external REGISTRY["GitLab / Registry
артефакты поставки"]:::external end PUBLISHED["Публикуемые входы PROD
10.97.145.147
HTTP/HTTPS, RTSP, архивы"]:::external MASTER_APP["Мастер-нода / Swarm manager
ctd-sova-cpu02.severstal.
severstalgroup.com
labels: db, rest
UI/API: ui-nginx, ui-react, ui-rest-to-gprc
Backend: statistics, severstal
CODE: ~/CODE/box3"]:::node subgraph COMPUTE["Вычислительный GPU-контур
Docker label: inference"] direction TB INF_CTRL["Inference control-plane
inf-load-balancer, inf-monitoring,
inf-image-storage, inf-flows-manager,
svr-models-registry, converters,
report-video-extractor, Guardant, Coturn"]:::lb subgraph GPU_NODES["Вычислительные GPU-ноды PROD (11)"] direction LR subgraph CTD["CTD GPU-ноды (6)
ctd-sova-gpu01, 02, 03, 04, 05, 11"] direction TB CTD_RUNTIME["inf-mediaserver -> IPC/tmpfs
-> inf-nri-inference -> модели AI
/converted, /mnt/ram0, /tsm_tmpfs"]:::node CTD_SANDBOX["Node-RED Sandbox
размещён на CTD GPU-ноде
nr-sbx-nginx, nr-sbx-frontend,
nr-sbx-backend, nr-sbx-node-red-vl,
nr-sbx-nri, nr-sbx-kafka,
nr-sbx-redis, nr-sbx-celery,
nr-sbx-flower, nr-sbx-mm-conversion,
nr-sbx-yolo-conversion
labels: nr_sandbox,
flows_manager, events_validator"]:::sandbox end METIZ["Metiz GPU-нода (1)
metiz-sova-gpu1
inf-mediaserver -> IPC/tmpfs
-> inf-nri-inference -> модели AI
/converted, /mnt/ram0, /tsm_tmpfs"]:::node BLG["BLG GPU-ноды (4)
blg-sova-gpu01, 02, 03, 04
inf-mediaserver -> IPC/tmpfs
-> inf-nri-inference -> модели AI
/converted, /mnt/ram0, /tsm_tmpfs"]:::node end end MASTER_DATA["Хранилища и шины мастер-ноды
PostgreSQL/Redis, ClickHouse,
MinIO/DTS, inf-kafka,
runtime YAML/config state"]:::storage OBS["Мониторинг и логи
log-prometheus, log-loki"]:::monitor subgraph SUPPORT["Эксплуатационный обмен"] direction TB NETWORK["Логические сети
Docker Swarm overlay bx_default,
node-red-sandbox,
per-node COMPOSE_DATA"]:::network GRAFANA["Grafana заказчика
показатели и логи"]:::external end EXT_USERS ==>|"вход"| PUBLISHED PUBLISHED ==>|"HTTP(S)"| MASTER_APP PUBLISHED ==>|"RTSP/файлы"| COMPUTE EXT_USERS <-->|"справочники,
статусы, OIDC/SMTP"| MASTER_APP REGISTRY -.->|"образы"| MASTER_APP MASTER_APP ==>|"API"| COMPUTE MASTER_APP ==>|"/sandbox/"| CTD_SANDBOX MASTER_APP ==>|"данные"| MASTER_DATA INF_CTRL ==>|"камеры, flows,
модели"| GPU_NODES GPU_NODES ==>|"events, media"| MASTER_DATA CTD_SANDBOX -.->|"сценарии,
модели, ассеты"| MASTER_DATA MASTER_APP -.->|"metrics/logs"| OBS MASTER_DATA -.->|"metrics/logs"| OBS COMPUTE -.->|"metrics/logs"| OBS CTD_SANDBOX -.->|"metrics/logs"| OBS MASTER_DATA ==>|"витрины ClickHouse"| GRAFANA OBS ==>|"показатели и логи"| GRAFANA MASTER_APP -.-> NETWORK COMPUTE -.-> NETWORK CTD_SANDBOX -.-> NETWORK class COMPUTE node; class SUPPORT network;

Исходный Mermaid-код схемы: И3-MER-003. 1.2. Ландшафты и схема размещения, схема 3.

Размещение ролей по узлам:

Узел Роли Docker labels Основные сервисы Данные и хранилища
Мастер-нода / Swarm manager db, rest; при наличии GPU также может выполнять inference ui-rest, backend-сервисы statistics и severstal, data-storage, kafka-domain, elk-log, служебные компоненты поставки. Доменные PostgreSQL, ClickHouse и Redis, Kafka data, MinIO/DTS, резервные копии, ${COMPOSE_DATA}.
Вычислительная GPU-нода inference inf-load-balancer, inf-mediaserver, inf-nri-inference, inf-monitoring, сервисы моделей и конвертации. Локальные модели, /converted, runtime-каталоги inference, tmpfs/IPC и временные медиаданные.
CTD GPU-нода с песочницей inference, nr_sandbox, flows_manager, events_validator Сервисы node-red-sandbox, sandbox Redis/Kafka, Celery, Flower, инструменты публикации flows и проверки событий. Данные песочницы, sandbox-сессии, ассеты сценариев, модели и результаты проверочных запусков.
Дополнительные вычислительные GPU-ноды inference Дополнительные экземпляры медиасервера и NRI-инференса для распределения камер и сценариев. Локальные модели, runtime-каталоги inference и временные данные обработки.

DEV совмещает роли на одном сервере. TEST разворачивается как кластер из одной мастер-ноды и двух вычислительных нод. PROD разворачивается как кластер из одной мастер-ноды и 11 вычислительных GPU-нод.

1.3. Состав и структура системы

BOX5-DIT-MGSN разворачивается как набор Docker Compose-доменов. Домен содержит один или несколько сервисов и собственные .env-параметры, а запуск и остановка выполняются из корня поставки через compose.sh. Для промышленного контура администратор должен рассматривать домен как минимальную единицу штатного перезапуска, если нет отдельного согласованного плана.

Домен Назначение Критичность для PROD
ui-rest Внешний web-вход, статический UI, API-шлюз ui-rest-to-gprc, маршруты /api/*, /api/ws/, /config.json, /settings.json, /sandbox/. Высокая: отказ блокирует интерактивную работу пользователей и большинство API-действий.
statistics Пользователи, роли, доступы, камеры, объекты, события, отчёты, уведомления, audit, ClickHouse-витрины. Высокая: отказ блокирует хранение и выдачу прикладных данных.
inference Медиасерверы, балансировка камер, NRI runtime, мониторинг камер, модели, изображения и видеофрагменты. Высокая: отказ прекращает формирование новых событий по видеопотокам.
extended-inference Управление flows, ресурсами инференса и связанными runtime-состояниями. Средняя/высокая: влияет на применение сценариев и управление ресурсами.
severstal Предметные сервисы и интеграции с ПК-КОТ, CSVN/VMS, АСУ ТП, сценариями, моделями, ассетами и переводами. Высокая для промышленной интеграции и предметных справочников.
data-storage MinIO, временное хранилище DTS, Redis временных объектов и шлюз /api/s3/. Высокая для медиа, отчётов, сценариев, моделей и файловых ссылок.
kafka-domain Основная Kafka-шина событий, команд, heartbeat и audit-сообщений. Высокая: нарушение Kafka разрывает асинхронную связность доменов.
elk-log Prometheus и Loki для эксплуатационного мониторинга и журналов. Средняя: отказ не останавливает аналитику, но ухудшает диагностику.
node-red-sandbox Песочница подготовки и проверки NRI-сценариев, конвертации моделей и sandbox-сессий. Низкая для текущей промышленной обработки, высокая для подготовки новых сценариев.

Основные эксплуатационные артефакты:

Артефакт Назначение
~/CODE/box3 Корневой каталог поставки с доменами, domains.conf, compose-файлами и .env-параметрами.
~/CODE/node-red-sandbox Отдельный compose-контур песочницы, если он вынесен из корня box3.
compose.sh Штатный wrapper запуска, остановки, проверки, pull и restart доменов.
${COMPOSE_DATA} Корневой каталог данных: PostgreSQL, ClickHouse, MinIO, Kafka, логи, отчёты, модели, сценарии и видео.
ui-rest/ui-config/config.json, settings.json Runtime-конфигурация web-интерфейса и клиентских feature flags.
Доменные .env Версии образов, внутренние endpoints, Kafka topics, пути, feature flags и параметры доступа.
Docker logs / Loki Основной источник runtime-журналов сервисов.

Данные системы распределены по нескольким типам хранилищ:

Тип данных Основные хранилища Что важно администратору
Пользователи и права PostgreSQL st-auth, st-access; Redis st-auth для служебных locks. Резервные копии st-auth и st-access критичны для входа и доступа.
Камеры, объекты и зоны PostgreSQL st-camera-storage, Kafka-фан-аут в downstream-сервисы. После восстановления или массовых изменений нужно проверять downstream-синхронизацию.
События и нарушения PostgreSQL st-event-storage, ClickHouse-зеркала, MinIO bucket event-storage. БД и медиа должны восстанавливаться согласованно.
Сценарии и модели svr-scenario-storage, svr-lite-scenario-storage, svr-models-registry, filesystem/MinIO, /models, /converted. Потеря файлов без БД или БД без файлов приводит к неработающим сценариям и моделям.
Интеграционные справочники svr-postgres-pk-kot, svr-severstal-integration, svr-asutp, Kafka/Schema Registry. Для PROD критична штатная связность с системами заказчика и корректность повторной синхронизации.
Временные бинарные объекты ds-data-temporary-storage, Redis DTS с TTL. Потеря DTS не восстанавливает временные UUID, но долговременные MinIO-объекты остаются отдельно.

Сетевые и инфраструктурные границы:

  • пользовательский вход и API идут через ui-nginx;
  • большинство сервисов доступно только внутри Docker-сети bx_default;
  • node-red-sandbox использует отдельную сеть и собственные volumes;
  • GPU и IPC/shared-memory критичны для медиасервера и NRI;
  • опубликованные технические порты и внешние endpoints должны быть ограничены сетевыми правилами площадки;
  • .env, токены, пароли, приватные URL, дампы БД и лицензионные файлы не публикуются в документации и общих каналах.

Для администратора базовая проверка структуры после запуска включает:

cd ~/CODE/box3

compose.sh check
compose.sh status all
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'
curl -fsS http://localhost/api/base/ping/
df -h / /data
nvidia-smi

Если промышленный контур развёрнут в swarm-профиле, вместо одноузловых compose-проверок используются штатные swarm-команды поставки, но логика контроля остаётся той же: состояние доменов, доступность UI/API, работа Kafka, хранилищ, GPU, инференса, интеграций и резервных копий.