Разделы

ПО Бизнес Импортонезависимость Облака

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

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

В последние три месяца бизнес активно переезжает из облака в облако. «С появлением труднообходимых рисков заказчики начали беспокоиться, что западные поставщики могут отказать в сервисах. Запросы на миграцию с зарубежных облаков на российские стали массовыми. И их спектр максимально широк: интересует и переезд всей инфраструктуры и приложений как есть, и замена приложений на российские аналоги и перенос приложений из 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.

Наталья Николаева