Антон Балагаев
Директор по консалтингу Arenadata
Задачи и трудозатраты
При переходе на отечественные продукты необходимо обеспечить продолжение работы приложений, созданных в рамках эксплуатации имеющихся систем. В процессе реализации проекта решаются следующие вопросы:- формируется список вариантов проекта миграции;
- рассчитываются трудозатраты по миграции данных и процессов, определяются компетенции специалистов, составляется ресурсный план;
- выбирается оборудование с учётом сложившихся в новых условиях реалий.
На долю кода СУБД приходится от 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-задач.
Сегодня весьма актуальной становится разгрузка инженерных систем (offload). Так, до сих пор многие организации не разделяли транзакционные и аналитические контуры, работавшие с единым хранилищем данных в комплексах Exadata. В нынешних условиях (из-за проблем с компанией Oracle и трудностей с приобретением новых машин баз данных) разгрузка Exadata позволит вывести на другую СУБД всё, что относится к аналитическому контуру, и оставить на прежних комплексах хорошо себя зарекомендовавшие сервисы, которые работают в OLTP-режиме.
В обоих сценариях миграции выполняются примерно одни и те же работы. Однако при разгрузке дополнительно решается задача организации внутренних и внешних федераций данных.
Выбор оборудования
Длительность проекта миграции существенно зависит от конкретных условий его выполнения и требований заказчиков. Но при любом сценарии миграции нужно помнить, что для разных СУБД требуется различное оборудование. Поэтому повторно использовать имеющиеся аппаратные средства и обойтись без покупки нового оборудования удаётся не всегда.Раньше подбор оборудования традиционно начинался с определения его типовой конфигурации для выполнения пилотного проекта. Как правило, это был небольшой кластер, сбалансированный по нагрузке на процессоры, память, диски и сетевые компоненты. Затем следовала модификация конфигурации для повышения производительности и выполнения SLA-соглашений. После этого производилась оптимизация суммарной стоимости владения системой.
В настоящее время, когда проекты миграции должны выполняться в весьма ограниченные сроки, такая классическая и хорошо себя зарекомендовавшая последовательность действий, к сожалению, практически не применима. Нередки ситуации, когда новое оборудование вообще отсутствует.
И тогда, как правило, возникает желание всё перенести в облака. Однако нужно учитывать, что публичные облака в большинстве своём не адаптированы к развёртыванию кластерных систем. На основании опыта партнёров Arenadata, прошедших в процессе такой адаптации длинный путь, можно сказать, что это довольно длительный и трудоёмкий процесс.
Если получить новое оборудование невозможно, приходится использовать имеющееся. Это не лучший вариант, но его нужно иметь в виду. Здесь в первую очередь следует заняться сжатием, которое раньше, возможно, не включали из-за снижения быстродействия. Если увеличение задержек теперь становится приемлемым, то в результате сжатия может появиться возможность выполнить декомиссию части оборудования. Высвободившиеся ресурсы позволят пережить трудные времена.
Вместе с тем стоит проанализировать соответствие новым реалиям политик резервного копирования, катастрофоустойчивости и требований бизнеса. При разумном подходе можно высвободить часть мощностей хранения данных.
Кроме того, в исключительных случаях имеет смысл рассмотреть возможность отхода от лучших практик и объединения таких ранее разделённых сред, как разработка, тестирование, пользовательское тестирование, preproduction.
Дополнительные возможности предоставляет разгрузка инженерных систем за счёт разделения аналитических и транзакционных задач. Сегодня для предприятий особенно важна долгосрочная стратегия непрерывности бизнеса, поэтому аналитические (как и некоторые другие) решения уходят на второй план. Их установка на менее производительное оборудование позволит повысить устойчивость наиболее критичных сервисов.
Освободившиеся аппаратные ресурсы можно использовать для СУБД с колоночным хранением, что значительно сокращает потребности в ёмкости хранения данных. Этот эффект усиливается современными алгоритмами компрессии и возможностью федерализации входящих и исходящих запросов для поддержки размещения данных в различных системах.
Чтобы исключить риски сбоев и отказов, для повторного применения оборудования имеющихся ПАК для новых задач следует тщательно проверить работоспособность их серверов с новым программным обеспечением. В частности, в тех случаях, когда предыдущее ПО содержит необходимые для работы оборудования драйверы, которые нельзя получить из других источников.
Если аппаратные средства не работают с новым ПО, то дальнейшее применение их компонентов — процессоров, оперативной памяти, дисков, RAID-контроллеров, сетевых карт — нужно рассматривать в контексте архитектуры нового ПО с учётом его узких мест и специфических требований.
Когда всё же появляется возможность приобрести новое оборудование, необходимо учитывать, что его цена может быть выше, чем раньше. Поэтому вряд ли стоит ориентироваться на прежние парадигмы производительности. В новой ситуации целесообразно оптимизировать стоимость терабайта хранения данных, рассматривать конфигурации с большей ёмкостью дискового пространства на процессорное ядро и объём оперативной памяти.
Итак, переход на отечественные решения устраняет риски, связанные с потерей поддержки зарубежного ПО и запретом на приобретение новых лицензий. Чтобы проект миграции стал успешным, нужно заручиться поддержкой российского вендора и его партнёров, способных предложить оптимальное решение, сократить время выполнения проекта, обучить персонал и обеспечить непрерывную поддержку работы информационных систем.
Источник: статья опубликована в издании «Компьютерный мир» (ИД «Открытые системы)
Всегда на связи. Узнайте больше о миграции иностранных СУБД на решения Arenadata
Специалисты Arenadata и сертифицированные партнёры компании имеют релевантный опыт миграции с иностранного ПО. Оставьте заявку на бесплатную консультацию по вопросам миграции с западных СУБД!