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

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

Аннотация¶

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

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

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

Администратор должен владеть навыками администрирования Linux и Kubernetes, уметь работать с Helm и kubectl, понимать назначение PostgreSQL, S3-совместимого объектного хранилища, Kafka, Redis, графических ускорителей и централизованного журналирования. Знание разработки моделей машинного обучения для выполнения штатных административных операций не требуется.

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

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

LPI-VAP-MM обеспечивает управляемый жизненный цикл моделей видеоаналитики: от регистрации модели и загрузки версии до автоматической проверки, публикации, применения в сценариях и вывода из эксплуатации. Компонент также предоставляет средства подготовки версионируемых проверочных данных и выполнения моделей на этих данных.

Таблица 1.1.1 — Группы задач администратора LPI-VAP-MM.

LPI-VAP-MM не выполняет непосредственную аутентификацию через СУДИР, управление камерами, исполнение моделей на рабочих видеопотоках и регистрацию событий. Единую точку входа и пользовательский контекст предоставляет LPI-VAP-CORE; разработку сценариев и замену версий моделей в них обеспечивает LPI-VAP-RS.

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

Компонент размещается на мастер-ноде и вычислительных нодах общего кластера Kubernetes Платформы 4.0. Отдельные физические серверы для LPI-VAP-MM не требуются, однако компоненту должны быть гарантированно выделены ресурсы, установленные проектом поставки.

Таблица 1.2.1 — Типы технических средств.

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

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

Таблица 1.3.1 — Уровни программных средств.

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

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

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

Таблица 2.1.1 — Составные части LPI-VAP-MM.

Обозначения svr-*, inf-* и nr-sbx-* в таблице являются логическими именами составных частей, согласованными с описанием программы. В текущем Helm-чарте ресурсы трёх хранилищ имеют имена wf-*; соответствие приведено в таблице 3.2.2. При выполнении команд администратор использует имена из отрендеренного манифеста принятой версии поставки.

Веб-интерфейс, API-шлюз, средства единого входа, PostgreSQL, MinIO, Kafka и Redis являются общеплатформенными или инфраструктурными средствами. Они нужны для работы LPI-VAP-MM, но не включаются в состав его прикладных сервисов.

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

Схема 2.1 — Основные связи LPI-VAP-MM.

Для целевой поставки по каждой связи в приложении В фиксируются имя Kubernetes Service, пространство имён, протокол, направление соединения, способ проверки готовности, владелец реквизитов и признаки нарушения связи.

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

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

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

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

Подготовка выполняется в составе общего кластера Kubernetes Платформы 4.0. Для прикладных хранилищ LPI-VAP-MM отдельные GPU не требуются; графические ускорители предоставляются конвертерам и исполнителям проверочных запусков. Размещение служебных подов на управляющих узлах Kubernetes допускается только тогда, когда это прямо предусмотрено схемой кластера и его политиками.

До развёртывания администратор выполняет следующие действия:

1. Проверяет доступ к API Kubernetes и состояние всех предусмотренных проектом узлов. Узлы должны иметь состояние Ready, а системные поды DNS и сетевого плагина — быть готовы.
2. Сверяет проектные метки, affinity и tolerations. Сервисы wf-models-registry, wf-asset-storage и wf-launch-storage размещаются на узлах прикладного контура; конвертеры и исполнители проверок — на вычислительных узлах с ресурсом nvidia.com/gpu.
3. Проверяет доступность StorageClass и постоянных томов инфраструктурных сервисов. Метаданные хранятся в PostgreSQL, пакеты моделей и материалы проверок — в S3-совместимом объектном хранилище. Удаление Helm-релиза не должно приводить к удалению этих данных.
4. Проверяет сетевую доступность PostgreSQL, MinIO, Kafka, Redis, сервисов LPI-VAP-RS и вычислительного контура из пространства имён поставки.
5. Проверяет синхронизацию времени на всех узлах. Расхождение времени нарушает сопоставление состояний асинхронных задач, журналов и сообщений Kafka.
6. Создаёт imagePullSecret для доверенного реестра образов и убеждается, что сервисные учётные записи могут получить образы, указанные в формуляре.
7. Задаёт requests и limits по результатам нагрузочного расчёта. Значения из демонстрационного values.yaml не используются как эксплуатационные без проверки на целевой нагрузке.
8. Проверяет запас ёмкости PostgreSQL и S3. Перед первичной загрузкой моделей и ассетов рекомендуется иметь не менее 20 % свободного пространства сверх расчётного объёма поставки.

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

