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

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

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

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

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

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

Частичная (постепенная) миграция

Частичная (постепенная) миграция

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

Полная миграция

Полная миграция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Импорт-экспорт vApp / VM

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

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

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

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

Вариант 2: vCloud Connector

vCloud Connector

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

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

Пример копирования ВМ из одного облака в другое, используя 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

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

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

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

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

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

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

Установка с нуля

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

При развертывании инфраструктуры в облаке на базе VMware предоставляется доступ к консоли vCloud Director

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

Заключение

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

Поделиться в социальных сетях

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...