Команда разработки Platform V Pangolin реализовала собственный DCS в релизе 6.2.0, который более чем наполовину состоит из доработок под требования ФСТЭК России к СУБД. Разберемся, как он устроен и какие задачи выполняет в продукте. Рассказывает Лилия Шокарева, инженер по тестированию Platform V Pangolin, которая входила в группу разработки решения и защитила свой диплом в МФТИ по этому кейсу.
Предыстория. Замена etcd на собственный DCS
Distributed Configuration Store (DCS) — это распределенное хранилище конфигурации. Обеспечивает защиту и синхронизацию конфигурационных параметров между узлами, а также необходим оркестратору кластера (Patroni) для управления кластером СУБД.
До выпуска релиза 6.2.0 для инсталляций Platform V Pangolin в качестве DCS наиболее часто использовался сервис etcd — открытое распределенное хранилище. Преимущество etcd в том, что с ним умеет работать Patroni — это Python-приложение для создания высокодоступных PostgreSQL-кластеров на основе потоковой репликации, на котором основана наш Pangolin Manager. Также важно то, что etcd можно использовать как базу данных и он готов к высоконагруженным средам.
В прошлом году ФСТЭК России выпустила список требований к безопасности СУБД. В частности, для соответствия им Platform V Pangolin нужно было отказаться от использования несертифицированного open source сервиса etcd. Весной 2024 года команда продукта выполнила все требования регулятора и прошла сертификационные испытания, по результатам которых переоформила сертификат соответствия до 2028 года. Теперь продукт включает собственный сервис распределенного хранилища конфигураций с RAFT-механизмом — Pangolin DCS. Он позволяет обходиться без open source DCS-сервисов, и таким образом снизить риски ИБ-инцидентов, уменьшить количество и разнообразие системного ПО, повысить устойчивость кластеров. Это особенно важно для клиентов, которые используют изолированные среды разработки в окружении с высокими требованиями к безопасности.
Как работает DCS
DCS представляет собой хранилище типа «ключ-значение». Ключ имеет формат «строка», то есть имя ключа, а значение может быть любым. Кластер из узлов, на которых размещается DCS, называется DCS-кластером (не путать с кластером СУБД). Узлы можно добавлять и удалять из него.
Благодаря синхронизации у ключа всегда одинаковое значение на всех узлах кластера. И сами ключи можно устанавливать с любого узла – все узлы DCS-кластера доступны для записи.
Пример: вы зашли на node1 и выставили ключу key1 значение value1. Потом зашли на node2 и прочитали значение ключа key1 — оно равно value1. Затем на той же node2 вы изменили ключ key1 значением value2, зашли на node1 и снова прочитали ключ key1 — значение изменилось и стало value2.
Как достигается распределенность и синхронизация ключей?
С помощью алгоритма RAFT — он используется и в etcd и в нашем DCS.
В кластере один лидер, а все остальные – фолловеры. Один раз в заданное время лидер отправляет фолловерам хартбит — сообщение о том, что он жив. Если кто-то из фолловеров не получил это сообщение в определенный отрезок времени, то он становится кандидатом на лидерство и инициирует новое голосование.
Отсчет времени в кластере происходит по таймлайнам. Кандидат увеличивает свой текущий таймлайн и отправляет сообщения всем узлам с просьбой проголосовать за него. Если фолловер получает сообщение о голосовании, и его таймлайн больше текущего таймлайна фолловера, то он отправляет сообщение о своем голосовании. Когда собрано большинство (более половины кластера) голосов, кандидат становится лидером и отправляет хартбиты всем участникам.
RAFT используется не только для выбора лидера, но и для создания и поддержания распределенного журнала, который содержит историю всех выполненных операций. Этот журнал необходим для восстановления узла после сбоев и определения самого актуального узла, что, в свою очередь, требуется для выборов лидера.
Лидер получает новую запись и отправляет сообщение о ней всем узлам. После получения «ОК» от всех фолловеров, запись готова к коммиту. Затем запись должны закоммитить фолловеры, а после — лидер. Аналогично в DCS ключи распределяются от лидера фолловерам. Фолловеру приходит запрос на запись — он перенаправляет ее лидеру. Так достигается доступность на запись с любого узла.
Как мы реализовали собственный DCS?
Мы взяли упрощенный вариант DCS RAFT от Patroni и доработали его под наши требования. Добавили SSL-защиту, реализовали с нуля REST API, добавили устойчивость к дисковым сбоям, сделали самосжимаемый журнал операций, написали логирование внутри DCS с настраиваемой ротацией логфайла.
Pangolin DCS и etcd: различия
Etcd — внешний сервис, который изначально ничего не знает про Pangolin Manager (patroni). Его нужно устанавливать и настраивать отдельно от кластера patroni. И Etcd может располагаться на узлах, отличных от узлов, где работает patroni.
Pangolin DCS находится внутри Pangolin Manager. При запуске Pangolin Manager на узле запускается также нода DCS-кластера. А при его остановке останавливается и сервер DCS. Поток DCS выполняется параллельно основному потоку Pangolin Manager.
Pangolin DCS обладает отказоустойчивостью перед дисковыми сбоями. Операции с диском выделены в отдельный поток. В случае недоступности диска, зависает только дочерний процесс записи или чтения, а сам DCS продолжает работать, используя свою память для хранения журнала операций. В etcd нет такой функциональности — он сильно зависит от дисковой производительности. И это важное отличие Pangolin DCS от etcd — отказоустойчивость перед дисковыми сбоями позволяет использовать продукт в самых нагруженных виртуальных средах.
Дополнительно
СУБД Platform V Pangolin SE имеет сертификат соответствия Системы сертификации средств защиты информации по требованиям безопасности информации № РОСС RU.0001.01БИ00 (№ 4704, выдан ФСТЭК России 22 августа 2023 года, действителен до 22 августа 2028 года) и соответствует требованиям следующих документов:
- Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий (утверждены приказом ФСТЭК России от 2 июня 2020 г. № 76), по 4 (четвёртому) Уровню доверия;
- Требования по безопасности информации к системам управления базами данных (утверждены приказом ФСТЭК России № 64 от 14 апреля 2023 г.) по 4 классу защиты.
О других наиболее крупных доработках Platform V Pangolin в 2024 году можно почитать в прошлых обзорах: здесь собраны главные изменения и улучшения в релизе 6.3.0, здесь — доработки в релизе 6.2.0.
Также вы можете получить запись наших вебинаров о продукте, где эксперты команды демонстрируют новую функциональность. Смотрите вебинар по релизу 6.3.0 и вебинар, посвященный бизнес-эффектам от импортозамещения СУБД.