Переезд из облака в облако без проблем — такое бывает?18.07.2022 13:00

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

В последние три месяца бизнес активно переезжает из облака в облако. «С появлением труднообходимых рисков заказчики начали беспокоиться, что западные поставщики могут отказать в сервисах. Запросы на миграцию с зарубежных облаков на российские стали массовыми. И их спектр максимально широк: интересует и переезд всей инфраструктуры и приложений как есть, и замена приложений на российские аналоги и перенос приложений из on-premise в облако из-за нехватки оборудования», — рассказывает Вячеслав Медведев, руководитель направления облачных решений «Инфосистемы Джет».

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

Вот только после выбора провайдера начинается самое интересное — миграция приложений. В этой статье мы рассмотрим три самых распространенных проблемы.

Перенос инфраструктуры Microsoft

Большинство компаний используют продукты Microsoft в своей локальной инфраструктуре. Служба каталогов Microsoft Active Directory, почта Exchange, ПО для совместной работы SharePoint, серверная ОС Windows Server, СУБД MS SQL — что-то из этого списка встретится почти у всех. Сегодня лицензии на это ПО в России продолжают предоставлять в аренду многие облачные провайдеры. Кто-то из них предлагает только базовый набор лицензий (Windows Server, SQL Server, RDS), у других список больше, но они не готовы предоставлять в аренду лицензии Microsoft новым клиентам — только уже существующим. Ситуация неоднородна и грозит измениться в любой момент.

Что можно предпринять в этом случае? Переходить на отечественное ПО, потому что, например, переезжая из зарубежного облака, придется разворачивать сервисы с нуля. Таких кейсов много. Чаще всего этот путь избирают российские отделения западных компаний, которые переносят свою ИТ-инфраструктуру и данные из-за границы, но головной офис не спешит делиться всем, что необходимо. «Недавно мы искали решение такой задачи для российского филиала европейской компании, — делится Вячеслав Медведев. — Филиал пользовался сервисами, созданными и обслуживаемыми за рубежом. И решил переехать на серверы в РФ, но при этом не мог забрать из западного облака нужные данные и мигрировать в прозрачном режиме. Заказчик просил нас помочь выбрать облачного провайдера, чтобы он был оптимальным по стоимости аренды, и чтобы можно было разместить у него необходимые сервисы. Но главное — компании нужно было забрать данные, которые остались «в ведении» штаб-квартиры. Все данные мигрировать было невозможно, однако мы смогли забрать те из них, которые можно перенести с юридической точки зрения: список пользователей, их прав и прочее». Отечественные аналоги ПО могут быть не столь функциональны, непривычны для пользователей, но основные корпоративные потребности они способны закрыть.

Пока еще доступен вариант остаться на ПО от Microsoft. У компаний, которые по разным причинам не могут перейти на отечественное ПО, но переезд в облако запланирован, лицензии Microsoft должны быть не старше двух поколений. Кроме того, они также должны попадать под программу License Mobility производителя. То есть переехать в облако с лицензиями, купленными лет десять назад, уже не получится. Помимо сложности с лицензиями, есть еще одна — резервное копирование. У одних провайдеров резервное копирование реализовано на уровне виртуальных машин, у других есть встроенные возможности Backup as a Service, позволяющие выполнять резервное копирование на уровне приложений внутри виртуальных машин. Со своей стороны, если необходимо, облачные консультанты могут разворачивать свою систему резервного копирования на основе IaaS-сервисов провайдера и доступного на сегодняшний день ПО.

«Такой переезд не будет простым. А раз тяготы и лишения неизбежны, то, возможно, стоит поступить радикально и перейти на другие решения. Например, зачем использовать именно MS Exchange или Skype? Здесь точно возможна замена. Сервисов ВКС в России уже немало. А привычный почтовый функционал от MS можно заменить на доступные аналоги: Мой Офис, CommuniGate Pro, VK WorkSpace. Со своей стороны мы рекомендуем, что лучше заменить, каким образом, и у какого облачного провайдера разместиться с учетом сегодняшних и завтрашних потребностей», — отмечает Вячеслав Медведев.

Смена инструментов аналитики и работы с данными

Сложности переноса данных из облака в облако связаны с тем, что стек технологий работы с данными у провайдеров разный. А значит, при переезде потребуется адаптация. «Нужно не только перенести сами данные, но и адаптировать, правильно написать SQL-запросы, трансформировать данные. Важно также правильно спроектировать архитектуру, обеспечить сайзинг, потому что на одной базе данных — одна нагрузка на оборудование, на другой — другая. Это очень большой объем работ», — рассказывает Станислав Шлишевский, руководитель направления продвижения центра управления данными «Инфосистемы Джет».

Интегратор сам пишет инструменты для переноса данных. Причем делается это под каждую конкретную задачу. Но и специальные инструменты не всегда помогают. «Недавно мы прорабатывали случай, когда клиент переезжал с одной базы данных на другую. Практически всё потребовалось делать вручную. Получилось, что нужный объем работ дороже, чем закупка «железной» обвязки, и займет около года», — говорит Станислав Шлишевский.

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

Миграция СУБД

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

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

«Чтобы понять, стоит ли затевать миграцию с одной платформы на другую, первым делом нужно детально обследовать БД, — отмечает Алексей Перегудов, руководитель направления БД «Инфосистемы Джет». — Узких моментов много, но в целом можно выделить четыре блока. Проверяется, есть ли унаследованные и полностью устаревшие системы, которые точно больше никогда не будут поддерживаться вендором. Есть ли вендорские решения, от которых невозможно отказаться. Анализируется сложность кода и, наконец, проводится инвентаризация и проверка всех точек, которые интегрированы со смежными системами».

Чтобы гарантировать работоспособность приложения с новой базой, нужно найти и проанализировать весь код, взаимодействующий с СУБД. «Мы смотрим, что находится внутри базы данных. Потом анализатором собственной разработки отлавливается код, который не хранится в базе, а исполняется снаружи каким-либо приложением. Так мы иногда обнаруживаем, что, кроме обычных хранимых процедур, у нас есть еще несколько миллионов строк кода в приложении, которые понадобится адаптировать при миграции БД. Если база данных признана пригодной к миграции, то строится полноценная тестовая инфраструктура со всеми интеграциями нужных приложений. Туда и производится начальная миграция — всё в рамках тестов. Если нужно, то переписывается и код», — подытоживает Алексей Перегудов.

Легкость использования облаков не оборачивается легкостью миграций в них. Это тем более справедливо для сегодняшней ситуации, когда так сильно поменялись правила игры и миграция подобного на подобное — редкое исключение. «Настоящие запросы со стороны клиентов сдвинули фокус облачного консалтинга. Раньше он был в области поиска оптимального провайдера и в интересе передать внешним экспертам задачи, до которых не доходили руки. Теперь он сместился в сторону запроса помощи по новым вызовам. Компании ищут экспертизу по вопросам, которые до сих не возникали, и на них нет однозначных ответов, — резюмирует Вячеслав Медведев. — В этой парадигме облачные консультанты способны принести ощутимую пользу».

Проконсультироваться по вопросам миграции в облако можно с экспертами Jet CloudLab cloudlab@jet.su.

Полный текст статьи читайте на CNews