Многие ИТ-специалисты уже стали экспертами по миграции локального сервера в облако Microsoft Azure. Об этом уже написано множество статей, в том числе и на это сайте. Но что, делать, если вы хотите перенести свою виртуальную машину из облака Azure в свою локальную среду (On-Premises)? Об этом информации гораздо меньше. В этой статье я постараюсь пошагово описать процесс по обратной миграции виртуальной машины из облака Azure на локальную площадку заказчика на базе кластера Hyper-V Windows Server 2016.
Существует несколько способов перемещения виртуальной машины из точки A в точку Б. Мы сосредоточимся на простом, но эффективном методе, который можно применять для малых и средних миграций. Мы будем делать все вручную, но в дальнейшем можно будет автоматизировать многие задачи. Весь процесс состоит из трех задач, а именно: инвентаризации ВМ в среде Azure, копирование VHD файлов и создание виртуальных машин в соответствии с полученными на первом этапе данными.
Инвентаризация виртуальных машин в Azure
Инвентаризация позволит существенно сэкономить время в процессе миграции ВМ. Идея заключается в создании Word или Excel файла для документирования всей информации о виртуальной машине. Хотя мы будем создавать новые локальные виртуальные машины с использованием дисков, которые использовались в Azure, мы должны убедиться, что характеристики CPU, памяти и имена диска были правильно документированы.
В этой примере нашей целью является перенос из Azure тестовой среды SharePoint. Первая задача — проверить, сколько виртуальных машин задействовано в этом сервисе. Если вы организовали свою тестовую среду с помощью групп ресурсов, то это большой плюс. Выведите список ресурсов такой группы, и вы получите список задействованных ВМ. Из приведенного ниже скриншота видно, что нам нужно перенести пять виртуальных машин.
Второй шаг — остановка всех виртуальных машин, помеченных для миграции. Имейте в виду, что это приведет к остановке работы сервиса, поэтому заранее запланируйте работы и оповестите о простое пользователей. Достаточно выбрать нужную виртуальную машину, и в открывшейся вкладке нажмите Stop.
гк
Третий шаг – сохранение информации об используемых ресурсах (память, процессор, диски). Доступ к этим данным можно получить, щелкнув по нужной виртуальной машине и нажав Overview. Нужные данные появятся в новом окне справа.
Последним шаг – идентификация имен дисков. Щелкните по кнопке Disks. В окне появится список системных дисков и дисков данных, которые используются текущей виртуальной машиной. По очереди выберите каждый из дисков и скопируйте его имя из правого окна (воспользуйтесь кнопкой копирования).
В результате инвентаризации у вас получится примерно такая таблица, в которой собрана информация обо всех имеющихся виртуальным машинах и используемых дисках.
Копирование VHD файлов с помощью Microsoft Azure Storage Explorer
На втором этапе нам потребуется использовать утилиту Microsoft Azure Storage Explorer (можно скачать версию для Windows, Mac или Linux). Процесс ее установки прост и не требует дополнительных комментариев.
Чтобы упростить себе задачу, мы создадим отдельный раздел для хранения всех мигрированных из Azure виртуальных машин тестовой среды SharePoint. Этот раздел нужно презентовать всем узлам локального кластера Hyper-V.
Запустите Microsoft Azure Storage Explorer и нажмите значок учетной записи, настроив авторизацию в Azure. После проверки подлинности список всех объектов хранения будет показан с левой стороны. Разверните те объекты, которые связаны с виртуальными машинами, которые нужно переместить, затем разверните Blog Containers, а затем vhds. Выберите каждый VHD файл в правой части и нажмите Download.
Прогресс закачки каждого диска будет отображаться нижней правой части окна. Прежде чем перейти к следующей фазе миграции, дождитесь завершения загрузки всех виртуальных дисков.
Создание ВМ на локальном кластере Hyper-V
Самый простой способ создать виртуальные машины с использованием существующих дисков, находящихся на локальном хранилище – воспользоваться Failover Cluster Manager (так проще даже при наличии Virtual Machine Manager).
Здесь все просто. Откройте Failover Cluster Manager, щелкните ПКМ по Roles, выберите Virtual Machines… и затем по New Virtual Machine. В новом окне со списком всех узлов выберите любой доступный узел и нажмите ОК.
На странице Before you Begin нажмите Next. Затем в окне Specify Name and Location page укажите имя виртуальной машины и папку на томе, в которой хранятся скачанные с Azure vhd файлы
Укажите поколение ВМ — Generation 1 (наши виртуальные машины в Azure созданы на VHD файлах). Конечно, можно преобразовать диски в формат VHDX и использовать второе поколение ВМ, но в этом случае это не требуется.
На странице Assign Memory укажите тот же объем памяти, которой был у ВМ в Azure. Затем выберите нужный виртуальный коммутатор.
На этапе Connect Virtual Hard Disk укажите, что нужно использовать имеющиеся диски (Use an existing virtual hard disk), с помощью кнопки Browse выберите файл системного диска, скачанный с Azure.
Примечание. На данный момент мы настроим только диск с ОС.
На этапе настройке High Availability используйте значения по-умолчанию.
Теперь вернемся к главной странице Failover Cluster Manager. Щелкните правой кнопкой мыши по созданной ВМ и откройте ее настройки (Settings). Выберите IDE Controller 0, выберите Hard Drive и нажмите Add. Новый диск появится под существующим контроллером IDE. Нажмите Browse и выберите имеющийся диск с данными. Если у ВМ были дополнительные диски, добавьте их по аналогии.
Прежде чем продолжить, откройте секцию Processor и отредактируйте количество виртуальных CPU в соответствии с данными их таблицы.
Тестирование и заключительные штрихи
Теперь, когда виртуальная машина была создана, настало время ее запустить. После начальной загрузки администратор должен скорректировать следующие детали:
- Файл подкачки. По умолчанию Azure использует для файла подкачки отдельный временный диск D:. Т.к. мы его не копировали, нужно будет создать новый диск или переместить файл подкачки на другой диск
- Настройки временной зоны. Проверьте настройки Time Zone в Windows
- Настройки IP – т.к. при создании новой виртуальной машины, создается новый виртуальный сетевой адаптер, необходимо задать ему корректную конфигурацию IP и дождаться репликации изменений в DNS
После того, как все ваши виртуальные машины запущены в локальной среде (On-Premises) и пользователи подтвердили корректность работы сервиса, можно удалить старые виртуальные машины в Microsoft Azure.
1 comment
Спасибо за статью!
Также добавлю, что поколение ВМ должно совпадать в Azure и On-Premises, в противном случае после переноса она может не запуститься, т.к. во втором поколении поддерживается только UEFI-загрузка с GPT диска.
Лично не встречал второго поколения ВМ на Azure, косвенно всегда это можно определить по наличию Floppy-дисковода в диспетчере устройств ВМ (удалить его невозможно).
Также, как вы отметили в статье, для первого поколения в Azure используюется VHD-формат для виртуальных дисков ВМ, хотя VHDX тоже поддерживается.