Подготовка к миграции без агента VMware

Статья
10/25/2024

Внимание

Эта статья ссылается на CentOS, дистрибутив Linux, который является состоянием "Конец жизни" (EOL). Пожалуйста, рассмотрите возможность использования и планирования соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

В этой статье представлен обзор изменений, выполненных при переносе виртуальных машин VMware в Azure с помощью метода миграции без агента с помощью средства миграции и модернизации.

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

Версии операционной системы, поддерживаемые для расконсервации

Windows Server 2008 или более поздней версии
Red Hat Enterprise Linux 9.x, 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x
CentOS Stream
SUSE Linux Enterprise Server 15 с пакетом обновления 4 (SP4), 15 с пакетом обновления 3 (SP3), 15 SP2, 15 SP1, 12, 11 с пакетом обновления 4 (SP4), 11 с пакетом обновления 3 (SP3)
Ubuntu 22.04, 21.04, 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS
Kali Linux (2016, 2017, 2018, 2019, 2020, 2021, 2022)
Debian 11, 10, 9, 8, 7
Oracle Linux 9, 8, 7.7-CI, 7.7, 6

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

Проверка наличия необходимых драйверов
Включение последовательной консоли
Настройка параметров сети
Установка гостевого агента виртуальной машины

Процесс расконсервации

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

Когда пользователь запускает Тестовую миграцию или Миграцию, служба Миграция Azure выполняет миграцию, чтобы подготовить локальную виртуальную машину для миграции в Azure. Чтобы настроить процесс расконсервации, служба Миграция Azure создает временную виртуальную машину Azure и присоединяет диски исходной виртуальной машины для внесения изменений, чтобы подготовить исходную виртуальную машину к работе в Azure. Временная виртуальная машина Azure — это промежуточная виртуальная машина, созданная во время миграции до создания окончательной перенесенной виртуальной машины. Временная виртуальная машина будет создана с аналогичным типом ОС (Windows/Linux) с помощью одного из образов ОС из Marketplace. Если локальная виртуальная машина работает с Windows, то диск операционной системы локальной виртуальной машины будет подключен как диск данных к временной виртуальной машине для выполнения изменений. Если это сервер Linux, все диски, подключенные к локальной виртуальной машине, будут присоединены как диски данных к временной виртуальной машине Azure.

Служба Миграция Azure создаст сетевой интерфейс, новую виртуальную сеть, подсеть и группу безопасности сети (NSG) для размещения временной виртуальной машины. Эти ресурсы создаются в подписке клиента. Если имеются конфликтующие политики, которые препятствуют созданию артефактов сети, служба Миграция Azure попытается создать временную виртуальную машину Azure в виртуальной сети и подсети, указанные в параметрах целевого объекта репликации.

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

Шаги миграции

Примечание.

Диски виртуальной машины Гидратации не поддерживают управляемый клиентом ключ (CMK). Управляемый ключ платформы (PMK) — это параметр по умолчанию.

Изменения, вносимые в процессе расконсервации

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

Изменения, вносимые на серверах Windows

Обнаружение и подготовка тома в ОС Windows

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

На этом шаге выполняются следующие действия.
- Монтируется каждый раздел диска ОС, присоединенного к временной виртуальной машине.
- Выполняется поиск файлов реестра \Windows\System32\Config\System после монтирования раздела.
- Если файлы не найдены, раздел отключен, и поиск продолжается для правильной секции.
- Если файлы отсутствуют в каких-либо разделах, он может указать, что выбран неправильный диск ОС или диск ОС поврежден. Служба Миграция Azure завершает процесс миграции с соответствующей ошибкой.
Примечание.

Этот шаг не имеет значения, если вы вручную подготавливаете серверы к миграции.
Внесение изменений, связанных с загрузкой и подключением

После того как будут обнаружены файлы исходного тома операционной системы, скрипт подготовки загрузит куст системного реестра в редактор реестра временной виртуальной машины Azure и внесет следующие изменения, чтобы обеспечить возможность загрузки и подключения виртуальной машины. Эти параметры необходимо настроить вручную, если версия ОС не поддерживается для гидратации.
1. Проверка наличия необходимых драйверов
  
  Убедитесь, что необходимые драйверы установлены и для них настроена загрузка при запуске загрузки. Следующие драйверы Windows позволяют серверу взаимодействовать с оборудованием и другими подключенными устройствами.
  - IntelIde.sys
  - Atapi
  - Storfit
  - Storvsc
  - VMbus
