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

В этой статье приводятся ответы на распространенные вопросы о средстве миграции и модернизации . Если у вас есть еще вопросы, воспользуйтесь следующими ресурсами:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения см. в разделе "Выбор варианта миграции VMware".

Какие географические регионы поддерживаются для миграции с помощью службы "Миграция Azure"?

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

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

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

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

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

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

Целевой регион заблокирован:

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

Поддерживает ли Служба "Миграция Azure" Azure Resource Graph?

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

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

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

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

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

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

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

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

Существует ли параметр отката для службы "Миграция Azure"?

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

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

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

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

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

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

Кнопка "Тестовая миграция" может быть отключена в следующих сценариях:

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

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

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

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

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

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

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

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

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

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

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

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

Средство миграции и модернизации переносит компьютеры на основе UEFI в Azure в качестве виртуальных машин поколения 2 Azure. Если вы хотите перенести их в качестве виртуальных машин поколения 1 Azure, преобразуйте тип загрузки в BIOS перед началом репликации, а затем используйте средство миграции и модернизации для миграции в Azure.

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

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

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

Операционные системы, поддерживаемые для компьютеров на основе UEFI	VMware в Azure без агента	Hyper-V в Azure без агента	VMware на основе агента, физические и другие облака в Azure
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012	Y	Y	Y
Windows 11 Pro, Windows 11 Enterprise	Y	Y	Y
Windows 10 Pro, Windows 10 Корпоративная;	Y	Y	Y
SUSE Linux Enterprise Server 15 с пакетом обновления 1 (SP1), SP2, SP3, SP4, SP5, SP6	Y	Y	Y
SUSE Linux Enterprise Server 12 SP4;	Y	Y	Y
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS	Y	Y	Y
RHEL 9.x, 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x	Y	Y	Y
CentOS Stream	Y	Y	Y
Oracle Linux 9, 8, 7.7-CI, 7.7, 6	Y	Y	Y

Можно ли перенести контроллеры домена Active Directory с помощью службы "Миграция Azure"?

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

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

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

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

Средство миграции и модернизации теперь поддерживает обновление ОС Windows во время миграции. Этот параметр в настоящее время недоступен для Linux. Дополнительные сведения об обновлении ОС Windows.

Требуется ли VMware vCenter для переноса виртуальных машин VMware?

Чтобы перенести виртуальные машины VMware с помощью агента VMware или миграции без агента, vCenter Server должен управлять узлами 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 для репликации данных с дисков виртуальных машин.

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

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

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

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

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

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

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

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

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

Вы можете выполнить требование пропускной способности на основе следующих способов:

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

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

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

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

Разделы справки регулирование репликации при использовании устройства службы "Миграция Azure" для репликации без агента VMware?

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

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

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 Server. Но когда я пытаюсь перенести виртуальные машины, я вижу только виртуальные машины, соответствующие одному из устройств.

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

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

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

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

Репликация виртуальных машин 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", используемом для обнаружения и оценки. Дополнительные сведения см. в статье "Миграция компьютеров в качестве физических серверов в Azure ".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете выполнить требование пропускной способности на основе следующих способов:

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

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

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

• Дополнительные сведения о переносе виртуальных машин VMware, виртуальных машин Hyper-V и физических серверов.