BOX 3.x
Варианты развертывания BOX 3.x
Централизованный кластер и локальные кластеры площадок: связность, отказоустойчивость, эксплуатация и консолидация данных.
На этой странице
Что определяет топологию
Выбор начинается не с количества серверов, а с требований к автономности площадок, задержке видеопотока, пропускной способности межплощадочных каналов, хранению данных, единой отчётности и модели сопровождения.
Ниже приведены две базовые схемы. Итоговая конфигурация может быть гибридной и всегда требует расчёта по числу камер, сценариям, разрешению, FPS, глубине архива и резервированию.
Базовая модель кластера BOX 3.x
Внутри каждого контура BOX 3.x сервисы работают под управлением Docker Swarm. Референсная архитектура предусматривает одну мастер-ноду для UI, API, бизнес-логики, Kafka и данных и одну или несколько вычислительных нод для видеопотоков и inference.
Горизонтально масштабируется вычислительная часть. Количество compute-узлов рассчитывается по камерам, FPS и профилю моделей; требования к резервированию мастер-ноды и хранилищ фиксируются проектом.
- Docker Swarm
- Мастер-нода — 1
- Вычислительные ноды — 1…N
- Kafka — центральная шина сообщений
- Хранилища разделены по профилю данных
Сравнение базовых вариантов
Централизованная схема упрощает единое управление. Локальная схема сохраняет обработку видео при проблемах внешнего канала.
| Критерий | Один общий кластер | Кластер на каждой площадке |
|---|---|---|
| Управление | Единый интерфейс, настройки и справочники | Локальное управление; нужна синхронизация правил |
| Межплощадочная сеть | Критична для передачи потоков и постоянной работы | Обработка продолжается локально при потере внешней связи |
| Отказоустойчивость | Ресурсы можно перераспределять внутри общего кластера | Отказ одной площадки не останавливает остальные |
| Данные и отчёты | Единая база событий и аналитика | Для общей отчётности нужен консолидирующий слой или BI |
| Сопровождение | Меньше контуров для обновления | Больше контуров, версий и точек контроля |
| Когда выбирать | Надёжные высокопроизводительные каналы и единый центр | Автономность объектов и ограниченная связность |
Вариант 1. Общий кластер
Все предприятия используют общий вычислительный и операционный контур. Это даёт единый интерфейс, централизованные справочники и конфигурацию, общую базу событий и возможность балансировать ресурсы между узлами.
Главная зависимость — стабильная и производительная сеть между объектами и центром. Нужно отдельно рассчитать трафик видеопотоков, задержки, резервные маршруты и поведение системы при деградации канала.
Вариант 2. Кластеры площадок
На каждом предприятии работает локальный кластер, который принимает и обрабатывает видео независимо. При потере межплощадочной связи основная видеоаналитика продолжает работать на объекте.
Для сводной аналитики можно использовать отдельный сервер консолидации или корпоративную BI-систему. Цена автономности — большее количество релизных контуров, необходимость синхронизировать настройки и более сложное сопровождение.
Что зафиксировать до поставки
Результатом архитектурного этапа должна стать не только схема серверов, но и проверяемый набор допущений.
- Количество и профили камер
- Сценарии, модели, FPS и задержка
- Глубина видео- и событийного архива
- RPO, RTO и схема резервирования
- Сетевые каналы и автономный режим
- GPU, CPU, RAM и дисковая подсистема
- Контуры test / preprod / production
- Мониторинг, журналирование и обновления
Требования к ресурсам
Ориентиры из ранних поставок — не универсальная формула sizing. Для актуального расчёта используйте профиль камер, модели и замеры на целевом runtime. Совместимость ОС, контейнерного стека, драйверов и GPU также фиксируется для конкретной версии и спецификации решения.