2. Задать для политики сети хранения данных (SAN) значение Online All
  
  Это гарантирует, что тома Windows в виртуальной машине Azure используют те же назначения букв дисков, что и на локальной виртуальной машине. По умолчанию виртуальным машинам Azure в качестве временного хранилища назначен диск D. В результате для всех остальных назначений подключенного накопителя будет использоваться следующая по порядку буква. Чтобы предотвратить такое автоматическое назначение и убедиться, что Azure назначает следующую свободную букву диска временному тому, задайте для политики сети хранения данных (SAN) значение Online All.
  
  Чтобы настроить этот параметр вручную:
  - На локальном сервере откройте командную строку с повышенными привилегиями и введите команду diskpart.
  - Введите SAN. Если буква диска гостевой ОС не поддерживается, возвращается значение Offline All (Перевод всего в состояние "вне сети") или Offline Shared (Перевод в состояние "вне сети" общих ресурсов).
  - В командной строке DISKPART введите SAN Policy=OnlineAll. Этот параметр гарантирует, что диски будут подключены к сети и вы сможете выполнять чтение и запись на обоих дисках.
Настройка типа запуска DHCP

Скрипт подготовки также настроит тип запуска службы DHCP "Автоматически". Это позволит перенесенной виртуальной машине получить IP-адрес и установить подключение после миграции. Убедитесь, что служба DHCP настроена и для нее отображается статус "Выполняется".

Чтобы изменить параметры запуска DHCP вручную, выполните следующий пример в Windows PowerShell.
```
Get-Service -Name Dhcp
Where-Object StartType -ne Automatic
Set-Service -StartupType Automatic
```
Отключение службы Средства VMware

Выполните запуск службы VMware Tools, чтобы отключить ее, если она существует, так как она не требуется для виртуальной машины в Azure.

Примечание.

Чтобы подключиться к виртуальным машинам Windows Server 2003, на виртуальной машине Azure необходимо установить службы интеграции Hyper-V. По умолчанию эти службы не устанавливаются на машинах Windows Server 2003. Инструкции по установке и подготовке к миграции см. в этой статье.
Установка гостевого агента Windows Azure

Служба Миграция Azure попытается установить агент виртуальной машины Microsoft Azure — это защищенный упрощенный процесс, который управляет взаимодействием виртуальной машины с контроллером структуры Azure. Агент виртуальной машины играет важную роль во включении и запуске расширений виртуальных машин Azure, которые обеспечивают настройку виртуальной машины после развертывания, например установку и настройку программного обеспечения. Служба Миграция Azure автоматически устанавливает агент виртуальных машин Windows агент в Windows Server 2008 R2 и более поздних версий.

Агент виртуальной машины Windows можно установить вручную с помощью пакета установщика Windows. Чтобы вручную установить агент виртуальной машины Windows, скачайте установщик агента виртуальной машины. Можно также выполнить поиск конкретной версии в выпусках агента виртуальной машины GitHub Windows IaaS. Агент виртуальной машины поддерживается в Windows Server 2008 (64-разрядная версия) и более поздних версиях.

Чтобы проверить установку агента виртуальных машин Azure, откройте диспетчер задач, перейдите на вкладку Подробности и найдите процесс с именем WindowsAzureGuestAgent.exe. Наличие этого процесса означает, что агент виртуальной машины установлен. Для обнаружения агента виртуальных машин можно также использовать PowerShell.

После внесения вышеупомянутых изменений системный раздел будет выгружен. Теперь виртуальная машина готова к миграции. Дополнительные сведения об изменениях для серверов Windows.

Изменения на серверах Linux

Обнаружение и подключение разделов ОС Linux

Перед внесением соответствующих изменений конфигурации скрипт подготовки проверит правильность выбора диска ОС для миграции. Скрипт будет выполнять сбор информации обо всех разделах, их UUID и точках подключения. Скрипт также будет просматривать все эти видимые секции для поиска разделов /boot и /root.

