Миграция и модернизация: Часто задаваемые вопросы

Эта статья отвечает на распространенные вопросы о средстве миграции и модернизации. Если у вас есть другие вопросы, ознакомьтесь с этими ресурсами:

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

Общие вопросы

Каковы варианты миграции с помощью инструмента миграции и модернизации?

Инструмент миграции и модернизации предлагает миграцию без агентов и с агентами для переноса ваших исходных серверов и виртуальных машин (ВМ) в Azure.

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

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

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

Для VMware ВМ и Hyper-V ВМ доступны опции репликации без агента.

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

Опция миграции на основе агента может быть использована для:

• Виртуальные машины VMware.
• Hyper-V виртуальных машин.
• Физические серверы.
• Виртуальные машины, работающие в AWS.
• Виртуальные машины, работающие на GCP.
• Виртуальные машины, работающие на другом поставщике виртуализации.

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

Миграция без использования агентских программ предлагает больше удобства и простоты по сравнению с вариантами репликации на основе агента для виртуальных машин VMware и Hyper-V. Однако вам стоит рассмотреть возможность использования сценария на основе агента для следующих случаев использования:

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

• Отсутствие vCenter Server: Если у вас нет vCenter Server, вы можете рассматривать свои VMware VM как физические серверы и использовать миграционный процесс с агентом.

Чтобы узнать больше, ознакомьтесь с Выберите вариант миграции VMware.

Какие регионы поддерживаются для миграции с Azure Migrate?

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

Могу ли я использовать тот же проект Azure Migrate, чтобы осуществлять миграцию в несколько регионов?

Хотя в проекте Azure Migrate вы можете создавать оценки для нескольких регионов, один проект Azure Migrate можно использовать для миграции серверов только в один регион Azure. Вы можете создать больше проектов Azure Migrate для других регионов.

• Для миграций VMware без агентов целевой регион блокируется, когда вы включаете первую репликацию.
• Для миграции на основе агента (VMware, физические серверы и серверы из других облаков) целевой регион блокируется при выборе кнопки "Создать ресурсы " на портале при настройке устройства репликации.
• Для миграций без агента Hyper-V целевой регион блокируется при выборе кнопки "Создать ресурсы " на портале при настройке поставщика репликации Hyper-V.

Можно ли использовать один и тот же проект Azure Migrate для миграции на несколько подписок?

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

Целевая область заблокирована.

• После первой репликации для миграций VMware без агентов.
• Во время установки устройства репликации для миграций, основанных на агентах.
• Во время установки поставщика Hyper-V для миграций без использования агента Hyper-V.

Поддерживает ли Azure Migrate Azure Resource Graph?

В настоящее время Azure Migrate не интегрирован с Azure Resource Graph. Он поддерживает выполнение запросов, связанных с Azure Resource Graph.

Как данные передаются из локальной среды в Azure? Она шифруется перед передачей?

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

Могу ли я использовать хранилище служб восстановления, созданное с помощью Azure Migrate, для сценариев восстановления после аварий?

Мы не рекомендуем использовать хранилище служб восстановления, созданное Azure Migrate, для сценариев аварийного восстановления, так как это может привести к сбоям при запуске репликации в Azure Migrate.

Какова разница между операциями тестовой миграции и миграции?

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

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

Существует ли возможность отката для Azure Migrate?

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

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

Можно ли выбрать виртуальную сеть и подсеть для проведения тестовой миграции?

Вы можете выбрать виртуальную сеть для тестовых миграций. Azure Migrate автоматически выбирает подсеть на основе следующей логики:

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

Почему кнопка «Тестовая миграция» отключена на моём сервере?

Кнопка Test Migration может быть отключена в следующих случаях:

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

Что произойдет, если я не очищу свою пробную миграцию?

Тестовая миграция имитирует фактическую миграцию путем создания тестовой виртуальной машины Azure с использованием реплицированных данных. Сервер развернут с копией реплицированных данных на определенный момент времени в целевой группе ресурсов (выбранной при включении репликации) с суффиксом -test. Тестовые миграции предназначены для проверки функциональности сервера с целью минимизации проблем после миграции.

Если после тестирования тестовая миграция не завершена, тестовая виртуальная машина продолжает работать в Azure и начисляются расходы. Чтобы очистить после тестовой миграции, перейдите к представлению Replicating machines в инструменте Migration and modernization и используйте действие Cleanup test migration на машине.

