Машины баз данных: сделано в России

Перед российскими предприятиями стоит целый ряд актуальных задач, связанных с обработкой данных. Среди них как общая потребность в ускорении и повышении качества этой работы, так и вопросы импортозамещения зарубежных продуктов, в том числе миграции как процесса. Один из наиболее перспективных подходов – применение программно-аппаратных комплексов (ПАКов) или машин баз данных. Несколько лет назад в этом сегменте лидировала компания Oracle со своими комплексами Exadata. Сегодня, после ее ухода, разработчик «Тантор Лабс» готов предложить заказчикам отечественные машины баз данных Tantor XData. Мы задали несколько вопросов генеральному директору вендора Вадиму Яценко.

— Как изменились за последние годы потребности бизнеса в оперативном получении и использовании данных?

— За последние два года все сильно поменялось: ушли западные вендоры, и в первую очередь это затронуло отрасль обработки данных. Дело в том, что большие объемы данных создавались, хранились, обрабатывались и использовались бизнесом на зарубежном оборудовании и с помощью импортного программного обеспечения. Когда все это исчезло с рынка, возник острый вопрос: а что же делать дальше, чем все это заменить?

— Почему в свое время, когда появились Oracle Exadata, машины баз данных стали настоящей революцией в индустрии работы с данными?

— На самом деле, когда компания Oracle представила свою первую линейку Exadata, она, по сути, сделала то, что до этого делал любой системный интегратор или сам заказчик в своем ландшафте. Сначала приобреталось оборудование. Оно подбиралось так, чтобы наилучшим образом отвечать системным требованиям, которые предъявляло ПО. Далее на это оборудование устанавливался софт, все это коммутировалось, интегрировалось в ИТ-инфраструктуру заказчика. И вот после такой длительной интеграционной работы заказчик получал СУБД и начинал работать со своими базами данных. Все это отнимало довольно много времени и влекло за собой большое число рисков. Ведь нужно было грамотно выстроить архитектуру такого решения, правильно заложить сайзинги, то есть понимать, как будет расти и масштабироваться БД в перспективе трех-пяти лет. Нужна была серьезная архитектурная проработка и значительные усилия для интеграции, а самое главное — все это требовало времени.

Поэтому компания Oracle в свое время фактически создала готовый комплекс «под ключ», хотя не она была пионером в этом направлении. До нее такие решения создавала IBM. А Oracle представила заказчикам готовый ПАК, машину баз данных, которая была готова к работе «из коробки». Заказчику оставалось только привезти эту коробку к себе в ЦОД или серверную, достать оборудование, подключить к электропитанию и сети, после чего можно было сразу приступать к работе с ним. Весь функционал был ему доступен сразу – без каких-либо интеграционных работ. Такой подход заметно сокращал и расход времени, и риски, и трудозатраты. Это не могло не понравиться заказчикам, ведь риски сводились к минимуму, и большую их часть компания Oracle брала на себя, к примеру, вопросы, связанные с сайзингом. В какой-то момент заказчик понимал, что ему не хватает возможностей имеющейся машины БД, и у Oracle была понятная и прозрачная схема, по которой можно было масштабировать отдельно аппаратный сервер, хранилище, софт и т.д. Такой подход привлекал заказчиков по всему миру.

Справедливости ради надо сказать, что первые модели Exadata не отличались сверхвысокой производительностью и значительно уступали машинам баз данных от IBM. Однако Oracle завоевала клиентов именно прозрачной и удобной моделью использования и масштабирования. Заказчики реально экономили затраты на поддержку, а вендор тем временем доводил свое решение до совершенства, до требуемого уровня. И сегодня Oracle Exadata – это очень серьезный продукт. На одном только российском рынке примерно за десять лет продано более тысячи экземпляров.

— СУБД существуют не один десяток лет. ПАК для работы с базами данных появились на рубеже 2010-х годов. Почему это не произошло раньше?

— Потому что в Oracle изначально выбрали подход, при котором софт практически неотделим от аппаратной части. Вы можете купить отдельно ПО у Oracle или партнеров компании, но на Exadata установлено именно такое ПО, которое специально написано для этого «железа», а оно подобрано по определенным спецификациям. Изначально производителем аппаратной части Exadata выступала HP Enterprise, но уже вторую линейку выпустили на оборудовании Sun Microsystems, которую Oracle поглотила. То есть уже со второго поколения Exadata оборудование, как и софт, делалось исключительно под нее, и вся архитектура в целом выстраивалась под конкретное оборудование.

Почему все это не могло появиться раньше? Возможно, потому что создать такие машины было сложнее, а еще свою роль сыграла популярность СУБД Oracle: на тот момент ее уже использовали значительно шире, чем DB/2 от IBM. Пользователи и заказчики, которые ранее работали с СУБД Oracle, достаточно позитивно восприняли машины баз данных.