На этом шаге выполняются следующие действия.
- Обнаружение /корневой секции:
  - Подключите каждый видимый раздел и найдите etc/fstab.
  - Если файлы fstab не найдены, раздел отключен, а поиск продолжается для правильной секции.
  - Если файлы fstab найдены, прочтите содержимое fstab, чтобы определить корневое устройство и подключить его как базовую точку подключения.
- Обнаружение /boot и других системных разделов:
  - Используйте содержимое fstab, чтобы определить, является ли /boot отдельным разделом. Если это отдельный раздел, получите имя устройства загрузочного раздела из содержимого fstab или найдите раздел с флагом загрузки.
  - Скрипт продолжит обнаружение и подключение /boot и других необходимых разделов на /mnt/azure_sms_root для создания корневого дерева файловой системы, необходимого для рутированных взломанных устройств. Другие требуемые разделы: /boot/grub/menu.lst, /boot/grub/grub.conf, /boot/grub2/grub.cfg, /boot/grub/grub.cfg, /boot/efi (for UEFI boot), /var, /lib, /etc, /usr и т. д.
Обнаружение версии ОС

После обнаружения корневой секции скрипт будет использовать следующие файлы для определения дистрибутива и версии операционной системы Linux.
- RHEL: etc/redhat-release
- OL: etc/oracle-release
- SLES: etc/SuSE-release
- Ubuntu: etc/lsb-release
- Debian: etc/debian_version
Установка служб интеграции Hyper-V Linux и повторное создание образа ядра

Следующим шагом является проверка образа ядра и повторное построение образа инициализации Linux таким образом, чтобы он содержал необходимые драйверы Hyper-V (hv_vmbus, hv_storvsc, hv_netvsc) на начальном ramdisk. Повторная сборка образа инициализации гарантирует, что виртуальная машина будет загружаться в Azure.

Azure запускается на гипервизоре Hyper-V. Таким образом, Linux требует определенные модули ядра для запуска в Azure. Чтобы подготовить образ Linux, вам потребуется выполнить повторную сборку initrd, чтобы на начальном электронном диске были доступны по крайней мере модули ядра hv_vmbus и hv_storvsc. Механизм повторной сборки образа initrd или initramfs может отличаться в зависимости от дистрибутива. Чтобы узнать правильную процедуру для вашего дистрибутива, см. документацию по дистрибутиву или раздел поддержки. Ниже приведен один из примеров для перестроения инициализации с помощью служебной программы mkinitrd:
1. Поиск списка ядер, установленных в системе (/lib/modules)
2. Для каждого модуля необходимо проверить, включены ли драйверы Hyper-V.
3. Если какой либо из этих драйверов отсутствует, добавьте необходимые драйверы и повторно создайте образ для соответствующей версии ядра.
  
  Примечание.
  
  Этот шаг может не применяться для виртуальных машин Ubuntu и Debian, так как драйверы Hyper-V в этом случае встроены по умолчанию. Дополнительные сведения об изменениях.
  
  Пример, демонстрирующий повторное построение initrd
  - Создание резервной копии существующего образа initrd
```
 cd /boot
 sudo cp initrd-`uname -r`.img  initrd-`uname -r`.img.bak
```
  - Выполните повторную сборку initrd с использованием модулей ядра hv_vmbus и hv_storvsc:
```
   sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-`uname -r`.img `uname -r`
```
В большинстве новых версий дистрибутивов Linux это включено по умолчанию. Если она не включена, установите вручную для всех версий, кроме тех, которые были вызваны, выполнив указанные выше действия.
Включение ведения журнала Серийной консоли Azure

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

Измените строку загрузки ядра в GRUB или GRUB2 и включите в нее следующие параметры, задающие отправку всех сообщений консоли в первый последовательный порт. Эти сообщения могут использоваться службой поддержки Azure при отладке возникающих проблем.
```
 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300
```
Кроме того, мы рекомендуем удалить следующие параметры (если они заданы).
```
rhgb quiet crashkernel=auto
```
Сведения о конкретных изменениях см. в этой статье.
Изменения сети для настройки возможностей подключения

