Руководство администратора¶

Полное наименование: Центральный модуль управления данными и распределёнными вычислениями Обозначение: LPI-VAP-CORE Краткое наименование (для работы с документом): «Центральный модуль» Программный продукт: «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0») Стандарт: ГОСТ 19.503-79

Аннотация¶

Настоящий документ является руководством администратора Центрального модуля управления данными и распределёнными вычислениями (LPI-VAP-CORE) в составе программного продукта «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0»; далее — Платформа 4.0). Документ предназначен для специалистов, выполняющих развёртывание, настройку, проверку и обслуживание серверной части компонента.

Документ определяет: общие сведения о компоненте, требования к техническим и программным средствам, состав составных частей и связи между ними, порядок подготовки узлов, развёртывания и запуска, состав параметров настройки, порядок настройки доступа, источников медиаданных и интеграционного обмена, способы проверки работоспособности, регламентные операции обслуживания, а также сообщения и диагностические признаки, возникающие при настройке, проверке и эксплуатации.

Порядок работы пользователя в веб-интерфейсе приведён в руководстве пользователя; состав, логическая структура, входные и выходные данные компонента — в описании программы; состав и версии поставки — в формуляре.

Администратор должен: владеть навыками администрирования серверных операционных систем и кластеров Kubernetes, уметь работать с Helm и kubectl, понимать назначение применяемых хранилищ и брокера сообщений, знать принятый у заказчика порядок предоставления доступа, резервного копирования и обращения в службу сопровождения, а также знать настоящее руководство. Подготовка в области разработки программного обеспечения и машинного обучения не требуется.

1. Общие сведения о программе¶

1.1. Назначение и функции программы¶

Центральный модуль управления данными и распределёнными вычислениями (LPI-VAP-CORE) является управляющим и исполняющим контуром Платформы 4.0. Он обеспечивает ведение данных видеоаналитики, организацию распределённой обработки видеопотоков и отдельных кадров, регистрацию событий и нарушений и представление результатов пользователю.

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

Таблица 1.1.1 — Задачи администратора компонента.

Функциональные возможности компонента, доступные пользователям, приведены в разделах 1 и 2 описания программы, а порядок работы в веб-интерфейсе — в руководстве пользователя.

Подготовка, конвертация и версионирование моделей видеоаналитики выполняются компонентом управления моделями видеоаналитики (LPI-VAP-MM), разработка и отладка версий сценариев — компонентом среды разработки сценариев видеоаналитики (LPI-VAP-RS), обработка изображений мультимодальными языковыми моделями — компонентом обработки мультимодальных данных (LPI-VAP-MLLM). Администрирование этих компонентов выполняется по их собственным руководствам; настоящий документ описывает только использование их результатов Центральным модулем управления данными и распределёнными вычислениями.

1.2. Сведения о технических средствах¶

Компонент размещается в кластере Kubernetes на серверных технических средствах заказчика. Узлы кластера разделены на три типа; их состав приведён в таблице 1.2.1. LLM-нода относится к компоненту LPI-VAP-MLLM и используется Центральным модулем как внешний вычислительный ресурс.

Таблица 1.2.1 — Типы серверных узлов кластера.

Размещение рабочих нагрузок по типам узлов задаётся метками узлов и правилами планирования Kubernetes (nodeSelector, affinity и tolerations) в конфигурации Helm-релиза. Количественные требования к мастер-ноде и вычислительной ноде приведены в подразделе 4.3 описания программы.

Минимальная конфигурация, установленная требованиями к инфраструктуре заказчика, и вариант её распределения по узлам приведены в таблице 1.2.2.

Таблица 1.2.2 — Минимальная конфигурация серверного оборудования.

Таблица 1.2.2 соответствует одной вычислительной ноде. Для обработки не менее 6000 камер при опросе одного кадра раз в две минуты применяются четыре вычислительные ноды, суммарно 16 ускорителей класса NVIDIA T4. Ресурсы LLM-ноды в итог LPI-VAP-CORE не включаются.

Каждый графический ускоритель вычислительного узла должен иметь не менее 16 ГБ видеопамяти, CUDA Compute Capability не ниже 7.5, не менее 2 560 CUDA-ядер и 300 Tensor Cores, пропускную способность видеопамяти не менее 300 ГБ/с и аппаратную поддержку вычислений FP16 и INT8. Допускается применение эквивалента, не уступающего указанным значениям.

Требования «не хуже», подтверждённые обследованием контрольной конфигурации, приведены в таблице 1.2.3. Полный состав требований и порядок расчёта числа узлов приведены в подразделах 4.1–4.4 описания программы.

Таблица 1.2.3 — Требования «не хуже» к техническим средствам.

Размещение данных компонента по носителям приведено в таблице 1.2.4.

Таблица 1.2.4 — Размещение данных на технических средствах.

Рабочее место администратора должно соответствовать требованиям подраздела 2.1 руководства пользователя и дополнительно обеспечивать защищённый доступ к консоли управления серверными узлами в соответствии с принятым у заказчика порядком.

1.3. Сведения о программных средствах¶

Системное программное обеспечение узлов приведено в таблице 1.3.1.

Таблица 1.3.1 — Системное программное обеспечение.

Инфраструктурные сервисы, входящие в поставку компонента, приведены в таблице 1.3.2.

Таблица 1.3.2 — Инфраструктурные сервисы компонента.

Внешние программные средства, необходимые для работы компонента, приведены в таблице 1.3.3.

Таблица 1.3.3 — Внешние программные средства.

