Как стать автором
Обновить
138.26
MWS
Больше, чем облако

Миграция в три шага, волшебные кнопки и обезболивающие

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров1.9K

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

В 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.

Теги:
Хабы:
Всего голосов 13: ↑11 и ↓2+16
Комментарии0

Публикации

Информация

Сайт
mws.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия