Журнал "Information Security/ Информационная безопасность" #3, 2024

использования, поэтому разработку пол- ноценного инструмента типа Oracle Enter- prise Manager отечественные вендоры откладывали до лучших времен. Мы были отчасти первопроходцами и создали платформу Tantor – инструмент в помощь администратору PostgreSQL для эффективного управления СУБД и контроля ее состояния. – Что бизнес требует от рос- сийской СУБД? – Бизнес хочет отказоустойчивости, высокой производительности по сравне- нию с ванильной сборкой и доступности важных сервисов из коробки, например резервного копирования. Иногда заказ- чики формулируют свои потребности так: доделайте PostgreSQL, чтобы полу- чился Oracle. Но это утопическая идея, потому что невозможно один в один перетащить все технологии Oracle и PostgreSQL. Такой гипотетический комбайн будет работать нестабильно и с огромными ограничениями, это неправильный путь. Добавлять возможности, несомненно, нужно, но более осознанно, с оглядкой на специфику российского рынка. Напри- мер, в PostgreSQL нет автономных тран- закций, но к ним все привыкли, поэтому мы включили эту опцию в нашу сборку. Еще один пример. Очень часто, осо- бенно в финтехе, используются анони- мизация и маскирование данных в целях информационной безопасности. Мы раз- работали свой инструмент для реализа- ции таких возможностей, так как в опен- сорсном PostgreSQL их нет. Третий пример – повышение произво- дительности Tantor для работы с 1С:ERP. Недостаток производительности – острейшая проблема, которая мешает миграции с MS SQL на российские СУБД. Изучением данного вопроса зани- мается Центр компетенций 1С "Группы Астра", в рамках которого также осу- ществляется доработка ядра нашей СУБД для обслуживания 1С в сегменте Enterprise. – Какие есть способы повысить производительность СУБД? – Есть только два пути получения гарантированно высокой производитель- ности СУБД. Первый – это предоставление СУБД в облаке. Таким путем пошли многие западные вендоры: у Amazon появилась Aurora, у Google – AlloyDB, у Microsoft – Citus. Возможностей и производительно- сти OpenSource-версии не хватает, и эти компании доработали сборки для облака с расчетом на большие базы, высокие нагрузки и гарантированный SLA. Второй путь – программно-аппаратные комплексы (ПАК). Это то, что делал Oracle со своей Exadata. За 10 лет ПАК семейства Exadata широко распростра- нились на российском рынке; по разным оценкам, у нас в стране их более тысячи. Мы тоже пошли по этому пути и соз- дали ПАК Tantor XData, ведь на про- извольной инфраструктуре невозможно гарантировать нормальную работу базы данных. Продукт должен помочь рос- сийским заказчикам в миграции с Oracle Exadata и других подобных решений. Сейчас мы активно проводим испытания Tantor XData и предлагаем его на тесты заказчикам – на нашей площадке или внутри реальной инфраструктуры. – Какая автоматизация и инфор- мационная безопасность заложе- ны в XData? – Мы разрабатываем набор компо- нентов, которые целенаправленно пишутся для XData. Например, Tantor Appliance Manager отвечает за автома- тизацию внутри XData, управляет кла- стерами, деплоит их, управляет лимита- ми памяти, процессора и дискового ввода/вывода. Причем он может это делать динамически, без остановки сер- виса СУБД. Невозможно также представить про- граммно-аппаратный комплекс в отрыве от информационной безопасности, осо- бенно учитывая, что ПАК используются в составе объектов КИИ. XData построен полностью на нашем программном обеспечении, в частности на операционной системе Astra Linux с самым высоким уровнем защиты информации. Кроме того, СУБД Tantor прошла сертификацию в соответствии с актуальными требованиями ФСТЭК России. Таким образом, мы имеем все возможности дорабатывать наш продукт с точки зрения безопасности. Уже сей- час он достаточно закрыт: в XData есть всего один внешний интерфейс, кото- рый позволяет взаимодействовать в ПАК, все остальные компоненты защи- щены во внутреннем периметре устрой- ства. С использованием в нашем программ- но-аппаратном комплексе дополнитель- но наложенных средств защиты без- опасность базы данных станет еще более надежной, и мы уверенно движемся в этом направлении, привлекая партнеров по ИБ-рынку. – Как решается вопрос с про- изводительностью в XData? – Весь софт для ПАК должен быть собран определенным образом, и про- граммное обеспечение, которое рабо- тает на этом оборудовании, должно учи- тывать специфику и архитектуру исполь- зуемого железа. Производительность ПАК в первую очередь зависит от оборудования: даже самые мощные серверы имеют опреде- ленный вычислительный предел. Поэто- му приходится решать вопрос масшта- бирования на уровне программного обес- печения. Мы делаем это с помощью добавления новых реплик и масштаби- руем комплектами по три сервера. К сожалению, кластеризация Active- Active сложно реализуется в PostgreSQL, поэтому многие используют механизмы шардирования. Но, как показала практика, шардирование в PostgreSQL очень сложно поддерживать, оно требует специальных навыков и доработок программного обес- печения бизнес-приложений. В идеале хотелось бы получить HTAP- систему (Hybrid Transactional/Analytical Processing), которая способна работать с гибридной нагрузкой. Многие заказ- чики привыкли к этому, пока использо- вали Oracle Exadata. – Как организуется резервное копирование в XData? – Программно-аппаратный комплекс должен иметь систему резервного копи- рования (СРК), это один из важнейших компонентов обеспечения отказоустой- чивости СУБД. Бэкапы также исполь- зуются для механизма Disaster Recovery. Поскольку XData в первую очередь наце- лен на мощные базы данных и на боль- шое их количество в одном ПАК, то вопрос резервирования стоит очень остро. Главная проблема – время резервного копирования больших баз. Традиционные системы резервного копирования обычно бэкапят со скоро- стью порядка 1 Тбайт/ч, что, конечно же, неприемлемо для баз объемом в десятки терабайт. Поэтому внутри XData работает своя система резервного копирования, кото- рая главным образом ориентирована на производительность. Уже сейчас под- твержденная тестированием на близких к реальным кейсам скорость резервного копирования составляет 10 Тбайт/ч. То есть полноценный бэкап базы данных в 50 Тбайт будет создан за 3–5 часов, а инкрементальный пройдет еще быстрее. На синтетических тестах мы достигали и более высоких скоростей – до 20 Тбайт/ч. Восстановление – это вторая пробле- ма, которую мы решаем. В XData реали- зован трехузловой кластер и необходимо воссоздавать реплики в случае падения ноды, а речь идет о потенциально очень больших базах. Поэтому у нас есть спе- циальные режимы catchup, чтобы быстро восстанавливаться и иметь возможность работать с кластером, даже если какая- либо нода вышла из строя. Отмечу, что мы не подменяем собой централизованную систему резервного копирования в организации. Встроенные в XData механизмы бэкапа используются в первую очередь для обеспечения ско- рости. Под резервные копии внутри XData выделено 3 Пбайт – достаточно большой объем, если учитывать, что копии сжи- маются. По оценочным расчетам, это позволяет хранить резервные копии за неделю или даже больше в зависимости от баз данных. А дальше копии можно переносить на любую централизованную 12 • В ФОКУСЕ