Для работы администратора требуются: веб-браузер в соответствии с подразделом 2.2 руководства пользователя, защищённый доступ к консоли управления узлами и к API Kubernetes, а также Helm и kubectl. Установка средств разработки и сборки на серверные узлы не требуется: составные части поставляются готовыми контейнерными образами. Точные версии программных средств целевой поставки приведены в формуляре.

2. Структура программы¶

2.1. Составные части программы¶

Компонент поставляется набором контейнерных образов и Helm-чартом box5. Родительский чарт объединяет дочерние чарты функциональных доменов, в том числе workflow, ui-rest, statistics, integration, data-storage, data-sync, utils, mediamtx, inference и redis. Конкретный состав дочерних чартов и их версии фиксируются формуляром целевой поставки. Состав функций приведён в таблице 2.1.1. Технические обозначения сервисов соответствуют схеме развёртывания Платформы 4.0 и не являются самостоятельными программными продуктами.

Таблица 2.1.1 — Составные части компонента.

Отключение опциональной составной части выполняется исключением соответствующего дочернего чарта или рабочей нагрузки из состава Helm-релиза (подраздел 3.3). В Kubernetes прикладные сервисы обычно представлены ресурсами Deployment, хранилища — StatefulSet и постоянными томами, сетевые точки доступа — Service и Ingress, параметры — ConfigMap, а конфиденциальные значения — Secret. При отключении связанная функция становится недоступной, а остальные функции продолжают работать.

2.2. Связи между составными частями¶

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

1. синхронные вызовы — пользовательские и программные запросы поступают через веб-шлюз в прикладной шлюз, который обращается к сервисам по внутренним типизированным интерфейсам и возвращает результат;
2. асинхронный обмен — команды, результаты обработки и уведомления передаются через брокер сообщений; получатель обрабатывает сообщение независимо от отправителя, при недоступности потребителя сообщение сохраняется в брокере;
3. общие хранилища и локальные области узла — транзакционное, аналитическое и объектное хранилища, кэш, временное хранилище кадров, а на вычислительном узле — разделяемая память между приёмом видеопотоков и исполняющим ядром и локальный каталог артефактов моделей.

Схема связей приведена на схеме 2.1.

Схема 2.1 — Связи между составными частями компонента.

Основные группы сообщений обмена приведены в таблице 2.2.1.

Таблица 2.2.1 — Группы сообщений обмена.

Зависимости запуска составных частей приведены в таблице 2.2.2; порядок выполнения запуска описан в подразделе 3.2.

Таблица 2.2.2 — Зависимости запуска составных частей.

2.3. Связи с другими программами¶

Внешние связи компонента и требования к ним приведены в таблице 2.3.1.

Таблица 2.3.1 — Связи с другими программами и системами.

Перечень сетевых адресов, портов и реквизитов подключения для целевой поставки приводится в эксплуатационной документации и в приложении Г.

3. Настройка программы¶

3.1. Настройка на состав технических средств¶

Подготовка кластера выполняется до развёртывания компонента в следующем порядке.

1. Кластер Kubernetes. На узлах устанавливаются серверная операционная система, совместимая среда исполнения контейнеров и Kubernetes. Проверяются состояния Ready, системные рабочие нагрузки, внутренняя служба DNS и доступ администратора к API кластера.
2. Типы узлов и планирование. Узлам назначаются согласованные проектом метки для мастер-нод и вычислительных нод. Для рабочих нагрузок задаются nodeSelector, affinity и tolerations, исключающие размещение хранилищ и прикладных сервисов на неподходящих узлах. LLM-нода настраивается по руководству компонента LPI-VAP-MLLM.
3. Постоянные тома. Создаются классы хранения и постоянные тома для транзакционного и аналитического хранилищ, объектного хранилища, брокера, журналов и, при использовании видеоархива, архивных материалов. Политика возврата томов не должна удалять данные при удалении Helm-релиза. Запас свободного места — не менее 20 %.
4. Оперативная и разделяемая память. На вычислительных нодах выделяются область разделяемой памяти для передачи кадров между медиасервером и исполняющим ядром — не менее половины оперативной памяти ноды — и отдельная область для обмена кадрами и сегментов трансляций — не менее 4 ГБ. Способ предоставления задаётся томами и параметрами рабочих нагрузок чарта.
5. Графические ускорители. На вычислительных нодах устанавливаются драйвер NVIDIA и средства предоставления GPU в Kubernetes. Ускорители должны отображаться как доступный ресурс nvidia.com/gpu; запросы и пределы GPU задаются в Helm-конфигурации рабочих нагрузок вычислительного контура.
6. Сеть и входной трафик. Проверяются связность узлов, разрешение имён сервисов, доступ к источникам медиаданных, внешним системам и СУДИР. Для пользовательского доступа настраиваются Ingress либо предусмотренная проектом служба типа LoadBalancer, сертификат HTTPS и медиапорты HLS, WebRTC и TURN/STUN.
7. Время. Все узлы синхронизируются с единым источником NTP; расхождение не должно превышать 1 секунды.
8. Образы и секреты. В пространстве имён создаётся imagePullSecret для реестра образов. Пароли хранилищ, ключи СУДИР, SMTP и иные реквизиты помещаются в Kubernetes Secret, а не в открытый файл значений Helm.
9. Режим работы серверов. На серверных узлах отключаются спящий режим и гибернация, включается автоматический запуск служб Kubernetes после перезагрузки. Системные лимиты, параметры ядра и файловых систем задаются проектом поставки; произвольное изменение этих параметров не допускается.

