Архитектура Платформы
В этом разделе представлены основные компоненты, из которых состоит Платформа, а также описано их функционирование и взаимодействие.
Основные компоненты и их функции
Платформа состоит из следующих компонентов:
Клиентская часть — представляет собой веб-интерфейс для администраторов и позволяет управлять базами данных.
Серверная часть — обеспечивает основную функциональность платформы. Состоит из следующих компонентов:
backend — реализует логику работы системы и предоставляет API. Разработан на Golang;
keeper — обрабатывает входные потоки метрик с агентов. Разработан на Golang;
pg_configurator — модуль рекомендаций конфигурации СУБД — предлагает рекомендации по настройке базы данных. Разработан на Python.
Фронтенд — обеспечивает интерактивность и удобство использования для пользователей. Разработан на JS Angular.
СУБД — является ядром продукта. Основана на PostgreSQL. Имеет следующие расширения для обработки большого количества метрик:
btree_gin,
HTTP,
pg_cron,
pg_framework,
pg_stat_statements,
pg_store_plans,
pipelinedb,
plpgsql,
uuid.
Агент — легковесное приложение на Golang — собирает информацию с базы данных и операционной системы и отправляет данные с изменениями на серверную часть Платформы, обеспечивает безопасную связь с backend и keeper-серверами. Агент обеспечивает управление и конфигурацию СУБД, а также выполнение заранее запрограммированных задач и задач по расписанию.
Брокер сообщений NATS — обеспечивает асинхронный обмен сообщениями и доставку данных в базу данных OperDB.
pg_anon — средство для анонимизации данных в СУБД.
pg-explain — модуль расширенной аналитики.
Swagger — набор инструментов для создания, кодогенерации и использования API-документации в соответствии со спецификацией OpenAPI.
Рис.1 Схема архитектуры Платформы
Взаимодействие агента с объектами мониторинга и управления
Postgres/TantorDB — агент Платформы осуществляет взаимодействие с экземплярами Postgres/TantorDB и прочими Postgres подобными базами данными, используя стандартные порты СУБД и unix socket файлы.
Patroni — агент осуществляет функции сбора метрик Patroni и управление.
Источник соединения |
Целевой компонент |
Порт и протокол |
Комментарии |
|---|---|---|---|
Внутренние взаимодействия в пределах среды сервера (хост) |
|||
Platform Agent |
Postgres/TantorDB |
|
Управляющие команды, сбор метрик Целевые порты отличаются в зависимости от среды заказчика |
Platform Agent |
Patroni |
TLS/TCP |
Управляющие команды, сбор метрик Целевые порты отличаются в зависимости от среды заказчика |
Docker-compose
Архитектура соединений между компонентами Платформы, функционирующими в Docker через docker-compose, организована следующим образом:
Основные подсистемы
Подсистема мониторинга и управления.
Браузерные компоненты взаимодействуют с серверной частью Платформы через общий Reverse Proxy (nginx), который слушает HTTP и HTTPS порты (80, 443). Также Reverse Proxy задействован для некоторых взаимодействий между серверными элементами Платформы.
Внешний агент (Platform Agent) подключается к nginx через TCP:4222 и HTTPS:443.
Swagger UI доступен по HTTP:8080.
Компонент Platform Frontend взаимодействует с nginx по HTTP:80.
Flyway и NATS осуществляют обмен данными по TCP:4222.
Keeper, pgbouncer, OperDB (TantorDB), MainDB используют TCP:5432 для соединений с базами данных.
Сервер/Backend взаимодействует с различными сервисами по HTTP:5666, HTTP:80 и через базы данных по TCP:5432.
Подсистема расширенной аналитики.
pg_explain доступен через HTTP:80 и HTTP:443.
pg_monitor (dispatcher и collector) работают через TCP:5432.
Взаимодействие с пользовательским интерфейсом.
Platform UI и Tensor UI доступны для браузера через Reverse Proxy (nginx) по HTTP:80 и HTTPS:443.
Внешние сервисы.
Аутентификация: Active Directory, LDAP, ALD Pro — взаимодействие через TCP:389 или иной порт и протокол, сконфигурированный заказчиком.
Интеграция: XData, RuBackup, SIEM, AI-ассистент — HTTP:8081 или иной.
Почтовые уведомления: SMTP — TCP:25, TCP:465 или иные в зависимости от настроек почтового сервера
Потоки взаимодействия.
Все входящие внешние подключения (от агента, браузера) проходят через nginx (Reverse Proxy).
Внутренние сервисы и базы данных подключаются друг к другу преимущественно через TCP:4222 (NATS, Flyway, Keeper) и TCP:5432 (pgbouncer, MainDB, OperDB, pg_monitor).
Авторизация и интеграция с внешними системами реализуется через отдельные сервисы, подключаемые к Backend по соответствующим портам.
Источник соединения |
Целевой контейнер |
Порт и протокол |
Комментарии |
|---|---|---|---|
Внутренние взаимодействия |
|||
Platform Agent |
Reverse Proxy (nginx) |
TCP:4222, HTTPS:443 |
Управляющие команды, телеметрия, пакеты установки новых версий агента |
Reverse Proxy (nginx) |
swagger_ui |
HTTP:8080 |
Swagger UI |
Reverse Proxy (nginx) |
Platform Frontend |
HTTP:80 |
Пользовательский интерфейс |
Reverse Proxy (nginx) |
Server / Backend |
HTTP:5666 |
Доступ к API платформы |
Platform UI (браузер) |
Reverse Proxy (nginx) |
HTTP:80,HTTPS 443 |
Пользовательский интерфейс Платформы |
Tensor UI (браузер) |
Reverse Proxy (nginx) |
HTTP:80, HTTPS:443 |
Пользовательский интерфейс инструментов расширенной аналитики |
pg_anon |
Reverse Proxy (nginx) |
HTTP:80 |
Асинхронные ответы на запросы анонимизации |
pg_configurator |
Server / Backend |
HTTP:7777 |
Выработка конфигураций Postgres |
Server / Backend |
pg_anon |
HTTP:8080, HTTP:5666 |
Запросы на анонимизацию |
Flyway |
pgbouncer |
TCP:5432 |
Миграции баз данных |
Server / Backend |
NATS |
TCP:4222 |
Взаимодействие с подсистемой обмена данных Платформы |
pgbouncer |
OperDB (TantorDB) |
TCP:5432 |
Взаимодействие с базой данных |
pgbouncer |
MainDB |
TCP:5432 |
Взаимодействие с базой данных |
Keeper |
pgbouncer |
TCP:5432 |
Взаимодействие с базой данных |
pg_explain |
pg_monitor (dispatcher) |
TCP:5432 |
Взаимодействие с базой данных |
pg_monitor (dispatcher) |
pg_monitor (collector) |
TCP:5432 |
Взаимодействие с базой данных |
Внешние взаимодействия |
|||
Server / Backend |
Active Directory, LDAP, ALD Pro |
TCP/TLS:389, 636, 88, 3268 или 3269 в зависимости от системы |
Внешняя аутентификация |
Server / Backend |
|
HTTPS:443 |
Интеграции со сторонними системами |
Server / Backend |
SMTP |
TCP/TLS:25, 587 |
Отправка почтовых уведомлений |
Архитектура построена по принципу микросервисов, где каждый компонент функционирует в отдельном Docker-контейнере, а их взаимодействие реализовано через стандартизированные сетевые порты и протоколы. Основная точка входа и маршрутизации — Reverse Proxy (nginx), обеспечивающий безопасность и балансировку нагрузки между сервисами Платформы.
Кластеризация
Платформа поддерживает возможность развертывания экземпляров баз данных в кластерах, что позволяет эффективно масштабировать систему и обеспечивать высокую отказоустойчивость.
Кластеризация Платформы обеспечивается с помощью Python-приложения Patroni, основанного на потоковой репликации. Приложение позволяет преобразовать систему из ведущего и ведомых узлов в высокодоступный кластер с автоматическим контролируемым и аварийным переключением.
С помощью Patroni можно легко добавлять новые реплики в существующий кластер и изменять конфигурацию СУБД одновременно на всех узлах кластера. Patroni поддерживает синхронную репликацию, настраиваемые действия при переключении узлов, REST API и возможность запуска пользовательских команд для создания реплики. Patroni также взаимодействует с Kubernetes и имеет множество других возможностей.
Рис.2 Схема масштабируемой платформы
Пакетная установка
Архитектура развертывания Платформы на виртуальных машинах (ВМ) подразумевает установку до нескольких компонентов на некоторые ВМ. Управление установкой и конфигурацией компонентов осуществляется с помощью Ansible. Всё взаимодействие происходит в изолированной сети Платформы.
Примечание
Данная архитектура развертывания является референсной. Фактическая реализация может отличаться в зависимости от архитектурных особенностей Заказчика.
Группы компонентов
Внешние интерфейсы.
Агент Платформы и браузерные клиенты (Platform UI, Tensor UI) подключаются к Платформе через внешний балансировщик нагрузки (nginx) и обратный (reverse) прокси.
Все внешние подключения происходят по каналам TCP:4222, HTTPS:443.
Для администрирования используется отдельный сервер с инструментами flyway, ansible и nginx (локальный репозиторий).
Внешний балансировщик нагрузки.
Nginx, работающий на порту TCP:4222, выполняет функцию публикации доступа к подсистеме сообщений NATS.
Обеспечивает маршрутизацию трафика между клиентами и внутренними сервисами Платформы.
Keepalived для целей предоставления VIP (Virtual IP Address), обеспечивающего отказоустойчивость компонента Платформы и являющегося единой точкой входа в компонент.
Reverse Proxy.
Nginx, принимающий HTTP(s) на портах 80, 443, 8443, 5666 и перенаправляющий запросы до портов 4200, 8000, 8080.
Keepalived для целей предоставления VIP (Virtual IP Address), обеспечивающего отказоустойчивость компонента платформы и являющегося единой точкой входа в компонент.
Группированная функциональная логика.
Содержит несколько компонентов решения:
Backend,
pg_configurator,
Keeper,
Nginx (Platform UI),
Swagger,
pg_explain и Tensor_ui,
pg_anon.
Сервисы взаимодействуют между собой и с другими подсистемами через внутренние прокси и балансировщики.
Система сбора логов и анализа запросов.
PG Monitor Collector (8000) и PG Monitor Dispatcher (8001, 9000), предоставляющие функциональность системы расширенной аналитики.
Подсистема сообщений NATS.
3 экземпляра NATS, работающие на портах NATS: 4222, 6222, 8222.
Обеспечивает очереди сообщений между компонентами Платформы.
Внутренние прокси и балансировщики.
Внутренний балансировщик нагрузки (VIP) маршрутизирует трафик между компонентами Платформы.
Используются порты: TCP proxy:4222
Подсистема TantorDB/Postgres.
Oper DB (TantorDB): порт 5432,
Main DB (TantorDB): порт 5432,
Tensor DB: порт 5432.
Административный сервер.
Используется для запуска Ansible playbooks и настройки компонентов.
На каждую ВМ Ansible устанавливает необходимые компоненты согласно роли ВМ: балансировщик, proxy, сервер приложений, collector, БД, NATS и др.
Потоки взаимодействия.
Источник соединения (группа пакетов) |
Целевая группа |
Порт и протокол |
Комментарии |
|---|---|---|---|
Внутренние взаимодействия |
|||
Platform UI и Tensor UI |
Reverse Proxy (nginx) |
HTTP:80, HTTPS:443 |
Пользовательский интерфейс |
Platform Agent |
Внешний Load Balancer |
TCP:4222, HTTP(S):80(443) Протокол и порт могут отличаться в зависимости от индивидуальных настроек экземпляра Платформы |
Управляющие команды, телеметрия пакеты установки новых версий агента. |
Внешний Load Balancer |
NATS |
TCP:4222 |
Балансировка запросов доступа к NATS |
Reverse Proxy |
Сгруппированная функциональная логика |
HTTP:
|
Доступ к функциональным портам |
Административный сервер |
Все сервера |
SSH/TLS:22 |
Управление и конфигурация |
Все сервера |
Административный порт |
TCP (HTTP):80 |
Работа с локальным репозиторием и установки пакетов |
Административный сервер |
Подсистема TantorDB / Postgres
|
TCP:5432 |
Управление и конфигурация |
Внутренний Load Balancer |
Подсистема TantorDB / Postgres
|
TCP:5432 |
Доступ к Postgres |
Внутренний Load Balancer |
NATS |
TCP:4222 |
Взаимодействие с подсистемой обмена данных Платформы |
NATS |
NATS |
TCP:6222 |
Обмен статусами (heartbits) |
Любой клиент имеющий доступ к сети Платформы |
NATS |
HTTP:8222 (доступ к телеметрии) |
UI-компонент NATS |
Tensor Collector (collector и dispatcher) |
Внутренний Load Balancer |
TCP:5433 |
Доступ к Postgres |
Сервер приложений (collector и dispatcher) |
Внутренний Load Balancer |
TCP:
|
Доступ к Postgres и NATS |
Данная архитектура обеспечивает гибкость масштабирования, отказоустойчивость и централизованное управление компонентами Платформы. Использование Ansible позволяет автоматизировать процесс установки, обновления и конфигурирования всех сервисов на виртуальных машинах.
Особенности архитектуры Платформы
Клиент-серверная архитектура: Платформа основана на клиент-серверной архитектуре, в которой клиентская часть представляет собой веб-интерфейс, а серверная часть состоит из нескольких модулей, написанных на языках Golang, Python и JS Angular.
Сбор метрик: cбор метрик осуществляется с помощью Агента. Агент наблюдает за базой данных и операционной системой. Он собирает информацию о метриках из администрируемой базы данных и отправляет их через брокер сообщений NATS на backend-сервер. Агент также имеет возможность отправлять только изменившиеся данные на основе срезов и предагрегации данных для снижения объема сетевого трафика и нагрузки на сервер.
Хранение метрик: метрики хранятся в основанной на PostgreSQL СУБД, которая была дополнена специальными расширениями для обработки большого количества метрик «на лету». Полученные данные сохраняются в OperDB и могут быть распределены по пространствам.
Сбор и хранение журналов СУБД: с помощью дополнительного сервиса pg-monitor возможно настроить сбор и аналитику журналов СУБД с последующей визуализацией в графическом интерфейсе. Этот сервис является опциональным, так как требует дополнительное защищенное соединение SSH к наблюдаемым экземплярам.
Масштабирование: Платформа поддерживает горизонтальное масштабирование большинства компонентов.
Отказоустойчивость: Платформа обеспечивает отказоустойчивость путем дублирования основных компонентов.
Безопасность: среда исполнения Агента не требует наличия дополнительных открытых сетевых портов. Однако Агенту необходимо иметь сетевое подключение до портов NATS как точки обмена данными с серверной частью Платформы. Также Агент выполняется от имени пользователя postgres, что с одной стороны позволяет иметь возможность глубоко интегрироваться с СУБД, а с другой — минимизирует его влияние не среду операционной системы.