kubectl cluster-info
kubectl get nodes -o wide
kubectl get nodes --show-labels
kubectl get storageclass
kubectl get pods -A
helm version

Для вычислительной ноды дополнительно проверяется наличие ресурса GPU:

kubectl describe node <имя-вычислительной-ноды>

В секциях Capacity и Allocatable должен присутствовать ресурс nvidia.com/gpu в количестве, предусмотренном проектом. Проверка nvidia-smi в операционной системе не заменяет проверку предоставления GPU в Kubernetes.

Схема 3.1 — Размещение основных рабочих нагрузок LPI-VAP-MM.

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

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

Таблица 3.1.1 — Контроль готовности инфраструктуры LPI-VAP-MM.

Результаты заносятся в протокол приложения Д. В протокол не включаются пароли, токены, закрытые ключи и полное содержимое Kubernetes Secret.

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

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

• <релиз> — имя Helm-релиза Платформы 4.0;
• <пространство> — пространство имён Kubernetes;
• <чарт> — каталог или пакет родительского чарта box5;
• <значения> — проверенный файл открытых параметров целевой поставки;
• <секреты> — защищённый YAML-файл значений для формирования Kubernetes Secret; файл не включается в дистрибутив с открытыми параметрами и не прикладывается к протоколу.

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

Команды с --set-file не выполняются с включённой трассировкой оболочки. Вывод helm template, kubectl get secret -o yaml и kubectl describe secret не добавляется в заявку сопровождения или общедоступный журнал.

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

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

В составе дочернего чарта workflow проверяются как минимум следующие ресурсы:

Таблица 3.2.2 — Соответствие логических и Kubernetes-имён.

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

1. Версии Chart.yaml и Chart.lock совпадают с формуляром, а digest файла блокировки не изменён после приёмки комплекта.
2. В values.yaml заданы согласованные адреса PostgreSQL, MinIO и Kafka, внутренние URL зависимых сервисов, имена бакетов, топиков и групп.
3. Секретные параметры PostgreSQL, MinIO, Kafka и реестра образов исключены из открытых ConfigMap и передаются через Kubernetes Secret или подключённое средство управления секретами.
4. Теги образов заменены неизменяемыми digest либо сопоставлены с digest в ведомости поставки.
5. Ресурсы, размещение, Service и сетевые политики соответствуют схеме кластера. Прямой внешний доступ к сервисам wf-* не открывается, если все обращения проходят через общий API-шлюз.
6. Значения очистки объектных данных оставлены отключёнными до утверждения сроков хранения и успешной проверки резервного копирования.

В типовом чарте probes для wf-models-registry, wf-asset-storage и wf-launch-storage параметризованы, но по умолчанию отключены. Их нельзя включать формально только ради состояния Ready: сначала на образах версии поставки проверяются фактические маршруты и семантика /healthz и /ready.

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

1. Создайте либо выберите пространство имён и проверьте квоты:

kubectl get namespace <пространство>
kubectl get resourcequota,limitrange -n <пространство>

1. Подготовьте imagePullSecret, открытый файл значений и защищённый файл секретов. Убедитесь, что последний доступен только исполнителю установки.
2. Выполните helm dependency build, helm lint и helm template командами таблицы 3.2.1. Проверьте отсутствие паролей и ключей в создаваемых ConfigMap, корректность имён Service и отсутствие незапланированного внешнего NodePort.
3. Установите релиз командой helm upgrade --install из таблицы 3.2.1.
4. Проверьте состояние релиза, Deployment и событий пространства имён. В составе workflow должны появиться wf-models-registry, wf-asset-storage, wf-launch-storage и wf-scenario-storage.
5. Убедитесь, что init-контейнеры подготовки баз данных завершились с кодом 0, а основные контейнеры не находятся в CrashLoopBackOff или ImagePullBackOff.
6. Выполните контроль по подразделу 3.2.5 и сквозные примеры раздела 4.

Если --atomic вернул ошибку и удалил неуспешную редакцию, сначала сохраните события и журналы доступных подов, устраните причину, затем повторите установку. Не отключайте ожидание готовности, чтобы скрыть ошибку инициализации.

3.2.3. Порядок запуска составных частей¶

Kubernetes может запускать независимые Deployment параллельно, поэтому порядок обеспечивается init-контейнерами, проверками готовности и повторными подключениями, а контролируется по следующим группам:

1. PostgreSQL, MinIO, Kafka и Redis доступны по сетевым именам, указанным в конфигурации.
2. Init-контейнеры создают или проверяют базы models-registry, asset-storage и launch-storage; изменения схем завершаются до допуска прикладных запросов.
3. Запускаются wf-models-registry, wf-asset-storage и wf-launch-storage; создаются или проверяются их S3-бакеты.
4. Запускаются inf-flows-manager, конвертеры и контур sandbox. Их точные Kubernetes-имена и чарты фиксируются в приложении В для целевой поставки.
5. Настраиваются маршруты общего API-шлюза и веб-интерфейса.
6. Проверяются потребители Kafka и прохождение состояний модели и запуска через WebSocket-канал интерфейса.

Отсутствие готового вычислительного контура не препятствует открытию каталога, но делает невозможными автоматическую проверку версии и пользовательский проверочный запуск. Поэтому доступность страницы «Модели» не является достаточным признаком успешного запуска LPI-VAP-MM.

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

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

Перезапуск прикладных сервисов выполняется средствами Kubernetes:

kubectl rollout restart deployment/wf-models-registry -n <пространство>
kubectl rollout restart deployment/wf-asset-storage -n <пространство>
kubectl rollout restart deployment/wf-launch-storage -n <пространство>
kubectl rollout status deployment/wf-models-registry -n <пространство>
kubectl rollout status deployment/wf-asset-storage -n <пространство>
kubectl rollout status deployment/wf-launch-storage -n <пространство>

Если изменена Helm-конфигурация, выполняйте helm upgrade, а не ручное редактирование Deployment. Запуск процесса внутри контейнера и удаление Helm-релиза не являются штатными способами перезапуска. Перед остановкой PostgreSQL, MinIO или Kafka останавливаются зависящие от них прикладные и вычислительные нагрузки.

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

Установка считается технически успешной при одновременном выполнении следующих условий:

• helm status показывает установленную редакцию без неуспешных hook и Job;
• Deployment wf-models-registry, wf-asset-storage и wf-launch-storage имеют требуемое число доступных реплик;
• init-контейнеры баз данных завершены, число перезапусков основных контейнеров не растёт;
• внутренние Service имеют EndpointSlice с адресами готовых подов;
• из подов открывается /api/docs/ каждого сервиса на порту 3000; эта проверка подтверждает доступность HTTP-процесса, но не заменяет функциональный пример;
• сервисы подключились к PostgreSQL, MinIO и Kafka без повторяющихся ошибок авторизации, TLS или разрешения имён;
• в интерфейсе через общий шлюз открываются разделы «Модели», «Ассеты» и «Запуски» в соответствии с полномочиями;
• эталонная опубликованная версия модели проходит автоматическую проверку, а проверочный запуск на опубликованной версии ассета завершается с доступным результатом и журналом.

Основные команды контроля:

helm status <релиз> -n <пространство>
kubectl get deployment,pod,service,endpointslice -n <пространство>
kubectl get events -n <пространство> --sort-by=.lastTimestamp
kubectl logs deployment/wf-models-registry -n <пространство> --tail=200
kubectl logs deployment/wf-asset-storage -n <пространство> --tail=200
kubectl logs deployment/wf-launch-storage -n <пространство> --tail=200

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

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

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

Таблица 3.3.1 — Выбор функций LPI-VAP-MM.

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

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

3.4.1. Загрузка и обработка пакетов моделей¶

Фиксируются максимальный размер пакета, допустимые форматы, тайм-ауты загрузки, предел распакованного объёма и правила проверки обязательных файлов. Лимиты задаются согласованно на Ingress, API и рабочем томе: увеличение только одного из них не обеспечивает приём большего пакета. Проверка включает допустимый эталонный архив, повреждённый ZIP и архив с превышением лимита.

3.4.2. Конвертация и автоматическая проверка¶

Фиксируются доступные конвертеры, профили CUDA/TensorRT, число параллельных операций, лимиты CPU, памяти и GPU, время ожидания и повтор задачи. Тип модели должен однозначно направляться в совместимый конвертер. Параллелизм повышается только после контроля памяти GPU, времени очереди и влияния на рабочую видеоаналитику Центрального модуля.

3.4.3. Проверочные данные и запуски¶

Фиксируются ограничения медиафайлов, число параллельных запусков, параметры очереди Celery, сроки хранения кадров и журналов, правила остановки и повтора. Фото- и видеоассеты проверяются раздельно. Повтор отказавшей задачи не должен создаваться, пока не установлено, завершилась ли исходная задача и не остались ли у неё активные исполнители.

