Миграция виртуальных машин VMware с помощью службы Миграции Azure

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

Процесс репликации

Вариант репликации без агента подразумевает использование моментальных снимков VMware и технологии отслеживания измененных блоков (CBT) VMware для репликации данных с дисков виртуальных машин. На следующей блок-схеме показаны различные шаги, связанные с переносом виртуальных машин с помощью средства миграции и модернизации.

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

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

Для отслеживания изменений между циклами репликации используется технология отслеживания измененных блоков (CBT). В начале цикла репликации создается моментальный снимок виртуальной машины, и для получения изменений между текущим моментальным снимком и последним успешно реплицированным моментальным снимком используется отслеживание измененных блоков. Реплицируются только те данные, которые были изменены с момента выполнения предыдущего цикла репликации, чтобы обеспечить синхронизацию виртуальной машины. В конце каждого цикла репликации моментальный снимок освобождается, а для виртуальной машины выполняется объединение моментальных снимков.

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

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

Циклы репликации

Примечание.

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

Циклы репликации — это процессы периодической передачи данных из локальной среды на управляемые диски Azure. Полный цикл репликации состоит из следующих этапов.

1. Создание моментального снимка VMware для каждого диска, связанного с виртуальной машиной
2. Отправка данных в учетную запись хранения журнала в Azure
3. Выпуск моментального снимка
4. Консолидация дисков VMware

Цикл считается завершенным после консолидации дисков.

Компоненты, участвующие в репликации

Локальные компоненты: устройство Миграции Azure содержит следующие компоненты, которые отвечают за репликацию.

• Агент DRA
• Агент шлюза

Компоненты Azure: в следующей таблице перечислены различные артефакты Azure Artifacts, созданные при использовании метода миграции виртуальных машин VMware без агента.

Компонент	Область/регион	Отток подписок	Description
Хранилище служб восстановления	Регион проекта Миграции Azure	Подписка проекта Миграции Azure	Используется для управления репликацией данных
Cлужебная шина	Целевой регион	Подписка проекта Миграции Azure	Используется для обмена данными между облачной службой и устройством Миграции Azure
Учетная запись хранения журналов	Целевой регион	Подписка проекта Миграции Azure	Используется для хранения данных репликации, которые считываются службой и применяются к управляемому диску клиента.
Учетная запись хранения шлюза	Целевой регион	Подписка проекта Миграции Azure	Используется для хранения состояний машины во время репликации
Хранилище ключей	Целевой регион	Подписка проекта Миграции Azure	Управление строка подключения для служебной шины и ключей доступа для учетной записи хранения журналов
Виртуальная машина Azure	Целевой регион	Целевая подписка	Виртуальная машина, созданная в Azure во время миграции
управляемые диски Azure.	Целевой регион	Целевая подписка	Управляемые диски, подключенные к виртуальным машинам Azure
Сетевые адаптеры	Целевой регион	Целевая подписка	Сетевые карты, подключенные к виртуальным машинам, которые созданы в Azure

Требуемые разрешения

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

• Владелец или участник и администратор доступа пользователей в группе ресурсов проекта Миграции Azure и целевой группе ресурсов

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

• Владелец или участник в группе ресурсов проекта Миграции Azure и целевой группе ресурсов

Помимо описанных выше ролей, пользователю, вошедшему в систему, потребуются следующие разрешения на уровне подписки — Microsoft.Resources/Subscriptions/resourceGroups/Read.

Целостность данных

Каждый цикл репликации включает два этапа, которые обеспечивают целостность данных между локальным диском (исходным диском) и диском реплики в Azure (целевым диском).

1. Во-первых, мы проверяем, реплицируется ли каждый сектор, измененный на исходном диске, на целевой диск. Проверка выполняется с помощью битовых карт. Исходный диск делится на секторы по 512 байт. Каждый сектор на исходном диске сопоставляется с битом в битовой карте. При запуске репликации данных на исходном диске, который необходимо реплицировать, создается битовая карта для всех измененных блоков (в разностном цикле). Аналогично, при передаче данных на целевой диск Azure создается битовая карта. После успешного перемещения данных облачная служба сравнивает две битовые карты, чтобы убедиться в отсутствии измененных блоков. Если между битовыми картами имеется несоответствие, цикл считается неудачным. Поскольку при каждом цикле выполняется повторная синхронизация, несоответствие будет устранено в следующем цикле.

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

Безопасность

Устройство Миграции Azure сжимает данные и шифрует их перед отправкой. Данные передаются по защищенному каналу связи по протоколу HTTPS с использованием TLS 1.2 или более поздней версии. Кроме того, служба хранилища Azure автоматически шифрует данные при сохранении данных в облаке (шифрование неактивных данных).