Как мне узнать, успешно ли переместилась моя виртуальная машина?

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

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

Что произойдет, если я не остановлю репликацию после миграции?

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

Что произойдет, если я не выберу "Завершить миграцию" после миграции?

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

Как я могу перенести машины на базе UEFI в Azure как виртуальные машины первого поколения Azure?

Инструмент модернизации и миграции переносит машины на основе UEFI в Azure в виде виртуальных машин второго поколения Azure. Если вы хотите мигрировать их как виртуальные машины первого поколения Azure, сначала измените тип загрузки на BIOS перед началом репликации, а затем используйте инструмент Migration and modernization для миграции в Azure.

Конвертирует ли Azure Migrate машины на основе UEFI в машины на основе BIOS и переносит их в Azure как виртуальные машины поколения 1 Azure?

Инструмент миграции и модернизации переносит все машины на основе UEFI в Azure как виртуальные машины второго поколения Azure. Мы больше не поддерживаем преобразование виртуальных машин на основе UEFI в виртуальные машины на основе BIOS. Все машины на базе BIOS мигрированы в Azure только как виртуальные машины поколения 1 Azure.

Какие операционные системы поддерживаются для миграции машин на базе UEFI в Azure?

Могу ли я перенести контроллеры домена Active Directory с использованием Azure Migrate?

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

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

• Перенос в изолированную среду в Azure, которая требует собственных контроллеров домена.
• Тестирование приложений в среде песочницы.

Могу ли я обновить свою ОС во время миграции?

Инструмент Миграция и модернизация теперь поддерживает обновление операционной системы Windows во время миграции. Вариант не доступен для Linux в данный момент. Получите больше информации о обновлении Windows OS.

Нужен ли мне VMware vCenter для миграции виртуальных машин VMware?

Чтобы перенести виртуальные машины VMware, используя миграцию на основе агента VMware или без него, сервер vCenter должен управлять хостами ESXi, на которых расположены виртуальные машины. Если у вас нет vCenter Server, вы можете мигрировать виртуальные машины VMware как физические серверы. Подробнее.

Могу ли я объединить несколько исходных виртуальных машин в одну виртуальную машину в процессе миграции?

Инструмент миграции и модернизации в настоящее время поддерживает миграции на эквивалентной основе. Мы не поддерживаем объединение серверов в процессе миграции.

Будут ли Windows Server 2008 и 2008 R2 поддерживаться в Azure после миграции?

Вы можете перенести ваши локальные серверы Windows Server 2008 и 2008 R2 на виртуальные машины Azure и получать расширенные обновления безопасности в течение трёх лет после дат окончания поддержки без дополнительных затрат, кроме стоимости эксплуатации виртуальной машины. Вы можете использовать инструмент миграции и модернизации, чтобы перенести рабочие нагрузки Windows Server 2008 и 2008 R2.

Как перенести Windows Server 2003, работающий на VMware/Hyper-V, в Azure?

Расширенная поддержка Windows Server 2003 завершилась 14 июля 2015 года. Команда поддержки Azure продолжает помогать в решении проблем, связанных с работой Windows Server 2003 на платформе Azure. Однако эта поддержка ограничивается проблемами, которые не требуют устранения неполадок или патчей на уровне ОС.

Рекомендуется перенести приложения в экземпляры Azure с более новой версией Windows Server, чтобы обеспечить эффективное использование гибкости и надежности облака Azure.

Если вы все же решите перенести Windows Server 2003 в Azure, вы можете использовать инструмент миграции и модернизации, если ваша установка Windows Server является виртуальной машиной, работающей на VMware или Hyper-V. Для получения дополнительной информации см. Подготовка машин Windows Server 2003 к миграции.

Миграция VMware без агента

Как работает миграция без агентов?

Инструмент Миграции и модернизации предоставляет варианты репликации без агентов для миграции виртуальных машин VMware и Hyper-V, работающих под управлением Windows или Linux. Инструмент предлагает еще один вариант репликации на основе агентов для серверов Windows и Linux. Этот другой вариант может быть использован для миграции физических серверов и x86/x64 виртуальных машин у таких провайдеров, как VMware, Hyper-V, AWS и GCP.

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

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

Когда для виртуальной машины (VM) настраивается репликация, она сначала проходит фазу начальной репликации. В процессе начальной репликации создается моментальный снимок виртуальной машины, и полная копия данных с дисков моментальных снимков реплицируется на управляемые диски в вашей подписке. После завершения начальной репликации для ВМ, процесс репликации переходит в фазу инкрементальной репликации (дельта-репликации).

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

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

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

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