3.4.4. Публикация и интеграционный обмен¶

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

3.4.5. Журналирование и мониторинг¶

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

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

Настройка подключения Платформы 4.0 к СУДИР относится к LPI-VAP-CORE. Для LPI-VAP-MM администратор проверяет получение доверенного пользовательского контекста через общий шлюз и соответствие полномочий операциям просмотра, загрузки, публикации, архивирования, удаления и запуска проверки. Прямое подключение MM к СУДИР и отдельный OIDC-клиент не настраиваются.

Таблица 3.5.1 — Контроль настройки доступа LPI-VAP-MM.

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

Открытые параметры размещаются в конфигурации Helm и ConfigMap, секретные — в Kubernetes Secret либо подключённом средстве управления секретами. В целевой поставке определяются владельцы значений, минимальные права сервисных учётных записей, период ротации и пороги срока действия сертификатов.

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

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

Экспорт Secret, полный вывод переменных окружения и сохранение отрендерированного Secret в открытом протоколе запрещены. Сертификаты MinIO, Kafka, Ingress и реестра образов проверяются до истечения срока, чтобы их замена не совпала с обновлением прикладных образов.

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

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

Проверка строится по уровням: состояние Kubernetes; доступность хранилищ и очередей; готовность прикладных API; прохождение асинхронной задачи; сквозной пользовательский сценарий. Состояние Running само по себе не подтверждает работоспособность компонента.

Таблица 4.1.1 — Уровни проверки работоспособности LPI-VAP-MM.

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

Таблица 4.2.1 — Набор контрольных примеров.

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

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

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

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

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

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

Резервная копия LPI-VAP-MM должна позволять восстановить каталог моделей, проверочные данные и результаты запусков в согласованное состояние. Имена баз и бакетов из таблицы 5.1.1 являются типовыми; перед настройкой задания они сверяются с отрендерированным Helm-манифестом целевой поставки.

Таблица 5.1.1 — Состав резервной копии LPI-VAP-MM.

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

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

5.1.2. Подготовка и выполнение копирования¶

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

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

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

Копирование только PVC без предусмотренного приложением механизма quiesce или snapshot не считается согласованной резервной копией. Аналогично, отдельная копия PostgreSQL без бакетов S3 не обеспечивает восстановление загруженных пакетов моделей и проверочных материалов.

5.1.3. Восстановление¶

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

1. Выберите одну согласованную точку восстановления и проверьте наличие всех частей копии и поддерживаемой версии образов.
2. Ограничьте входной трафик к LPI-VAP-MM. Зафиксируйте исходное число реплик, затем остановите прикладные сервисы и исполнителей, способных записывать в восстанавливаемые хранилища.
3. Восстановите базы models-registry, asset-storage и launch-storage, а затем бакеты S3 из той же согласованной точки.
4. Восстановите конфигурацию и секреты, примените соответствующий Helm-релиз и дождитесь завершения инициализации баз и готовности рабочих нагрузок.
5. Сверьте незавершённые на момент копии конвертации и запуски. Зависшие операции не переводятся в успешное состояние вручную; их останавливают или повторяют штатной операцией после анализа журналов.
6. Выполните проверки таблицы 5.1.2 и контрольные примеры раздела 4. Входной трафик возвращается только после положительного результата.

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

Контрольное восстановление проводится периодически с частотой, установленной регламентом, и после изменения способа копирования. Успешное завершение задания копирования без контрольного восстановления не подтверждает пригодность копии.

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

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

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

Перед включением автоматической ротации маска удаления проверяется на тестовом наборе. Она должна быть ограничена каталогом или бакетом резервных копий и не может совпадать с префиксами рабочих данных LPI-VAP-MM.

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

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

Таблица 5.2.1 — План обновления LPI-VAP-MM.

Порядок обновления:

1. Сопоставьте формуляр исходной и целевой поставок. Проверьте изменение схем, параметров и контрактов с LPI-VAP-CORE, LPI-VAP-RS и вычислительным контуром.
2. Проверьте helm history, состояние подов, PVC, хранилищ и очередей. До начала работ устраните исходные ошибки и нехватку ресурсов.
3. Дождитесь завершения активных загрузок, конвертаций и запусков либо остановите их штатным способом. Выполните резервное копирование по 5.1.
4. Подготовьте новый чарт и значения. Выполните helm lint и helm template, сравните Deployment, Service, Secret, задания и параметры миграций с текущей редакцией. Отрендерированный Secret не сохраняйте в открытом протоколе.
5. Выполните helm upgrade с ключами --atomic --wait и установленным для поставки тайм-аутом. Не запускайте миграции базы вручную параллельно с init-контейнерами чарта.
6. Проверьте helm status, состояние миграций, доступность трёх сервисов wf-*, отставание групп Kafka и журналы конвертеров.
7. Выполните контрольные примеры раздела 4 и зарегистрируйте принятую редакцию.

Способ отката зависит от изменения данных:

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

helm rollback возвращает Kubernetes-ресурсы предыдущей редакции, но не отменяет уже выполненные необратимые изменения PostgreSQL и S3. В таком случае восстанавливается весь согласованный набор данных по 5.1. Предыдущие чарты и образы не удаляются до подтверждения новой версии и окончания установленного периода наблюдения.

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

Таблица 5.3.1 — Объекты контроля ёмкости LPI-VAP-MM.

Встроенная очистка S3 управляется параметром ENABLE_CLEARING_MINIO и в типовой конфигурации сервисов отключена. До её включения администратор обязан:

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

Очистка по превышению предельного размера может удалить старые объекты раньше TTL. Поэтому MINIO_MAX_BUCKET_SIZE_GB задаётся по расчётному объёму и политике хранения, а не оставляется равным демонстрационному значению чарта.

При достижении порога заполнения сначала определяется источник роста и проверяется работа штатной очистки. Затем, в зависимости от причины, увеличивается том или квота S3, корректируется срок хранения либо временно ограничиваются новые загрузки и запуски. Расширение PVC выполняется только для StorageClass, допускающего увеличение; существующий PVC не уменьшается.

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

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

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

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

1. Зафиксировать время, операцию, идентификаторы сущностей и отображаемое состояние. Не повторять массово операцию до определения, была ли она фактически принята.
2. Определить границу отказа: API и хранилище метаданных, S3, брокер, менеджер потоков, конвертер либо исполнитель sandbox.
3. Проверить Helm-релиз, готовность подов, число перезапусков, init-контейнеры, EndpointSlice, PVC и события пространства имён.
4. Найти записи за интервал инцидента по идентификатору модели, версии, ассета или запуска и сопоставить время между связанными сервисами.
5. Проверить доступность PostgreSQL, MinIO, Kafka и Redis и наличие ресурса GPU, не выводя реквизиты подключения.
6. После устранения причины повторить затронутый контрольный пример раздела 4 и проверить связанные функции.

Минимальный безопасный набор команд:

helm status <релиз> -n <пространство>
helm history <релиз> -n <пространство>
kubectl get deploy,pod,svc,endpointslice,pvc -n <пространство> -o wide
kubectl get events -n <пространство> --sort-by=.lastTimestamp
kubectl logs <под> -n <пространство> -c <контейнер> --since=30m
kubectl logs <под> -n <пространство> -c <контейнер> --previous --tail=200

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

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

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

Масштабируются две разные группы нагрузок:

• прикладные API wf-models-registry, wf-asset-storage и wf-launch-storage — по числу запросов, длительности ответа и соединениям с PostgreSQL;
• конвертеры и исполнители проверочных запусков — по длине очереди, времени ожидания, числу задач и доступным GPU.

Простое увеличение реплик API не ускоряет GPU-задачи. Аналогично, добавление исполнителей не устраняет ограничение пропускной способности PostgreSQL, MinIO, Kafka или сети.

Перед горизонтальным масштабированием администратор проверяет:

1. допускает ли сервис несколько реплик и не выполняет ли каждая реплика одну и ту же периодическую очистку или миграцию;
2. поддерживают ли общий каталог и блокировки безопасное параллельное выполнение конвертаций;
3. имеются ли свободные GPU, видеопамять, CPU, RAM и ephemeral storage;
4. соответствуют ли nodeSelector, affinity, tolerations и запрос nvidia.com/gpu целевым вычислительным узлам;
5. выдерживают ли PostgreSQL, MinIO, Kafka и Redis возросшее число подключений и поток данных;
6. не вытеснит ли проверочная нагрузка рабочую видеоаналитику LPI-VAP-CORE.

Изменение выполняется через файл значений Helm с последующим helm upgrade. Ручное масштабирование kubectl scale допустимо только как временная мера при инциденте: желаемое число реплик затем переносится в Helm-конфигурацию, иначе следующее обновление его отменит.

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

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

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

