Этапы переноса инфраструктуры в облако
Каждый из этапов имеет свои нюансы, знание которых позволит не допустить ошибок.
Перенос инфраструктуры в облако — это поэтапный процесс, который осуществляется совместными усилиями компании-заказчика и облачного провайдера. В большинстве случаев переезд выполняется не с железного оборудования, а с работающей системы виртуализации, но, несмотря на это, процесс требует особой подготовки.
Разберем основные этапы переноса инфраструктуры в облако. Каждый из них имеет свои нюансы, знание которых позволит не допустить ошибок.
Этап подготовки
Оценка мощности
Подготовка начинается с оценки имеющейся инфраструктуры и составления плана переноса. Необходимо рассчитать точную мощность тех ресурсов, которые вы планируете перенести в облако. Зачастую они могут оказаться меньше, чем используемые в настоящий момент. Работая с собственной физической или виртуальной инфраструктурой, мы закладываем запас по мощности, чтобы предвидеть будущий рост запросов бизнеса, а также нивелировать огрехи оптимизации, которые исключены в среде облачного провайдера. Аренда виртуальной инфраструктуры позволяет добавлять дополнительные ресурсы только тогда, когда в них возникает необходимость, поэтому, если вы просчитали, что для работы определенного сервиса необходимо 2 ядра, 16 Гб ОЗУ и 500 Гб дискового пространства, значит, столько необходимо арендовать, а когда потребуется увеличить производительность — скорректируете спецификацию.
План переноса
Необходимо составить таблицу с перечнем всех переносимых сервисов, для каждого указать потребляемые ресурсы, определить приоритет переноса и критичность остановки на время переноса. Обычная практика заключается в том, что сначала в облако переносятся некритичные сервисы, те, на которых можно опробовать работу с облачным провайдером, и только спустя некоторое время производится миграция всей остальной инфраструктуры.
Проще всего переносить сервисы, которые не имеют большой или постоянной загрузки. Это могут быть тестовые стенды или рабочие станции пользователей. Именно с них стоит начать миграцию, а затем переносить «боевые» среды.
Следующим важным аспектом планирования является окно остановки работы систем на время миграции. С точки зрения переноса оно зависит от времени, которое будет затрачено на конвертацию виртуальных машин и копирование данных, а с точки зрения бизнеса — насколько можно без потерь остановить работу данного сервиса. Бывают такие приложения, которые невозможно остановить без финансового ущерба или последствий для репутации.
Важно определить зависимости между сервисами, они играют большую роль для составления порядка миграции. Перенос зависимых сервисов лучше всего осуществлять одновременно. Если их службы активно обмениваются данными, то разнесение их по разным площадкам может критично сказаться на производительности.
Выбор способа переноса
В основном способ переноса зависит от исходной платформы (тип виртуализации в случае миграции частного облака или железный сервер) и активности данных (будет это офлайн-переезд или необходимо переносить горячие данные). Также играет роль скорость интернет-канала между исходной инфраструктурой и центром обработки данных облачного провайдера. При низкой скорости или невысоком качестве линии связи имеет смысл рассмотреть вариант миграции с использованием внешнего NAS.
После того как определены сервисы, которые будут мигрировать в облако, рассчитана потребляемая ими мощность, составлен план переноса с учетом приоритета, выбран способ переноса данных и заключен договор с облачным провайдером, можно начинать переезд в облако.
Этап переезда
На этом этапе происходит перенос сервисов в облако провайдера. Существует множество вариантов того, как это может происходить, каждый из них подходит для определенной инфраструктуры.
Если осуществляется перенос железных серверов, то используется специальное программное обеспечение для клонирования образов серверов от Acronis, Clonezilla, Partition magic или VMware vCenter Converter, которое подходит для миграции в среду VMware. Они подходят для офлайн-преезда, когда можно выключить сервер, сделать его полную копию и развернуть в виртуальной среде. В данном случае необходимо учитывать совместимость операционной системы: старая ОС Windows может хорошо работать на устаревшем железе, а для современной аппаратной платформы провайдера у нее может не оказаться драйверов.
Если заказчик переносит в облако собственную виртуальную инфраструктуру VMware, можно использовать функцию экспорта/импорта через файл формата OVF/OVA (унифицированный формат распространения готовых виртуальных машин) как для отдельных виртуальных машин, так и для целых vApp.
Еще один способ удобной миграции — использование инструмента VMware vCloud Connector, он объединяет частное облако заказчика и публичное облако провайдера. Администратор получает доступ к понятному графическому интерфейсу, в котором можно запускать задачи копирования одной или нескольких виртуальных машин.
Для решения некоторых задач производится миграция сервисов по отдельности. В облаке поставщика услуг разворачивается дублирующий сервис, например Active Directory, запускается синхронизация с локальным, после удачной репликации и проверки локальный сервис отключается, а работа продолжается с перенесенным в облако.
Заключение
Заключительным этапом переноса инфраструктуры в облако является проверка и тестирование перенесенных сервисов. Если ошибок нет и сервисы функционируют с запланированной производительностью, их можно переводить в работу. Сейчас многие компании предпочитают переносить инфраструктуру в облако провайдера и использование модели IaaS, а не содержать собственную серверную. Выбор правильной стратегии переноса и следование рекомендациям позволят произвести миграцию с минимальными простоями для бизнеса.