Нюансы миграции с западных СУБД

Антон Балагаев, директор по консалтингу Arenadata

Информационные системы, обеспечивающие деятельность и развитие российских предприятий из различных отраслей экономики, стали неотъемлемыми компонентами их деловой и производственной инфраструктуры.

В условиях обострения геополитических противоречий жизненно важной необходимостью становится импортозамещение. В области информационных технологий оно регламентируется рядом директивных документов регуляторов и стимулируется рыночной конъюнктурой. Замена зарубежных ИТ-продуктов отечественными является первоочередной задачей для госструктур и госорганизаций, особенно в тех случаях, когда ИТ-объекты относятся к критической информационной инфраструктуре

В настоящее время известные зарубежные вендоры объявили об уходе с российского рынка, и при выборе ИТ-решений отечественные предприятия всех видов собственности должны рассчитывать на поддержку российских разработчиков и интеграторов.

В компании Arenadata созданы продукты, способные замещать решения таких зарубежных вендоров, как Cloudera, Oracle (Exadata и Big Data Appliance), Teradata, Vertica и ряда других.

Программные решения Arenadata вошли в проекты миграции крупнейших российских организаций, включая ФНС РФ, Счетную палату России, ПАО «Газпром нефть», банк ВТБ, X5 Retail Group и ряд других.

На основе собственного опыта специалисты Arenadata разработали методические рекомендации по миграции с зарубежных преднастроенных инженерных систем (или программно-аппаратных комплексов, ПАК), содержащих оборудование и СУБД. Эти рекомендации относятся также и к миграции СУБД, не работающих в составе этих комплексов.

Эта статья поможет разобраться в нюансах переноса таких решений.

Задачи и трудозатраты

При переходе на отечественные продукты необходимо обеспечить продолжение работы приложений, созданных в рамках эксплуатации имеющихся систем. В процессе реализации проекта решаются следующие вопросы:

• формируется список вариантов проекта миграции;
• рассчитываются трудозатраты по миграции данных и процессов, определяются компетенции специалистов, составляется ресурсный план;
• выбирается оборудование с учетом сложившихся в новых условиях реалий.

Прикладные задачи, созданные для имеющейся системы, нужно локализовать и изменить таким образом, чтобы их можно было использовать после миграции. Обычно связанные с такими задачами разработки охватывают код СУБД, ETL/ELT-процессы и код приложений.

На долю кода СУБД приходится от 40 до 95% строк прикладных разработок. Это код запросов выполнения операций над данными — модификации данных, представлений и вывода информации. Самое важное в реляционных СУБД — код SQL, наиболее понятный объект приложения усилий при миграции.

ETL/ELT-процессы (0-60% строк) включают процессы загрузки данных, выполненные в ETL-инструментах, часто содержат исполняемый код, написанный на языке СУБД исходной инженерной системы.

Код приложений составляет от 0 до 15% строк. Несмотря на то, что приложения, которые обращаются к СУБД, обычно хранят только ссылки на объекты СУБД, они, тем не менее, могут содержать встроенный код.

Наработки, созданные для выполнения прикладных задач, содержат код различных функциональных типов, и изменения, необходимые для их дальнейшего функционирования, можно классифицировать следующим образом:

• преобразование метаданных, то есть служебных сведений, описывающих, как хранятся данные и влияющие на них объекты (в наиболее частых случаях — около 5% кода);
• изменение скриптового кода запросов и представлений, в том числе содержащихся в хранимых процедурах (75% кода);
• модификация функционального кода процедур, пакетов, функций и триггеров (20% кода).

Такие изменения выполняют и разработчики, и аналитики, объемы загрузки которых зависят от типа модифицируемого кода.

Обработка метаданных полностью осуществляется разработчиками, конвертирующими в целевой вид конструкции, уникальные для СУБД инженерной системы. Большая часть кода метаданных может быть обработана автоматически.

До 70% работы со скриптами выполняют аналитики, которые знают бизнес-задачи, понимают, что именно эти скрипты преобразуют и каким должен быть результат. Оставшиеся 30% — дело разработчиков, переписывающих коды в сложных случаях, к примеру, при изменении синтаксиса запросов.

Конверсия функционального кода на 70% осуществляется разработчиками, которые хорошо осведомлены о специфике работы алгоритмов преобразования. Остальные 30% приходятся на аналитиков, выполняющих документирование.

После получения новых метаданных, скриптов и функций проводится замена кода. Её выполняют разработчики и аналитики, усилия которых распределяются в соотношениях 70 и 30%, 70 и 30%, 100 и 0%.

Для объективной оценки сроков выполнения проекта миграции следует учитывать не только трудоемкий процесс переписывания кода, но и весь комплекс работ, трудозатрат и временных издержек, которые нужны для его реализации.

Как показывает опыт выполнения подобных проектов, перенос кода составляет основную часть трудозатрат, обычно до 80%. Далее следуют трудозатраты на вендорский или архитектурный надзор, верифицирующий правильность выполнения работ (8%), на настройку информационной безопасности (6%), на адаптацию регламентной документации (6%).

Наряду с этим необходимо предусмотреть временные затраты на обучение персонала (в среднем четыре человеко-дня на каждого специалиста) и пусконаладочные работы (до 10 человеко-дней с учетом всех согласований, включая вопросы размещения оборудования).

