Привет, Хабр! В конце января мы в 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-дистрибутивов или их локальные зеркала или кэши, что, в общем-то, всегда и реализуется в закрытых контурах.
А каких фич не хватает в используемых вами решениях? Готов ответить на ваши вопросы в комментариях.