Исходное состояние кластера проверяется командами:

kubectl get nodes -o wide
kubectl get storageclass
kubectl get pods -A
kubectl describe node <имя-вычислительной-ноды>

В выводе describe node вычислительной ноды должно присутствовать требуемое число ресурсов nvidia.com/gpu. Фактические имена меток, классов хранения, пространства имён и секретов устанавливаются схемой развёртывания целевой поставки и фиксируются в приложении Г.

3.1.1. Контроль готовности инфраструктуры¶

До установки релиза администратор заполняет контрольный лист. Версии и имена в таблице сверяются со спецификацией конкретной поставки, а не с примерами из документов предыдущих версий.

Таблица 3.1.1 — Предварительная проверка инфраструктуры.

Схема 3.1 — Размещение рабочих нагрузок Центрального модуля в Kubernetes.

3.2. Развёртывание и запуск¶

Целевое развёртывание выполняется единым Helm-релизом родительского чарта box5. В командах ниже используются обозначения, значения которых задаются проектом поставки:

• <релиз> — имя Helm-релиза;
• <пространство> — пространство имён Kubernetes;
• <чарт> — путь к каталогу или пакету чарта BOX5;
• <значения> — файл открытых значений целевой поставки.

Таблица 3.2.1 — Основные команды развёртывания и контроля.

3.2.1. Состав и проверка дистрибутива¶

Комплект установки формируется для конкретной версии поставки и должен позволять установить её без обращения к публичным репозиториям. Рекомендуемый состав комплекта приведён в таблице 3.2.2.

Таблица 3.2.2 — Состав комплекта установки.

В изолированном контуре образы сначала загружаются в доверенный внутренний реестр с сохранением digest, затем ссылки на него указываются в значениях Helm. Установка образов непосредственно на отдельные ноды не применяется: Kubernetes должен получать одинаковый образ из реестра при любом повторном планировании пода.

Факт приёмки дистрибутива фиксируется в протоколе приложения Е: версия, контрольные суммы, перечень загруженных образов и результат шаблонизации чарта.

3.2.2. Первичное развёртывание¶

1. Подготовить пространство имён, Secret с конфиденциальными параметрами, imagePullSecret, классы хранения и постоянные тома.
2. Заполнить файл значений: версии образов, адреса хранилищ и брокера, параметры СУДИР и внешних систем, состав включённых дочерних чартов, ресурсы, метки размещения и параметры входного трафика.
3. Выполнить helm dependency build, helm lint и helm template; проверить, что секретные значения не попали в сформированные общедоступные ConfigMap.
4. Установить релиз командой helm upgrade --install из таблицы 3.2.1.
5. Проконтролировать состояние релиза, подов, заданий и постоянных томов; дождаться завершения инициализации баз данных и выполнить проверки раздела 4.

3.2.3. Порядок запуска групп¶

Зависимости групп приведены в таблице 2.2.2. Kubernetes запускает независимые рабочие нагрузки параллельно, поэтому порядок обеспечивается проверками готовности, заданиями инициализации и повторными подключениями сервисов:

1. транзакционное хранилище — при первом запуске создаются базы данных и учётные записи сервисов, при последующих применяются изменения схем данных;
2. централизованное журналирование;
3. брокер сообщений;
4. объектное и временное хранилища;
5. прикладные сервисы;
6. вычислительный контур;
7. ретрансляция и доставка видео;
8. синхронизация источников и интеграционный обмен;
9. веб-интерфейс и шлюз прикладных интерфейсов.

До допуска пользовательского трафика должны успешно завершиться задания инициализации, хранилища — перейти в состояние готовности, а прикладные рабочие нагрузки — пройти startupProbe и readinessProbe. При отказе процесса livenessProbe инициирует перезапуск контейнера. Наличие пода в фазе Running само по себе не подтверждает готовность компонента.

3.2.4. Остановка и перезапуск¶

Штатный перезапуск отдельной рабочей нагрузки выполняется командой kubectl rollout restart deployment/<имя> -n <пространство> с последующей командой kubectl rollout status. Для StatefulSet применяют предусмотренную проектом процедуру с сохранением постоянных томов. Полная остановка выполняется только для регламентных работ: сначала прекращается входной трафик и работа прикладных и вычислительных нагрузок, затем брокера и хранилищ. Удаление Helm-релиза не является штатным способом остановки и не должно удалять постоянные данные.

3.2.5. Признаки успешного запуска¶

• открывается страница входа и выполняется вход пользователя;
• камеры отображаются с актуальными состояниями, обновляются превью;
• камеры распределены по вычислительным узлам, узлы подтверждают работоспособность;
• в журнал поступают новые события;
• отсутствует накопление очереди в брокере сообщений и в интеграционном обмене;
• helm status не сообщает об ошибке, все обязательные поды готовы, задания инициализации завершены, PersistentVolumeClaim находятся в состоянии Bound, а число повторных запусков контейнеров не растёт.

3.3. Выбор функций¶

Состав функций определяется двумя способами: включением соответствующих дочерних чартов и рабочих нагрузок в значениях Helm-релиза и параметрами включения отдельных возможностей.

Таблица 3.3.1 — Включение и отключение функций.

Группы сервисов, не входящие в целевую поставку, отключаются в файле значений; их ресурсы не должны присутствовать в результате helm template. Функциональные возможности, требующие графических ускорителей (видеоаналитика, подготовка видеофрагментов), включаются только для рабочих нагрузок с запросом GPU и правилом размещения на вычислительных нодах.

3.4. Настройка режимов работы¶