Чтобы начать, обратитесь к учебникам безагентной миграции VMware и безагентной миграции Hyper-V.

Как определить потребность в пропускной способности для моих миграций?

Диапазон факторов может повлиять на объем пропускной способности, необходимый для репликации данных в Azure. Требование к пропускной способности зависит от того, насколько быстро устройство Azure Migrate на площадке может читать и реплицировать данные в Azure. Репликация имеет две фазы: начальную репликацию и дельта-репликацию.

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

Вы можете рассчитать требования к пропускной способности, исходя из:

• Объем данных, которые вам нужно переместить в волне.
• Время, которое вы хотите выделить для начального процесса репликации.

Желательно, чтобы первоначальная репликация была завершена как минимум за 3-4 дня до начала фактического окна миграции. Этот график дает вам достаточное время для выполнения тестовой миграции перед фактическим окном и позволяет свести время простоя в окне к минимуму.

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

• Время, необходимое для завершения начальной репликации = {размер дисков (или используемый размер, если доступен) * 0,7 (предполагая средний уровень сжатия 30% — консервативная оценка)}/доступная пропускная способность для репликации.

Как ограничить репликацию при использовании устройства Azure Migrate для безагентной репликации VMware?

Вы можете ограничивать, используя NetQosPolicy. Этот метод ограничения применяется только к исходящим соединениям от устройства Azure Migrate.

Например, значение AppNamePrefix для использования в NetQosPolicy — это GatewayWindowsService.exe. Вы можете создать политику на устройстве Azure Migrate для ограничения трафика репликации с этого устройства, создав такую политику:

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

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

#Replace with an account that's part of the local Administrators group
$User = "localVmName\userName"

#Set the task names
$ThrottleBandwidthTask = "ThrottleBandwidth"
$IncreaseBandwidthTask = "IncreaseBandwidth"

#Create a directory to host PowerShell scaling scripts
if (!(Test-Path "C:\ReplicationBandwidthScripts"))
{
 New-Item -Path "C:\" -Name "ReplicationBandwidthScripts" -Type Directory
}

#Set your minimum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 10 MBps
New-Item C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 10MB'
$ThrottleBandwidthScript = "C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1"

#Set your maximum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 1000 MBps
New-Item C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 1000MB'
$IncreaseBandwidthScript = "C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1"

#Timezone set on the Azure Migrate Appliance (VM) is used; change the frequency to meet your needs
#In this example, the bandwidth is being throttled every weekday at 8:00 AM local time
#The bandwidth is being increased every weekday at 6:00 PM local time
$ThrottleBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 8:00am
$IncreaseBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 6:00pm

#Setting the task action to execute the scripts
$ThrottleBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $ThrottleBandwidthScript"
$IncreaseBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $IncreaseBandwidthScript"

#Creating the scheduled tasks
Register-ScheduledTask -TaskName $ThrottleBandwidthTask -Trigger $ThrottleBandwidthTrigger -User $User -Action $ThrottleBandwidthAction -RunLevel Highest -Force
Register-ScheduledTask -TaskName $IncreaseBandwidthTask -Trigger $IncreaseBandwidthTrigger -User $User -Action $IncreaseBandwidthAction -RunLevel Highest -Force

Как коэффициент оттока влияет на репликацию без агентов?

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

Как часто запланирован цикл репликации?

Формула для планирования следующего цикла репликации: (время предыдущего цикла / 2) или один час, в зависимости от того, что больше.

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

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

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

Как репликация без агентов влияет на серверы VMware?

Репликация без агента приводит к некоторому влиянию на производительность серверов VMware vCenter и хостов VMware ESXi. Поскольку репликация без использования агента использует снимки, она потребляет IOPS на хранилище, поэтому требуется пропускная способность для некоторых IOPS. Мы не рекомендуем использовать репликацию без агента, если в вашей среде существуют ограничения на хранение данных или IOPS.

Можно ли реплицировать выключенные виртуальные машины?

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

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

Можно ли использовать миграцию Azure для переноса веб-приложений в Службу приложений Azure?

Вы можете выполнить масштабную миграцию ASP.NET веб-приложений без использования агента, работающих на веб-серверах IIS, которые размещены на операционной системе Windows в среде VMware. Подробнее.

