Миграция в облако

Виды миграции в облако

При переносе ИТ-инфраструктуры в облако приложения, сервисы и данные меняют место своего обитания. Но прежде чем запустить процесс миграции, следует выбрать один из нескольких миграционных путей.

Итак, подытожим: в зависимости от размера организации и сложности инфраструктуры определяется, какой вид миграции следует выбрать:

Частичная (постепенная) миграция	Полная миграция
Выбирать постепенную, или частичную, миграцию следует тогда, когда в облако переезжает крупная компания с разветвленной инфраструктурой. Нескольких дней на переезд будет точно мало. В этом случае составляется дорожная карта, с указанием критичных и важных сервисов, учитывается приоритет переноса: какой сервис мигрирует первым, какой вторым, какие сервисы переносятся сразу, а какие могут подождать.	Полная миграция предусматривает перенос инфраструктуры компании за несколько дней. Здесь хоть и нет необходимости составлять дорожную карту, все же требуется определить главные или критичные сервисы. В этом случае составляется план работ, которого необходимо придерживаться. Как правило, процедура такой миграции занимает несколько дней.

Итак, подытожим: в зависимости от размера организации и сложности инфраструктуры определяется, какой вид миграции следует выбрать:

• В случае с малым и средним бизнесом, ИТ-инфраструктура которых достаточно простая, подойдет полная миграция.
• В случае с крупным бизнесом и сложной ИТ-инфраструктурой следует использовать вариант частичной миграции, в основе которой лежит принцип последовательного и постепенного переноса сервисов с обязательным использованием дорожной карты миграции.

Перед любой организацией, вставшей на путь переезда в облако, стоит единственная задача – повышение качества сервисов и снижение затрат на эксплуатацию. А поскольку миграция в большинстве своем возможна без остановки сервиса, это является ее выгодным преимуществом. Бесшовность, отсутствие шероховатости и прозрачность, достигаемая в условиях грамотно спланированного процесса переезда на облачную площадку, делают облако не решением, а настоящей стратегией.

Примеры миграции в облако

Сегодня можно найти большое количество кейсов, демонстрирующих успешную миграцию ИТ-инфраструктуры в облако IaaS-провайдера. В своих статьях мы часто публикуем истории успеха компаний, клиентов «ИТ-ГРАД», использующих облачные технологии для решения актуальных и востребованных задач. Одни используют облако в качестве дополнительной площадки, где размещены некритичные сервисы, другие – наоборот, полностью переносят инфраструктуру в облако с размещением жизненно важных для компании решений.

Delivery Club, абсолютный лидер российского рынка по заказу доставки еды, является примером компании, осуществившей перенос всех сервисов в облако провайдера. Поскольку заказ еды через интернет является достаточно востребованной услугой, наблюдался постоянный рост нагрузок на сервисы Delivery Club, что требовало быстрой реакции. Миграция в облако решила проблему. Теперь все сервисы компании виртуализированы и физические сервера перенесены на виртуальную машину.

Миграция инфраструктуры компании Delivery Club в облако IaaS-провайдера

Для Delivery Club облако оказалось выгоднее и удобнее в плане администрирования, поддержки и обеспечения отказоустойчивости. Миграция в облако позволила компании не задумываться о замене или покупке новых серверов, а динамическое управление всем пулом выделенных ресурсов оказалось не только выгодным, но и надежным решением.

Подробнее о миграции в облако IaaS компании Delivery Club

Автомобильный холдинг «Терра-авто» тоже выполнил последовательную, постепенную миграцию в облако провайдера и перенес сервера на виртуальную машину.

Миграция инфраструктуры компании «Терра-авто» в облако IaaS-провайдера

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

Подробнее о миграции в облако IaaS компании «Терра-авто»

Еще один яркий пример постепенной миграции в облако – поэтапная трансформация инфраструктуры компании NETFLIX , о которой мы рассказывали в одной из предыдущих статей . Процесс миграции занял несколько лет, поскольку пришлось полностью пересмотреть концепцию предоставления сервиса и отказаться от решений, размещенных в локальном ЦОД копании.

Миграция инфраструктуры NETFLIX в облако провайдера

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

Подробнее о миграции в облако IaaS компании NETFLIX

Ошибки и подводные камни миграции

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

Ошибка 1. Отсутствие схемы зависимости приложений