Параметры настройки задаются в файле значений Helm и создаваемых из него ConfigMap и Secret. Конфиденциальные значения хранятся только в Secret; их запрещается помещать в репозиторий документации и вывод команд диагностики. Назначение параметров по областям приведено в таблице 3.4.1; полный перечень с допустимыми значениями приводится в приложении А.

Таблица 3.4.1 — Области настройки режимов работы.

Изменение параметров выполняется обновлением файла значений и применением новой редакции Helm-релиза. Если изменение ConfigMap или Secret не вызывает автоматического обновления подов, выполняется контролируемый rollout restart только затронутой рабочей нагрузки. Перед изменением параметров, влияющих на нагрузку (частота кадров, интервалы опроса, число камер на узел), следует оценить запас производительности вычислительных узлов по подразделу 4.4 описания программы.

3.5. Настройка доступа¶

3.5.1. Подключение к СУДИР¶

Компонент подключается к СУДИР по протоколу OIDC/OAuth 2.0 в режиме авторизационного кода. Порядок подключения и состав заявки установлены методикой подключения к СУДИР (внутренний контур); требования к составу запросов и обработке ответов — документом ИИПМ-5ген-СУДИР.

1. Оформить заявку на подключение приложения к СУДИР по регламенту подключения (внутренний контур). В заявке указываются разрешённые префиксы адресов возврата при авторизации (redirect_uri) и при логауте (post_logout_redirect_uri), перечень запрашиваемых разрешений (scope), необходимость получения маркера обновления и перечень дополнительных атрибутов маркера идентификации.
2. По результатам исполнения заявки получить идентификатор приложения (client_id), секрет приложения (client_secret), зарегистрированные адреса возврата и перечень разрешений. Секрет приложения хранится как реквизит доступа и в эксплуатационную документацию не переносится.
3. Согласовать разрешённые адреса возврата: их префиксы должны соответствовать доменным именам веб-интерфейса целевой поставки. Адрес возврата, не совпадающий ни с одним зарегистрированным префиксом, приводит к отказу в аутентификации.
4. Согласовать запрашиваемые разрешения и состав сведений о пользователе. Применяемые разрешения приведены в таблице 3.5.1.
5. Задать параметры подключения в конфигурации развёртывания: идентификатор и секрет приложения, адрес возврата, адреса сервисов СУДИР по таблице 3.5.2 либо единый адрес метаданных, из которого эти адреса считываются.
6. Обеспечить сетевой доступ узлов и рабочих мест к серверам СУДИР по HTTPS (порт 443) и доверие к их сертификатам (п. 3.5.1.1).
7. Проверить вход пользователя: перенаправление на страницу входа, возврат в интерфейс по адресу возврата, обмен авторизационного кода на маркеры, получение сведений о пользователе и его групповых правах.

Таблица 3.5.1 — Разрешения СУДИР, запрашиваемые компонентом.

Состав запрашиваемых разрешений определяется проектом целевой поставки: обязательным является openid, состав остальных разрешений согласуется исходя из сведений о пользователе, отображаемых в интерфейсе и в журнале аудита.

Таблица 3.5.2 — Адреса сервисов СУДИР.

Вместо перечисления отдельных адресов в конфигурации допускается указать адрес метаданных: остальные адреса считываются из него. Среда СУДИР (тестовая или продуктивная) выбирается по контуру целевой поставки.

Запрос авторизации формируется с параметрами client_id, response_type=code, redirect_uri, scope, state (случайный идентификатор запроса для защиты от перехвата) и access_type; значение access_type=offline запрашивается, если требуется маркер обновления. Полученный авторизационный код обменивается серверной частью компонента на маркер доступа, маркер обновления и маркер идентификации; срок действия маркера доступа — 3600 секунд, продление выполняется по маркеру обновления без повторного входа пользователя.

3.5.1.1. Сетевой доступ к СУДИР¶

Серверы СУДИР должны быть доступны по HTTPS (порт 443) как с рабочих мест пользователей (перенаправление браузера на страницу входа и возврат), так и с тех узлов Платформы 4.0, которые обращаются к сервисам обмена маркерами, получения сведений о пользователе и проверки маркеров.

Таблица 3.5.3 — IP-адреса серверов СУДИР для правил межсетевого экрана.

Адреса приведены по приложению 1 методики подключения и подлежат проверке на актуальность при настройке правил фильтрации трафика.

Доступ к компоненту предоставляется при наличии у пользователя соответствующего группового права. Пользователю без такого права выполняется отказ в доступе после успешной аутентификации.

3.5.2. Учётные записи, роли и области видимости¶

1. В разделе администрирования пользователей создать или проверить учётную запись пользователя.
2. Назначить роль: «Пользователь (оператор)» или «Администратор» в соответствии с подразделом 1.3 руководства пользователя.
3. Задать область видимости — перечень объектов и камер, доступных пользователю; выборки журнала, отчёты, уведомления и статистика ограничиваются этой областью.
4. При необходимости назначить пользователя ответственным за камеры объекта для адресации уведомлений.
5. Отзыв доступа выполняется отключением учётной записи и (или) отзывом группового права в СУДИР.

3.5.3. Справочники, определяющие работу видеоаналитики¶

Два справочника ведутся администратором в интерфейсе и определяют, что и как обрабатывается по камерам.

Таблица 3.5.4 — Справочники, ведущиеся администратором.

Изменение справочника затрагивает все камеры, на которых используются соответствующие типы: после изменения проверяются разметка зон, привязка версий сценариев и результаты проверок по затронутым камерам. Промпты и языковые модели ведутся компонентом обработки мультимодальных данных (LPI-VAP-MLLM).

