Организация управляемой и безопасной миграции в облако

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

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

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

Для простоты все приводимые примеры будут касаться модели предоставления облачных сервисов IaaS — ее суть заключается в аренде ИТ-ресурсов у провайдера с последующей настройкой и установкой ПО силами ИТ-команды заказчика.

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

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

Частичная миграция в облако

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

Полная миграция в облако

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

Подготовка к миграции в облако

Итак, вы определились с четкой целью переезда в облако и выбрали провайдера. Что делать дальше?

Аудит

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

Определение схемы и инструментов миграции

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

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

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

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

Планирование миграции

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

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

В бой

Что ж, дело за малым — грамотно и в соответствии с планом перенести элементы ИТ-инфраструктуры. Это можно сделать самостоятельно или обратиться к команде провайдера. У крупных игроков, как правило, уже есть команда высококвалифицированных специалистов, которые обеспечат корректную миграцию систем. Например, в #CloudMTS для этих задач есть команда проектных решений: специалисты возьмут на себя аудит, планирование миграции, проработку архитектуры решения и обеспечат миграцию под ключ.

Что не нужно мигрировать в публичное облако

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

• Существует ряд приложений, для корректной работы которых требуется нетиповая конфигурация. Такие сервисы не стоит переносить в public cloud — вместо этого лучше рассмотреть вариант миграции в частное облако.
• Ряд бизнес-критичных высокопроизводительных систем также не стоит мигрировать, чтобы не потерять эффективность их работы. Проекты с особыми требованиями к производительности можно разместить в частном облаке провайдера, а для SAP и 1С — выбрать специализированный хостинг.
• Критические системы, остановка которых может нанести существенный вред организации, необходимо предварительно протестировать на работоспособность в облаке.
• Перенос в облако некоторых ИТ-систем может быть ограничен требованиями государственных регуляторов — например, для их размещения подойдут только специализированные виртуальные инфраструктуры. Рассмотрите аттестованное Облако 152-ФЗ для размещения ИСПДн и хостинг PCI DSS, если требуется безопасная обработка данных платежных карт.

Миграция между различными гипервизорами

Для переноса ВМ с одной платформы на другую вы можете сконвертировать их из формата одного гипервизора (например, Hyper-V) в любой другой с помощью специализированных программ. В этой статье мы не будем заострять внимание на работе с конкретными утилитами, и под занавес рассмотрим ключевые способы переноса инфраструктуры.

Существует три стратегии миграции в облако:

• Простой перенос

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

• Перенос с оптимизацией

Для повышения производительности можно мигрировать инфраструктуру не as it is, а с некоторыми изменениям: например, изменить сценарий взаимодействия ИТ-систем с базами данных.

• Замена сервисов

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

Самое важное в подготовке компании к облачной миграции — формализовать и структурировать все внутренние процессы. Оставшуюся часть задач (а в отдельных случаях и некоторый пул клиентских) могут взять на себя специалисты облачного провайдера. Перед началом процесса вы получите полноценную дорожную карту миграции, изучив которую вы сможете выявить и устранить все потенциальные сложности и узкие места