Migración y modernización: peguntas comunes
Este artículo responde a las preguntas más frecuentes sobre la herramienta de Migración y modernización. Si tiene otras preguntas, repase estos recursos:
- Obtenga Información general sobre Azure Migrate.
- Lea preguntas frecuentes sobre el dispositivo de Azure Migrate.
- Conozca más sobre la detección, valoración y visualización de dependencias.
- Publique preguntas en el foro de Azure Migrate.
Precaución
En este artículo, se hace referencia a CentOS, una distribución de Linux que tiene un estado de fin de vida. Tenga en cuenta su uso y planeación en consecuencia. Para obtener más información, consulte la guía de fin de vida de CentOS.
Preguntas generales
¿Cuáles son las opciones de migración en la herramienta de Migración y modernización?
La herramienta de Migración y modernización ofrece dos opciones para migrar sus servidores de origen y máquinas virtuales a Azure: migración sin agente y migración basada en agente.
Independientemente de la opción de migración elegida, el primer paso para migrar un servidor utilizando la herramienta de Migración y modernización es iniciar la replicación para el servidor. Se este modo, se realiza una replicación inicial de los datos de la máquina virtual o el servidor en Azure. Una vez completada la replicación inicial, se establece una replicación en curso (sincronización diferencial) que migra los datos incrementales a Azure. Una vez que la operación alcance la fase de sincronización diferencial, podrá optar por migrar a Azure en cualquier momento.
Tenga en cuenta la siguiente información a medida que decida qué opción de migración usar.
Las migraciones sin agente no requieren que se implemente software (agentes) en las máquinas virtuales o servidores de origen que se van a migrar. La opción sin agente orquesta la replicación al integrarse con la funcionalidad proporcionada por el proveedor de virtualización.
Las opciones de replicación sin agente están disponibles para las máquinas virtuales de VMware y las de Hyper-V.
Las migraciones basadas en agente requieren que instale software (agentes) de Azure Migrate en las máquinas virtuales de origen que va a migrar. La opción basada en agente no se basa en la plataforma de virtualización para la funcionalidad de replicación. Se puede usar con cualquier servidor que ejecute una arquitectura x86/x64 y una versión de un sistema operativo compatible con el método de replicación basado en agente.
La opción de migración basada en agente se puede usar para:
- VM de VMware.
- VM de Hyper-V.
- Servidores físicos.
- máquinas virtuales que se ejecutan en AWS.
- Máquinas virtuales que se ejecutan en GCP.
- Máquinas virtuales que se ejecutan en un proveedor de virtualización diferente.
La migración basada en agente trata a las máquinas como servidores físicos para la migración.
La migración sin agente ofrece mayor comodidad y simplicidad que las opciones de replicación basadas en agente para máquinas virtuales de VMware y Hyper-V. Sin embargo, puede considerar la posibilidad de usar el escenario basado en agente para los siguientes casos de uso:
Entornos restringidos por operaciones de entrada y salida por segundo (IOPS): la replicación sin agente usa instantáneas y consume IOPS o ancho de banda de almacenamiento. Se recomienda el método de migración basado en agente si hay restricciones de almacenamiento/IOPS en el entorno.
Sin vCenter Server: si no tiene un servidor vCenter Server, puede tratar las máquinas virtuales de VMware como servidores físicos y usar el flujo de trabajo de migración basado en agente.
Para más información, consulte Seleccione una opción de migración de VMware.
¿Qué zonas geográficas se admiten para la migración con Azure Migrate?
Revise las zonas geográficas admitidas para las nubes públicas y las gubernamentales.
¿Se puede usar el mismo proyecto de Azure Migrate para realizar la migración a varias regiones?
Aunque puede crear evaluaciones para varias regiones en un proyecto de Azure Migrate, se puede usar un proyecto de Azure Migrate para migrar servidores a una sola región de Azure. Puede crear más proyectos de Azure Migrate para otras regiones.
- En el caso de las migraciones de VMware sin agente, la región de destino se bloquea al habilitar la primera replicación.
- En el caso de las migraciones basadas en agentes (VMware, servidores físicos y servidores de otras nubes), la región de destino se bloquea cuando se selecciona el botón Crear recursos en el portal al configurar el dispositivo de replicación.
- En el caso de las migraciones de Hyper-V sin agente, la región de destino se bloquea cuando se selecciona el botón Crear recursos en el portal al configurar el proveedor de replicación de Hyper-V.
¿Se puede usar el mismo proyecto de Azure Migrate para realizar la migración a varias suscripciones?
Sí, puede usar el mismo proyecto de Azure Migrate para migrar a varias suscripciones con el mismo inquilino de Azure en la misma región de destino. Puede seleccionar la suscripción de destino al habilitar la replicación para una máquina o un conjunto de máquinas.
La región de destino está bloqueada:
- Después de la primera replicación para migraciones de VMware sin agente.
- Durante la instalación del dispositivo de replicación para migraciones basadas en agente.
- Durante la instalación del proveedor de Hyper-V para migraciones de Hyper-V sin agente.
¿Admite Azure Migrate Azure Resource Graph?
Actualmente, Azure Migrate no está integrado con Azure Resource Graph. Admite la realización de consultas relacionadas con Azure Resource Graph.
¿Cómo se transmiten los datos desde un entorno local a Azure? ¿Se cifran antes de la transmisión?
Con la replicación sin agente, el dispositivo de Azure Migrate comprime y cifra los datos antes de cargarlos. Los datos se transmiten a través de un canal de comunicación seguro a través de HTTPS y usa TLS 1.2 o posterior. Además, Azure Storage cifra automáticamente los datos cuando conserva los datos en la nube (cifrado en reposo).
¿Puedo usar el almacén de Recovery Services creado por Azure Migrate en escenarios de recuperación ante desastres?
No se recomienda usar el almacén de Recovery Services creado por Azure Migrate para escenarios de recuperación ante desastres, ya que esto puede provocar errores de replicación de inicio en Azure Migrate.
¿Cuál es la diferencia entre las operaciones de migración de prueba y de migración?
La opción Migración de pruebas de permite probar y validar las migraciones antes de la migración real. La Migración de pruebas funciona al permitirle usar un entorno de espacio aislado en Azure para probar las máquinas virtuales antes de la migración real. Una red virtual de prueba que especifique demarca el entorno de espacio aislado. La operación de migración de pruebas no es disruptiva, siempre y cuando la red virtual de prueba esté lo suficientemente aislada. Una red virtual está suficientemente aislada cuando se diseñan las reglas de conexión entrantes y salientes para evitar conexiones no deseadas. Por ejemplo: restringe la conexión a máquinas locales.
Las aplicaciones pueden continuar ejecutándose en el origen mientras permiten realizar pruebas en una copia clonada dentro de un entorno de espacio aislado. Puede realizar varias pruebas, según sea necesario, para validar la migración, realizar pruebas de aplicaciones y resolver todos los problemas antes de la migración real.
¿Hay una opción de reversión para Azure Migrate?
Puede usar la opción Migración de pruebas para validar la funcionalidad y el rendimiento de la aplicación en Azure. Puede realizar cualquier número de migraciones de prueba y realizar la migración final después de establecer la confianza a través de la operación de Migración de pruebas.
Una migración de prueba no afecta a la máquina local, que permanece operativa y continúa replicando hasta que realice la migración real. Si hay algún error durante las pruebas de aceptación del usuario (UAT) para la migración de prueba, puede optar por posponer la migración final y mantener la máquina virtual o servidor de origen en ejecución y replicación en Azure. Puede volver a intentar la migración final después de resolver los errores.
Nota:
Después de realizar una migración final a Azure y de apagar la máquina de origen local, no puede realizar una reversión de Azure al entorno local.
¿Puedo seleccionar la red virtual y la subred que se van a usar para las migraciones de prueba?
Puede seleccionar una red virtual para realizar migraciones de prueba. Azure Migrate selecciona automáticamente una subred en función de la siguiente lógica:
- Si especifica una subred de destino (distinta de la predeterminada) como entrada al habilitar la replicación, Azure Migrate da prioridad a una subred con el mismo nombre en la red virtual que se usa para la migración de prueba.
- Si no se encuentra una subred con el mismo nombre, Azure Migrate selecciona alfabéticamente la primera subred disponible que no es una puerta de enlace, una puerta de enlace de aplicaciones, un firewall o una subred de Azure Bastion.
¿Por qué está deshabilitado el botón Probar migración para mi servidor?
El botón Migración de pruebas podría deshabilitarse en los escenarios siguientes:
- No puede iniciar una migración de prueba hasta que se complete una replicación inicial para la máquina virtual. El botón Migración de pruebas está deshabilitado hasta que se complete el proceso de replicación inicial. Puede realizar una migración de prueba después de que la máquina virtual esté en una fase de sincronización diferencial.
- El botón puede estar deshabilitado si ya se ha completado una migración de prueba, pero no se ha realizado una limpieza de esta para la máquina virtual. Realice una limpieza de la migración de prueba y vuelva a intentar la operación.
¿Qué sucede si no se limpia la migración de prueba?
Una migración de prueba simula la migración real mediante la creación de una máquina virtual de Azure de prueba mediante datos replicados. El servidor se implementa con una copia a un momento dado de los datos replicados en el grupo de recursos de destino (seleccionado al habilitar la replicación) con un sufijo -test. Las migraciones de prueba están diseñadas para validar la funcionalidad del servidor para minimizar los problemas posteriores a la migración.
Si la migración de prueba no se limpia después de las pruebas, la máquina virtual de prueba continúa ejecutándose en Azure y incurre en cargos. Para limpiar después de una migración de prueba, vaya a la Vista replicación de máquinas en la herramienta de migración y modernización y use la acción migración de pruebas de limpieza en la máquina.
¿Cómo sé si mi máquina virtual se ha migrado correctamente?
Después de migrar correctamente la máquina virtual o el servidor, puede ver y administrar la máquina virtual desde el panel Máquinas virtuales. Conéctese a la máquina virtual migrada para realizar la validación.
También puede revisar el estado del trabajo de para comprobar si la migración se completó correctamente. Si ve algún error, resíquelos y vuelva a intentar la operación de migración.
¿Qué ocurre si no detengo la replicación después de la migración?
Al detener la replicación, la herramienta Migración y modernización limpia los discos administrados de la suscripción que se creó para la replicación.
¿Qué ocurre si no selecciono Completar migración después de una migración?
Al seleccionar Completarde migración, la herramienta Migración y modernización limpia los discos administrados de la suscripción que se crearon para la replicación. Si no selecciona completar la migración después de una migración, seguirá generando cargos por estos discos. La Migración completa no afecta a los discos conectados a las máquinas que ya se han migrado.
¿Cómo puedo migrar a Azure máquinas basadas en UEFI-como máquinas de Azure de primera generación?
La herramienta Migración y modernización migra máquinas basadas en UEFI a Azure como máquinas virtuales de generación 2 de Azure. Si quiere migrarlas como máquinas virtuales de generación 1 de Azure, convierta el tipo de arranque en BIOS antes de iniciar la replicación y, a continuación, use la herramienta Migración y modernización para migrar a Azure.
¿Convierte Azure Migrate las máquinas virtuales basadas en UEFI en máquinas basadas en BIOS y las migra a Azure como máquinas virtuales de Azure de primera generación?
La herramienta migración y modernización migra todas las máquinas basadas en UEFI a Azure como máquinas virtuales de generación 2 de Azure. Ya no se admite la conversión de máquinas virtuales basadas en UEFI en máquinas virtuales basadas en BIOS. Todas las máquinas basadas en BIOS se migran a Azure solo como máquinas virtuales de generación 1 de Azure.
¿Qué sistemas operativos se admiten para la migración a Azure de máquinas basadas en UEFI?
Nota:
Si se admite una versión principal de un sistema operativo en la migración sin agente, se admiten automáticamente todas las versiones secundarias y kernels.
| Sistemas operativos compatibles con máquinas basadas en UEFI | De VMware sin agente a Azure | De Hyper-V sin agente a Azure | VMware basado en agente, físico y otras nubes en 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 Enterprise | Y | Y | Y |
| SUSE Linux Enterprise Server 15 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 |
¿Puedo migrar controladores de dominio de Active Directory mediante Azure Migrate?
La herramienta migración y modernización es independiente de la aplicación y funciona para la mayoría de las aplicaciones. Al migrar un servidor mediante la herramienta Migración y modernización, todas las aplicaciones que instale en el servidor se migran con él. Sin embargo, los métodos de migración alternativos podrían ser más adecuados para migrar algunas aplicaciones.
Para Active Directory, el tipo de entorno puede ser un factor. En un entorno híbrido con un sitio local conectado a su entorno de Azure, puede ampliar el directorio a Azure agregando controladores de dominio adicionales y configurando la replicación de Active Directory. Puede usar la herramienta migración y modernización si está:
- Migrando a un entorno aislado en Azure que requiere sus propios controladores de dominio.
- Probando aplicaciones en un entorno de espacio aislado.
¿Puedo actualizar mi sistema operativo durante la migración?
La herramienta migración y modernización ahora admite la actualización del sistema operativo Windows durante la migración. Esta función no está disponible actualmente. Obtenga más información sobre actualización del sistema operativo Windows.
¿Necesito VMware vCenter para migrar máquinas virtuales de VMware?
Para migrar máquinas virtuales de VMware mediante la migración basada en agente de VMware o sin agente, vCenter Server debe administrar los hosts ESXi en los que se encuentran las máquinas virtuales. Si no tiene vCenter Server, puede migrar máquinas virtuales de VMware como servidores físicos. Más información.
¿Puedo consolidar varias máquinas virtuales de origen en una sola máquina virtual durante la migración?
La herramienta migración y modernización admite actualmente migraciones similares. No se admite la consolidación de servidores durante la migración.
¿Windows Server 2008 y 2008 R2 serán compatibles en Azure después de la migración?
Puede migrar los servidores de Windows Server 2008 y 2008 R2 locales a máquinas virtuales de Azure y obtener actualizaciones de seguridad extendidas durante tres años después de las fechas de finalización del soporte técnico sin ningún cargo adicional por encima del costo de ejecutar la máquina virtual. Puede usar la herramienta migración y modernización para migrar las cargas de trabajo de Windows Server 2008 y 2008 R2.
¿Cómo se migra de Windows Server 2003 en ejecución en VMware o Hyper-V a Azure?
El soporte extendido de Windows Server 2003 finalizó el 14 de julio de 2015. El equipo de soporte técnico de Azure sigue contribuyendo a solucionar problemas relacionados con la ejecución de Windows Server 2003 en Azure. Sin embargo, este soporte se limita a los problemas que no requieren revisiones o ni soluciones en el nivel de sistema operativo.
Se recomienda migrar las aplicaciones a instancias de Azure que ejecutan una versión más reciente de Windows Server para asegurarse de que usa eficazmente la flexibilidad y confiabilidad de la nube de Azure.
Si todavía decide migrar Windows Server 2003 a Azure, puede usar la herramienta Migración y modernización si la implementación de Windows Server es una máquina virtual que se ejecuta en VMware o Hyper-V. Para obtener más información, vea Preparar las máquinas de Windows Server 2003 para la migración.
Migración de VMware sin agente
¿Cómo funciona la migración sin agente?
La herramienta Migración y modernización proporciona opciones de replicación sin agente para la migración de máquinas virtuales de VMware y Hyper-V que ejecutan Windows o Linux. La herramienta proporciona otra opción de replicación basada en agente para servidores Windows y Linux. Esta otra opción se puede usar para migrar servidores físicos y máquinas virtuales x86/x64 en proveedores como VMware, Hyper-V, AWS y GCP.
La replicación basada en agente requiere que instale software de agente en la máquina virtual o servidor que va a migrar. La opción sin agente no requiere que instale software en las máquinas virtuales, lo que puede ofrecer comodidad y simplicidad.
La opción de replicación sin agente usa mecanismos proporcionados por el proveedor de virtualización (VMware o Hyper-V). En el caso de las máquinas virtuales de VMware, el mecanismo de replicación sin agente usa instantáneas de VMware y tecnología de seguimiento de bloques modificados de VMware para replicar datos de discos de máquina virtual. Muchos productos de copia de seguridad usan un mecanismo similar. En el caso de las máquinas virtuales de Hyper-V, el mecanismo de replicación sin agente usa instantáneas de máquina virtual y la funcionalidad de seguimiento de cambios de la réplica de Hyper-V para replicar datos de discos de máquina virtual.
Cuando la replicación está configurada para una máquina virtual, la máquina virtual pasa primero por una fase de replicación inicial. Durante la replicación inicial, se toma una instantánea de máquina virtual y se replica una copia completa de los datos de los discos de instantáneas en discos administrados de la suscripción. Una vez completada la replicación inicial de la máquina virtual, el proceso de replicación cambia a una fase de replicación incremental (replicación diferencial).
La fase de replicación incremental aborda los cambios de datos que se produjeron desde el último ciclo de replicación completado. Estos cambios se replican periódicamente y se aplican a los discos administrados por réplica. Este proceso mantiene la replicación sincronizada con los cambios en la máquina virtual.
La tecnología de seguimiento de bloques modificados de VMware realiza un seguimiento de los cambios entre los ciclos de replicación de las máquinas virtuales de VMware. Al principio del ciclo de replicación, se toma una instantánea de la máquina virtual y se usa el seguimiento de bloques con cambios para obtener los cambios entre la instantánea actual y la última instantánea que se replicó correctamente. De este modo, solo es necesario replicar los datos que han cambiado desde el último ciclo de replicación completado para mantener sincronizada la replicación de la máquina virtual.
Al final de cada ciclo de replicación, se publica la instantánea y se realiza la consolidación de instantáneas para la máquina virtual. Del mismo modo, en el caso de las máquinas virtuales de Hyper-V, el motor de seguimiento de cambios de réplica de Hyper-V realiza un seguimiento de los cambios entre ciclos de replicación consecutivos.
Al realizar la operación de Migrate en una máquina virtual de replicación, puede apagar la máquina virtual local y realizar una replicación incremental final para garantizar una pérdida de datos cero. Cuando se realiza la replicación, los discos administrados por réplica que corresponden a la máquina virtual se usan para crear la máquina virtual en Azure.
Para empezar, consulte los tutoriales Migración sin agente de VMware y Migración sin agente de Hyper-V.
¿Cómo se mide el requisito de ancho de banda para las migraciones?
Un intervalo de factores puede afectar a la cantidad de ancho de banda que necesita para replicar datos en Azure. El requisito de ancho de banda depende de la rapidez con la que el dispositivo local de Azure Migrate puede leer y replicar los datos en Azure. La replicación tiene dos fases: la replicación inicial y la replicación diferencial.
Cuando se inicia la replicación de una máquina virtual, se produce un ciclo de replicación inicial en el que se replican las copias completas de los discos. Una vez completada la replicación inicial, se programan periódicamente ciclos de replicación incremental (ciclos diferenciales) para transferir los cambios que se hayan producido desde el ciclo de replicación anterior.
Puede solucionar el requisito de ancho de banda en función de:
- El volumen de datos que necesita mover en la onda.
- Tiempo que desea asignar para el proceso de replicación inicial.
Lo ideal es que quiera que la replicación inicial se complete al menos entre 3 y 4 días antes de la ventana de migración real. Esta escala de tiempo proporciona tiempo suficiente para realizar una migración de prueba antes de la ventana real y mantener el tiempo de inactividad durante la ventana como mínimo.
Puede calcular el ancho de banda o el tiempo necesario para la migración de máquinas virtuales de VMware sin agente con la siguiente fórmula:
- Tiempo necesario para completar la replicación inicial = {tamaño de los discos (o tamaño usado si está disponible) * 0,7 (suponiendo un 30 % de promedio de compresión, que es una estimación conservadora)}/ancho de banda disponible para la replicación.
¿Cómo se limita la replicación al usar el dispositivo de Azure Migrate para la replicación de VMware sin agente?
Puede limitar mediante NetQosPolicy. Este método de limitación solo se aplica a las conexiones salientes desde el dispositivo de Azure Migrate.
Por ejemplo, el valor de AppNamePrefix que se va a usar en NetQosPolicy es GatewayWindowsService.exe. Se puede crear una directiva en el dispositivo de Azure Migrate para limitar el tráfico de replicación desde el dispositivo mediante la creación de una directiva como la siguiente:
New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB
Para aumentar y reducir el ancho de banda de replicación según una programación, puede usar tareas programadas de Windows para escalar el ancho de banda según sea necesario. Una tarea reduce el ancho de banda y otra tarea aumenta el ancho de banda.
Nota:
Debe crear el NetQosPolicy mencionado anteriormente antes de ejecutar los comandos siguientes.
#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
¿Cómo afecta la tasa de modificación a la replicación sin agente?
Dado que la replicación sin agente incorpora datos, el patrón de modificación es más importante que la tasa de modificación. Cuando un archivo se escribe una y otra vez, la tasa no tiene un gran efecto. Sin embargo, un patrón en el que se escriben todos los demás sectores produce una gran renovación en el ciclo siguiente. Dado que minimiza la cantidad de datos que transfiere, permite que los datos se doblan tanto como sea posible antes de programar el siguiente ciclo.
¿Con qué frecuencia se programa un ciclo de replicación?
La fórmula para programar el siguiente ciclo de replicación es: (Tiempo de ciclo anterior / 2) o una hora, lo que sea mayor.
Por ejemplo, si una VM tarda cuatro horas en un ciclo diferencial, su siguiente ciclo se programa dos horas después y no en la próxima hora. El proceso es distinto inmediatamente después de la replicación inicial, en la que el primer ciclo diferencial se programa inmediatamente.
He implementado dos (o más) dispositivos para detectar máquinas virtuales en mi instancia de vCenter Server. Pero cuando intento migrar las máquinas virtuales, solo veo las máquinas virtuales que corresponden a uno de los dispositivos.
Si configura varios dispositivos, no se puede superponer entre las máquinas virtuales de las cuentas de vCenter proporcionadas. No se admiten los escenarios con detecciones con este tipo de superposición.
¿Cómo afecta la replicación sin agente a los servidores de VMware?
La replicación sin agente produce un impacto en el rendimiento de los hosts de VMware vCenter Server y VMware ESXi. Dado que la replicación sin agente utiliza instantáneas, consume IOPS en el almacenamiento, por lo que se necesita algo de ancho de banda de almacenamiento de IOPS. No se recomienda usar la replicación sin agente si hay restricciones en el almacenamiento o en el número de IOPS en el entorno.
¿Se pueden replicar máquinas virtuales apagadas?
Se admite la replicación de máquinas virtuales de VMware mientras están apagadas, pero solo en el enfoque sin agente.
Importante
No podemos garantizar que una máquina virtual apagada arranque correctamente, ya que no podemos comprobar su estado operativo antes de la replicación.
Se recomienda encarecidamente realizar una migración de prueba para asegurarse de que todo continúe sin problemas durante la migración real. Este método puede ser útil cuando el proceso de replicación inicial es largo o para máquinas virtuales de alta renovación, como servidores de bases de datos u otras cargas de trabajo que consumen mucho disco.
¿Puedo usar Azure Migrate para migrar mis aplicaciones web a Azure App Service?
Puede realizar una migración sin agente a escala de aplicaciones web para ASP.NET que se ejecutan en servidores web IIS hospedados en un sistema operativo Windows en un entorno de VMware. Más información.
Migración basada en agente
¿Cómo puedo migrar mis instancias de AWS EC2 a Azure?
Revise detectar, evaluar y migrar máquinas virtuales de Amazon Web Services (AWS) a Azure.
¿Cómo funciona la migración basada en agente?
La herramienta migración y modernización proporciona una opción de migración basada en agente para migrar servidores Windows y Linux que se ejecutan en servidores físicos o como máquinas virtuales x86/x64 en proveedores como VMware, Hyper-V, AWS y GCP.
El método de migración basado en agente usa software de agente para replicar los datos del servidor en Azure. Instale el software en el servidor que va a migrar. El proceso de replicación utiliza una arquitectura de descarga en la que el agente retransmite los datos de replicación a un servidor de replicación dedicado denominado "dispositivo de replicación" o servidor de configuración (o servidor de procesos en el caso de escalabilidad horizontal). Para obtener más información, consulte arquitectura de migración basada en agente.
Nota:
El dispositivo de replicación es diferente del dispositivo de detección de Azure Migrate y debe instalarse en una máquina independiente o dedicada.
¿Dónde se debe instalar el dispositivo de replicación para las migraciones basadas en agentes?
Debe instalar el dispositivo de replicación en una máquina dedicada. No debe instalar el dispositivo de replicación en una máquina de origen que quiera replicar o en el dispositivo de Azure Migrate que usó para la detección y la evaluación. Lea Migración de máquinas como servidores físicos a Azure para más información.
¿Puedo migrar máquinas virtuales de AWS que ejecuten el sistema operativo de Amazon Linux?
Las máquinas virtuales que ejecutan Amazon Linux no se pueden migrar tal cual, ya que el sistema operativo Amazon Linux solo se admite en AWS.
Para migrar las cargas de trabajo que se ejecutan en Amazon Linux, puede hacer funcionar una máquina virtual CentOS/RHEL en Azure. Después, puede migrar la carga de trabajo que se ejecuta en la máquina linux de AWS mediante un enfoque de migración de cargas de trabajo pertinente. Por ejemplo, en función de la carga de trabajo, puede haber herramientas específicas de la carga de trabajo para ayudar a la migración, como herramientas para bases de datos o herramientas de implementación para servidores web.
¿Cómo se mide el requisito de ancho de banda para las migraciones?
Un intervalo de factores puede afectar a la cantidad de ancho de banda que necesita para replicar datos en Azure. El requisito de ancho de banda depende de la rapidez con la que el dispositivo local de Azure Migrate puede leer y replicar los datos en Azure. La replicación tiene dos fases: la replicación inicial y la replicación diferencial.
Cuando se inicia la replicación de una máquina virtual, se produce un ciclo de replicación inicial en el que se replican las copias completas de los discos. Una vez completada la replicación inicial, se programan periódicamente ciclos de replicación incremental (ciclos diferenciales) para transferir los cambios que se hayan producido desde el ciclo de replicación anterior.
Para un método basado en agente de replicación, Deployment Planner de Azure Site Recovery puede ayudar a generar perfiles del entorno para la renovación de datos y ayudar a predecir los requisitos de ancho de banda necesarios. Para más información, lea Planeamiento de la implementación de VMware.
Migración de Hyper-V sin agente
¿Cómo funciona la migración sin agente?
La herramienta Migración y modernización proporciona opciones de replicación sin agente para la migración de máquinas virtuales de VMware y Hyper-V que ejecutan Windows o Linux. La herramienta proporciona otra opción de replicación basada en agente para servidores Windows y Linux. Esta otra opción se puede usar para migrar servidores físicos y máquinas virtuales x86/x64 en proveedores como VMware, Hyper-V, AWS y GCP.
La replicación basada en agente requiere que instale software de agente en la máquina virtual o servidor que va a migrar. La opción sin agente no requiere que instale software en las máquinas virtuales, lo que puede ofrecer comodidad y simplicidad.
La opción de replicación sin agente funciona mediante los mecanismos que proporciona el proveedor de virtualización (VMware, Hyper-V). En el caso de las máquinas virtuales de Hyper-V, el mecanismo de replicación sin agente usa instantáneas de máquina virtual y la funcionalidad de seguimiento de cambios de la réplica de Hyper-V para replicar datos de discos de máquina virtual.
Cuando la replicación está configurada para una máquina virtual, la máquina virtual pasa primero por una fase de replicación inicial. Durante la replicación inicial, se toma una instantánea de máquina virtual y se replica una copia completa de los datos de los discos de instantáneas en discos administrados de la suscripción. Una vez completada la replicación inicial de la máquina virtual, el proceso de replicación cambia a una fase de replicación incremental (replicación diferencial).
La fase de replicación incremental aborda los cambios de datos que se produjeron desde el último ciclo de replicación completado. Estos cambios se replican periódicamente y se aplican a los discos administrados por réplica. Este proceso mantiene la replicación sincronizada con los cambios en la máquina virtual.
La tecnología de seguimiento de bloques modificados de VMware se usa para realizar un seguimiento de los cambios entre los ciclos de replicación de las máquinas virtuales de VMware. Al principio del ciclo de replicación, se toma una instantánea de la máquina virtual y se usa el seguimiento de bloques con cambios para obtener los cambios entre la instantánea actual y la última instantánea que se replicó correctamente. De este modo, solo es necesario replicar los datos que han cambiado desde el último ciclo de replicación completado para mantener sincronizada la replicación de la máquina virtual.
Al final de cada ciclo de replicación, se publica la instantánea y se realiza la consolidación de instantáneas para la máquina virtual. Del mismo modo, en el caso de las máquinas virtuales de Hyper-V, el motor de seguimiento de cambios de réplica de Hyper-V realiza un seguimiento de los cambios entre ciclos de replicación consecutivos.
Al realizar la operación de Migrate en una máquina virtual de replicación, puede apagar la máquina virtual local y realizar una replicación incremental final para garantizar una pérdida de datos cero. Los discos administrados por réplica que corresponden a la máquina virtual se usan para crear la máquina virtual en Azure.
Para empezar, consulte el tutorial sobre migración sin agente de Hyper-V.
¿Cómo se mide el requisito de ancho de banda para las migraciones?
Un intervalo de factores puede afectar a la cantidad de ancho de banda que necesita para replicar datos en Azure. El requisito de ancho de banda depende de la rapidez con la que el dispositivo local de Azure Migrate puede leer y replicar los datos en Azure. La replicación tiene dos fases: la replicación inicial y la replicación diferencial.
Cuando se inicia la replicación de una máquina virtual, se produce un ciclo de replicación inicial en el que se replican las copias completas de los discos. Una vez completada la replicación inicial, se programan periódicamente ciclos de replicación incremental (ciclos diferenciales) para transferir los cambios que se hayan producido desde el ciclo de replicación anterior.
Puede solucionar el requisito de ancho de banda en función de:
- El volumen de datos que necesita mover en la onda.
- Tiempo que desea asignar para el proceso de replicación inicial.
Lo ideal es que quiera que la replicación inicial se complete al menos entre 3 y 4 días antes de la ventana de migración real. Esta escala de tiempo proporciona tiempo suficiente para realizar una migración de prueba antes de la ventana real y mantener el tiempo de inactividad durante la ventana como mínimo.
Contenido relacionado
- Más información sobre la migración de Máquinas virtuales de VMware, Máquinas virtuales de Hyper-V y Servidores físicos.