3.5.4. Контроль действий пользователей¶

Действия пользователей регистрируются в журнале аудита. Администратор контролирует журнал в разделе логирования действий: доступны отбор по периоду, пользователю, сервису и виду действия, а также выгрузка выборки. Записи журнала содержат имя входа, сетевой адрес, отображаемое имя, дату и время, сервис и описание действия. Порядок работы с журналом приведён в подразделе 3.7.3 руководства пользователя.

3.6. Настройка источников медиаданных и интеграций¶

3.6.1. Внешние системы видеонаблюдения и сервисы получения кадров¶

1. В разделе администрирования открыть перечень систем видеонаблюдения и добавить систему.
2. Задать параметры подключения: наименование, адрес программного интерфейса, реквизиты доступа, признак включения.
3. Задать параметры синхронизации: периодичность, размер порции при включении камер, правила именования и привязки камер к объектам, интервал опроса кадров по умолчанию.
4. Выполнить первичную синхронизацию и проконтролировать её результат по времени последней синхронизации и истории синхронизаций.
5. Проверить, что полученные камеры отображаются в дереве объектов и переходят в работоспособное состояние.

Камеры, исчезнувшие из внешней системы, помечаются признаком отсутствия и не удаляются автоматически. Реквизиты доступа после сохранения не отображаются. Порядок работы с формой приведён в подразделе 3.3.4 руководства пользователя.

3.6.2. Интеграционный обмен событиями¶

1. Задать параметры внешнего интеграционного интерфейса: адреса, реквизиты доступа, способ аутентификации, идентификатор задачи, передаваемый вместе с событием.
2. Задать условия передачи: состав категорий, требование предварительного подтверждения события оператором, состав передаваемых материалов.
3. Задать параметры очереди и повторных попыток при недоступности внешней системы.
4. Выполнить контрольную передачу и проконтролировать результат по журналу обмена.

3.6.3. Уведомления¶

1. Задать параметры почтового сервера: адрес, порт, учётные данные, параметры шифрования, адрес отправителя.
2. При использовании мессенджеров задать реквизиты подключения каналов доставки.
3. Задать роли получателей и назначить ответственных за камеры объектов.
4. Выполнить контрольную отправку и проконтролировать доставку.

Контроль результатов настройки источников, интеграций и уведомлений выполняется проверками раздела 4.

3.7. Защита конфигурации, секретов и сертификатов¶

Администратор разделяет открытые параметры и конфиденциальные данные. Открытые значения Helm допускается хранить в системе управления версиями; пароли, токены, закрытые ключи, строки подключения с реквизитами и клиентские секреты СУДИР хранятся в Kubernetes Secret либо во внешнем хранилище секретов заказчика.

Таблица 3.7.1 — Защита эксплуатационной конфигурации.

После ротации секрета определяют все использующие его рабочие нагрузки, применяют новую редакцию секрета, выполняют контролируемый перезапуск и проверяют соответствующую внешнюю связь. Старое значение отзывается только после успешной проверки нового, если политика внешней системы допускает переходный период.

4. Проверка программы¶

4.1. Способы проверки работоспособности¶

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

1. инфраструктура Kubernetes — ноды, системные сервисы, GPU, сеть и тома;
2. прикладной контур — рабочие нагрузки, хранилища, брокер и внутренние связи;
3. сквозные функции — вход пользователя, камера, видеоаналитика, событие, отчёт, уведомление и интеграционный обмен.

Переход к следующему уровню допускается после успешного завершения предыдущего.

Таблица 4.1.1 — Проверки работоспособности компонента.

Служебные программные интерфейсы контроля состояния предназначены для диагностики и доступны в пределах серверной сети. Они предоставляют перечень камер и их состояний, подтверждения работоспособности камер, исполняющего ядра и медиасерверов, журналы отказов, помех и ошибок, а также показатели приёма и декодирования видеопотоков.

Минимальная инфраструктурная проверка после установки выполняется командами:

helm status <релиз> -n <пространство>
kubectl get nodes
kubectl get pods -n <пространство> -o wide
kubectl get pvc -n <пространство>
kubectl get events -n <пространство> --sort-by=.lastTimestamp

Если под не готов, сначала просматривают kubectl describe pod, затем журналы контейнера командой kubectl logs; для контейнера после перезапуска применяют параметр --previous. Значения секретов в диагностические материалы не включают.

4.2. Контрольные примеры¶

Контрольные примеры выполняются последовательно: результат предыдущего примера является исходным состоянием для следующего.

Таблица 4.2.1 — Контрольные примеры.

Если в целевой поставке отключена соответствующая функция (подраздел 3.3), относящийся к ней контрольный пример не выполняется, о чём делается отметка в результатах проверки.

4.3. Результаты проверки¶

Проверка считается успешной, если выполнены все условия таблицы 4.3.1.

Таблица 4.3.1 — Критерии успешного результата проверки.

При отрицательном результате проверки выполняется следующий порядок действий:

1. зафиксировать проверку, время, состав выполненных действий и полученное сообщение;
2. определить границу отказа: составная часть, внешняя система, источник медиаданных или параметры настройки;
3. просмотреть журналы соответствующих составных частей и служебные интерфейсы контроля состояния;
4. проверить параметры настройки, относящиеся к отказавшей функции (подразделы 3.3–3.7), и связанные внешние системы;
5. устранить причину, повторить проверку и убедиться, что связанные проверки также выполняются успешно;
6. при повторяющемся отказе передать в службу сопровождения сведения по подразделу 6.3.

