Сегодня мы хотели бы затронуть очень важную для DLP-решений тему – выбор СУБД для хранения данных. Так исторически сложилось, что большинство российских DLP используют для этих целей Oracle Database. На заказчиков это накладывает определенные финансовые ограничения: стоимость лицензий Oracle закладывается в стоимость DLP-системы. Это создает определенный фильтр, сокращающий аудиторию пользователей продукта: СУБД Oracle могут позволить себе не все – как в техническом, так и в финансовом плане.
Теперь, когда импортозамещение шагает по стране, госсектор (и не только) формирует спрос на DLP, поддерживающие свободные СУБД. Это очень ощутимый импульс, но, метнувшись в сторону свободных СУБД, важно сохранить удобство, производительность и функциональные возможности продукта. В этой статье речь пойдет о том, как мы решали эту задачу, реализуя поддержку PostgreSQL и разрабатывая схему секционирования в Solar Dozor.
Oracle vs PostgreSQL
Система Solar Dozor в качестве основной системы хранения данных использует реляционную СУБД. Критерии выбора СУБД до недавнего времени являлись довольно простыми: объем и возможность разделить архив на оперативный и «до востребования».
В отношении объема БД существовали определенные ограничения, выведенные эмпирически: он не должен был превышать 3-4 ТБ (это порядка 5 млн перехваченных сообщений). Выше этих значений наблюдалась значительная деградация работы системы: нагрузка на IO из-за необходимости регулярно запускать запросы на удаление старых данных, вакуминг, снижение скорости выполнения запросов (на больших выборках фактически производилось полное сканирование таблиц). Поэтому если оценка необходимого объема выходила за эти цифры, для хранения данных всегда использовалась СУБД Oracle.
Второй критерий – возможность разделить архив на оперативный и «до востребования» – можно прочитать как необходимость реализовать секционирование на СУБД. Вплоть до 2016 года DLP-система Solar Dozor поддерживала секционирование исключительно на СУБД Oracle.
Мы понимали, что бюджеты заказчиков ограничены, и иногда они просто не могут позволить себе покупку лицензий Oracle. Поэтому в некоторых проектах с объемом хранения в 10-15 Тб мы стали использовать PostgreSQL.
Как мы реализовывали секционирование на PostgreSQL
Архитектура и возможности системы Solar Dozor позволяют подключать к ней любое количество баз данных как Oracle, так и PostgreSQL. При этом для каждой базы можно указать, можно ли производить по ней поиск или архивировать в нее сообщения. Поэтому сначала мы решили создавать несколько инстансов СУБД PostgreSQL на одном или разных серверах и поочередно записывать в них данные с периодом в 1 месяц. По истечении срока хранения самая старая база пересоздавалась – и так далее по кругу. Но это решение было довольно дорогим с точки зрения поддержки и подходило только очень узкому кругу заказчиков.
Следующая реализация секционирования данных тоже была построена на идее «одна секция – одна БД», но теперь все БД создавались в рамках одного инстанса PostgreSQL. Для всех операций работы с секциями были написаны соответствующие утилиты, и такая схема вполне неплохо работала у нескольких заказчиков. Опираясь на нее, некоторые даже мигрировали с Oracle.
Однако у этой реализации все же был ряд проблем, связанных с особенностями работы ряда сервисов в Solar Dozor. При большом количестве секций необходимо было держать одновременно более 1000 соединений на инстанс. Кроме того, было не очень удобно производить обновление схемы данных при выходе новых релизов.
В итоге мы решили использовать секционирование, которое предлагает нам сам PostgreSQL. То есть для всех таблиц, в которых присутствует ключ, ссылающийся на дату укладки сообщения, создаются наследованные таблички с ограничением по этому ключу. Укладывание данных в нужный набор таблиц производится по триггеру, который создается отдельно под каждую секцию. Такая схема дает нам весь необходимый функционал: при запросах поднимаются с диска только те секции данных, на период которых идет запрос; если необходимо вывести секцию из обращения, таблицы выводятся из наследования базовой, после чего делается их дамп. Для всех таких секций написаны утилиты для управления: перевод в оффлайн/онлайн, добавление, удаление, дамп и т.д.
Эта реализация стала реальной заменой Oracle, позволяя держать десятки терабайт данных в оперативном доступе и еще десятки – в архиве на более медленных системах хранения. Всем новым заказчикам мы предлагаем делать секционирование на PostgreSQL. Если уже существующий заказчик с секционированием на Oracle хочет перейти на PostgreSQL, мы предлагаем ему записывать новые данные в PostgreSQL, а старые оставить в Oracle до момента их устаревания.
Писать специальные процедуры миграции данных с Oracle на PostgreSQL мы сочли не целесообразным, потому что и сама их разработка, и непосредственно работы по миграции обходятся очень дорого, особенно если у заказчика есть отключенные данные каких-либо старых версий продукта. Да и запросов таких очень мало.
Чего удалось добиться с помощью секционирования БД в DLP-системе
Повышение производительности
В DLP-систему сохраняются все перехваченные сообщения. Для задач DLP важно знать, когда информация передавалась и была перехвачена. Таким образом, все перехваченные сообщения имеют четкую привязку к линии времени. Поэтому у нас используется RANGE-секционирование по дате перехвата, точнее, по дате поступления сообщения на обработку в DLP-систему как наиболее приближенного к моменту перехвата. Итак, при использовании секционирования данные разбивается на куски по временным периодам. Обычно используется период времени в одну неделю.
Какие преимущества может дать такая разбивка данных? Чаще всего запросы в рамках DLP-системы делаются в отношении весьма ограниченных, небольших периодов времени. Таким образом, если мы храним данные в течение 3-6 месяцев и запрашиваем информацию за 1-2-4 недели, мы существенно увеличиваем скорость работы решения уже за счет того, что с дисковой системы читается меньше данных. Понятно, что как на секционированной, так и на несекционированной схеме параллельно строится значительное количество разнообразных индексов, которые позволяют не производить полное сканирование таблиц и читать меньший объем данных с диска. Но здесь мы во многом оставляем на усмотрение оптимизатора БД, надо ли делать полное сканирование или лучше использовать индекс. Если же используется секционирование, мы всегда попадаем в довольно четкий кусок данных, занимающий ограниченный объем на диске.
Снижение нагрузки на администраторов
Скорость выполнения запросов является только одним из преимуществ использования секционирования. Еще один плюс – это возможность в разы упростить управление сроком хранения данных. Если секционирования нет, приходится ежедневно или еженедельно делать запрос на удаление старых данных, иначе при достижении определенных объемов БД начинаются проблемы с ее производительностью и обслуживанием. Секционирование позволяет свести удаление старых данных к более простой операции удаления конкретной секции. В Oracle для этого достаточно удалить с дисковой системы два табличных пространства секции и их файлы данных. В PostgreSQL необходимо удалить базы данных, созданные под эту секцию.
В ближайшем релизе Solar Dozor секционирование на PostgreSQL будет реализовано стандартным методом с использованием inherit-таблиц. Таким образом, в новой версии удаление секции будет сводиться к удалению таблиц, отвечающих за эту секцию.
Сокращение затрат на хранение данных
Большим преимуществом секционирования данных в DLP является возможность разделить архив данных на оперативный и так называемый «архив до востребования». В чем суть этого разделения?
Для большинства заказчиков важно иметь в прямом/оперативном доступе перехваченные данные за последние 3-6-12 месяцев. Все, что старше этого периода, некоторые вообще готовы удалять. Однако многие хотят сохранить эти данные, чтобы иметь возможность проводить расследования, опираясь на полный объем перехваченных сообщений. Это может быть продиктовано как внутренними стандартами безопасности компании, так и требованием соответствия ряду стандартов. Большие сроки хранения требуют от дисковой системы объемов в десятки терабайт. К тому же, для оперативного архива обычно проектируются SAS 10k диски, и набирать ими эти десятки терабайт довольно дорого. В секционированной схеме данные, которые выходят за период оперативной доступности, можно легко отключить от поисковой машины и разместить на более медленных и дешевых системах хранения. Ряд заказчиков покупает под хранение offline-архива SATA-диски, другие используют ленточные библиотеки, что особенно актуально при необходимости хранить 200-300 терабайт данных, которые понадобятся всего несколько раз за все время хранения. Реализовано это следующим способом:
Oracle:
Табличные пространства устаревшей секции переводятся в offline, после чего файлы данных этой секции переносятся на подготовленное для них хранилище. Когда возникает необходимость в поиске за период, относящийся к отключенной секции, файлы данных переносятся обратно, секция подключается, и можно производить по ней любые запросы. После этого секция отключается и убирается обратно.
PostgreSQL:
Устаревшая секция переводится в offline, далее делаем дамп (pg_dump) таблиц (или базы данных), отвечающих за данную секцию, и удаляем эти таблицы из БД. Дамп сохраняется в подготовленном offline-хранилище. Далее, по аналогии с Oracle, при востребованности этих данных производится восстановление удаленных таблиц из дампа (pg_restore). Секции переводятся в online, после чего можно делать по ним поиск. По окончании расследования секция переводится в offline, таблицы удаляются – место освобождается.
Чтобы осуществлять все эти операции отключения/подключения, не надо быть квалифицированным администратором СУБД Oracle или PostgreSQL. Для этого есть специализированные утилиты, которые позволяют смотреть состояние секций, подключать, отключать, удалять их и т.д. В случае с Oracle часть операций по отключению/подключению секций и переноса секций в другой каталог доступны непосредственно из веб-интерфейса. Автоматизация создания и отключения секций внутри СУБД снимает вопрос трудозатрат на обслуживание. Остаются только операции по копированию отключенных секций на подготовленные хранилища, но они не требуют специальной квалификации администраторов.
Итоги
В результате, благодаря секционированию в СУБД Solar Dozor, мы добились повышения производительности продукта и скорости поиска. Архив стал проще в управлении – перехваченные данные легко выгружать, освобождая дисковые ресурсы, и при необходимости загружать обратно. Все это делается в автоматическом режиме, поэтому нанимать отдельного квалифицированного специалиста для управления СУБД не нужно. Наконец, заказчик может хранить у себя данные за какой угодно период времени и при этом не сильно тратиться на систему хранения.
Автор: Solar Security