Состояние репликации

Когда виртуальная машина проходит реплика (копирование данных), существует несколько возможных состояний:

• Начальная реплика очереди. Виртуальная машина помещается в очередь для реплика (или миграции), так как могут быть другие виртуальные машины, использующие локальные ресурсы (во время реплика или миграции). После освобождения ресурсов эта виртуальная машина будет обработана.
• Начальное реплика выполнения: виртуальная машина планируется для начальной реплика.
• Начальная репликация: виртуальная машина проходит начальную репликацию. Когда виртуальная машина проходит начальную реплика, вы не можете продолжить миграцию тестов и миграцию. Репликацию можно прерывать только на этом этапе.
• Начальное реплика tion (x%): начальная реплика tion активна и выполняется на x%.
• Разностная синхронизация. Виртуальная машина может пройти цикл разностного реплика tion, который реплика выполняет оставшийся поток данных с момента последнего цикла реплика.
• Приостановка выполнения: виртуальная машина проходит активный цикл разностного реплика и будет приостановлен в течение некоторого времени.
• Приостановлено: циклы реплика tion были приостановлены. Циклы реплика можно возобновить, выполнив операцию возобновления реплика tion.
• Возобновление очереди. Виртуальная машина помещается в очередь для возобновления реплика tion, так как существуют другие виртуальные машины, которые в настоящее время используют локальные ресурсы.
• Возобновление выполнения (x%): цикл реплика tion возобновляется для виртуальной машины и выполняется на x%.
• Остановка реплика выполнения: очистка репликации выполняется. Если остановить репликацию, промежуточные управляемые диски (начальные диски), созданные во время репликации, будут удалены. Подробнее.
• Завершена миграция: очистка миграции выполняется. После завершения миграции промежуточные управляемые диски (начальные диски), созданные во время реплика tion, будут удалены. Подробнее.
• — когда виртуальная машина успешно перенесена и (или) при остановке реплика tion, состояние изменяется на "-". После остановки реплика и завершения миграции и успешного завершения операции виртуальная машина будет удалена из списка реплика компьютеров. Виртуальную машину можно найти на вкладке "Виртуальные машины" в мастере реплика te.

Другие состояния

• Сбой первоначальной реплика tion: исходные данные не удалось скопировать для виртуальной машины. Следуйте указаниям по исправлению, чтобы устранить проблему.
• Ожидание восстановления: возникла проблема в цикле реплика. Вы можете выбрать ссылку, чтобы понять возможные причины и действия по исправлению (как применимо). Если вы выбрали автоматическое восстановление реплика tion, выбрав "Да" при активации реплика tion виртуальной машины, средство попытается восстановить его. В противном случае выберите виртуальную машину и выберите "Восстановить репликацию". Если вы не выбрали автоматическое восстановление реплика tion или если приведенный выше шаг не работал для вас, остановите реплика tion для виртуальной машины, сбросьте измененное отслеживание блоков на виртуальной машине, а затем перенастроите реплика.
• Восстановление реплика очереди. Виртуальная машина помещается в очередь для восстановления реплика, так как существуют другие виртуальные машины, использующие локальные ресурсы. После освобождения ресурсов виртуальная машина будет обработана для восстановления реплика.
• Повторная синхронизация (x%): виртуальная машина проходит повторную синхронизацию данных. Это может произойти, если во время реплика данных возникла ошибка или несоответствие.
• Не удалось остановить реплика миграцию или завершить миграцию: выберите ссылку, чтобы понять возможные причины сбоя и действий по исправлению (как применимо).

Примечание.

Некоторые виртуальные машины помещаются в состояние "В очереди", чтобы обеспечить минимальное воздействие на исходную среду из-за потребления памяти в хранилище. Такие виртуальные машины обрабатываются на основе логики планирования, как описано в следующем разделе.

Состояние миграции и тестирования

• Ожидание тестовой миграции: виртуальная машина находится на этапе разностной репликации, и теперь можно выполнить тестовую миграцию (или миграцию).
• Проверка очистки миграции ожидается. После завершения тестовой миграции выполните очистку тестовой миграции, чтобы избежать расходов в Azure.
• Готовы к миграции: виртуальная машина готова к миграции в Azure.
• Выполняется миграция в очередь: виртуальная машина помещается в очередь для миграции, так как существуют другие виртуальные машины, которые используют локальные ресурсы во время реплика (или миграции). После освобождения ресурсов виртуальная машина будет обработана.
• Тестирование миграции и миграции: виртуальная машина проходит тестовую миграцию и миграцию. Можно выбрать ссылку для проверки текущего задания миграции.
• Дата, метка времени: дата и метка времени миграции и тестирования.
• –: выполняется начальное реплика. Миграцию или тестирование можно выполнить после перехода процесса реплика tion на этап разностной синхронизации (добавочное реплика).