Результаты проверок фиксируются в эксплуатационной документации в порядке, принятом у заказчика: дата и время, состав выполненных проверок, результат по каждой из них, выявленные отклонения и принятые меры.

5. Дополнительные возможности¶

5.1. Резервное копирование и восстановление¶

5.1.1. Состав резервируемых данных¶

Таблица 5.1.1 — Состав резервируемых данных.

Для мастер-ноды целевой конфигурации RPO устанавливается не хуже 24 часов; конкретные RPO и RTO, глубина хранения и место размещения копий фиксируются регламентом резервного копирования заказчика.

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

Копирование хранилища метаданных и объектного хранилища выполняется согласованно: карточка события в хранилище метаданных и её изображения в объектном хранилище должны относиться к одному моменту, иначе часть событий восстановится без медиаматериалов.

5.1.2. Порядок копирования¶

1. Проверить доступность целевого хранилища копий, запас свободного места и состояние предыдущего задания резервного копирования.
2. Зафиксировать время начала, версию Helm-релиза и состояние хранилищ.
3. Выполнить согласованную копию транзакционного и аналитического хранилищ.
4. Выполнить копирование объектного хранилища из той же согласованной точки.
5. Скопировать конфигурацию развёртывания и защищённую копию секретов.
6. Проверить отсутствие ошибок, размер и контрольные суммы файлов или объектов, а также возможность прочитать каталог резервной копии.
7. Зарегистрировать результат: время начала и окончания, состав, объём, место хранения, срок хранения, версию релиза и ответственного.

Копии размещаются вне серверных узлов компонента. Глубина хранения, порядок шифрования и права доступа к копиям определяются регламентом заказчика.

5.1.3. Порядок восстановления¶

1. Прекратить входной трафик и масштабировать до нуля прикладные и вычислительные рабочие нагрузки, оставив работающими хранилища; состав и исходное число реплик зафиксировать перед изменением.
2. Восстановить хранилища метаданных из выбранной копии.
3. Восстановить разделы объектного хранилища из копии того же момента.
4. Восстановить версию Helm-чарта, открытые значения, Secret и конфигурацию постоянных томов, соответствующие выбранной копии.
5. Применить Helm-релиз и восстановить число реплик; дождаться готовности рабочих нагрузок и завершения заданий инициализации.
6. Выполнить проверки по разделу 4, обратив внимание на доступность медиаматериалов событий и состояние камер.

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

5.1.4. Автоматизация и ротация¶

Автоматическое резервное копирование выполняется Kubernetes CronJob либо внешней системой резервного копирования заказчика. Способ выбирается проектом поставки и должен обеспечивать:

• запрет параллельного запуска двух копирований одного хранилища;
• ограничение времени выполнения и повторные попытки при временном отказе;
• передачу копий за пределы узлов кластера и шифрование при хранении;
• автоматическую ротацию по сроку хранения без удаления последней успешной копии;
• уведомление об ошибке, отсутствии свежей копии и недостатке места;
• журналирование результата без вывода паролей, ключей и токенов.

Удаление копий выполняется по утверждённой политике хранения. Перед включением ротации проверяется, что маска удаления ограничена каталогом или бакетом резервных копий и не затрагивает данные рабочих хранилищ.

5.1.5. Проверка после восстановления¶

После восстановления выполняется контроль по таблице 5.1.2.

Таблица 5.1.2 — Проверки после восстановления.

5.2. Обновление версий и откат¶

До обновления оформляется план изменения по таблице 5.2.1.

Таблица 5.2.1 — План обновления.

1. Ознакомиться с составом обновления по формуляру целевой поставки: перечень изменяемых составных частей, изменения схем данных, изменения параметров настройки.
2. Проверить helm history, состояние узлов, подов и постоянных томов; убедиться в наличии ресурсов для одновременной работы старых и новых реплик во время последовательного обновления.
3. Выполнить резервное копирование по подразделу 5.1.
4. Подготовить новую версию чарта и значений, затем выполнить helm lint и helm template и проверить различия сформированных ресурсов.
5. Выполнить обновление командой helm upgrade с параметрами релиза, чарта, пространства имён и файла значений, а также ключами --atomic --wait; затем дождаться готовности рабочих нагрузок.
6. Проверить результат helm status, размещение подов, события Kubernetes, журналы заданий изменения схем данных и доступность постоянных томов.
7. Выполнить проверки по разделу 4.

Если новая редакция чарта и состояние данных совместимы с предыдущей версией, откат выполняется командой helm rollback с именем релиза, номером предыдущей редакции, пространством имён и ключом --wait. Если обновление необратимо изменило схему данных, одного отката Helm недостаточно: восстанавливают хранилища и конфигурацию из согласованной копии по подразделу 5.1. Предыдущие версии чарта и образов не удаляются до подтверждения работоспособности новой редакции.

Решение об откате принимается по схеме:

Схема 5.1 — Выбор способа отката обновления.

5.3. Управление ёмкостью и очистка данных¶

Таблица 5.3.1 — Управление ёмкостью хранилищ.

Порядок действий при приближении к пределу ёмкости:

1. определить группу данных, занимающую наибольший объём;
2. проверить, выполняется ли очистка по установленным правилам, и при необходимости изменить их параметры;
3. сократить глубину хранения наименее востребованных данных (архивные материалы, журналы, отклонённые события);
4. при устойчивом росте объёма увеличить ёмкость хранилища в соответствии с расчётом по подразделу 4.4 описания программы.