Трудозатраты зависят и от сценария проекта, то есть выполнения полной миграции или разгрузки существующей инженерной системы.

Полная миграция осуществляется при преобразовании, к примеру, аналитических хранилищ или озер данных, когда бизнес-приложение полностью переносится из одной системы в другую. В подавляющем большинстве проектов миграция такого типа выполняется для OLAP-задач.

Сегодня весьма актуальной становится разгрузка инженерных систем. Так, до сих пор многие организации не разделяли транзакционные и аналитические контуры, работавшие с единым хранилищем данных в комплексах Exadata. В нынешних условиях (из-за проблем с компанией Oracle и трудностей с приобретением новых машин баз данных) разгрузка Exadata позволит вывести на другую СУБД все, что относится к аналитическому контуру, и оставить на прежних комплексах хорошо себя зарекомендовавшие сервисы, которые работают в OLTP-режиме.

В обоих сценариях миграции выполняются примерно одни и те же работы. Однако при разгрузке дополнительно решается задача организации внутренних и внешних федераций данных.

Выбор оборудования

Длительность проекта миграции существенно зависит от конкретных условий его выполнения и требований заказчиков. Но при любом сценарии миграции нужно помнить, что для разных СУБД требуется различное оборудование. Поэтому повторно использовать имеющиеся аппаратные средства и обойтись без покупки нового оборудования удается не всегда.

Раньше подбор оборудования традиционно начинался с определения его типовой конфигурации для выполнения пилотного проекта. Как правило, это был небольшой кластер, сбалансированный по нагрузке на процессоры, память, диски и сетевые компоненты. Затем следовала модификация конфигурации для повышения производительности и выполнения SLA-соглашений. После этого производилась оптимизация суммарной стоимости владения системой.

В настоящее время, когда проекты миграции должны выполняться в весьма ограниченные сроки, такая классическая и хорошо себя зарекомендовавшая последовательность действий, к сожалению, практически неприменима. Нередки ситуации, когда новое оборудование вообще отсутствует.

И тогда, как правило, возникает желание все перенести в облака. Однако нужно учитывать, что публичные облака в большинстве своем не адаптированы к развертыванию кластерных систем. На основании опыта партнёров Arenadata, прошедших в процессе такой адаптации длинный путь, можно сказать, что это довольно длительный и трудоёмкий процесс.

Если получить новое оборудование невозможно, приходится использовать имеющееся. Это не лучший вариант, но его нужно иметь в виду. Здесь в первую очередь следует заняться сжатием, которое раньше, возможно, не включали из-за снижения быстродействия. Если увеличение задержек теперь становится приемлемым, то в результате сжатия может появиться возможность выполнить декомиссию части оборудования. Высвободившиеся ресурсы позволят пережить трудные времена.

Вместе с тем стоит проанализировать соответствие новым реалиям политик резервного копирования, катастрофоустойчивости и требований бизнеса. При разумном подходе можно высвободить часть мощностей хранения данных.

Кроме того, в исключительных случаях имеет смысл рассмотреть возможность отхода от лучших практик и объединения таких ранее разделенных сред, как разработка, тестирование, пользовательское тестирование, preproduction.

Дополнительные возможности предоставляет разгрузка инженерных систем за счет разделения аналитических и транзакционных задач. Сегодня для предприятий особенно важна долгосрочная стратегия непрерывности бизнеса, поэтому аналитические (как и некоторые другие) решения уходят на второй план. Их установка на менее производительное оборудование позволит повысить устойчивость наиболее критичных сервисов.

Освободившиеся аппаратные ресурсы можно использовать для СУБД с колоночным хранением, что значительно сокращает потребности в емкости хранения данных. Этот эффект усиливается современными алгоритмами компрессии и возможностью федерализации входящих и исходящих запросов для поддержки размещения данных в различных системах.

Чтобы исключить риски сбоев и отказов, для повторного применения оборудования имеющихся ПАК для новых задач следует тщательно проверить работоспособность их серверов с новым программным обеспечением. В частности, в тех случаях, когда предыдущее ПО содержит необходимые для работы оборудования драйверы, которые нельзя получить из других источников.

Если аппаратные средства не работают с новым ПО, то дальнейшее применение их компонентов — процессоров, оперативной памяти, дисков, RAID-контроллеров, сетевых карт — нужно рассматривать в контексте архитектуры нового ПО с учетом его узких мест и специфических требований.

Когда все же появляется возможность приобрести новое оборудование, необходимо учитывать, что его цена может быть выше, чем раньше. Поэтому вряд ли стоит ориентироваться на прежние парадигмы производительности. В новой ситуации целесообразно оптимизировать стоимость терабайта хранения данных, рассматривать конфигурации с большей емкостью дискового пространства на процессорное ядро и объем оперативной памяти.

Итак, переход на отечественные решения устраняет риски, связанные с потерей поддержки зарубежного ПО и запретом на приобретение новых лицензий. Чтобы проект миграции стал успешным, нужно заручиться поддержкой российского вендора и его партнеров, способных предложить оптимальное решение, сократить время выполнения проекта, обучить персонал и обеспечить непрерывную поддержку работы информационных систем.