Arquitectura de recuperación ante desastres de Hyper-V en Azure
Este artículo describe la arquitectura y los procesos que se utilizan al replicar, conmutar por error y recuperar máquinas virtuales de Hyper-V entre los hosts de Hyper-V local y Azure, mediante el servicio Azure Site Recovery.
Los hosts de Hyper-V pueden administrarse en nubes privadas de System Center Virtual Machine Manager (VMM).
Componentes de la arquitectura: Hyper-V sin VMM
La tabla y el gráfico siguientes proporcionan una visión general de los componentes utilizados para la replicación de Hyper-V en Azure, cuando los hosts de Hyper-V no están administrados por VMM.
| Componente | Requisito | Detalles |
|---|---|---|
| Azure | Suscripción de Azure, cuenta de Azure Storage y red de Azure. | Los datos replicados desde las cargas de trabajo de las máquinas virtuales locales se almacenan en la cuenta de almacenamiento. Las máquinas virtuales de Azure se crean con los datos de la carga de trabajo replicados cuando se produce la conmutación por error desde el sitio local. Las máquinas virtuales de Azure se conectan a la red virtual de Azure cuando se crean. |
| Hyper-V | Durante la implementación de Site Recovery, se recopilan los clústeres y los hosts de Hyper-V en los sitios de Hyper-V. Se instala el agente de Recovery Services y el Proveedor de Azure Site Recovery en cada host de Hyper-V independiente y en cada nodo de clúster de Hyper-V. | El proveedor organiza la replicación con Site Recovery a través de Internet. El agente de Recovery Services se encarga de la replicación de datos. Las comunicaciones del proveedor y el agente son seguras y cifradas. También se cifran los datos replicados en el almacenamiento de Azure. |
| Máquinas virtuales de Hyper-V | Una o varias máquinas virtuales en ejecución en Hyper-V. | No es necesario instalar nada explícitamente en las máquinas virtuales. |
Arquitectura de Hyper-V a Azure (sin VMM)
Componentes de la arquitectura: Hyper-V con VMM
La tabla y gráfico siguientes proporcionan una visión general de los componentes utilizados para la replicación de Hyper-V en Azure, cuando los hosts Hyper-V se administran en VMM.
| Componente | Requisito | Detalles |
|---|---|---|
| Azure | Suscripción de Azure, cuenta de Azure Storage y red de Azure. | Los datos replicados desde las cargas de trabajo de las máquinas virtuales locales se almacenan en la cuenta de almacenamiento. Las máquinas virtuales de Azure se crean con los datos replicados cuando se produce la conmutación por error desde el sitio local. Las máquinas virtuales de Azure se conectan a la red virtual de Azure cuando se crean. |
| Servidor VMM | El servidor de VMM tiene una o varias nubes que contienen hosts de Hyper-V. | Se instala el Proveedor de Site Recovery en el servidor VMM para orquestar la replicación con Site Recovery, y se registra el servidor en el almacén de Recovery Services. |
| Host de Hyper-V | Uno o más hosts o clústeres de Hyper-V administrados por VMM. | Se instala el agente de Recovery Services en cada nodo del clúster o host de Hyper-V. |
| Máquinas virtuales de Hyper-V | Una o varias máquinas virtuales en un servidor host de Hyper-V. | No es necesario instalar nada explícitamente en las máquinas virtuales. |
| Redes | Redes lógicas y de máquinas virtuales configuradas en el servidor de VMM. La red de máquinas virtuales debe estar vinculada a una red lógica asociada con la nube. | Las redes de máquinas virtuales se asignan a las redes virtuales de Azure. Cuando se crean máquinas virtuales de Azure después de la conmutación por error, se agregan a la red de Azure que está asignada a la red de máquinas virtuales. |
Arquitectura de Hyper-V a Azure (con VMM)
Configuración de la conectividad de red saliente
Para que Site Recovery funcione de la forma esperada, debe modificar la conectividad de red saliente para permitir la replicación de su entorno.
Nota:
Site Recovery no admite el uso de un proxy de autenticación para controlar la conectividad de la red.
Conectividad de salida para las direcciones URL
Si usa un proxy de firewall basado en direcciones URL para controlar la conectividad de salida, debe permitir el acceso a ellas:
| Nombre | Comercial | Gobierno | Descripción |
|---|---|---|---|
| Storage | *.blob.core.windows.net |
*.blob.core.usgovcloudapi.net |
Permite que los datos se puedan escribir desde la máquina virtual a la cuenta de almacenamiento de caché en la región de origen. |
| Microsoft Entra ID | login.microsoftonline.com |
login.microsoftonline.us |
Proporciona autorización y autenticación de las direcciones URL del servicio Site Recovery. |
| Replicación | *.hypervrecoverymanager.windowsazure.com |
*.hypervrecoverymanager.windowsazure.com |
Permite que la máquina virtual se comunique con el servicio Site Recovery. |
| Azure Service Bus | *.servicebus.windows.net |
*.servicebus.usgovcloudapi.net |
Permite que la máquina virtual escriba los datos de diagnóstico y supervisión de Site Recovery. |
Proceso de replicación
Proceso de replicación y recuperación
Habilitar protección
- Después de habilitar la protección de una máquina virtual de Hyper-V, en el Azure Portal o de forma local, la opción Habilitar la protección se inicia.
- El trabajo comprueba que la máquina cumpla los requisitos previos e invoca CreateReplicationRelationship para que configure la replicación con su configuración.
- El trabajo comienza la replicación inicial con la invocación del método StartReplication para inicializar una replicación completa de la máquina virtual y enviar los discos virtuales de la máquina virtual a Azure.
- Puede supervisar el trabajo en la pestaña Trabajos.
Replicación inicial de datos
- Cuando se desencadena la replicación inicial, se toma una instantánea de la máquina virtual de Hyper-V.
- Los discos duros virtuales en la máquina virtual se replican uno a uno hasta que se copian todos en Azure. Esto puede tardar unos minutos, en función del tamaño de la máquina virtual y del ancho de banda de la red. Aprenda a aumentar el ancho de banda de red.
- Si se producen cambios en el disco con la replicación inicial en curso, el seguimiento de replicaciones de Réplica de Hyper-V realiza un seguimiento de esos cambios en los registros de replicación de Hyper-V (.hrl). Estos archivos de registro se encuentran en la misma carpeta que los discos. Cada disco tiene un archivo .hrl asociado que se envía al almacenamiento secundario. Los archivos de instantáneas y de registro consumen recursos de disco mientras la replicación inicial está en curso.
- Cuando finalice la replicación inicial, se elimina la instantánea de la máquina virtual.
- Los cambios diferenciales en el registro del disco se sincronizan y se combinan en el disco primario.
Proceso de finalización de la protección
- Una vez finalizada la replicación inicial, se ejecuta el trabajo Finalizar la protección en la máquina virtual. Configura la red y otras opciones posteriores a la replicación, para que la máquina virtual esté protegida.
- En esta fase puede comprobar la configuración de la máquina virtual para asegurarse de que está lista para la conmutación por error. Puede ejecutar una exploración de la recuperación ante desastres (conmutación por error de prueba) para la máquina virtual, a fin de comprobar que la conmutación se realiza según lo previsto.
Replicación diferencial
- Después de la replicación inicial, comienza la diferencial, según la directiva de replicación.
- La herramienta de seguimiento de la replicación de Réplica de Hyper-V supervisa los cambios realizados en un disco duro virtual como archivos .hrl. Cada disco configurado para la replicación tiene un archivo .hrl asociado.
- El registro se envía a la cuenta de almacenamiento del cliente. Cuando un registro se encuentra en tránsito hacia Azure, los cambios en el disco principal se siguen en otro archivo de registro de la misma carpeta.
- Durante la replicación inicial y diferencial, puede supervisar la máquina virtual en Azure Portal.
Proceso de resincronización
Si se produce un error en la replicación diferencial y una replicación completa sería costosa en términos de ancho de banda o de tiempo, se marca una máquina virtual para la resincronización.
- Por ejemplo, si los archivos .hrl alcanzan el 50 % del tamaño del disco, la máquina virtual se marcará para repetir la sincronización.
- De forma predeterminada, la resincronización está programada para ejecutarse automáticamente fuera del horario de oficina.
La resincronización solo envía los datos de diferencias.
- Minimiza la cantidad de datos que se envían calculando sumas de comprobación de las máquinas virtuales de origen y de destino.
- Utiliza un algoritmo de fragmentación de bloques fijos donde los archivos de origen y destino se dividen en fragmentos fijos.
- Se generan sumas de comprobación para cada fragmento. Estas se comparan para determinar qué bloques del origen se deben aplicar al destino.
Una vez finalizada la resincronización, se debe reanudar la replicación diferencial normal.
Si no desea esperar para volver a sincronizar fuera del horario de forma predeterminada, puede volver a sincronizar una máquina virtual manualmente. Por ejemplo, si se produce una interrupción. Para ello, en Azure Portal, seleccione la máquina virtual > Volver a sincronizar.
Reintento del proceso
Si se produce un error de replicación, se realiza un reintento de forma predefinida. El reintento se clasifica como se describe en la tabla.
| Categoría | Detalles |
|---|---|
| Errores irrecuperables | No se realiza ningún reintento. El estado de la máquina virtual será Crítico y se requiere la intervención del administrador. Entre los ejemplos de estos errores se incluyen la interrupción de la cadena de discos duros virtuales, un estado no válido de la máquina virtual de réplica, errores de autenticación de red, errores de autorización, y errores que indican que no se encuentra la máquina virtual (para servidores Hyper-V independientes). |
| Errores recuperables | Los reintentos se producen con cada intervalo de replicación mediante el uso de la interrupción exponencial, lo que aumenta el intervalo de reintentos desde el inicio del primer intento en 1, 2, 4, 8 y 10 minutos. Si el error persiste, reintente cada 30 minutos. Por ejemplo, pueden producirse errores de red, de espacio insuficiente en disco y de memoria insuficiente. |
Proceso de conmutación por error y conmutación por recuperación
- Puede ejecutar una conmutación por error, planeada o no, desde máquinas virtuales de Hyper-V locales en Azure. Si ejecuta una conmutación por error planeada, las máquinas virtuales de origen se apagan para garantizar que no se pierdan datos. Ejecute una conmutación por error no planeada, si el sitio primario no está accesible.
- Puede conmutar por error una única máquina o crear planes de recuperación para organizar la conmutación por error de varias máquinas.
- Ejecuta una conmutación por error. Una vez que se completa la primera fase de la conmutación por error, debería poder ver las máquinas virtuales de la réplica creadas en Azure. Puede asignar una dirección IP pública a la máquina virtual si es necesario.
- Después, confirme la conmutación por error, para iniciar el acceso a la carga de trabajo desde la máquina virtual de Azure de la réplica.
Una vez que la infraestructura local está activa y ejecutándose, puede conmutar por recuperación. La conmutación por recuperación se produce en tres fases:
Se inicia una conmutación por error planeada desde Azure en el sitio local:
- Minimize downtime (Minimizar tiempo de inactividad): si usa esta opción, Site Recovery sincroniza los datos antes de la conmutación por error. Comprueba si hay bloques de datos que han cambiado y los descarga en el sitio local, mientras la máquina virtual de Azure se sigue ejecutando, lo que minimiza el tiempo de inactividad. Cuando especifica manualmente que la conmutación por error se debe completar, la máquina virtual de Azure se apaga, los cambios de deferencias finales se copian y se inicia la conmutación por error.
- Full download (Descarga completa): con esta opción, los datos se sincronizan durante la conmutación por error. Esta opción descarga todo el disco. Es más rápido porque no se calculan las sumas de comprobación, pero hay más tiempo de inactividad. Utilice esta opción si ha ejecutado la réplica de máquinas virtuales de Azure durante algún tiempo, o si se ha eliminado la máquina virtual local.
- Create VM (Crear VM): Puede seleccionar conmutar por recuperación en la misma máquina virtual o en otra alternativa. Puede especificar que Site Recovery deba crear la máquina virtual si aún no existe.
Una vez finalizada la sincronización inicial, seleccione esta opción para completar la conmutación por error. Una vez que se completa, puede iniciar sesión en la máquina virtual local para comprobar que todo funciona según lo previsto. En Azure Portal, puede ver que las máquinas virtuales de Azure se han detenido.
Después, confirme la conmutación por error para terminar y comience a acceder de nuevo a la carga de trabajo desde la máquina virtual local.
Una vez que las cargas de trabajo han conmutado por recuperación, habilite la replicación inversa, para que las máquinas virtuales locales se repliquen en Azure de nuevo.
Pasos siguientes
Siga este tutorial para empezar con la replicación de Hyper-V en Azure.