Migración y modernización: peguntas comunes
Precaución
En este artículo se hace referencia a CentOS, una distribución de Linux con un estado de finalización del servicio (EOL). Tenga en cuenta su uso y planeación en consecuencia. Para más información, consulte la Guía de fin de ciclo de vida de CentOS.
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:
- Preguntas generales sobre Azure Migrate
- Preguntas sobre el dispositivo de Azure Migrate
- Preguntas sobre la detección, valoración y visualización de dependencias
- Obtenga respuestas a sus preguntas en el foro de Azure Migrate
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 en curso) para migrar 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.
Estas son algunas consideraciones que debe tener en cuenta a la hora de elegir una opción de migración.
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 agentes requieren de la instalación de software (agentes) de Azure Migrate en las VM o máquinas de origen que se van a migrar. La opción basada en agente no se basa en la plataforma de virtualización para la funcionalidad de replicación. Por tanto, se puede usar con cualquier servidor en el que se ejecute una arquitectura x86/x64 y una versión de un sistema operativos admitida por el método de replicación basado en agente.
La opción de migración basada en agente se puede usar para las máquinas virtuales de VMware, las máquinas virtuales de Hyper-V, los servidores físicos, las máquinas virtuales que se ejecutan en AWS, las máquinas virtuales que se ejecutan en GCP o las 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.
Aunque la migración sin agente ofrece otra comodidad y simplicidad en comparación con las opciones de replicación basadas en agentes para los escenarios admitidos (VMware e Hyper-V), debería considerar la posibilidad de usar el escenario basado en agente para los casos de uso siguientes:
- Entorno con limitaciones de IOPS: La replicación sin agente utiliza instantáneas y consume IOPS/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.
- Si no tiene una instancia de 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 obtener más información, consulte este artículo para comparar las opciones de migración para VMware.
¿Qué zonas geográficas se admiten para la migración con Azure Migrate?
Revise las zonas geográficas admitidas para nubes públicas y 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, cada uno se puede usar para migrar servidores a una sola región de Azure. Puede crear proyectos de Azure Migrate adicionales para cada región a la que tenga que migrar.
- En el caso de las migraciones de VMware sin agente, la región de destino se bloquea una vez que ha habilitado 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 una vez que se selecciona el botón "Crear recursos" del portal mientras se configura el dispositivo de replicación.
- En el caso de las migraciones de Hyper-V sin agente, la región de destino se bloquea una vez que se selecciona el botón "Crear recursos" del portal durante la configuración del 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 migrar a varias suscripciones (mismo inquilino de Azure) de la misma región de destino con un proyecto de Azure Migrate. Puede seleccionar la suscripción de destino al habilitar la replicación de una máquina o de un conjunto de máquinas. La región de destino se bloquea después de la primera replicación para las migraciones de VMware sin agente y durante la instalación del dispositivo de replicación y del proveedor de Hyper-V para las migraciones basadas en agentes y para las migraciones de Hyper-V sin agente, respectivamente.
¿Admite Azure Migrate Azure Resource Graph?
Actualmente, Azure Migrate no está integrado con Azure Resource Graph. Admite la realización de consultas relacionadas con ARG.
¿Cómo se transmiten los datos desde el entorno local a Azure? ¿Se cifran antes de la transmisión?
El dispositivo Azure Migrate del caso de replicación sin agente comprime los datos y los cifra 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 al guardarlos 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 el uso del almacén de Recovery Services creado por Azure Migrate en escenarios de recuperación ante desastres. Si lo hace, pueden producirse 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 migración de prueba proporciona una manera de probar y validar las migraciones antes de una migración real. La migración de prueba funciona al permitirle usar un entorno de espacio aislado en Azure para probar las máquinas virtuales antes de realizar la migración real. El entorno de espacio aislado está delimitado por la red virtual de prueba que especifique. La operación de migración de prueba no conlleva interrupciones, siempre que la red virtual de prueba esté lo suficientemente aislada. La red virtual aislada aquí significa que las reglas de conexión de entrada y salida están diseñadas para evitar conexiones no deseadas. Por ejemplo, la conexión a máquinas locales está restringida.
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 de migración de prueba para validar la funcionalidad y el rendimiento de la aplicación en Azure. Puede realizar el número de migraciones de prueba que quiera y ejecutar la migración final después de establecer un valor de confianza a través de la operación de migración de prueba. Una migración de prueba no afecta a la máquina local, que sigue funcionando y continúa las replicaciones hasta que se realiza la migración real. Si se produjeron errores durante la pruebas de aceptación de usuario de 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 realizando replicaciones en Azure. Puede volver a intentar la migración final una vez que haya resuelto los errores. Nota: Una vez que haya realizado una migración final a Azure y que la máquina de origen local se haya apagado, no podrá realizar una reversión de Azure al entorno local.
¿Puedo seleccionar la red virtual y la subred que se usarán para las migraciones de prueba?
Puede seleccionar una red virtual para las migraciones de prueba. La subred se selecciona automáticamente en función de la siguiente lógica:
- Si se especificó una subred de destino (distinta de la predeterminada) como entrada al habilitar la replicación, Azure Migrate prioriza el uso de una subred con el mismo nombre en la red virtual seleccionada para la migración de prueba.
- Si no se encuentra la subred con el mismo nombre, Azure Migrate selecciona la primera subred disponible en orden alfabético que no sea una subred de puerta de enlace, Application Gateway, Firewall o Bastion.
¿Por qué está deshabilitado el botón de migración de prueba para mi servidor?
El botón Migración de prueba puede estar en el estado deshabilitado en los escenarios siguientes:
- No se puede iniciar una migración de prueba hasta que se haya completado una replicación inicial para la máquina virtual. El botón migración de prueba estará deshabilitado hasta que se complete el proceso de replicación inicial. Puede realizar una migración de prueba una vez que la máquina virtual se encuentre 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?
La migración de prueba simula una migración real mediante la creación de una máquina virtual de Azure de prueba con datos replicados. El servidor se implementará con una copia en un momento dado de los datos replicados en el grupo de recursos de destino (que seleccionó al habilitar la replicación) con el sufijo "-test". Las migraciones de prueba están pensadas para validar la funcionalidad del servidor con el fin de minimizar los problemas posteriores a la migración. Si la migración de prueba no se limpia después de la prueba, la máquina virtual de prueba seguirá ejecutándose en Azure y se aplicarán cargos. Para limpiar después de una migración de prueba, vaya a la vista de máquinas de replicación en la herramienta de Migración y modernización, y utilice la acción "limpiar migración de prueba" en la máquina.
¿Cómo puedo saber si la máquina virtual se migró correctamente?
Una vez que haya migrado la máquina virtual o el servidor correctamente, podrá ver y administrar la máquina virtual desde la página 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 la operación con el fin de comprobar si la migración se completó correctamente. Si ve algún error, resuélvalo y vuelva a intentar la operación de migración.
¿Qué ocurre si no se detiene la replicación después de una migración?
Cuando se detiene la replicación, la herramienta de Migración y modernización limpia los discos administrados en la suscripción que se creó para la replica.
¿Qué ocurre si no se completa la migración al terminar?
Cuando finaliza la migración, la herramienta de Migración y modernización limpia los discos administrados de la suscripción que se crearon para la replicación. Si no selecciona Complete migration después de una migración, se seguirán aplicando cargos por estos discos. Esta acción de completar la migración 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 de Migración y modernización migra máquinas basadas en UEFI a Azure como máquinas virtuales Azure de generación 2. Si desea migrarlas a máquinas virtuales Azure de generación 1, convierta el tipo de arranque a BIOS antes de iniciar la replicación, y luego, utilice la herramienta de 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 de Migración y modernización migra todas las máquinas basadas en UEFI a Azure como máquinas virtuales Azure de generación 2. 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 únicamente como máquinas virtuales de Azure de primera generación.
¿Qué sistemas operativos se admiten para la migración a Azure de máquinas basadas en UEFI?
| Sistemas operativos compatibles con máquinas basadas en UEFI | De VMware sin agente a Azure | De Hyper-V sin agente a Azure | De VMware basado en agente, físico y otras nubes a Azure |
|---|---|---|---|
| Windows Server 2019, 2016, 2012 R2, 2012 | Y | Y | Y |
| Windows 10 Pro, Windows 10 Enterprise | 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, 18.04, 19.04, 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, 7.7-CI | Y | Y | Y |
¿Puedo migrar los controladores de dominio de Active Directory mediante Azure Migrate?
La herramienta de Migración y modernización es independiente de las aplicaciones y funciona con la mayoría de ellas. Cuando se migra un servidor utilizando la herramienta de Migración y modernización, todas las aplicaciones instaladas en el servidor se migran junto con él. Sin embargo, para algunas aplicaciones, otros métodos de migración distintos de la herramienta de Migración y modernización pueden ser más adecuados para la migración. Para Active Directory, en los entornos híbridos en los que el sitio local está conectado al entorno de Azure, puede extender el directorio a Azure si agrega más controladores de dominio en Azure y configura la replicación de Active Directory. Si está migrando a un entorno aislado en Azure que requiere sus propios controladores de dominio (o probando aplicaciones en un entorno de espacio aislado), puede migrar servidores utilizando la herramienta de Migración y modernización.
¿Puedo actualizar mi sistema operativo durante la migración?
La herramienta de migración y modernización ahora admite la actualización del sistema operativo Windows durante la migración. Esta opción no está disponible actualmente para Linux. Más detalles sobre la 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 sin agente o basada en agentes de VMware. vCenter Server debe administrar los hosts de ESXi en los que se encuentran las máquinas virtuales. Si no tiene vCenter Server, puede migrar máquinas virtuales de VMware mediante su migración 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?
Las capacidades de migración y modernización admiten actualmente migraciones similares. No se admite la consolidación de los servidores como parte de la migración.
¿Windows Server 2008 y 2008 R2 serán compatibles en Azure después de la migración?
Puede migrar los servidores Windows Server 2008 y 2008 R2 a máquinas virtuales de Azure y recibir Actualizaciones de seguridad extendidas durante tres años a contar desde la finalización del soporte técnico, sin cargos adicionales por encima del costo que implica ejecutar la máquina virtual. Puede utilizar la herramienta de Migración y modernización para migrar sus 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 ayudando 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. La migración de las aplicaciones a instancias de Azure que ejecutan una versión más reciente de Windows Server es el enfoque recomendado para asegurarse de que se usa de forma eficaz la flexibilidad y confiabilidad de la nube de Azure.
Sin embargo, si aún así decide migrar su Windows Server 2003 a Azure, puede utilizar la herramienta de Migración y modernización si su Windows Server es una máquina virtual que se ejecuta en VMware o Hyper-V Revise este artículo para preparar sus máquinas Windows Server 2003 para la migración.
Migración de VMware sin agente
¿Cómo funciona la migración sin agente?
La herramienta de Migración y modernización ofrece opciones de replicación sin agentes para la migración de máquinas virtuales VMware y máquinas virtuales Hyper-V que ejecutan Windows o Linux. La herramienta también ofrece otra opción de replicación adicional basada en agente para los servidores Windows y Linux que se puede usar para migrar servidores físicos, y máquinas virtuales x86/x64 en VMware, Hyper-V, AWS, GCP, etc. Para la opción de replicación basada en agente es necesario instalar el software del agente en el servidor o máquina virtual que se va a migrar, mientras que en la opción sin agente no es necesario instalar ningún software en las máquinas virtuales, por lo que ofrece mayor comodidad y simplicidad en comparación con la opción de replicación basada en agentes.
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 VMware, el mecanismo de replicación sin agente usa las instantáneas de VMware y la tecnología de seguimiento de bloques con cambios de VMware para replicar datos de discos de máquinas virtuales. Este mecanismo es similar al que usan muchos productos de copia de seguridad. En el caso de las máquinas virtuales de Hyper-V, el mecanismo de replicación sin agente usa las instantáneas de VM y la funcionalidad de seguimiento de cambios de la réplica de Hyper-V para replicar datos de discos de máquinas virtuales.
Cuando la replicación está configurada para una máquina virtual, primero pasa por una fase de replicación inicial. Durante la replicación inicial, se realiza una instantánea de la máquina virtual y se replica una copia completa de los datos de los discos de instantánea en los 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). En la fase de replicación incremental, los cambios en los datos que se han producido desde el último ciclo de replicación completado se replican periódicamente y se aplican a los discos administrados de la réplica, lo que mantiene la replicación sincronizada con los cambios que se producen en la máquina virtual. En el caso de las máquinas virtuales de VMware, la tecnología de seguimiento de bloques con cambios de VMware se usa para realizar un seguimiento de los cambios entre los ciclos de replicación. 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 la réplica de Hyper-V se usa para realizar un seguimiento de los cambios entre los ciclos de replicación consecutivos.
Al realizar la operación de migración en una máquina virtual de replicación, tiene la opción de apagar la máquina virtual local y realizar una última replicación incremental para garantizar que no haya pérdida de datos. Al realizar la migración, se usan los discos administrados de la réplica correspondientes a la máquina virtual 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?
El ancho de banda para la replicación de datos en Azure depende de varios factores y es una función de la rapidez con la que el dispositivo Azure Migrate local 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 calcular el requisito de ancho de banda en función del volumen de datos que necesita mover durante la fase y el tiempo en los que quiere que se complete la replicación inicial (lo ideal es que la replicación inicial se haya completado al menos 3 o 4 días antes del período de migración real, para que tenga el tiempo suficiente para realizar una migración de prueba antes del período real y para mantener un tiempo de inactividad mínimo durante este).
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 puedo limitar la replicación en el uso del dispositivo de Azure Migrate para la replicación de VMware sin agente?
Se puede limitar mediante NetQosPolicy. Tenga en cuenta que esta limitación solo es aplicable a las conexiones salientes desde el dispositivo de Azure Migrate. Por ejemplo:
El elemento 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 disminuir el ancho de banda de replicación según una programación, puede utilizar la tarea programada de Windows para escalar el ancho de banda según sea necesario. Se usará una tarea para reducir el ancho de banda y otra para aumentarlo. Nota: Debe crear el objeto netQosPolicy, descrito anteriormente, antes de ejecutar los comandos siguientes.
#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
¿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 se reduce la cantidad de datos que se transfieren, se permite que los datos se plieguen lo más 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 igual al 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. Sin embargo, cuando intento migrar las máquinas virtuales, solo veo las máquinas virtuales que corresponden a uno de los dispositivos.
Si hay varios dispositivos configurados, es necesario que no exista ninguna superposición entre las máquinas virtuales en 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.
¿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 el artículo para detectar, evaluar y migrar las instancias de AWS EC2 a Azure.
¿Cómo funciona la migración basada en agente?
Además de las opciones de migración sin agente para máquinas virtuales VMware y máquinas virtuales Hyper-V, la herramienta de Migración y modernización ofrece una opción de migración basada en agente para migrar servidores Windows y Linux que se ejecutan en servidores físicos, o que se ejecutan como máquinas virtuales x86/x64 en VMware, Hyper-V, AWS, Google Cloud Platform, etc.
El método de migración basado en agente usa el software de agente instalado en el servidor que se va a migrar para replicar los datos en Azure. 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). Más información sobre cómo funciona la opción 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 un equipo independiente o dedicado.
¿Dónde se debe instalar el dispositivo de replicación para las migraciones basadas en agentes?
El dispositivo de replicación debe instalarse en una máquina dedicada. El dispositivo de replicación no se debe instalar en una máquina de origen que quiera replicar ni en el dispositivo de Azure Migrate (usado para la de detección y evaluación) que pueda haber instalado antes. Siga el tutorial para obtener más detalles.
¿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 de Amazon Linux solo es compatible con AWS. Para migrar las cargas de trabajo que se ejecutan en Amazon Linux, puede poner en marcha una máquina virtual CentOS/RHEL en Azure y migrar la carga de trabajo que se ejecuta en la máquina Linux de AWS mediante una estrategia de migración de carga de trabajo adecuada. Por ejemplo, en función de la carga de trabajo, puede haber herramientas específicas de carga de trabajo que ayuden a la migración, como las bases de datos o las herramientas de implementación, en el caso de los servidores web.
¿Cómo se mide el requisito de ancho de banda para las migraciones?
El ancho de banda para la replicación de datos en Azure depende de varios factores y es una función de la rapidez con la que el dispositivo Azure Migrate local 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 de replicación basado en agente, Deployment Planner puede ayudar a generar perfiles del entorno para la renovación de datos y predecir el requisito de ancho de banda necesario. Para obtener más información, vea este artículo.
Migración de Hyper-V sin agente
¿Cómo funciona la migración sin agente?
La herramienta de Migración y modernización ofrece opciones de replicación sin agentes para la migración de máquinas virtuales VMware y máquinas virtuales Hyper-V que ejecutan Windows o Linux. La herramienta también ofrece una opción de replicación adicional basada en agente para los servidores Windows y Linux que se puede usar para migrar servidores físicos, así como máquinas virtuales x86/x64 en VMware, Hyper-V, AWS, GCP, etc. La opción de replicación basada en agente requiere de la instalación del software del agente en el servidor o máquina virtual que se está migrando, mientras que en la opción sin agente no es necesario instalar ningún software en las máquinas virtuales, por lo que ofrece mayor comodidad y simplicidad en comparación con la opción de replicación basada en agentes.
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 las instantáneas de VM y la funcionalidad de seguimiento de cambios de la réplica de Hyper-V para replicar datos de discos de máquinas virtuales.
Cuando la replicación está configurada para una máquina virtual, primero pasa por una fase de replicación inicial. Durante la replicación inicial, se realiza una instantánea de la máquina virtual y se replica una copia completa de los datos de los discos de instantánea en los 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). En la fase de replicación incremental, los cambios en los datos que se han producido desde el último ciclo de replicación completado se replican periódicamente y se aplican a los discos administrados de la réplica, lo que mantiene la replicación sincronizada con los cambios que se producen en la máquina virtual. En el caso de las máquinas virtuales de VMware, la tecnología de seguimiento de bloques con cambios de VMware se usa para realizar un seguimiento de los cambios entre los ciclos de replicación. 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 la réplica de Hyper-V se usa para realizar un seguimiento de los cambios entre los ciclos de replicación consecutivos.
Al realizar la operación de migración en una máquina virtual de replicación, tiene la opción de apagar la máquina virtual local y realizar una última replicación incremental para garantizar que no haya pérdida de datos. Al realizar la migración, se usan los discos administrados de la réplica correspondientes a la máquina virtual 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?
El ancho de banda para la replicación de datos en Azure depende de varios factores y es una función de la rapidez con la que el dispositivo Azure Migrate local 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 calcular el requisito de ancho de banda en función del volumen de datos que necesita mover durante la fase y el tiempo en los que quiere que se complete la replicación inicial (lo ideal es que la replicación inicial se haya completado al menos 3 o 4 días antes del período de migración real, para que tenga el tiempo suficiente para realizar una migración de prueba antes del período real y para mantener un tiempo de inactividad mínimo durante este).
Pasos siguientes
Más información sobre la migración de Máquinas virtuales de VMware, Máquinas virtuales de Hyper-V y Servidores físicos.