Мы регулярно рассказываем, как облачный инструментарий помогает оптимизировать хранение данных, ускорить доставку контента, оцифровать рабочие места. Всем этим процессам зачастую предшествует один — миграция инфраструктуры.
В 2007 году, как показало исследование Bloor Research, 80% проектов по миграции оканчивалось неудачей, или обходилось куда дороже, чем планировало руководство компании. Спустя 15 лет, по данным Forbes, 64% компаний по-прежнему превышает бюджеты на миграцию, и всего 16% укладываются в спрогнозированные временные рамки.
Может ли на этом фоне провайдер предложить волшебное однокнопочное решение «Мигрировать», которое подарит исключительно позитивный опыт переноса данных? На что обратить внимание, как подойти к задаче — в нашем сегодняшнем материале.
Обезболивание: управляемая и безопасная миграция
Основная причина неудачного перехода в облако — плохое планирование. Если не проработать схему переноса инфраструктуры, заказчик столкнется с задержками и сбоями.
Чтобы не терять данные и избежать простоя, нужно учесть следующие аспекты миграции.
Планирование
Чем детальнее прописан план миграции, тем успешнее переезд. Нужно заранее учесть простои и прописать шаги на случай отката. В плане учитываются:
все взаимосвязи между ИТ-системами (например, служб Active Directory, CRM, почты и т. д.)
изменения в объеме данных за день, неделю, месяц;
дизайн сети;
требования ИБ и регуляторов;
лицензии на ПО и аппаратные комплексы.
Тестирование
Даже если клиент и облачный провайдер на 100% уверены в подходе к миграции, стоит поднять тестовые машины. Это поможет проверить скорость передачи данных, познакомиться с облаком и его инструментами, оценить безопасность подключения к ВМ из внешних сетей. При этом точки входа к системам на проде для клиента не меняются. Тестирование также необходимо для оценки слаженности работы вовлеченных в процесс ИТ-специалистов.
Простой
Бесшовная миграция ≠ беспростойная. Допустим, во время переноса данных «просел» канал у интернет-провайдера клиента, миграция выходит за указанный временной интервал. Тогда перенос откладывается или включается откат.
Универсальной формулы расчета времени простоя не существует, но предсказать примерное время в каждом конкретном случае вполне реально. После аудита мы понимаем, сколько есть бизнес-критичных приложений, какой объем данных у клиента. Во время тестирования оцениваем простой таких систем и на основании этих данных строим прогноз. Благодаря этому, представители клиента могут заранее согласовать простой с бизнес-юнитами, и подготовиться к нему.
Все процессы прямо говорят о том, что в этом комплексе работ нет волшебных кнопок.
Планирование, подбор инструментов, тестирование и поэтапный перенос — вот, что помогает клиентам переезжать в облако с любой площадки. Причем самые сложные кейсы связаны не с инфраструктурой и сервисами как таковыми, а с большими объемами постоянно изменяющихся данных. Чем больше данных, тем тщательнее должна быть проработана стратегия миграции.
Переход в облако по шагам: на что обратить внимание
Шаг 1: аудит
Успешная миграция начинается с аудита: необходимо составить список имеющихся серверов / сетевого оборудования и собрать данные о переносимых приложениях. Заказчику важно учесть нюансы, связанные с лицензиями — некоторые из них привязываются к оборудованию и могут перестать работать в облаке.
Определение очередности переносимых приложений (они ранжируются по критичности простоя) — это совместная работа сервис-провайдера и заказчика. Клиент лучше любых внешних специалистов знает особенности своих систем.
Мы плотно взаимодействуем с заказчиком, заполняющими опросный лист, чтобы сразу выявить потенциальные подводные камни. Например, если доступа к виртуализации нет, нужно будет мигрировать с помощью инструментов резервного копирования.
Шаг 2: план
Когда нарисован инфраструктурный ландшафт, можно переходить к составлению плана миграции (например, в формате блок-схем).
Здесь возможны несколько вариантов:
полная миграция — в облако переносят все приложения вместе с настройками;
частичная миграция — только часть сервисов переходят в публичное облако — занимает больше времени, так как требует углубленного анализа зависимостей приложений.
План также нужен, чтобы установить порядок и время миграции в облако. Необходимо определить часы перехода, когда нагрузка на сервисы минимальна, а также уточнить другие нюансы: например, некоторые приложения можно переносить только одновременно. Хорошей идеей будет провести резервное копирование компонентов инфраструктуры.
Непосредственно технологии миграции подбираются в зависимости от спектра сервисов клиента. Можно использовать нативные утилиты систем виртуализации — например, VMware Cloud Director Availability, когда у клиента инфраструктура построена на VMware — или воспользоваться встроенными средствами переносимых приложений.
Шаг 3: собственно, переезд в облако
Инженеры иногда используют выражение «миграция в ад» — когда виртуальная машина уже покинула корпоративный сервер, но из-за стечения обстоятельств не «доехала» до облака и пропала безвозвратно. Чтобы оценить консистентность данных, избежать неприятных казусов, стоит провести тестовую миграцию.
Очередность переноса в «боевой» миграции устанавливается еще на этапе планирования. Однако начинать все же стоит с некритических сервисов. Наиболее значимые приложения мигрируют в последнюю очередь.
Если по форс-мажору возник простой — например, как упоминалось выше, «просел» канал у интернет-провайдера клиента — заказчик может решить отложить процедуру. Реакция на случайные события прописывается заранее — всегда должен быть заранее составленный план А, B, C…, учитывающий интересы бизнеса.
Оценить работу сервисов в новых условиях помогут финальные тесты — на этот этап в плане миграции тоже закладывается время, которое зависит от аспектов работы перемещенной ИТ-инфраструктуры.
Сроки
На аудит и составление плана уходит от трех дней — точные сроки зависят от компании и масштабов ее инфраструктуры. Непосредственно миграция может пройти за несколько дней (плюс потребуется время на настройку политик безопасности).
На «час Х» завершения миграции влияют разные факторы — результаты нагрузочного тестирования, приёмо-сдаточные испытания и т. д. Дни, недели, месяцы часть машин могут работать на площадке клиента, часть — уже в облаке, а некоторые — синхронизируются и в облаке и на локальной площадке.
В нашей практике есть кейс — мы помогли BMI Russia перенести систему управления ресурсами SAP ERP в наше облако. Проект завершили за две недели — с аудитом, разверткой инфраструктуры и переносом данных. Тестовая миграция ERP и сервера управления печатью показала, что все работает в штатном режиме. Финальную миграцию проводили в нерабочее время — она заняла несколько часов.
Другой пример — сеть магазинов одежды MODIS, которая перенесла свою систему управления базами данных от оператора облачных ресурсов во Франкфурте на нашу виртуальную инфраструктуру в Санкт-Петербурге. Сам процесс миграции занял один день. Еще день потребовался для стабилизации и проверки ошибок на уровне прикладного ПО.
Проектная команда CloudMTS, нашего технологического партнера NDBC и MODIS согласовала план, этапы и длительность миграции в соответствии с функциональными требованиями. Из-за ограничений со стороны зарубежного сервис-провайдера по пропускной способности каналов связи перенос базы данных был разделен на несколько этапов. В ходе первого этапа создали полную резервную копию SAP-системы на стороне немецкой компании, потом перенесли эту копию на площадку заказчика, а затем восстановили базу данных в нашем дата-центре на предварительно подготовленную инфраструктуру.
Чтобы получить расчет стоимости и сроков управляемой миграции в облако для вашего проекта, переходите на сайт.
Что еще необходимо уточнить
В первую очередь — возможные ограничения. Если не принимать во внимание сценарий, когда компании вообще запрещено мигрировать в облако (это касается некоторых госкомпаний), остаются кейсы, когда бизнесу необходимо выполнять требования регуляторов. Например, при работе с финансовыми данными клиентов необходимо уточнить у сервис-провайдера, предоставляет ли он виртуальную инфраструктуру в соответствии со стандартом ГОСТ 57580.