Миграция и модернизация: распространенные вопросы
Внимание
Эта статья ссылается на CentOS, дистрибутив Linux, который является состоянием "Конец жизни" (EOL). Пожалуйста, рассмотрите возможность использования и планирования соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.
В этой статье приводятся ответы на распространенные вопросы о средстве миграции и модернизации. Если у вас есть другие вопросы, проверьте следующие ресурсы:
- Общие вопросы о службе "Миграция Azure"
- Вопросы об устройстве Миграции Azure
- Вопросы об обнаружении, оценке и визуализации зависимостей.
- Получение ответов на вопросы на форуме службы "Миграция Azure"
Общие вопросы
Каковы варианты миграции в миграции и модернизации?
Средство миграции и модернизации предлагает два варианта переноса исходных серверов и виртуальных машин в Azure: миграция без агента и миграция на основе агента.
Независимо от выбранного варианта миграции, первый шаг для миграции сервера с помощью средства миграции и модернизации — начать репликацию сервера. При этом выполняется начальная репликация данных виртуальной машины или сервера в Azure. После завершения начальной репликации устанавливается текущая репликация (текущая разностная синхронизация) для миграции добавочных данных в Azure. Когда операция достигнет этапа разностной синхронизации, вы сможете выполнить миграцию в Azure в любое время.
Ниже приведены некоторые рекомендации, которые следует учитывать при выборе варианта миграции.
Миграции без агента не требуют развертывания программного обеспечения (агентов) на исходных виртуальных машинах или серверах. Параметр без агента управляет репликацией путем интеграции с функциями, предоставляемыми поставщиком виртуализации. Параметры репликации без агента доступны для виртуальных машин VMware и виртуальных машин Hyper-V.
Для миграции на основе агента требуется, чтобы на исходных виртуальных машинах или компьютерах, миграцию которых нужно выполнить, было установлено программное обеспечение (агенты) службы "Миграция Azure". Вариант на основе агента не зависит от платформы виртуализации для функций репликации. Таким образом, его можно использовать с любым сервером, на котором работает архитектура x86/x64, и версией операционной системы, поддерживаемой методом репликации на основе агента.
Параметр миграции на основе агента можно использовать для виртуальных машин VMware, виртуальных машин Hyper-V, физических серверов, виртуальных машин, работающих на AWS, виртуальных машин, работающих на GCP, или для виртуальных машин, работающих в другом поставщике виртуализации. Миграция на основе агента рассматривает компьютеры как физические серверы для целей миграции.
Хотя миграция без агента обеспечивает дополнительное удобство и простоту по сравнению с вариантами репликации на основе агента для поддерживаемых сценариев (VMware и Hyper-V), вам может потребоваться использовать сценарий на основе агента в следующих вариантах использования:
- Ограниченная среда операций ввода-вывода в секунду. Для репликации без агента используются моментальные снимки и потребляются операции ввода-вывода в секунду или пропускная способность хранилища. Рекомендуем использовать метод миграции на основе агента, если в вашей среде есть ограничения на хранилище или операции ввода-вывода в секунду.
- Если у вас нет vCenter Server, виртуальные машины VMware можно рассматривать как физические серверы и использовать рабочий процесс миграции на основе агента.
Чтобы узнать больше, ознакомьтесь с этой статьей и сравните варианты миграций для VMware.
Какие географические регионы поддерживаются для миграции с помощью службы "Миграция 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. Она поддерживает выполнение запросов, связанных с ARG.
Как данные передаются из локальной среды в 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 только в качестве виртуальных машин Azure поколения 1.
Какие операционные системы поддерживаются для миграции компьютеров на основе UEFI в Azure?
| Операционные системы, поддерживаемые для компьютеров на основе UEFI | VMware в Azure без агента | Hyper-V в Azure без агента | VMware на основе агента, физические и другие облака в Azure |
|---|---|---|---|
| Windows Server 2019, 2016, 2012 R2 и 2012 | Y | Y | Y |
| Windows 10 Pro, Windows 10 Корпоративная; | Y | Y | Y |
| SUSE Linux Enterprise Server 15 SP1 | Y | Y | Y |
| SUSE Linux Enterprise Server 12 SP4; | Y | Y | Y |
| Ubuntu Server 16.04, Ubuntu Server 18.04, Ubuntu Server 19.04, Ubuntu Server 19.10; | 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 7.7, Oracle Linux 7.7-CI. | Y | Y | Y |
Можно ли перенести контроллеры домена Active Directory с помощью службы "Миграция Azure"?
Средство миграции и модернизации не зависит от приложений и работает для большинства приложений. При миграции сервера с помощью средства миграции и модернизации все приложения, установленные на сервере, переносятся вместе с ним. Однако для некоторых приложений альтернативные методы миграции, отличные от миграции и модернизации, лучше подходят для миграции. Для Active Directory, если гибридные среды, в которых локальный сайт подключен к среде Azure, вы можете расширить каталог в Azure, добавив дополнительные контроллеры домена в Azure и настроив репликацию Active Directory. При миграции в изолированную среду в Azure, требующей собственных контроллеров домена (или тестирования приложений в изолированной среде), можно перенести серверы с помощью средства миграции и модернизации.
Можно ли обновить операционную систему во время миграции?
Средство миграции и модернизации теперь поддерживает обновление ОС Windows во время миграции. Для Linux этот параметр в настоящее время недоступен. Дополнительные сведения об обновлении ОС Windows.
Требуется ли VMware vCenter для переноса виртуальных машин VMware?
Чтобы перенести виртуальные машины VMware с помощью миграции VMware на основе агента или без агента, узлами ESXi, на которых расположены виртуальные машины, должен управлять vCenter Server. Если у вас нет 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 используется для отслеживания изменений между последовательными циклами репликации.
При выполнении операции миграции на реплицируемой виртуальной машине вы можете завершить работу локальной виртуальной машины и выполнить последнюю добавочную репликацию, чтобы обеспечить нулевой потери данных. При миграции управляемые диски реплики, соответствующие виртуальной машине, используются для создания виртуальной машины в Azure.
Чтобы приступить к работе, ознакомьтесь с учебниками по миграции без агента для VMware и миграции без агента для Hyper-V.
Как определить требования к пропускной способности для миграций?
Пропускная способность репликации данных в Azure зависит от ряда факторов, а также от того, насколько быстро локальное устройство службы "Миграция Azure" может считывать и реплицировать данные в Azure. Репликация состоит из двух этапов: начальная репликация и разностная репликация данных.
При запуске репликации для виртуальной машины выполняется начальный цикл репликации, в котором реплицируются полные копии дисков. После завершения начальной репликации планируются периодические циклы инкрементной репликации (разностные циклы) для передачи изменений, внесенных с момента предыдущего цикла репликации.
Вы можете использовать требования к пропускной способности в зависимости от объема данных, которые необходимо переместить на текущем этапе, и времени, в течение которого требуется выполнить начальную репликацию (в идеале необходимо, чтобы начальная репликация была выполнена по крайней мере за 3–4 дня до фактического окна миграции, чтобы вы смогли обеспечить себе достаточное количество времени для выполнения тестовой миграции до окна и уменьшить время простоя до минимума на этот период).
Вы можете оценить пропускную способность или количество времени, необходимое для миграции виртуальных машин VMware без агента, с помощью следующей формулы:
Время для завершения начальной репликации = {размер дисков (или уже использованный размер, если он доступен) * 0,7 (предполагается, что среднее время сжатия составляет 30 % — консервативная оценка)} / пропускная способность, доступная для репликации.
Как отрегулировать репликацию с помощью устройства службы "Миграция Azure" для репликации VMware без агента?
Регулирование можно выполнить с помощью NetQosPolicy. Обратите внимание, что это регулирование применимо только к исходящим подключениям из устройства службы "Миграция Azure". Например:
Префикс AppNamePrefix, который нужно использовать в NetQosPolicy — GatewayWindowsService.exe. Вы можете создать политику на устройстве Миграции Azure, чтобы регулировать трафик репликации с устройства, создав такую политику.
New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB
Чтобы увеличить и уменьшить пропускную способность репликации в зависимости от расписания, можно использовать назначенное задание Windows, чтобы масштабировать пропускную способность по мере необходимости. Для снижения пропускной способности будет использоваться одна задача, а для увеличения — другая. Примечание. Перед выполнением приведенных ниже команд необходимо создать политику NetQosPolicy, описанную выше.
#Replace with an account 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) will be 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. Поскольку репликация без агента использует моментальные снимки, то она потребляет операции ввода-вывода в секунду в хранилище, поэтому необходима пропускная способность хранилища операций ввода-вывода в секунду. Мы не рекомендуем использовать репликацию без агента, если в вашей среде есть ограничения на хранение или операции ввода-вывода в секунду.
Можно ли использовать миграцию Azure для переноса веб-приложений в службу приложение Azure?
Вы можете выполнять масштабируемую миграцию ASP.NET веб-приложений, работающих на веб-серверах IIS, размещенных в ОС Windows в среде VMware. Подробнее.
Миграция на основе агента
Как перенести экземпляры AWS EC2 в Azure?
Ознакомьтесь с этой статьей, чтобы узнать, как обнаруживать, оценивать и переносить экземпляры AWS EC2 в Azure.
Как работает миграция на основе агента?
Помимо вариантов миграции без агента для виртуальных машин VMware и виртуальных машин Hyper-V, средство миграции и модернизации предоставляет возможность миграции серверов на основе агента для миграции серверов Windows и Linux, работающих на физических серверах, или на виртуальных машинах x86/x64 на VMware, Hyper-V, AWS, Google Cloud Platform и т. д.
Метод миграции на основе агента использует программное обеспечение агента, установленное на переносимом сервере, для репликации данных сервера в Azure. В процессе репликации используется архитектура разгрузки, в которой агент ретранслирует данные репликации на выделенный сервер репликации, называемый устройством репликации или сервером конфигурации (либо на сервер обработки горизонтального увеличения масштаба). Узнайте больше о том, как работает вариант миграции на основе агента.
Примечание. Устройство репликации отличается от устройства обнаружения службы "Миграция Azure" и должно быть установлено на отдельном или выделенном компьютере.
Где следует установить устройство репликации для миграций на основе агента?
Устройство репликации следует установить на выделенном компьютере. Устройство репликации не следует устанавливать на исходном компьютере, который необходимо реплицировать, или на устройстве службы "Миграция Azure" (для обнаружения и оценки), которое вы могли установить ранее. Дополнительные сведения см. в этом учебнике.
Можно ли перенести виртуальные машины AWS с операционной системой Amazon Linux?
Виртуальные машины под управлением Amazon Linux нельзя перенести так, как ос Amazon Linux поддерживается только в AWS. Чтобы перенести рабочие нагрузки, выполняемые в Amazon Linux, можно запустить виртуальную машину CentOS или RHEL в Azure и перенести рабочую нагрузку, запущенную на компьютере AWS Linux, с помощью соответствующего подхода к миграции рабочей нагрузки. Например, в зависимости от рабочей нагрузки могут применяться специальные средства для упрощения миграции, например для баз данных или средств развертывания в случае веб-серверов.
Как определить требования к пропускной способности для миграций?
Пропускная способность репликации данных в Azure зависит от ряда факторов, а также от того, насколько быстро локальное устройство службы "Миграция Azure" может считывать и реплицировать данные в Azure. Репликация состоит из двух этапов: начальная репликация и разностная репликация данных.
При запуске репликации для виртуальной машины выполняется начальный цикл репликации, в котором реплицируются полные копии дисков. После завершения начальной репликации планируются периодические циклы инкрементной репликации (разностные циклы) для передачи изменений, внесенных с момента предыдущего цикла репликации.
В случае с методом репликации на основе агента планировщик развертывания может помочь с профилированием среды для обработки данных и прогнозированием необходимых требований к пропускной способности. Дополнительные сведения см. в этой статье
Миграция 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 используется для отслеживания изменений между последовательными циклами репликации.
При выполнении операции миграции на реплицируемой виртуальной машине вы можете завершить работу локальной виртуальной машины и выполнить последнюю добавочную репликацию, чтобы обеспечить нулевой потери данных. При миграции управляемые диски реплики, соответствующие виртуальной машине, используются для создания виртуальной машины в Azure.
Чтобы приступить к работе, ознакомьтесь с руководством по миграции Hyper-V без агента.
Как определить требования к пропускной способности для миграций?
Пропускная способность репликации данных в Azure зависит от ряда факторов, а также от того, насколько быстро локальное устройство службы "Миграция Azure" может считывать и реплицировать данные в Azure. Репликация состоит из двух этапов: начальная репликация и разностная репликация данных.
При запуске репликации для виртуальной машины выполняется начальный цикл репликации, в котором реплицируются полные копии дисков. После завершения начальной репликации планируются периодические циклы инкрементной репликации (разностные циклы) для передачи изменений, внесенных с момента предыдущего цикла репликации.
Вы можете использовать требования к пропускной способности в зависимости от объема данных, которые необходимо переместить на текущем этапе, и времени, в течение которого требуется выполнить начальную репликацию (в идеале необходимо, чтобы начальная репликация была выполнена по крайней мере за 3–4 дня до фактического окна миграции, чтобы вы смогли обеспечить себе достаточное количество времени для выполнения тестовой миграции до окна и уменьшить время простоя до минимума на этот период).
Следующие шаги
Дополнительные сведения о переносе виртуальных машин VMware, виртуальных машин Hyper-V и физических серверов.