Расширение постоянного тома выполняется только если используемый StorageClass допускает увеличение. После изменения размера PersistentVolumeClaim контролируют состояние PVC, события Kubernetes и новый размер файловой системы внутри пода. Уменьшение существующего PVC не выполняют: для него создают новый том и переносят данные по процедуре хранилища.

Уменьшение глубины хранения событий и медиаматериалов согласовывается с заказчиком: оно ограничивает доступную пользователям историю и глубину отчётности.

5.4. Диагностические средства и журналы¶

Таблица 5.4.1 — Диагностические средства.

Уровень журналирования задаётся параметрами настройки соответствующих составных частей. Повышенный уровень применяется временно, на период диагностики: он увеличивает объём журналов и нагрузку на дисковую подсистему. После устранения неисправности уровень возвращается к штатному.

Рекомендуемый порядок диагностики:

1. определить границу отказа по разделу 4: интерфейс, прикладной сервис, вычислительный контур, хранилище, внешняя система;
2. проверить состояние Helm-релиза, рабочих нагрузок, подов, постоянных томов и результаты проверок готовности;
3. проверить события пространства имён и просмотреть журналы соответствующих составных частей за интервал возникновения отказа;
4. проверить служебные интерфейсы контроля состояния и отставание групп потребителей брокера;
5. проверить параметры настройки, относящиеся к отказавшей функции;
6. при необходимости передать в службу сопровождения сведения по подразделу 6.3.

Для обращения в службу сопровождения формируется диагностический пакет по приложению Ж. Он охватывает только интервал инцидента и затронутые рабочие нагрузки. Перед передачей из файлов удаляются значения Secret, маркеры доступа, пароли, строки подключения, персональные данные и кадры, не требуемые для разбора. Полная выгрузка конфигурации пространства имён и команда kubectl cluster-info dump без фильтрации не применяются, поскольку могут раскрыть конфиденциальные сведения.

5.5. Масштабирование вычислительного контура¶

Производительность обработки масштабируется числом вычислительных нод Kubernetes. Порядок добавления ноды:

1. подготовить узел по подразделу 3.1: системное программное обеспечение, драйверы графических ускорителей, тома, разделяемая память, сетевой доступ;
2. включить ноду в кластер, назначить метки и tolerations целевой конфигурации; проверить состояние Ready и доступность ресурса nvidia.com/gpu;
3. изменить число реплик или параметры размещения вычислительных рабочих нагрузок в Helm-конфигурации и применить новую редакцию релиза;
4. убедиться, что поды размещены на новой ноде, нода подтверждает работоспособность и отображается в интерфейсе распределения нагрузки;
5. дождаться перераспределения камер либо инициировать его; при необходимости изменить весовые коэффициенты узлов;
6. проверить показатели приёма и декодирования и поступление событий по перераспределённым камерам.

Перед выводом ноды проверяют достаточность оставшихся ресурсов, переводят камеры на другие ноды и запрещают новое планирование командой kubectl cordon. После перераспределения камер и рабочих нагрузок выполняют kubectl drain с параметрами, согласованными с типами томов и PodDisruptionBudget. Ноду удаляют из кластера только после подтверждения отсутствия рабочих нагрузок компонента.

Расчёт требуемого числа узлов выполняется по удельным величинам подраздела 4.4 описания программы: производительность одного узла — не менее 45 000 кадров в час, что соответствует примерно 1500 камерам при опросе раз в две минуты. При изменении интервала опроса, разрешения кадров или состава сценариев расчёт выполняется заново.

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

6. Сообщения системному программисту¶

Сообщения выводятся в журналы составных частей, в ответы программных интерфейсов и в веб-интерфейс. В настоящем разделе приведены типовые сообщения с указанием причины и порядка действий; тексты приведены по смыслу, поскольку точная формулировка зависит от версии составной части. Сообщения, адресованные пользователю, приведены в разделе 4 руководства пользователя.

6.1. Сообщения при настройке¶

Таблица 6.1.1 — Сообщения при настройке.

6.2. Сообщения при проверке¶

Таблица 6.2.1 — Сообщения при проверке.

6.3. Сообщения при выполнении программы¶

Таблица 6.3.1 — Сообщения при выполнении программы.

При обращении в службу сопровождения передаются: дата и время, наименование составной части, текст сообщения из журнала, состав выполнявшихся действий, идентификаторы камеры и события (при наличии), а также сведения о конфигурации: версия поставки, состав узлов, изменения параметров настройки за последнее время.

6.4. Диагностические коды¶

Таблица 6.4.1 — Диагностические коды и признаки состояний.

Перечень кодов ответов конкретных программных интерфейсов приводится в описании программных интерфейсов целевой поставки. Соответствие признаков состояний наименованиям в интерфейсе приведено в руководстве пользователя.

Приложения¶

Приложение А (обязательное). Параметры настройки¶

Параметры сгруппированы по областям подраздела 3.4. Значения целевой поставки фиксируются в конфигурации развёртывания и в формуляре; в таблице приведены назначение, характер значения и рекомендации по выбору.

Таблица А.1 — Параметры настройки компонента.

Изменение параметра применяется новой редакцией Helm-релиза. Если шаблон чарта не связывает изменение ConfigMap или Secret с шаблоном пода, соответствующая рабочая нагрузка перезапускается контролируемо. Параметры, влияющие на нагрузку, изменяются с последующим контролем показателей по разделу 4.

Для целевой поставки дополнительно составляется карта применения настроек по форме таблицы А.2. Она связывает пользовательское значение с ресурсом Kubernetes и позволяет определить, какие поды должны получить новую конфигурацию.