При миграции в облако следует уделить внимание схеме зависимости приложений друг от друга и инфраструктуры в целом. Результаты лучше всего отражать визуально в виде карты зависимостей. Допустим, приложения A, B, C используют одну и ту же базу данных. Следовательно, необходимо учесть это и проработать механизм комбинированного перемещения в облако. Если этого не сделать, велика вероятность некорректной работы приложения.

Пример схемы зависимости приложений

Ошибка 2. Отсутствие плана миграции

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

Ошибка 3. Запуск миграции без предварительных тестов

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

Общепринятая схема миграции в облако

Чтобы миграция прошла успешно, следует придерживаться общепринятой схемы, которая включает в себя разработку плана, создание инфраструктуры в облаке, миграцию данных, тестирование инфраструктуры и запуск сервисов в облаке. Помните, что для каждой компании переезд в облако – процесс индивидуальный и требующий отдельного внимания. Каждый этап подразумевает решение как технических, так и организационных вопросов.

Шаг 1.

На первом этапе требуется выполнить инвентаризацию существующего ИТ-окружения и определиться с моделью облака.

• Инвентаризация позволит оценить текущую картину имеющейся инфраструктуры. Сюда входит определение компонентов, какие из них являются важными, какие вспомогательными, как компоненты взаимодействуют друг с другом и так далее. Наличие такой документации облегчит процесс миграции и упростит задачу тестирования всех перенесенных в облако систем.
• Кроме того, необходимо заранее решить, какая облачная модель лучше подойдет для реализации проекта: публичное, частное или гибридное облако. Наиболее востребованной моделью использования облачного окружения среди большинства компаний является гибридное облако.

Шаг 2. На этом этапе происходит поиск, оценка и выбор облачного провайдера с последующим тестированием возможностей облачной площадки и выполнением тестовой миграции.

• Поиск и выбор поставщика услуг – достаточно серьезная задача, отнестись к которой необходимо со всей ответственностью. Вам необходимо удостовериться в надежности облачной площадки провайдера, убедиться, что она соответствует всем необходимым для реализации проекта требованиям.
• Тестирование облачной площадки и запуск процесса тестовой миграции – это то, чему следует уделить отдельное внимание. На этом этапе необходимо проверить функционал облака, выполнить частичную миграцию сервисов и убедиться в их стабильном, корректном функционировании. Частичный перенос и последующее тестирование приложений помогут оперативно выявить и устранить возникшие ошибки.

Шаг 3. План или дорожная карта миграции позволяют контролировать все выполняемые шаги на пути переезда в облако.

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

Шаг 4. После того как выполнены вышеуказанные шаги, можно приступать к процессу миграции, придерживаясь вышеупомянутой стратегии. Если переносимая инфраструктура сложная и разветвленная, следует двигаться поэтапно. Если перенос некоторых сервисов не удается разделить на части, полный переход является единственным вариантом переноса.

Шаг 5. Этот этап является заключительным, поскольку здесь выполняется проверка и тестирование перенесенных сервисов, а в случае отсутствия ошибок и успешности выполненного процесса – вывод сервисов в продакшен. Эта схема подходит при миграции рабочих нагрузок и ИТ-инфраструктуры как с физических, так и с виртуальных сред в виртуальную среду или облако хостинг-провайдера.

Способы миграции в облако

Существует несколько способов миграции в облако. Какой вариант подойдет именно вам, зависит от ситуации. Это может быть перенос физической ИТ-инфраструктуры в виртуальную среду, перенос локальной виртуальной инфраструктуры в облако, переезд из облака одного поставщика в облако другого провайдера, перенос сервера на виртуальную машину, перенос виртуальной машины на другой сервер. Ниже рассмотрим возможные варианты миграции более подробно.

Вариант 1: Импорт-экспорт vApp / VM

Этот вариант подходит для сценария, в котором уже существует виртуальная инфраструктура на базе VMware, но возникла необходимость переезда в облако хостинг провайдера. Поскольку виртуальное окружение VMware представляет собой набор виртуальных машин, заключенных в vApp, существует возможность мигрировать как одну, так и перенести несколько виртуальных машин на другой сервер.

Пример экспорта vApp

