Архитектура миграции без агента

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

Компонент	Область/регион	Отток подписок	Описание
Хранилище служб восстановления	Регион проекта Миграции 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 автоматически шифрует данные при сохранении данных в облаке (шифрование неактивных данных).

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

Примечание.

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

Указать окно отключения для устройства можно, создав или обновив файл 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 без агента.