Миграция в облако без ошибок
Минувший год показал, что использование сервисов в корпоративных целях из внешних облаков становится все более привычной практикой. Однако процесс миграции в облако имеет специфические особенности, не учитывая которых, можно потерпеть неудачу - не добиться той цели, которая изначально преследовалась.
Сформулируйте цели
К облачным сервисам сегодня прибегают компании самого разного профиля. Облака - это удобная среда не только для небольших и средних компаний, но и для крупного бизнеса, который размещает в ней как вспомогательные, так и критичные приложения: ERP-системы, базы данных, файловые хранилища, почтовые системы и т.д.
Обдумывая возможность миграции сервисов в облако, для начала следует определиться с тем, какая цель преследуется. Кто-то мигрирует в облако, потому что предоставление сервисов в этой модели для него оказывается дешевле; чей-то бизнес не позволяет ждать поставок оборудования месяц или два; кому-то нужен гибкий ресурс для наращивания инфраструктуры; а для кого-то важно избавиться от рутины, связанной с поддержкой ИТ, и переключиться на стратегические задачи.
Переход в облака решает и побочные задачи. Некоторые заказчики используют облачную среду для создания зоны тестирования новых приложений. Переход в облака дисциплинирует внутренние ИТ-службы заказчика, так как у них появляются планы переустановки приложений, планы Disaster Recovery. И вообще, миграция в облако - хороший повод навести порядок и избавиться от лишнего.
Путь в облака определяется целесообразностью. Облачный сервис стоит выбирать лишь в том случае, если он оптимален с точки зрения выбранного критерия. В решении о миграции сервисов в облака на первый план выступают такие приоритеты как оптимальное сочетание функциональности, легкость и скорость внедрения, а также экономические параметры. Далеко не всегда облачные услуги выигрывают по совокупности всех этих факторов.
«Возможные проблемы следует предусмотреть еще до начала этого процесса, - подчеркивает Эдуард Бавижев, начальник отдела виртуализации компании DataLine. - Сформулируйте для себя все плюсы и минусы перехода и, сопоставив их, оцените риски, которые сопутствуют передаче приложений в облако».
Важным моментом на этом этапе является выбор поставщика облачных услуг. А главный критерий выбора определяется опытом сервис-провайдера в предоставлении облачной инфраструктуры. Следует выяснить, как давно данный поставщик работает на рынке облачных услуг? Каков уровень его партнерства с вендорами, приложения которых он использует для предоставления сервисов? Ответьте и на такой вопрос: поддерживаются ли производителями гипервизора, на базе которого построено облако провайдера, те приложения, которые заказчик намерен перенести в облако?
Один из ключевых вопросов, на который надо обратить внимание, касается зрелости инфраструктуры провайдера, на основе которой он строит облако. Следует учитывать не только надежность оборудования, но и такие аспекты как компетенция персонала провайдера, а также количество имеющихся у провайдера заказчиков корпоративного уровня. Серьезным аргументом в пользу провайдера является наличие быстрой и квалифицированной поддержки в режиме 24×7.
Шесть подготовительных шагов
На этапе проектирования и миграции сервисов в облако от руководителей бизнеса Эдуард Бавижев дает несколько советов. В первую очередь, следует получить план развития услуг. «Он поможет правильно выстроить стратегию миграции и решить, какие услуги будут внедрены в течение ближайшего периода времени (например, полугода), - поясняет специалист. - Эти данные позволят оптимизировать затраты при расширении или уменьшении необходимого количества ресурсов в облаке.
Кроме того, весьма желательно предусмотреть сбор статистики ИТ-инфраструктуры, анализ которой даст точное представление о производительности (в терминах утилизации ресурсов процессора, ОП, СХД) и доступности сервисов, передаваемых в облако.
Прежде чем отдавать корпоративные сервисы в публичное облако, необходимо понимать, насколько данная инфраструктура соответствует тем приложениям, которые функционируют на ее основе. Для этого на этапе проектирования стоит позаботиться о составлении плана тестирования облачного провайдера с учетом имеющихся статистических данных существующей инфраструктуры и планов по наращиванию ресурсов. Анализ этих данных позволяет понять, сколько ресурсов необходимо для качественного предоставления сервисов на текущий момент времени. Дополнительно бизнес предоставляет информацию о будущем расширении.
Следующий шаг состоит в подготовке документации на инфраструктуру, которая включает составление логических схем размещения оборудования, на базе которого предоставляются сервисы. Документирование дает точное представление о взаимосвязи всех звеньев цепочки предоставления сервисов и серьезно облегчает их поддержку в будущем.
Поскольку часть сервисов переносится в облако, а часть может оставаться в офисе или филиалах, на этапе проектирования и миграции следует уделить особое внимание составлению сетевой схемы, которая отражает взаимодействие облачной и офисной инфраструктур. Такая схема дает представление о том, как будут взаимодействовать сервисы всех зон.
Наконец, обязательным шагом на стадии проектирования и миграции является составление плана резервного копирования. Когда часть данных находится в облаке, необходимо позаботиться о сохранении их резервных копий. При этом особое внимание следует обратить на то, где эти копии будут храниться, - на стороне провайдера или в офисе заказчика. Не на последнем месте стоит также вопрос о глубине хранения и частоте проведения тестовых проверок копий.
Доступ в облако
Получив мандат для доступа в облако в виде тестового аккаунта, можно приступить к прогону тестов производительности работы приложений на основе ранее составленного плана. По итогам тестов необходимо зафиксировать метрики производительности, на основании которых можно сравнить, насколько изменилась работа приложения по сравнению с тем, как оно функционировало в обычной инфраструктуре заказчика.
После того как метрики зафиксированы, представители обеих сторон (заказчика и провайдера) приступают к составлению SLA. В этом договоре заказчик может зафиксировать, какие конкретные показатели он ожидает от облачного провайдера по тем или иным метрикам.
Миграция началась
Если результаты тестирования удовлетворили заказчика, и у него есть данные по метрикам производительности, можно принимать решение о миграции данных. На этом этапе необходимо составить план миграции инфраструктуры.
Сценарий миграции прорабатывается обоюдно заказчиком и провайдером, и выбирается исходя из размера окна резервного копирования, объема данных и намерения заказчика конвертировать или обновить свою инфраструктуру.
На этапе планирования можно определиться с методом миграции, выбор которого зависит от ряда факторов. Одни заказчики переносят данные с физических серверов на виртуальные (P2V); другие - с виртуальной инфраструктуры на виртуальную инфраструктуру в облако (V2V); у третьих виртуальная инфраструктура находится на гипервизоре, отличном от того, на котором построено облако - в этом случае возникает задача конвертации виртуальных машин. В некоторых случаях есть смысл разворачивать заново операционную систему в облаке ВМ и переносить именно сервисы, а не ВМ целиком или сервисы целиком.
После миграции
После завершения миграции начинается этап эксплуатации сервисов в облаке. На этом шаге немаловажную роль играет мониторинг инфраструктуры.
«Мониторинг крайне необходим как для физической инфраструктуры, так и для сервисов, особенно на первом этапе после завершения миграции, - отмечает Бавижев. - Во многом это объясняется тем, что на начальном этапе еще не устоялись структурные взаимосвязи. На этом шаге любое изменение должно быть отражено в журнале, так как это существенно облегчает выявление причин инцидентов при их разборе и позволяет администратору выяснить, какие изменения оказывают позитивное, а какие - негативное влияние на сервисы».
Приведенные в статье рекомендации с высокой вероятностью облегчат переход в облако и позволят избежать проблем в будущем.
|
