Осуществление миграции из традиционной среды дата-центра в облачную среду позволяет командам упростить оптимизацию рабочих нагрузок с помощью инструментов, предоставляемых облачными платформам. Однако миграция — это сложный, многоуровневый процесс, который требует тщательного планирования, пишет на портале Network Computing Джоуи Йоре, главный консультант компании 2nd Watch.

Несмотря на потенциальные проблемы, связанные с миграцией дата-центров, преимущества отказа от физических инфраструктур, корпоративных ЦОДов или локальных СХД и переход к облачным дата-центрам или гибридным облачным системам вполне оправдывают затраченные усилия. Но как провести успешную миграцию и при этом эффективно управлять рисками? Ниже изложена типовая высокоуровневая стратегия миграции, которая разбита на четыре фазы: обнаружение, планирование, выполнение и оптимизация. Она позволяет определить активы, минимизировать затраты и риски миграции, обеспечить развертывание, конфигурацию и, наконец, оптимизировать конечное развертывание.

1. Обнаружение

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

Ключевыми на этой фазе являются:

  • создание общей инвентаризационной схемы ЦОДа: каждая команда и каждый сотрудник, участвующий в его миграции в облако, должны знать, какие активы и ресурсы будут задействованы;
  • создание первоначального проекта фундамента облачной платформы: этот пункт включает определение централизованных концепций организации облачной платформы, таких как структура папок, модель управления идентификацией и доступом (IAM), модель сетевого администрирования и т. д.;
  • проведение в качестве передовой практики межфункционального диалога с участием различных команд от ИТ до финансов и управления программами, чтобы убедиться, что все согласны с изменениями, необходимыми для поддержки будущих облачных процессов. Кроме того, следует подумать о том, обучена ли команда дата-центра поддерживать системы и инфраструктуру облачного провайдера.

2. Планирование

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

Ключевыми на этой фазе являются:

  • сопоставление списка имеющихся серверов с типами машин облачной платформы. Каждая текущая рабочая нагрузка обычно выполняется на виртуальной машине (ВМ) с аналогичной вычислительной мощностью, памятью и диском. Однако они часто бывают избыточными, поэтому необходимо оценить каждую рабочую нагрузку, чтобы убедиться, что она будет перенесена на подходящую для нее ВМ;
  • определение целевых дат для каждого проекта миграции;
  • определение рабочих нагрузок в каждой группе. Выясните, по каким признакам группируются волны миграции, т. е. непроизводственные и производственные приложения;
  • определение периодичности выпуска кода. Учитывайте все предстоящие выпуски кода, поскольку это может повлиять на решение о сроках миграции;
  • определение времени на развертывание и тестирование инфраструктуры. Выделите перед полным переходом в облако достаточно времени для тестирования инфраструктуры;
  • оценка зависимостей приложений. На очередность миграции должно влиять количество зависимостей приложений. Приложения с наименьшим количеством зависимостей, как правило, являются хорошими кандидатами для миграции в первую очередь. И наоборот, приложение, которое зависит от нескольких БД, следует переносить после них;
  • оценка сложности и рисков миграции. Порядок миграции также должен учитывать сложность. Как правило, миграция оказывается более успешной, если сначала рассмотрены более простые ее аспекты.

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

3. Выполнение

После того как компании разработали план, его нужно воплотить в жизнь. Здесь необходимо тщательно продумать шаги и подобрать конфигурации. На этапе выполнения компании устанавливают компоненты инфраструктуры и обеспечивают их надлежащую настройку, например, IAM, сети, правила брандмауэра и учетные записи для подключения служб. Помимо этого команды должны протестировать приложения на конфигурациях инфраструктуры, чтобы убедиться, что они имеют доступ к БД, файловым ресурсам, веб-серверам, балансировщикам нагрузки, серверам Active Directory и т. д. Выполнение также включает протоколирование и мониторинг, чтобы убедиться, что приложения продолжают функционировать с необходимой производительностью.

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

4. Оптимизация

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

  • изменение типов машин и размеров дисков;
  • использование ПО для более гибкого и предсказуемого развертывания, такого, например, как Terraform;
  • улучшение автоматизации для снижения операционных накладных расходов;
  • усиление интеграции с инструментами регистрации, мониторинга и оповещения;
  • внедрение управляемых услуг для снижения эксплуатационных расходов.

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