Другие состояния

• Завершено с информацией: задание миграции и тестирования миграции завершено с информацией. Вы можете выбрать ссылку, чтобы проверка последнее задание миграции для возможных причин и действий по исправлению (как применимо).
• Сбой: сбой задания миграции или тестирования. Вы можете выбрать ссылку, чтобы проверка последнее задание миграции, чтобы устранить возможные причины и действия.

Логика планирования

Начальная репликация планируется при настройке репликации для виртуальной машины. За ним следует добавочные реплика tions (разностные реплика tions).

Разностные циклы репликации планируются следующим образом.

• Первый цикл разностной репликации планируется сразу после завершения цикла начальной репликации
• Следующие циклы разностного реплика вы планируете в соответствии со следующей логикой: min[max[1 hour, (предыдущее разностное время цикла реплика tion/2)], 12 часов]

То есть следующее разностное реплика будет запланировано не раньше одного часа и не более 12 часов. Например, если цикл разностной репликации виртуальной машины занимает четыре часа, то следующий цикл разностной репликации будет запланирован через два часа, а не в течение следующего часа.

Примечание.

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

• При активации миграции выполняется цикл разностной репликации по запросу (цикл разностной репликации до отработки отказа) перед миграцией виртуальной машины.

Приоритизация виртуальных машин для различных этапов репликации

• Для текущих репликаций виртуальных машин назначается приоритет по расписанию (новые репликации).
• Цикл предварительной отработки отказа (разностная реплика по запросу) имеет самый высокий приоритет, за которым следует начальный цикл реплика. Цикл разностной репликации имеет наименьший приоритет.

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

Ограничения.

Мы используем следующие ограничения, чтобы не превысить ограничения операций ввода-вывода в секунду для сетей SAN.

• Каждое устройство Миграции Azure поддерживает репликацию 52 дисков в параллельном режиме.
• Каждый узел ESXi поддерживает 8 дисков. Каждый узел ESXi имеет NFC-буфер в размере 32 МБ. Таким образом, можно запланировать 8 дисков на узле (каждый диск занимает 4 МБ буфера для IR, аварийного восстановления).
• Каждое хранилище данных может иметь не более 15 моментальных снимков дисков. Единственное исключение — когда к виртуальной машине подключено более 15 дисков.

Репликация с горизонтальным увеличением масштаба

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

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

Остановка реплика миграции или завершение миграции

Если остановить репликацию, промежуточные управляемые диски (начальные диски), созданные во время репликации, будут удалены. Можно остановить реплика только во время активного реплика tion. Чтобы остановить реплика tion после переноса виртуальной машины, можно выбрать полную миграцию.

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

Рекомендуется всегда завершить миграцию после успешной миграции виртуальной машины в Azure, чтобы убедиться, что не взимается дополнительная плата за транзакции хранилища на промежуточных управляемых дисках (начальных дисках). В некоторых случаях вы заметите, что остановка реплика отнимает время. Это связано с тем, что при остановке реплика tion текущий цикл реплика tion завершается (только если виртуальная машина находится в разностной синхронизации) перед удалением артефактов.

Влияние оттока

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

Управление репликацией

Регулирование

Можно увеличить или уменьшить пропускную способность реплика с помощью NetQosPolicy. AppNamePrefix, используемый в NetQosPolicy, имеет значение "GatewayWindowsService.exe".

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

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

Примечание.

Это относится ко всем одновременно реплицируемым виртуальным машинам с устройства Миграции Azure.

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

Окно отключения

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

Примечание.

• Существующие циклы репликации в начале окна отключения будут завершены до того, как репликация будет приостановлена.
• Для любой миграции, инициированной во время отключения, окончательный реплика tion не будет выполняться, что приведет к сбою миграции.

Указать окно отключения для устройства можно, создав или обновив файл GatewayDataWorker.json в папке C:\ProgramData\Microsoft Azure\Config. Типичный файл имеет следующий вид.

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

Список окон отключения — это строка с разделителями "|" в формате DayOfWeek;StartTime;Duration. Длительность можно указать в днях, часах и минутах. Например, окно отключения можно указать следующим образом.

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

Первое значение в приведенном выше примере указывает, что окно отключения начинается каждый понедельник в 07:00 по местному времени (время на устройстве) и длится 7 часов.

После создания или обновления файла GatewayDataWorker.js с использованием этих данных необходимо перезапустить службу шлюза на устройстве, чтобы эти изменения вступили в силу.

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

Следующие шаги

Миграция виртуальных машин VMware без агента.