Сообщения LPI-VAP-MM выводятся в веб-интерфейсе, ответах прикладных интерфейсов, событиях Kubernetes и журналах составных частей. В таблицах ниже приведены устойчивые признаки сообщений, их смысл и безопасный порядок действий. Точная формулировка может различаться между версиями образов, поэтому при диагностике вместе с сообщением фиксируются время, имя составной части, версия образа и идентификаторы модели, версии, ассета, запуска или фоновой задачи. Пользовательские сообщения и действия с объектами приведены в руководстве пользователя.

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

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

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

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

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

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

При обращении в службу сопровождения передаются время и часовой пояс, наименование составной части, версия релиза и образа, наблюдаемый признак, действия перед отказом, идентификаторы сущностей и задачи, а также отфильтрованные события Kubernetes и журналы за соответствующий интервал. Пароли, токены, содержимое Secret, строки подключения, подписанные S3-адреса и пользовательские медиафайлы без отдельного согласования не передаются.

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

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

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

Приложения¶

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

Значения целевой поставки фиксируются в файле значений Helm, защищённом хранилище реквизитов и формуляре. Имена путей в values.yaml могут различаться между редакциями чарта; перед изменением используется схема и результат helm template принятой версии, а не имя из другой поставки.

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

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

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

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

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

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

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

MM-AG-MER-001. Схема 2.1 — Основные связи LPI-VAP-MM¶

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

flowchart TB
    CORE["LPI-VAP-CORE<br/>единый вход и пользовательский контекст"]
    UI["Веб-интерфейс и API-шлюз"]
    subgraph MM["LPI-VAP-MM"]
        MR["svr-models-registry"]
        AS["svr-asset-storage"]
        LS["svr-launch-storage"]
        FM["inf-flows-manager"]
        CONV["Конвертеры<br/>основного контура"]
        SB["nr-sbx-backend"]
        CEL["nr-sbx-celery"]
        SCONV["Конвертеры<br/>контура проверки"]
    end
    DB[("PostgreSQL")]
    S3[("MinIO")]
    K["Kafka Платформы 4.0"]
    KS["Kafka и Redis<br/>контура проверки"]
    RS["LPI-VAP-RS"]
    INF["Исполняющее ядро<br/>видеоаналитики"]
    CORE --> UI
    UI --> MR
    UI --> AS
    UI --> LS
    UI --> FM
    MR --> DB
    AS --> DB
    LS --> DB
    MR --> S3
    AS --> S3
    LS --> S3
    MR <--> K
    K --> FM
    FM --> CONV
    FM --> MR
    FM <--> RS
    LS --> SB
    SB <--> KS
    SB --> CEL
    CEL --> SCONV
    CEL --> S3
    K --> INF
    INF --> MR

MM-AG-MER-002. Схема 3.1 — Размещение основных рабочих нагрузок LPI-VAP-MM¶

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

flowchart LR
    GW["Общий API-шлюз<br/>Платформы 4.0"]

    subgraph K8S["Кластер Kubernetes"]
        subgraph APP["Узлы прикладного контура"]
            MR["wf-models-registry"]
            AS["wf-asset-storage"]
            LS["wf-launch-storage"]
        end
        subgraph GPU["Вычислительные узлы"]
            FM["inf-flows-manager"]
            CV["Конвертеры моделей"]
            SB["Исполнители проверочных запусков"]
            DEV["nvidia.com/gpu"]
            FM --> CV --> DEV
            SB --> DEV
        end
    end

    PG[("PostgreSQL")]
    S3[("MinIO / S3")]
    K[("Kafka")]
    R[("Redis контура проверок")]

    GW --> MR
    GW --> AS
    GW --> LS
    MR --> PG
    AS --> PG
    LS --> PG
    MR --> S3
    AS --> S3
    LS --> S3
    MR <--> K
    LS <--> K
    K <--> FM
    LS --> SB
    SB <--> R

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

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

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

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

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

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

Таблица Е.1 — Состав диагностического пакета LPI-VAP-MM.

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

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

Рабочая редакция 0.4 дополняет руководство эксплуатационными процедурами, таблицами сообщений, диагностическими кодами, параметрами настройки, регламентными операциями и составом диагностического пакета LPI-VAP-MM. Она не является зарегистрированным изменением утверждённого оригинала. История подготовки рабочей редакции сохраняется в Git и не заменяет оформленный лист регистрации изменений.