Основная идея продаж Exadata звучала так: у вас есть БД Oracle, у вас проблемы с производительностью «железа» или софта, база данных стала «тяжелой» и «неповоротливой» – значит, вам нужна Exadata, причем все данные вы сможете перенести без каких-либо проблем с совместимостью. В итоге заказчик получал «из коробки» готовое решение с точно такой же БД, только работающей гораздо быстрее. Да и все вопросы масштабирования решались намного проще. До внедрения Exadata можно было «упереться» в ограничения, связанные с работой процессора, памяти, сетевого взаимодействия и т.д. Решение проблем, связанных с масштабированием – это очень важно. У заказчика есть горизонт планирования на 3-5 лет, нужно посчитать CAPEX и OPEX, и Oracle давала удобную и понятную схему масштабирования. Наконец, играл роль ценовой фактор: покупать Exadata было выгоднее, чем ПО и оборудование по отдельности, а также заниматься интеграцией. Вот благодаря всему этому eXadata стала самым распространенным в мире решением для обработки больших объемов данных.

— БД часто становятся «тяжелыми» и «неповоротливыми». Как понять, достаточно ли оптимизации программными средствами или уже пора покупать машину баз данных, чтобы перейти на новый уровень производительности?

— На постсоветском пространстве много хороших инженеров, а их рабочее время до недавних пор стоило относительно дешево. Еще несколько лет назад можно было услышать множество докладов и прочитать массу статей о том, как заказчик ускорил тот или иной процесс, связанный с обработкой данных, на несколько миллисекунд. Боролись буквально за каждую миллисекунду. На Западе подход был другой. Там инженерные кадры стоят дорого, а оборудование гораздо доступнее по цене, и проблему проще «завалить» «железом» – аппаратными ресурсами. Покупаем более мощное оборудование до тех пор, пока БД нормально работает. Как только «упираемся» в потолок, пора проводить программную оптимизацию. Иными словами, до последнего идет вертикальное масштабирование, а когда оно уже не дает результата, мы лезем в код. Вот это ключевой аспект, который отличает российский ИТ-рынок от западного.

— Давайте поговорим о вашем ПАКе Tantor XData. В чем его архитектурные особенности, благодаря чему он гарантирует высокие скорости обработки данных?

— Мы в какой-то степени ориентируемся на архитектуру Oracle Exadata: учиться нужным вещам у хороших учителей всегда полезно, так что некоторые архитектурные подходы, которые реализовали мы, сделаны с оглядкой на Oracle. Если говорить про то, как организована вычислительная часть, то у нас, как и в Exadata, есть несколько подсистем. Основная отвечает за хранение данных, выполнение запросов и все основные процессы, связанные с работой СУБД, а другая – за внутреннее резервное копирование и отказоустойчивость. Конечно, это не полноценная система резервного копирования (СРК), поэтому в любом случае необходимо интегрировать XData с внешней СРК. Есть еще управляющая подсистема для управления БД и оборудованием, а также мониторинга. Очень важную роль в работе всего комплекса играет сетевое оборудование, которое специально подбирается для разделения потоков данных, чтобы несколько операций могли выполняться, не мешая друг другу.

Самый простой пример. Есть InterConnect, на котором строится взаимодействие вычислительных модулей. При этом модуль резервного копирования работает со своей специально выделенной сетью, чтобы не мешать работе других подсистем. Внутренняя архитектура строится так, чтобы добиться производительности, сократить время RPO и RTO (простоя и восстановления) и обеспечить высокую скорость резервного копирования. Те проблемы, которые решаются архитектурой XData, можно решить и на стороне заказчика, но чтобы самостоятельно построить такой комплекс, потребуется много знаний и ресурсов. Мы разрабатываем специально для XData дополнительный специальный софт, который решает множество задач и доступен только вместе с ПАКом.

— По каким моделям и сценариям вы рекомендуете использовать XData?

— Мы рекомендуем три больших блока сценариев. Первый – это замена машин баз данных, которые использовались ранее, прежде всего это Oracle Exadata. Их много, и эту проблему надо решать, ведь вендор полностью прекратил их поддержку, обслуживание и поставку комплектующих. Если вспомнить те времена, когда компания Oracle только выходила на рынок со своими Exadata, она не могла на равных конкурировать с IBM, чьи машины тогда «переваривали» огромные объемы данных, но была способна замещать менее масштабные решения. Мы идем примерно по тому же пути и уже сегодня можем заменять Exadata с поддержкой БД объемом до 120 ТБ. Однако мы продолжаем развитие, чтобы в дальнейшем заменять и более производительные машины Oracle.