Миграция на основе агентной модели

Как перенести мои экземпляры AWS EC2 в Azure?

Обзор обнаружения, оценки и миграции виртуальных машин Amazon Web Services (AWS) в Azure.

Как работает миграция, основанная на агентах?

Инструмент Миграции и модернизации предоставляет возможность миграции на основе агентов для переноса серверов Windows и Linux, которые работают на физических серверах или как виртуальные машины x86/x64 на платформах таких как VMware, Hyper-V, AWS и GCP.

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

Где мне установить устройство репликации для миграций на основе агента?

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

Можно ли перенести виртуальные машины AWS, работающие на операционной системе Amazon Linux?

Виртуальные машины на базе Amazon Linux не могут быть перенесены в исходном состоянии, так как операционная система Amazon Linux поддерживается только на AWS.

Чтобы перенести рабочие нагрузки, выполняемые на Amazon Linux, вы можете запустить виртуальную машину CentOS/RHEL в Azure. Затем вы можете перенести рабочую нагрузку, работающую на машине AWS Linux, с использованием соответствующего подхода к миграции нагрузки. Например, в зависимости от рабочей нагрузки, могут существовать инструменты, специфичные для рабочей нагрузки, чтобы помочь в миграции, такие как инструменты для работы с базами данных или инструменты для развертывания веб-серверов.

Как определить потребность в пропускной способности для моих миграций?

Диапазон факторов может повлиять на объем пропускной способности, необходимый для репликации данных в Azure. Требование к пропускной способности зависит от того, насколько быстро устройство Azure Migrate на площадке может читать и реплицировать данные в Azure. Репликация имеет две фазы: начальную репликацию и дельта-репликацию.

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

Для метода репликации на основе агентской технологии, Azure Site Recovery Deployment Planner может помочь профилировать среду для изменений данных и предсказать необходимую потребность в пропускной способности. Чтобы узнать больше, прочитайте План развертывания VMware.

Миграция Hyper-V без агентов

Как работает миграция без агентов?

Инструмент Миграции и модернизации предоставляет варианты репликации без агентов для миграции виртуальных машин VMware и Hyper-V, работающих под управлением Windows или Linux. Инструмент предлагает еще один вариант репликации на основе агентов для серверов Windows и Linux. Этот другой вариант можно использовать для миграции физических серверов и виртуальных машин x86/x64 у таких поставщиков, как VMware, Hyper-V, AWS и GCP.

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

Опция репликации без агента работает, используя механизмы, предоставляемые поставщиком виртуализации (VMware или Hyper-V). Для виртуальных машин Hyper-V механизм репликации без агента реплицирует данные с дисков виртуальных машин, используя снимки виртуальной машины и возможность отслеживания изменений реплики Hyper-V.

Когда для виртуальной машины (VM) настраивается репликация, она сначала проходит фазу начальной репликации. В процессе начальной репликации создается моментальный снимок виртуальной машины, и полная копия данных с дисков моментальных снимков реплицируется на управляемые диски в вашей подписке. После завершения начальной репликации для ВМ, процесс репликации переходит в фазу инкрементальной репликации (дельта-репликации).

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

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

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

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

Чтобы начать, обратитесь к руководству по миграции без агента в Hyper-V.

Как определить потребность в пропускной способности для моих миграций?

Диапазон факторов может повлиять на объем пропускной способности, необходимый для репликации данных в Azure. Требование к пропускной способности зависит от того, насколько быстро устройство Azure Migrate на площадке может читать и реплицировать данные в Azure. Репликация имеет две фазы: начальную репликацию и дельта-репликацию.

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

Вы можете рассчитать требования к пропускной способности, исходя из:

• Объем данных, которые вам нужно переместить в волне.
• Время, которое вы хотите выделить для начального процесса репликации.

Желательно, чтобы первоначальная репликация завершилась как минимум за 3-4 дня до фактического окна миграции. Этот график дает вам достаточное время для выполнения тестовой миграции перед фактическим окном и позволяет свести время простоя в окне к минимуму.

Как откатить, если что-то происходит неправильно во время процесса миграции?

В настоящее время Azure Migrate не поддерживает возможность отката, что означает, что после того как пользователи мигрируют, они не могут вернуться в он-премис.

Какие стратегии используются для уменьшения простоя во время миграции?

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

Связанный контент

• Узнайте больше о миграции VMware ВМ, Hyper-V ВМ и физических серверов.