Поскольку отдельно взятая ВМ представляет собой набор виртуальных дисков, характеристик и конфигураций, все это возможно экспортировать в файл формата OVF/ OVA (унифицированный формат распространения готовых виртуальных машин), который позже используется для экспорта/импорта на платформу виртуализации VMware vSphere и не только. Таким же способом можно импортировать/экспортировать содержимое vApp.

Вариант 2: vCloud Connector

С помощью инструмента VMware vCloud Connector вы можете объединять облака различного формата и переносить виртуальные машины на другой сервер, vApp в облако хостинг-провайдера и обратно. Для этого необходимо выполнить связку соответствующих инфраструктур друг с другом и, используя интуитивно понятный графический интерфейс, запустить задачу, к примеру, копирования одной или нескольких виртуальных машин в облако поставщика.

Пример копирования ВМ из одного облака в другое, используя vCloud Connector

После успешного выполнения операции следует убедиться в корректности функционирования перенесенной инфраструктуры. Более подробно о работе с VMware vCloud Connector читайте здесь.

Вариант 3: Миграция на уровне сервисов

Миграция на уровне сервисов – еще один из наиболее часто используемых вариантов. Суть метода заключается в создании дублирующего сервиса на стороне хостинг-провайдера и запуска синхронизации с имеющимся сервисом, установленным локально. После того как процедура закончилась успешно, локальный сервис выводится из эксплуатации. Примером выступает миграция Active Directory, где применяется следующий алгоритм:

• Организуется сетевая связность между локальной инфраструктурой и облаком провайдера.
• На облачной площадке поставщика разворачивается необходимое количество новых виртуальных машин, в которых настраиваются контроллеры домена AD с до­бавлением их в имеющийся лес.
• Затем база данных Active Directory реплицируется с работающими контроллерами локальной инфраструктуры в облако.
• После завершения репликации данных переназначаются мастера ролей операций на облачные контроллеры и убираются роли контроллеров домена с серверов в локальной инфраструктуре.
• После проверки исправной работы сервисов отключаются учетные записи старых контроллеров, после чего они выводятся из локального использования.

Вариант 4: Конвертация, или «горячее» клонирование

Утилита vCenter Converter используется для выполнения переноса физического сервера в виртуальную машину, фонового копирования и переноса работающей операционной системы в облако провайдера. Поскольку в таком формате переносится работающий сервис физического узла, конвертация носит название «горячее клонирование». В процессе конвертации основной сервер продолжает работу и останавливается только на время переключения. При работе с VMware vCenter Converter необходимо выбрать, что будет конвертироваться. Основной метод работы подразумевает перенос работающего сервера (Powered-on machine), который может быть физическим или виртуальным.

Пример работы с инструментом VMware vCenter Converter

При корректном подключении VMware vCenter Converter понимает, какую операционную систему предстоит мигрировать, определяя при этом диски и разделы, сетевые интерфейсы, оперативную память и процессоры. Эти параметры используются для создания новой виртуальной машины на ESXi-хосте.

Вариант 5: Конвертация, или «холодное» клонирование

Помимо «горячего» клонирования, с помощью VMware vCenter Converter можно выполнять «холодное» клонирование, или офлайн-миграцию с остановкой сервера на время переноса сервера на виртуальную машину с физической. При таком варианте клонирования рабочая машина останавливается, создается образ жесткого диска и выполняется конвертация в ВМ. Для серверов Active Directory, баз данных, почтовых серверов рекомендуется использовать такой вид клонирования.

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

Вариант 6: Установка с нуля

Установка с нуля – еще один вариант миграции, распространенный на практике. Для этого в облачной инфраструктуре провайдера создается ВМ, на которую устанавливается ОС и необходимое ПО, а также конфигурируются требуемые сервисы. После чего выполняется переключение клиентов на использование нового сервера, а старый выводится из обихода.

При развертывании инфраструктуры в облаке на базе VMware предоставляется доступ к консоли vCloud Director, в которой формируется инфраструктура согласно требованиям проекта. Используя интуитивно понятный интерфейс, здесь создаются виртуальные машины, производится настройка сетевых параметров, конфигурация необходимых сервисов и другое.

Заключение

Поскольку сегодня многие компании отдают предпочтение облаку в модели IaaS , вопрос миграции на облачную площадку приобретает все большую и большую актуальность. Ускорить этот процесс и свести на нет возможные ошибки поможет правильно выбранная тактика, заранее определенная стратегия и соблюдение общепринятых рекомендаций.