Системная архитектура

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

• Для публикации на сайте компании - описание продукта, white paper, datasheet;
• Для участия в конкурсах на закупку (RFI, RFP) - концептуальное описание продукта и его роль в IT экосистемы предприятия;
• Презентационные материалы для технических сессий с существующими и потенциальными клиентами;
• Публичная техническая документация на продукт.

Внутренняя техническая документация, разрабатываемая в отделе производства для внутреннего использования в компании-производителе ПО. Некоторые варианты представления архитектурных артефактов:

• В виде ADR (Architecture decision records) - запись архитектурных решений;
• Составная часть FDS (Functional design specification) с описанием архитектуры в C4 модели;
  • Контекстная диаграмма. Для бизнес-пользователей, которым не нужно погружаться в технические нюансы;
  • Диаграмма контейнеров. Для пользователей, которым нужно понять архитектуру приложения без глубокого погружения в техническую часть;
  • Диаграмма развертывания;
  • Сетевая диаграмма.

Для примера далее представлена доменная область - сеть радиодоступа O-RAN и подсистема управления и обслуживания физических и виртуализированных сетевых элементов (O-RAN management domain). Логическая архитектура рассматриваемого домена:

Описание компонент на диаграмме:

• O-CU-CP : O-RAN Central Unit – Control Plane. Плоскость управления центральным блоком O-RAN: логический узел, на котором размещены RRC (управление радиоресурсами) и CP (плоскость управления) PDCP (протокол конвергенции пакетных данных)
• O-CU-UP : O-RAN Central Unit – User Plane. Пользовательская плоскость: логический узел, на котором размещены SDAP (протокол адаптации служебных данных) и UP (пользовательский уровень) часть PDCP;
• O-DU : O-RAN Distributed Unit. (распределенный блок O-RAN): логический узел, на котором размещены уровни RLC (управление радиоканалом) / MAC (управление доступом к среде) / высокий PHY на основе LLS;
• O-RU : O-RAN Radio Unit. Удаленный блок O-RAN: логический узел, на котором размещается уровень низкого физического уровня (например, FFT / IFFT, PRACH) и RF на основе LLS (разделение нижнего уровня);
• Near-RT RIC : Near-Real-Time Radio Intelligent Controller. Интеллектуальный контроллер RAN в режиме близкого к реальному времени или nRT RIC: логический узел, обеспечивающий управление / оптимизацию элементов и ресурсов RAN в режиме почти реального времени посредством детального сбора данных и действий по E2. Контроллер nRT RIC может включать рабочий процесс AI / ML.
• PNF : Физическая базовая станция - eNodeB
• OAM functions : Компонент обеспечивающий управление и обслуживание физических и виртуализированных сетевых элементов. FCAPS (Fault, Configuration, Accounting, Performance, Security) с конфигурацией, реконфигурацией, регистрацией, безопасностью, производительностью, обменом деталями мониторинга с отдельными узлами

Концептуальная архитектура

Решаемая задача - объяснить место предлагаемого решения в IT экосистеме предприятия. Как правило визуализация архитектуры такого рода применяется в следующих артефактах:

• Маркетинговые материалы о продукте
• Тендерная документация на покупку IT систем
• Техническая пояснительная записка в рамках технико-коммерческого предложения
• Приложение к контракту на внедрение IT системы
• Высокоуровневый дизайн проекта

Основные принципы:

• Расположить на диаграмме внедряемую систему и все системы с которыми предполагается интеграция
• Для внедряемой системы определить внутреннюю структуры - основные компоненты, который важны для конкретного проекта
• Определить потоки данных между системами. Стрелками показать направление потока данных от источника к приемнику
• Описать интеграционные потоки с указанием протоколов, технологий

C4.Контекстная диаграмма

@startuml
!include C4_Context.puml

'LAYOUT_TOP_DOWN()
'LAYOUT_AS_SKETCH()
LAYOUT_WITH_LEGEND()

title Управление и обслуживание сетевых функций O-RAN

Person(ran_engineer, "Инженер экплуатации радио сети", "Разворачивает сетевые элементы, обновляет систему")
Person(l3_engineer, "Инженер поддержки L3 ", "Анализирует инциденты, решает клиентские заявки")


Boundary(ran, "Подсистема базовых станций") {
    System(oran_ems, "ORAN EMS", "Система управления и обслуживания сетевых функций ORAN")

    System_Ext(o_ran_mf, "O-RAM MF", "Manaegment fuction: O-DU, O-RU, CU-UP, CU-CP")
    System_Ext(nrt_ric, "Near realtime RIC", "Интеллектуальный контроллер RAN")
}
Boundary(ext, "Внешние системы клиента"){
    System_Ext(netcool, "Netcool", "Umbrella FM")
    System_Ext(prometheus, "Prometheus", "Umbrella PM")
    System_Ext(ndo, "NDO", "Service Activator")
    System_Ext(splunk, "Splunk", "SIEM")
    System_Ext(dwh, "DWH", "Data warehouse")
    System_Ext(postfix, "Postfix", "Umbrella FM")
}