В зависимости от версии ОС скрипт внесет необходимые изменения сети для настройки возможностей подключения к перенесенной виртуальной машине. Ниже представлены изменения.
1. Переместите (или удалите) правила udev, чтобы не создавать статические правила для интерфейса Ethernet. Эти правила приводят к появлению проблем при клонировании виртуальной машины в Azure.
  
  Пример для RedHat Server
```
   sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules
   sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
```
2. При необходимости удалите Диспетчер сети. Диспетчер сети может вступать в конфликт с агентом Azure Linux в ряде версий ОС. Рекомендуется внести эти изменения для серверов с дистрибутивами RedHat и Ubuntu.
3. Установите пакет, выполнив следующую команду:
  
  Пример для RedHat Server
```
   sudo rpm -e --nodeps NetworkManager
```
4. Создайте резервную копию существующих параметров сетевого адаптера и создайте файл конфигурации сетевого адаптера eth0 с параметрами DHCP. Для этого скрипт создаст или изменит файл /etc/sysconfig/network-scripts/ifcfg-eth0 и добавит следующий текст:
  
  Пример для RedHat Server
```
   DEVICE=eth0
   ONBOOT=yes
   BOOTPROTO=dhcp
   TYPE=Ethernet
   USERCTL=no
   PEERDNS=yes
   IPV6INIT=no
   PERSISTENT_DHCLIENT=yes
   NM_CONTROLLED=yes
```
5. Выполните сброс файла etc/sysconfig/network следующим образом:
  
  Пример для RedHat Server
```
   NETWORKING=yes
   HOSTNAME=localhost.localdomain
```
Проверка fstab

Служба Миграция Azure проверит записи в файле fstab и при необходимости заменит их записями с постоянными идентификаторами томов и UUID. Это гарантирует, что имя диска или раздела остается постоянным независимо от того, к какой системе она подключена.
- Если имя устройства — это стандартное имя устройства (например, /dev/sdb1), то:
  - Если это корневой или загрузочный раздел, он заменен UUID.
  - Если раздел сосуществует с корневой или загрузочной секцией как стандартные секции на том же диске, он заменен UUID.
- Если используется имя устройства UUID/LABEL/LV, изменения не вносятся.
- Если речь идет о сетевом устройстве (nfs, cifs, smbfs и т. д.), скрипт добавит комментарий к записи. Чтобы получить доступ к нему, можно удалить комментарий и перезагрузить виртуальную машину Azure.
Установка гостевого агента Azure для Linux

Служба Миграция Azure попытается установить агент виртуальной машины Microsoft Azure для Linux (waagent) — это защищенный упрощенный процесс, который управляет подготовкой Linux и FreeBSD и взаимодействием виртуальной машины с контроллером структуры Azure. Дополнительные сведения о функциональных возможностях, доступных в развертываниях IaaS Linux и FreeBSD с использованием агента Linux.

Изучите список обязательных пакетов для установки агента виртуальной машины Linux. Служба "Миграция Azure" автоматически устанавливает агент виртуальной машины Linux для RHEL 9.x, 8.x/7.x/6.x, Ubuntu 14.04/16.04/18.04/19.04/19.10/20.04, SUSE 15 SP0/15 SP1/12, Debian 9/8/7 и Oracle 7/6 при использовании метода миграции VMware без агента. Выполните следующие инструкции по установке агента Linux вручную в других версиях ОС.

С помощью этой команды можно проверить статус службы агента Azure для Linux, чтобы убедиться в его работоспособности. Имя службы должно быть walinuxagent или waagent. После внесения изменений в процессе расконсервации скрипт отключит все подключенные разделы, деактивирует группы томов, а затем освободит устройства.
```
   sudo vgchange -an <vg-name>
   sudo lockdev –flushbufs <disk-device-name>
```
Дополнительные сведения об изменениях для серверов Linux.

Очистка временной виртуальной машины

После внесения необходимых изменений служба Миграция Azure выключит временную виртуальную машину и освободит подключенные диски ОС (и диски данных). Это означает конец процесса расконсервации.

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

Подробнее

Подготовка локальных компьютеров к миграции в Azure

Поделиться через