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

Как правило, миграция с одного локального сервера на другой (server-to-server) относительно проста, тогда как миграция из дата-центра в облако сопряжена с рядом трудностей. Хотя цели облачной серверной миграции такие же, как и у локальной, первый вариант подразумевает детальное планирование, подготовку и процессы. Изучение, сравнение и понимание сильных сторон различных типов миграции вооружит вас знаниями и позволит избежать ошибок при переходе в облако.

Миграция в локальной среде

Локальная миграция с сервера на сервер может осуществляться в физической форме (physical to physical, P2P), когда традиционное невиртуализированное приложение, выполняемое на «голом железе» (bare metal), переносится с одного физического сервера на другой. Это равнозначно переустановке приложения на другой целевой сервер. Сократить время миграции могут помочь инструменты типа PlateSpin Migrate. Если с рабочей нагрузкой связаны локальные файлы данных, то их можно скопировать на целевой сервер, тогда как само перенесенное приложение конфигурируется для поиска всех перемещенных данных.

Миграция с физического сервера на виртуальный (physical-to-virtual, P2V) предполагает похожую схему действий. Bare metal-приложение можно переустановить на виртуальной машине и заранее подготовить. Ускоренные P2V-миграции поддерживают PlateSpin Migrate, VMware Converter и другие инструменты.

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

Локальная V2V-миграция

Миграция из одной виртуальной среды в другую (virtual-to-virtual V2V) — наиболее распространенный способ миграции онпремисных и облачных рабочих нагрузок. В качестве инструментов для проведения «живых» миграций задействуются гипервизоры, например, Hyper-V и vSphere. Они автоматически перемещают рабочую виртуальную машину (ВМ) с исходного сервера на целевой без необходимости приостановки или полной остановки ее работы. Результат — практически полное отсутствие простоев. Перенос данных в основном заключается в копировании файлов с одного сервера на другой. Это можно сделать до или во время динамической миграции. Однако перемещение больших наборов данных занимает значительное время даже в локальной сети, что требует кратковременного перевода рабочей нагрузки в пассивное состояние.

Стоит более детально рассмотреть общий процесс типичной локальной V2V-миграции.

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

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

Выполнение. Современные инструменты позволяют быстро справиться с реальным процессом миграции. Например, с помощью диспетчера Hyper-V администраторы выбирают исходный сервер и подключаются к нему, выбирают ВМ для перемещения, а затем с помощью Move Wizard выбирают тип перемещения, целевой сервер и многое другое. Когда администратор завершит работу с Move Wizard, перенос выполняется в автоматическом режиме. Хотя «живые» миграции предназначены для сокращения времени простоя, все же лучше выполнять их в периоды пассивного применения приложения — в этом случае потенциальные проблемы затронут наименьшее количество пользователей. Если вам по какой-либо причине необходимо приостановить работу приложения, следует запланировать время простоя.

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

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

Миграция с локального сервера в публичное облако

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

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

Во-вторых, мониторинг и аналитика инфраструктуры, полезные, но не обязательные в локальной среде, являются крайне важными для отслеживания состояния облачных рабочих нагрузок и данных. Это единственный практический способ понять, как применяются ресурсы, оценить затраты и производительность. Службы типа Amazon CloudWatch или Azure Monitor собирают метрики для мониторинга производительности и работоспособности приложений, составляя отчеты об использовании облачных ресурсов. Любое предприятие при переходе в облако должно понимать, каким образом оно будет применять эти службы.

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

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

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

Выполнение. Миграция в облако редко выполняется в ходе одного этапа. Как правило, к переносу данных приступают только после выбора подходящих ресурсов или цельной облачной инфраструктуры. Объем наборов данных может измеряться тера- или даже петабайтами. Он слишком велик, что резко увеличивает нагрузку на традиционное интернет-соединение и не позволяет перенести их в сжатые сроки. Вместо него лучше воспользоваться выделенным каналом или заняться отправкой данных на физические устройства через такие сервисы, как AWS Snowball или Google Transfer Appliance.

После перемещения данных в облако их необходимо синхронизировать с локальными данными, поскольку данные в ходе выполнения локальной рабочей нагрузки продолжают видоизменяться. Такие службы, как AWS DataSync и Azure File Sync, позволяют в ходе переноса обрабатывать большие массивы данных и обеспечивать синхронизацию. После их подготовки можно приступить к фактической миграции сервера и переноса локальных ВМ на вычислительные ВМ или инстансы, подготовленные в облаке. Администраторы могут без особых усилий копировать и запускать локальные файлы ВМ в виде облачных инстансов, но такой подход требует ручной работы и подойдет для небольшого числа миграций. Если предприятию нужно провести большое количество миграций, лучше всего воспользоваться инструментами, которые предлагают облачные провайдеры, такими как Google Migrate for Compute Engine и Azure Migrate.

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

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

Лучшие практики миграции в облако

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

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

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

Автоматизируйте повторяющиеся процессы. Процессы перемещения в облако больших рабочих нагрузок, таких как веб-серверы, лучше автоматизировать при помощи инструментов наподобие Amazon Server Migration Service.

Запуск мониторинга и аналитики. Пользователи облачных сервисов должны иметь представление о состоянии/производительности рабочей нагрузки и использовании ресурсов. Такие инструменты, как Azure Monitor, Amazon CloudWatch и Google Cloud Monitoring, позволяют получить ценную информацию о работе облачных приложений.

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