Таблица А.2 — Карта применения параметров целевой поставки.

Приложение Б (рекомендуемое). Регламентные операции обслуживания¶

Таблица Б.1 — Регламентные операции обслуживания.

Приложение В (справочное). Контрольные проверки после развёртывания¶

Таблица В.1 — Чек-лист проверок после развёртывания.

Приложение Г (обязательное при подготовке целевой поставки). Уточняемые сведения¶

Таблица Г.1 — Сведения, уточняемые для целевой поставки.

Приложение Д (справочное). Исходные тексты схем Mermaid¶

Приложение содержит исходный Mermaid-код графических схем документа. Диаграммы остаются в соответствующих разделах, а настоящее приложение предназначено для просмотра, копирования и проверки кода схем в Mermaid-редакторе, а также для случаев, когда графическое представление недоступно.

Исходные тексты¶

CORE-AG-MER-001. Схема 2.1 — Связи между составными частями компонента¶

Расположение схемы: 2.2. Связи между составными частями.

flowchart LR
    USER["Рабочее место"] --> GW["Веб-интерфейс и шлюз"]
    GW --> ACC["Доступ и аудит"]
    GW --> CFG["Объекты, камеры,<br/>зоны и справочники"]
    GW --> EVT["События и решения"]
    GW --> STAT["Статистика и отчёты"]
    CFG --> BUS["Брокер сообщений"]
    SYNC["Синхронизация источников"] --> BUS
    BUS --> LB["Распределение нагрузки"]
    LB --> NRI["Исполняющее ядро<br/>видеоаналитики"]
    MED["Приём и ретрансляция<br/>медиаданных"] --> NRI
    MED --> GW
    NRI --> BUS
    BUS --> EVT
    EVT --> VID["Подготовка видеоматериалов"]
    VID --> EVT
    EVT --> NOTIF["Уведомления"]
    EVT --> INTG["Интеграционный обмен"]
    EVT --> STAT
    ACC --> DATA[("Хранилища:<br/>транзакционное,<br/>аналитическое, объектное")]
    CFG --> DATA
    EVT --> DATA
    STAT --> DATA
    NRI --> LOCAL[("Локальные артефакты<br/>и разделяемая память узла")]

CORE-AG-MER-002. Схема 3.1 — Размещение рабочих нагрузок Центрального модуля в Kubernetes¶

Расположение схемы: 3.1. Настройка на состав технических средств.

flowchart TB
    INGRESS["Ingress / LoadBalancer<br/>HTTPS, WebSocket, медиапорты"]

    subgraph K8S["Кластер Kubernetes"]
        direction TB
        subgraph MASTER["Мастер-нода"]
            APP["Прикладные рабочие нагрузки<br/>и веб-шлюз"]
            DATA["StatefulSet и сервисы<br/>хранилищ и брокера"]
            PVC[("Постоянные тома<br/>SSD и HDD")]
            APP --> DATA --> PVC
        end
        subgraph COMPUTE["Вычислительные ноды"]
            MEDIA["Медиасерверы"]
            NRI["Исполняющее ядро<br/>видеоаналитики"]
            GPU["Ресурс nvidia.com/gpu"]
            MEDIA --> NRI --> GPU
        end
    end

    LLM["LLM-нода<br/>компонента LPI-VAP-MLLM"]
    REGISTRY["Реестр<br/>контейнерных образов"]
    INGRESS --> APP
    APP <--> NRI
    APP <--> LLM
    REGISTRY --> MASTER
    REGISTRY --> COMPUTE

CORE-AG-MER-003. Схема 5.1 — Выбор способа отката обновления¶

Расположение схемы: 5.2. Обновление версий и откат.

flowchart TD
    START["Применена новая редакция"] --> MIG{"Миграции данных<br/>завершены успешно?"}
    MIG -- Нет --> RESTORE["Остановить изменение;<br/>восстановить данные и конфигурацию<br/>из согласованной копии"]
    MIG -- Да --> CHECK{"Инфраструктурные и сквозные<br/>проверки успешны?"}
    CHECK -- Да --> ACCEPT["Зафиксировать приёмку<br/>новой редакции"]
    CHECK -- Нет --> REV{"Изменения данных<br/>обратимы?"}
    REV -- Да --> HELM["Выполнить helm rollback<br/>и повторить проверки"]
    REV -- Нет --> RESTORE

Приложение Е (рекомендуемое). Протокол установки и приёмочной проверки¶

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

Таблица Е.1 — Форма протокола установки и приёмочной проверки.

Приложение Ж (рекомендуемое). Состав диагностического пакета¶

Таблица Ж.1 — Состав диагностического пакета.

Лист регистрации изменений¶

Таблица — Лист регистрации изменений

Рабочая редакция 0.1 отражает первоначальное заполнение документа в формате docs-as-code и не является зарегистрированным изменением утверждённого оригинала. При выпуске утверждаемой редакции необходимо:

1. присвоить обозначение документа и формальный номер изменения;
2. сформировать DOCX или PDF и указать фактическое число и номера листов;
3. указать номер сопроводительного документа, если он оформляется;
4. получить подписи ответственного исполнителя, проверяющего и нормоконтролёра в порядке, принятом для проекта;
5. в последующих строках регистрировать только изменения утверждённого оригинала, а не отдельные технические коммиты Git.

История подготовки рабочей редакции сохраняется в Git. Она используется для трассировки исходного текста, но не заменяет оформленный лист регистрации изменений.