Rel_L(ran_engineer, oran_ems,"разворачивает и обновляет БС")
Rel_L(l3_engineer, oran_ems,"решает инциденты и исследует заявки клиентов")


Rel(oran_ems, o_ran_mf,"Управляет конфигурацией")
Rel(oran_ems, o_ran_mf,"Получает pmf файлы с метриками")
Rel( o_ran_mf, oran_ems,"Передает трейсы")
Rel( o_ran_mf, oran_ems,"Передает нотификации с авариями")
Rel(oran_ems, nrt_ric,"Забирает метрики")
Rel(nrt_ric, oran_ems, "Передает нотификации с авариями")
Rel(nrt_ric, oran_ems, "Передает нотификации с авариями")

Rel_U(oran_ems,netcool, "Передает нотификации с авариями")
Rel_U(oran_ems,prometheus, "Пересылает метрики")
Rel(ndo, oran_ems, "активирует и настраивает сервисы")
Rel_U(oran_ems,splunk, "передает логи аудита")
Rel_U(oran_ems,dwh, "Передает метрики и историю аварий")
Rel_U(oran_ems, postfix, "отправляет email нотификации")

skinparam nodesep 100
'skinparam Linetype ortho

@enduml

Прикладная архитектура

C4. Диаграмма "Контейнеров" модуля Performance Management

Рассмотрена подсистема записи и визуализации метрик в рамках приложения Performance Management.

• Интеграция с IAM и другими платформенными сервисами предполагается, но в данной статье не рассмотрена
• Микрофронтэнд pm-frontend - раздает пользователям JS,CSS файлы которые необходимы для сборки страницы в браузере.
• pm-bff - сервис проверяющий доступ пользователя к эндпоинтам.
  • Логирует аудитные логи при CRUD операция с сущностями домена Performance Management.
  • Представляет ответ от других api в удобном для фронтэнда виде.
• pm-integration-api - используется как интеграционный шлюз для связи с внешними системами.
  • Отправляет метрики в формате prometheus-remote-write во внешний prometheus.
  • Формирует csv файлы с агрегированными метриками во внешнее облако данных и систему отчетности.
  • Пишет аудитные логи в сервис аудит логирования
• pm-configuration-manager - управляет конфигурациями подсистемы. выдают конфигурационные файлы для других микросервисов
  • Хранит внутренние конфигурации - правила алертов, дашборды
  • Хранит настройки внешних интеграций
  • Формирует конфигурацию правил алертов и правил формирования производных метрик для vmalert
• vmalert - опенсорсное приложение экосистемы victoria-metrics
  • Выявляет пороговые аномалии на основе мпетрик
  • Формирует производные метрики с помощью recording-rules
• pm-oran-metrics-file - Собирает готовые файлы с метриками с подключенных виртуализированных сетевых элементов

Базы данных:

• pm-internal-configuration-manager - MongoDb. для хранения конфигруций подвистемы Prefomanve Management
• vmselect - сервис, часть экосистемы Victoria Metrics. Чтение, дедупликация и препроцессинг метрик
• vminsert - сервис, часть экосистемы Victoria Metrics. Подготовка метрик и нормализация модели данных метрик перед сохранением на диски.
• vmstorage - сервис, часть экосистемы Victoria Metrics. Хранит метрики и индексы на дисках

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

Диаграмма развертывания подсистемы сбора и хранения метрик

• База данных установлена на двух независимых площадках
• Stateless приложения базы данных victoria-metrics развернуты в кластере kubernetes вместе с микросервисами performance-management. При при изменении нагрузки на vmselect, vmstorage меняется количество инстансов с помощью механизма автоскалирования kubernetes
• Statefull приложение базы данных victoria-metrics (vmstorage) развернуто на отдельных виртуальных машинах на той же AZ, что и k8s кластер
• При записи метрик применяется фактор репликации = 2, таким образом данные для каждого временного ряда находятся на двух нодах
• Edge site - распределенная подсистема сбора файлов с метриками. В частном случае сборка может стоять и на центральных сайтах
• Сборщики собирают pmf файлы с метриками, хранят локально на дисках родительской виртуальной машины. После преобразования формата в prometheus_remote_write одинаковый поток данных записывается в 2 локации с установленной victoria-metrics
• В случае сетевой недоступности одной или двух центральных сайтов, поток метрик хранится на локальных дисков и досылается при восстановлении подключения

Описание услуг

Доменные области:

• Системы виртуализации и облачные платформы
• Системы поддержки процессов для телекоммуникационных сетей (OSS)
• Системы мониторинга. логирования, APM (application performance management)
• Внутрикорпоративные системы и автоматизация процессов

В зависимости от специфики вашего проекта предлагаю услуги по разработки и сопровождению архитектурной документации на продукт на всех этапах жизненного цикла продукта:

• Разработка технических презентационных материалов
• Разработка ответа для участия в конкурсах на закупку (RFP/RFQ) и ответа на запрос информации
• Разработка высокоуровнего дизайна приложения (HLD)
• Разработка низкоуровнего дизайна приложения (LLD)
• Разработка механизмов повышения доступности существующего приложения