Второй блок сценариев касается работы «тяжелых» ERP-систем на платформе «1С». Сегодня многие заказчики внедряют продукты на «1С», из них ERP-система самая тяжеловесная по своим требованиям. Здесь тоже очень полезны были бы XData. Также сейчас очень востребованы сценарии перехода с SAP на «1С». Зачастую в процессе такой миграции монолитная система SAP делится на несколько узлов, на каждом из которых работает «1С» с собственной БД, и мы можем предоставить площадку для создания кластеров баз данных для «1С: ERP».

Третье направление применения XData – DBaaS, база данных как сервис. На российском рынке есть услуги по созданию БД в облаке, однако с точки зрения производительности здесь есть ряд сложностей. Чаще всего за основу берут ту или иную платформу виртуализации, а любая из них имеет ограничения. Не все заказчики готовы к такому, многие крупные компании построили себе частные облака, но они в большинстве случаев созданы по такому же сценарию, что и публичные, то есть с теми же ограничениями, например, по объему БД. Мы строим XData по другому принципу, поскольку не обязаны следовать общепринятым стандартам облачной архитектуры. Поэтому мы готовы предоставлять XData для частных облаков, когда необходимо обрабатывать большие БД и соблюдать жесткие требования в части RPO, RTO и др.

— XData будет предоставляться и из облака?

— Что такое XData из облака? Мы взяли на вооружение опыт вендоров, прежде всего уже многократно упомянутой компании Oracle. Несколько лет назад она начала продвигать на рынке свои Oracle Cloud Machine. По сути это та же самая Exadata, которая подключена к облаку Oracle и управляется им. Эта идея исходила из требований одного заказчика из госсектора США. Он хотел пользоваться машиной баз данных, которая, находясь на его территории и в его ЦОДе, подключена к облаку Oracle, а управлением и мониторингом должна была заниматься сама компания Oracle. С таким решением можно работать, как с сервисом, при каких-либо проблемах машина отключается от облака, но весь ее функционал остается доступным заказчику. Мы хотели бы использовать похожую модель для решения тех же самых задач. В нашей стране тоже есть заказчики, которые хотели бы работать с облаком, и мы готовы предложить им подобный сценарий с управляемой машиной XData, подключенной к облаку. Наша команда отвечает за обновления, поддержку и обслуживание, но физически машина находится в ЦОДе заказчика.

— Как XData работает со сторонними бизнес-приложениями? Как известно, компания Oracle сама выпускала этот софт, поэтому проблем с интеграцией практически не было. Как решается эта задача в случае с XData?

— Если мы говорим про миграцию бизнес-приложений для Oracle, MS SQL и других зарубежных СУБД, нам придется столкнуться с рядом вопросов, особенно если само это приложение не поддерживает бесшовную миграцию. Например, в «1С» такая возможность реализована. Конечно, если у заказчика были кастомные доработки поверх СУБД, придется приложить усилия, чтобы их учесть. Если заказчик использовал бизнес-приложение, которое не поддерживает бесшовную миграцию, или даже «самописное» решение, и ему необходимо перенести хранилище данных, потребуется серьезный труд. Но все решаемо.

— Чем XData может помочь бизнесу в цифровом эквиваленте?

— Я за свою жизнь поработал в различных компаниях, в том числе в промышленности и финансовом секторе. Если, к примеру, ПАК для виртуализации предназначен для решения инфраструктурных задач, проблем, понятных айтишникам, и повышения качества их работы, то машина баз данных всецело ориентирована на бизнес-заказчиков. Перед бизнесом сейчас остро стоит вопрос миграции с западных ERP-систем на «1С». Сама российская ERP у него есть, ему важно перенести базу данных с Oracle или MS SQL и уложиться в установленный регулятором срок. С этим вопросом заказчик приходит в ИТ-подразделение и в ответ нередко слышит, что необходимо приобрести оборудование, расширить штат инженеров, поскольку весь профильный персонал перегружен задачами импортозамещения. Наконец, он сталкивается с просьбой нанять дополнительных специалистов по поддержке БД либо переобучить тех, кто ранее поддерживал западные продукты.

Таким образом бизнес понимает, что он сильно зависит от сильно перегруженной ИТ-службы, и будет искать готовое решение, чтобы соблюсти сроки. Ведь как обычно происходит закупка в организациях? Оборудование и ПО закупается отдельно, занимаются этим разные люди, и они зачастую не пересекаются друг с другом. Затем в процессе интеграции со всех сторон обнаруживаются проблемы, которые очень сильно влияют на результат. Как в этой ситуации может помочь XData? Это уже готовое решение – включил и работай. Скорость получения конечного продукта – одна из ключевых ценностей XData. Кроме того, для бизнеса важно, что ответственность за работу такого решения полностью берет на себя вендор: мы гарантируем, что машина будет работать с должным уровнем качества и заявленной производительностью, а все возможные проблемы на стыке оборудования и ПО будут решены. Заказчик получает единую «точку входа» для любых обращений. Вот это и есть основные ценности для бизнеса, которые можно измерить в деньгах и времени.

