Привет, Хабр! В конце января мы в Orion soft получили сертификат ФСТЭК на СУБД Proxima DB и выпустили новую версию 3.1 для редакций Proxima DB Core и Advanced.
На самом деле по количеству добавленных фич новую версию можно было бы переименовывать в 4.0 или даже в 5.0.
Софтверные гиганты здесь обычно показывают гору фантиков от сникерсов и пустых стаканчиков от кофе, использованных при выпуске нового релиза.
Но мы придерживаемся концепции изменения мажорной версии Proxima DB с изменением мажорной версии PostgreSQL, поэтому новая версия — именно 3.1.
В этой статье хотим поделиться:
С какими новыми требованиями регуляторов мы столкнулись в процессе;
Как технически реализовали новую для российских СУБД функцию мониторинга производительности в реальном времени;
Как работают другие ключевые фичи: возможность подключать другие СУБД на основе PostgreSQL, новая роль DBaaS-сервера, упрощенный процесс инсталляции базовой редакции СУБД.
Почему сертификация ФСТЭК стала сложнее
С лета 2023 года ФСТЭК начал формулировать узкоспециализированные требования к конкретным видам ПО (виртуализация, СУБД, контейнеризация).
Раньше формулировки касались по большей части общих требований, таких как разграничение доступа, очистка памяти, правильное логирование событий безопасности. Обычно такие требования закрывались проверкой кода, специальными настройками, организационными мерами и специальными решениями сертифицированных ОС.
Но в новых документах ФСТЭК появились более узкоспециализированные требования для СУБД.
Например, теперь ФСТЭК обязывает производителей СУБД реализовывать «доступность» СУБД, и она должна быть реализована через «отказоустойчивый кластер». Причем в новом изложении требований нет намека на формулировку вида «должна быть реализована возможность». Обычно при таких формулировках под возможностью понимают возможность настройки вручную, настройки с использованием инструкций или внешних/сторонних компонентов. В требованиях речь идет о том, чтобы все было именно «из коробки».
Кроме того, ФСТЭК стал предъявлять отдельные требования к реализации контроля целостности объектов СУБД: конфигурационных файлов, настроек, процедур, хранимых в БД. Причем, согласно документу, контроль должен выполняться автоматически не реже одного раза в сутки или при перезагрузке СУБД. И снова требования подразумевают, что все это не просто «возможность», а реализовано именно «из коробки».
Все это говорило о том, что получить сертификат ФСТЭК стало сложнее, и нам придется повозиться. Если развертывание кластеров у нас и так было «из коробки», то многие другие требования мы закрывали, разработав множество изменений фактически с нуля. Но в итоге мы прошли этот тернистый путь, и теперь у нас есть сертифицированная ФСТЭК редакция Proxima DB Special Edition.
Маленький шаг в номере версии — большой в развитии функциональности
Теперь — про версию Proxima DB 3.1. В этом релизе у нас очень много изменений, вот основные:
Новый, полностью переделанный мониторинг;
Возможность подключения (с целью управления и мониторинга) других СУБД на основе PostgreSQL;
Новая роль DBaaS-сервера в составе Proxima DB Advanced, которая позволяет в 1 клик развертывать Proxima DB в контейнерах;
Переработанный и упрощенный процесс инсталляции Proxima DB с поддержкой офлайн-режима.
Полное описание новой функциональности и всех изменений можно посмотреть в release notes.
Расскажу подробнее про перечисленные выше ключевые фичи.
Мониторинг производительности в режиме реального времени
Это, пожалуй, самая важная функциональность, которая вошла в редакцию Proxima DB Advanced 3.1.
Мониторинг Proxima DB осуществляется через отдельное расширение. Оно позволяет считывать данные о сессиях, запросах, транзакциях, о работе PostgreSQL в реальном времени. Большинство этих данных забирается напрямую из памяти PostgreSQL, а не тогда, когда транзакции или операции завершатся и попадут в pg_stat_*, как это обычно делают в системах мониторинга для PostgreSQL.
При считывании данных из памяти PostgreSQL есть возможность настройки семплирования данных. Например, их можно считывать как раз в секунду, так и раз в 10 секунд в зависимости от необходимой точности.
Вся новая функциональность, связанная с мониторингом, у нас сгруппирована по разделам: «Активность», «Производительность», «Сессии», «SQL Монитор».
Активность
Раздел «Активность» предоставляет детальные графики по профилю нагрузки выбранной базы данных. По графикам в этом разделе легко определить, что нагружает БД: запросы, ожидания, пользовательские сессии и так далее. В разделе «Активности» доступны графики по текущим активностям БД, таким как Wait class, Wait event, Application, Username, Blocking session и другие.
Производительность
Раздел «Производительность» дает общее представление о состоянии производительности БД и ОС. В нём можно получить информацию о трендах изменения нагрузки БД/ОС, об основных показателях производительности БД/ОС, о показателях запасов системных ресурсов.
В разделе «Производительность» экран разделен на два представления, в каждом из которых размещен свой график:
Верхний — профиль нагрузки БД, отображение графика нагрузки БД по классам активностей;
Нижний — динамические метрики по группам статистик, которые можно выбрать в фильтре.
Группа статистик в свою очередь представлена графиками Process and Load, Transactions, Reads/Writes & WAL, Active Parallel Sessions, Buffer reads, Query reads, CPU, Memory, Network и другими.
Сессии
В разделе «Сессии» можно найти необходимые инструменты для поиска проблемных сессий и понимания причин блокировок внутри БД: построение дерева блокировок, фильтрация по типам сессий, определение состояний блокировок.
Таблица «Сессий» формируется из представления pg_stat_activity. По каждой сессии во всплывающем окне можно посмотреть текст SQL-запроса, план запроса и ресурсы по блокировкам из представления pg_locks.
Таблица «Дерево блокировок» в разделе «Сессии» отображает заблокированные сессии из того же представления pg_stat_activity. По каждой сессии из «Дерева блокировок» можно посмотреть текст SQL-запроса, план запроса и ресурсы по блокировкам из представления pg_locks. Также на вкладке представлена таблица с цепочками ожиданий получаемых из представления pg_stat_activity.
SQL Монитор
Если какой-то запрос застрял — долго выполняется, висит в ожидании, съедает много ресурсов — то его можно досконально изучить в реальном времени в разделе «SQL Монитор». Там можно посмотреть проблемный узел плана, ошибки оптимизатора и время выполнения каждого узла плана с его статистиками.
В следующей статье мы более подробно расскажем, как устроен наш мониторинг, и покажем кейсы его использования.
Подключение других СУБД PostgreSQL
Еще одна новая фича релиза 3.1 — возможность подключать в интерфейс управления Proxima DB Advanced другие СУБД на базе Open Source PostgreSQL для дальнейшего управления ими, резервного копирования и мониторинга. Эти СУБД могут быть установлены из репозиториев ОС или отдельно.
Процесс подключения полностью автоматизирован и не требует дополнительной или предварительной установки пакетов. Все нужное ПО — как необходимые системные пакеты ОС, так и разнообразные агенты Proxima DB Advanced — установится автоматически, без необходимости доступа в сеть. Даже нужный systemd-сервис, с помощью которого реализуется управление, будет найден, каким бы странным именем его не назвали.
Все параметры и конфигурационные файлы подключаемой СУБД, расположение файлов с данными, — всё автоматически определяется из окружения СУБД. С точки зрения конфигурирования для подключения внешней СУБД достаточно указать только ip:port, пользователя с ролью superuser и его пароль. Для установки ПО ещё понадобится пользователь с правами sudo.
После импорта юнита для него будет открыта вся возможная функциональность Proxima DB Advanced: мониторинг, резервное копирование, управление.
Импорт внешних СУБД пока поддерживается для одноузловых конфигураций PostgreSQL 16.2, 16.4, установленных на ОС Astra Linux 1.7.5-16, РЕД ОС 7.4.3, РЕД ОС 8, Debian 11.
Новая роль DBaaS-сервера в Proxima DB Advanced
PostgreSQL используют для разных задач. Часто это небольшие тестирования, разработка/отладка ПО с отдельной копией БД или небольшое и ненагруженное хранение данных под какой-либо сервис. При этом часто возникает обязательное требование, чтобы данные хранились в отдельном инстансе PostgreSQL.
В общении с заказчиками мы встречали самые разные подходы в отношении схем инсталляций PostgreSQL и схем хранения данных для этой задачи: от множества сервисов-инстансов PostgreSQL на одной машине (для каждого сервиса — свой каталог data со своими настройками) до множества инсталляций PostgreSQL (как правило, с разными версиями PostgreSQL) и с большими Excel-табличками, содержащими информацию о том, кто за что отвечает и в каком инстансе что лежит.
Обслуживать и инвентаризировать весь этот «зоопарк» сложно, как и добавлять новые или удалять уже ненужные инстансы. Поэтому у нас родилась идея реализовать свой встроенный DBaaS-сервис. Это отдельная выделенная роль в Proxima DB Advanced — DBaaS-хост в терминах Proxima DB. Для её развертывания достаточно указать IP и креды для подключения по ssh к серверу, который будет выступать в роли DBaaS-хоста и на который Proxima поставит все нужные компоненты даже в закрытом контуре.
Далее по клику в нашем UI пользователь сможет «поднимать» в контейнере DBaaS-юниты, то есть инстансы Proxima DB, разворачиваемые за 2-3 секунды на установленном перед этим DBaaS-хосте.
DBaaS-хостов может быть несколько, одни могут использоваться для продуктовых сред, другие — только для тестирования и разработки.
По окончании создания DBaaS-юнита пользователю предоставят автоматически сгенерированный пароль и порт для обращения к сервису.
Управлять созданием DBaaS-юнитов можно как через web-интерфейс Proxima DB Advanced, так и через API.
Обновленный процесс инсталляции редакции Proxima DB Core
Core — это базовая редакция нашей СУБД. Подробнее про отличия редакций Core и Advanced можно почитать тут.
Одной из наших первоначальных целей в разработке продукта была простота инсталляции предлагаемых кластерных конфигураций Proxima DB. В веб-интерфейсе Advanced-редакции мы реализовали быстрое автоматизированное развертывание кластеров. Core-редакция в этом немного уступала, так как в Core шаблоны конфигурационных файлов нужно было заполнять руками.
В новом релизе процесс инсталляции Proxima DB Core представляет собой диалоговый режим, выполняемый в консоли и требующий от пользователя ответить не более чем на 6-7 несложных вопросов. Все остальное мы вычисляем сами. Это ускоряет процесс инсталляции и почти полностью исключает возможные ошибки из-за человеческого фактора или неопытности.
При этом мы не ограничиваем пользователей в вопросах конфигурирования СУБД. Пользователи, которые точно знают, что им в кластере нужны специальные настройки репликации, отдельные параметры работы PostgreSQL и так далее, могут как указать или скорректировать эти настройки перед развертыванием в отдельном конфигурационном файле, так и добавить или переопределить эти настройки после развертывания. Просто теперь эти возможные настройки не являются обязательными при установке кластера.
Дополнительно мы реализовали офлайн-режим инсталляции, который крайне важен для многих закрытых сред, особенно в КИИ. У нас не было задачи реализовать абсолютный офлайн-режим. Для этого потребовалось бы добавить в дистрибутив все официальные репозитории сертифицированных ОС и еще множество вариаций разных компонентов и их версий.
Мы стремились сократить размер дистрибутива, при наличии доступа в интернет скачивать нужные компоненты оттуда и только в случае отсутствия доступа в интернет дать возможность выполнять инсталляцию без него. Внешние скачиваемые компоненты нужны только для автоматизации процессов инсталляции, в самой СУБД эти компоненты не используются.
Кроме того, наш офлайн-режим подразумевает, что на серверах развертывания Proxima DB будут настроены официальные репозитории поставщиков Linux-дистрибутивов или их локальные зеркала или кэши, что, в общем-то, всегда и реализуется в закрытых контурах.
А каких фич не хватает в используемых вами решениях? Готов ответить на ваши вопросы в комментариях.