Для ИТ-специалистов это тоже интересное предложение: оно снимает большой пласт проблем, ускоряет и упрощает путь предоставления бизнесу конечного продукта или сервиса.

— В каких отраслях XData могут быть особо востребованы?

— В первую очередь это финансовый сектор, второй важный сегмент потребителей – промышленное производство, энергетика и ТЭК. Все они обрабатывают большие объемы данных. Третья категория пользователей – телеком. Государство не так жестко регулирует эти компании, но они сами уже вполне осознают риск работы с западными вендорами и поэтому смотрят на отечественные продукты. А вообще, XData могут быть полезны в любых сферах, где имеется значительный объем данных и большое количество инстансов.

— Готовы ли XData для использования на предприятиях КИИ, которым уже пора переходить на российские решения?

— Машина баз данных содержит продукты «Группы Астра». Это и сертифицированная регуляторами по первому уровню доверия ОС Astra Linux, и СУБД Tantor, которая в данный момент проходит сертификацию во ФСТЭК по 4-ому классу. Также имеется дополнительное служебное ПО, его сертифицировать не обязательно, но мы будем и его подавать на сертификацию в составе всего ПАКа. Кроме того, сейчас XData включается в реестры Минпромторга и Минцифры. Если заказчику потребуется уровень защиты выше 4-го, то могу сказать, что мы работаем и над этим, например, в новую Astra Linux 1.8 включена СУБД Tantor c усиленными ИБ-функциями.

— Есть ли какие-то особые требования к подготовке данных, чтобы с ними могли работать машины XData?

— Особых требований нет. Чтобы, к примеру, использовать БД для хранилищ, нужно применять те паттерны загрузки данных, которые мы задействуем для этой задачи. Подходы те же, что и при обычной работе БД на привычном оборудовании, при этом мы, конечно, думаем о расширении функционала XData, в частности, для работы со смешанной нагрузкой. Мы планируем реализацию инструмента, который позволит организовать бесшовную миграцию на XData без downtime из существующих систем заказчика.

— Хотелось бы поговорить о производителе аппаратной части XData. У Oracle были свои ресурсы – компания Sun Microsystems, которую вендор купил. У «Группы Астра» собственного производства нет, оборудование делает «Аквариус». Как вы искали партнера и как организовано ваше взаимодействие?

— Компания «Аквариус» для нас не чужая, мы работаем с ней по разным проектам далеко не первый год. Хочется ли повторять опыт Oracle, поглотившего Sun Microsystems? Думаю, нет. Производство оборудования – сложнейший процесс, чтобы организовать и реализовать его на уровне «Аквариуса», нужно много усилий. Наше партнерство очень эффективно: коллеги инвестируют свои время и ресурсы в создание XData, не просто поставляют нам оборудование, а активно участвуют в решении разных вопросов. Это настоящая технологическая кооперация. Как вендор мы берем на себя всю техническую поддержку XData, но вопросы, связанные с «железом», решаем совместно с коллегами. У них широкая логистическая сеть и склады комплектующих, а инженеры всегда готовы приехать и помочь заказчику. Поддержка оборудования на протяжении всего его жизненного цикла – ключевой момент в нашем взаимодействии. Такое сотрудничество кажется нам наиболее правильным, и мы не планируем идти по пути создания собственного оборудования. Есть планы совместно с партнёрами разработать линейку машин баз данных на ARM-процессорах.

— Насколько XData готова к работе с «большими данными»?

— Если говорить про транзакционную и смешанную нагрузку, то один экземпляр БД на XData способен обработать до 50 ТБ данных, и таких экземпляров на XData может быть несколько. Что касается общего объема данных, то одна машина первого поколения поддерживает до 2,5 ПБ без учета репликации, а также около 3 ПБ под резервные копии. Мы можем работать с хранилищами емкостью 120 ТБ данных. Конечно, эти возможности будут расширяться с развитием продукта.

— Какие подходы и сценарии миграции с Oracle eXadata на Tantor XData вы как разработчик можете предложить?

— У нас уже есть ряд инструментов, которые позволяют переносить данные с СУБД Oracle на Tantor. Это совсем не просто, особенно если браться за дело без помощи вендора. Поэтому мы оказываем техническую поддержку, а также в ближайшее время анонсируем новый продукт, который поможет переносить данные без downtime в онлайн-режиме, т.е. без остановки.