Resistencia de máquina virtual para Azure Local

Después de revisar e implementar las consideraciones de diseño para la resistencia de la infraestructura en el nivel de plataforma, es esencial comprender cómo las máquinas virtuales y las aplicaciones son resistentes a los errores. Esta comprensión le ayuda a permitirles detectar, resistir y recuperarse de errores dentro de un período de tiempo aceptable. La resistencia es fundamental para mantener las operaciones continuas para las aplicaciones críticas para la empresa.

De forma predeterminada, todas las máquinas virtuales (VM) en Azure Local están diseñadas para alta disponibilidad. Si se produce un error en un nodo físico del clúster, las máquinas virtuales afectadas se reinician automáticamente y continúan funcionando en los nodos restantes, siempre que haya suficiente capacidad de proceso disponible para las máquinas virtuales. Incluso con estas sólidas características de resistencia y tolerancia a errores de nivel de plataforma, es esencial que las aplicaciones implementadas dentro de las máquinas virtuales sigan principios bien diseñados.

Las aplicaciones bien diseñadas integran la confiabilidad en su código, infraestructura y operaciones. Por ejemplo, la implementación de varias instancias de servicios de aplicación dentro de dos o más máquinas virtuales locales de Azure es esencial para eliminar puntos únicos de error dentro del nivel de aplicación. La incorporación de resistencia adicional en esta capa mitiga el riesgo de tiempo de inactividad si se produce un error en una máquina virtual o instancia de aplicación individual. Para más información, consulte Resistencia de la carga de trabajo. Además, un diseño sólido de aplicaciones debe abarcar estrategias completas de continuidad empresarial y recuperación ante desastres (BCDR), incluida la validación regular de la conmutación por error en recuperación ante desastres y las pruebas de respaldo y recuperación de datos para garantizar que los procedimientos de recuperación ante desastres funcionen según lo previsto.

Para mitigar el riesgo de interrupciones del servicio o pérdida de datos que las funcionalidades de redundancia de una sola instancia local de Azure no pueden mitigar, es esencial implementar una combinación de estrategias de copia de seguridad completas junto con tecnologías de replicación de datos continuas.

• Las estrategias de copia de seguridad protegen frente a escenarios como daños en los datos, eliminación accidental o malintencionada y incidentes catastróficos. Facilitan la restauración de datos a un estado anterior cuando sea necesario.

• Las tecnologías de replicación de datos permiten mantener copias sincronizadas de datos de máquina virtual en varias instancias locales de Azure y regiones de Azure. Esta práctica puede minimizar el tiempo de inactividad y habilitar la conmutación por error rápida de la carga de trabajo en caso de error del hardware o del sistema. Juntos, estos enfoques proporcionan una red de seguridad sólida diseñada para proteger los datos y mantener la continuidad operativa y empresarial durante interrupciones inesperadas.

Para más información y recomendaciones para mejorar la resistencia de la carga de trabajo y las aplicaciones, revise Los principios de diseño de confiabilidad de Azure Well-Architected Framework (WAF).

Consideraciones sobre la ruta de acceso de almacenamiento (volúmenes)

Las instancias locales de Azure implementadas mediante la opción Crear volúmenes de carga de trabajo y volúmenes de infraestructura necesarios (recomendado) crean volúmenes compartidos de clúster (CSV) de UserStorage_X, uno por nodo físico en el clúster y un recurso de ruta de acceso de almacenamiento asociado creado en Azure para cada volumen. Los recursos de carga de trabajo, como las máquinas virtuales locales de Azure y los clústeres de Azure Kubernetes Server (AKS) habilitados para Arc, usan el recurso de ruta de acceso de almacenamiento en Azure para almacenar imágenes de máquina virtual. Por ejemplo, un CSV con la ruta del sistema de archivos local de C:\ClusterStorage\UserStorage_1\ tiene un recurso de ruta de almacenamiento creado en Azure que representa el volumen compartido del clúster (CSV) para permitir que los discos duros virtuales (VHDs) de las máquinas virtuales locales de Azure se coloquen en un volumen de destino específico. Para más información, consulte acerca de las rutas de acceso de almacenamiento.

Al implementar aplicaciones bien diseñadas que usan varias máquinas virtuales locales de Azure para mejorar la resistencia de la carga de trabajo, siempre que sea posible, coloque los discos duros virtuales (VHD) de cada máquina virtual en rutas de almacenamiento independientes para optimizar la redundancia. Por ejemplo, al aprovisionar varias máquinas virtuales locales de Azure que ejecutan instancias del mismo servicio, el uso de rutas de acceso de almacenamiento diferentes para cada VHD de máquinas virtuales ayuda a mitigar el riesgo de que todas las máquinas virtuales usen una única ruta de acceso de almacenamiento (volumen).

Configure la ruta de acceso de almacenamiento que usan las máquinas virtuales locales de Azure al crear sus discos duros virtuales. Cuando se usa la infraestructura como código (IaC) para aprovisionar cargas de trabajo, la lógica de ubicación de los VHD emplea una lógica de asignación round robin para la selección de la ruta de acceso de almacenamiento. En el caso de las instancias locales de Azure de varios nodos, cada ruta de acceso de almacenamiento se asigna a un volumen diferente de forma predeterminada. Por lo tanto, cada VHD de las máquinas virtuales (VMs) se distribuye entre diferentes rutas de acceso de almacenamiento (volúmenes), lo que aumenta la resistencia de la carga de trabajo, específicamente en escenarios en los que un único volumen está temporalmente fuera de línea o no disponible. Para un control de aprovisionamiento más pormenorizado, especifique el parámetro al usar la --storage-path-id CLI de Azure para la implementación de cargas de trabajo, lo que le permite dirigirse a rutas de acceso de almacenamiento específicas al aprovisionar discos duros virtuales para máquinas virtuales locales de Azure.

Herramientas de copia de seguridad

Microsoft Azure Backup Server

Microsoft Azure Backup Server (MABS), una evolución de System Center Data Protection Manager, es una solución de copia de seguridad de Microsoft que puede usar para proteger máquinas virtuales locales de Azure. MABS ofrece un enfoque de copia de seguridad híbrida, lo que proporciona retención a corto plazo en el almacenamiento en disco local para recuperaciones operativas rápidas y retención a largo plazo mediante la integración con los servicios de Azure Backup, lo que le permite almacenar copias de seguridad fuera del sitio en un almacén de Azure Recovery Services.

Si usa MABS, puede proteger las máquinas virtuales mediante dos enfoques: copia de seguridad de máquinas virtuales de nivel de host y copia de seguridad de máquinas virtuales de nivel de invitado.

• Copia de seguridad de máquina virtual de nivel de host: instale el agente de copia de seguridad en cada host local de Azure (cada nodo de clúster) y realice una copia de seguridad de máquinas virtuales completas en el nivel de hipervisor. Este enfoque captura toda la máquina virtual, incluidos todos los discos virtuales. No requiere un agente dentro de cada máquina virtual y es independiente del sistema operativo invitado. Las copias de seguridad de nivel de host permiten restauraciones completas de máquinas virtuales, donde puede recuperar una máquina virtual completa en el mismo clúster o diferente. Sin embargo, las copias de seguridad de nivel de host no son compatibles con la aplicación. Por ejemplo, no truncan los registros de SQL ni garantizan restauraciones coherentes con la aplicación más allá de lo que proporciona el Servicio de instantáneas de volumen (VSS).

  Nota:

  • La restauración de una máquina virtual local de Azure en un clúster diferente restaura la máquina virtual como una máquina virtual no administrada. Esto significa que todos los servicios dentro de la máquina virtual empiezan a funcionar, pero la máquina virtual no se puede administrar desde Azure hasta que se registra en el nuevo clúster local de Azure y se vuelve a conectar a su recurso que existe en Azure.
  • La reconexión significa que el recurso de Azure se actualiza con el nuevo grupo de recursos (opcional, también puede mantenerlo en el mismo grupo de recursos), la ubicación personalizada, la ruta de acceso de almacenamiento y la red lógica de la máquina virtual.
  • Si restaura la máquina virtual directamente en el mismo clúster, no es necesario registrar ni reconectar. La conexión de Azure de la máquina virtual se restaura y se sigue administrando desde Azure siempre y cuando esté dentro de la ventana de reconexión de 45 días de Azure Arc.

• Copia de seguridad de máquina virtual a nivel de invitado: instale agentes de copia de seguridad en el sistema operativo invitado de la máquina virtual. Este enfoque permite copias de seguridad coherentes con la aplicación para aplicaciones compatibles con VSS que se ejecutan en el sistema operativo, lo que garantiza que los datos de la aplicación se capturan en un estado coherente. Por ejemplo, puede realizar copias de seguridad de bases de datos SQL con fidelidad completa y restaurar elementos individuales como una base de datos única o un archivo específico fácilmente. La compensación es la capacidad de administración: debe administrar agentes en cada máquina virtual y la copia de seguridad solo cubre lo que hay dentro de la máquina virtual. Para restaurar toda la máquina virtual, normalmente se reconstruye y, a continuación, se restauran los datos.

• Use ambos: muchas organizaciones usan una combinación de ambos enfoques. Use copias de seguridad de nivel de invitado para aplicaciones críticas que necesitan recuperación a un momento dado o de nivel de elemento, como restaurar una base de datos única o un archivo sin revertir toda la máquina virtual. Use copias de seguridad de nivel de host para una recuperación rápida de máquinas virtuales completas o para recuperarse de escenarios de error de host.

La configuración de MABS implica implementar el software del servidor MABS en una máquina virtual dedicada en el clúster, configurar su almacenamiento local, instalar agentes de protección en los hosts o invitados locales de Azure y, a continuación, crear grupos de protección con las máquinas virtuales que desea proteger. Los grupos de protección definen qué se respalda (por ejemplo, máquinas virtuales específicas), el cronograma de respaldo y las políticas de retención a corto y largo plazo en disco local o en Azure. Para más información sobre cómo instalar MABS para máquinas virtuales locales de Azure, consulte Copia de seguridad de máquinas virtuales locales de Azure con Azure Backup Server.

Soluciones de copia de seguridad de asociados

Además de MABS, un mercado maduro de proveedores de copia de seguridad y recuperación de asociados ofrece soluciones sólidas para entornos locales de Azure. Estas soluciones suelen proporcionar un amplio conjunto de características avanzadas, compatibilidad con plataformas más amplia y diferentes modelos de licencias o costos que podrían ser atractivos en función de requisitos específicos de la organización.

CloudCasa de Catalogic

CloudCasa ofrece copias de seguridad nativas de Kubernetes, recuperación ante desastres y migración para AKS en clústeres habilitados para Azure Local y Arc. Protege los recursos del clúster y los volúmenes persistentes, con la capacidad de realizar restauraciones pormenorizadas, incluida la recuperación en el nivel de archivo. Las copias de seguridad se pueden almacenar en Azure Blob Storage, en otro almacenamiento de objetos o en el sistema de archivos de red (NFS). CloudCasa admite restauraciones en el mismo sitio, un clúster local de Azure secundario o Azure AKS para la recuperación ante desastres.

• CloudCasa en Azure Marketplace
• Soluciones de CloudCasa para Azure
• Simplificación de las actualizaciones y la copia de seguridad de Azure Local

Cohesity DataProtect

Cohesity DataProtect, parte de la plataforma Data Cloud, protege las máquinas virtuales con una única plataforma de seguridad de datos. Combina copias de seguridad, replicación y recuperación ante desastres con instantáneas inmutables ilimitadas, restauraciones granulares de archivos, máquinas virtuales o bases de datos, restauración masiva instantánea a escala y detección de anomalías integrada y clasificación de datos para acelerar la recuperación limpia después de los eventos cibernéticos. Para Azure Local, Cohesity ofrece una integración profunda con la plataforma. Esta integración incluye la detección automática de máquinas virtuales, la protección basada en directivas, muchas opciones de restauración y copias de seguridad incrementales para siempre mediante El seguimiento de cambios resistente (RCT) de Microsoft.

Cohesity amplía la compatibilidad aprovechando su conector y flujos de trabajo de Hyper-V maduros, lo que proporciona un modelo operativo coherente a medida que los clientes mueven Hyper-V cargas de trabajo a Azure Local.

• Protección de datos de cohesidad
• Instrucciones de soporte técnico para Azure Local

Cohesity NetBackup

Cohesity NetBackup ofrece protección de datos resistente a la ciberseguridad para Azure Local, lo que permite a las organizaciones proteger máquinas virtuales y aplicaciones locales de Azure mediante la misma plataforma de nivel empresarial en la que se basan en entornos híbridos y de varias nubes.

NetBackup usa su integración de Hyper-V madura y Microsoft Resilient Change Tracking (RCT) para proporcionar copias de seguridad incrementales basadas en directivas para cargas de trabajo locales de Azure. La captura eficaz de cambios de nivel de bloque minimiza el uso de las ventanas de copia de seguridad y la red. La compatibilidad con Azure Local se documenta en la lista de compatibilidad de software de NetBackup 11.x en Hyper-V y Azure Local.

• Cohesity NetBackup
• Lista de compatibilidad de software de NetBackup 11.x: Hyper-V y Azure Local
• Lista de compatibilidad de NetBackup para todas las versiones

Commvault

Commvault Cloud ofrece protección unificada de datos de nivel empresarial para entornos locales de Azure, lo que permite la protección segura de copias de seguridad, recuperación y ransomware en máquinas virtuales, bases de datos y datos no estructurados. Con la automatización inteligente y los flujos de trabajo controlados por directivas, Commvault simplifica el cumplimiento, mejora la resistencia y ofrece protección escalable desde el perímetro a la nube, a la vez que mantiene el control total de los datos dentro de la región local de Azure.

• Commvault para Azure Local
• Resúmenes de soluciones
• Commvault Marketplace SaaS

Rubrik

Rubrik Security Cloud ofrece una completa protección de datos y seguridad para las máquinas virtuales implementadas en entornos locales de Azure. Rubrik realiza un primer respaldo completo y luego incrementales para siempre, lo que garantiza la protección de datos con copias inmutables, aisladas físicamente y con control de acceso. A través de un plano de control de SaaS unificado, las organizaciones pueden administrar datos desde sus entornos locales de Azure, lo que proporciona una vista única en recursos de datos críticos. Esta integración también permite la supervisión continua de amenazas, la búsqueda de amenazas, la detección de anomalías y facilita la rápida recuperación cibernética, lo que permite la restauración rápida de máquinas virtuales y aplicaciones a un estado limpio después de un ataque.

• Hoja de datos de Azure Local Protection
• Protección de datos de Rubrik
• Análisis de amenazas de datos
• Recuperación masiva

Veeam

La copia de seguridad y la replicación de Veeam admiten la copia de seguridad y la replicación de máquinas virtuales locales de Azure. Con Veeam Backup and Replication es posible migrar cargas de trabajo de distintas plataformas o desde Hyper-V a Azure Local. La restauración multiplataforma se puede realizar mediante la recuperación instantánea de máquinas virtuales. También puede replicar cargas de trabajo de versiones anteriores de Hyper-V a Azure Local.

• Veeam Azure Marketplace
• Compatibilidad con Veeam Azure Local
• Plataformas compatibles con Veeam

Pruebas de frecuencia, retención y restauración de copias de seguridad

Incluso con la tolerancia a errores de hardware y Espacios de almacenamiento directo manteniendo varias copias de datos, es esencial implementar y probar periódicamente los procesos de copia de seguridad de datos. La redundancia de almacenamiento protege contra errores de infraestructura, pero no evita daños, eliminaciones o desastres en todo el sitio. Las copias de seguridad normales garantizan que puede restaurar datos o máquinas virtuales completas a un momento dado anterior si es necesario.

• Frecuencia de copia de seguridad y retención: asegúrese de que la frecuencia de copia de seguridad se alinea con el objetivo de punto de recuperación (RPO), que define la cantidad máxima aceptable de pérdida de datos para su organización. En función de la importancia de una máquina virtual para la empresa, programe copias de seguridad nocturnas o varias copias de seguridad al día si es necesario, mediante copias de seguridad incrementales. Además, implemente una directiva de retención que se alinee con los requisitos empresariales y de cumplimiento (por ejemplo, conservar copias de seguridad diarias durante dos semanas, copias de seguridad mensuales durante seis meses, copias de seguridad anuales durante siete años). Azure Backup, a través de Microsoft Azure Backup Server (MABS), puede facilitar tanto la retención local a corto plazo como la retención basada en la nube a largo plazo.

• Pruebas de restauraciones: una copia de seguridad solo es tan buena como la capacidad de restaurarla, por lo que es importante probar periódicamente la restauración de máquinas virtuales y datos de copias de seguridad. Realice periódicamente una prueba de recuperación de máquina virtual completa en una red aislada o en un clúster de laboratorio para asegurarse de que el proceso sea suave y oportuno. Esta práctica forma parte de la estrategia de recuperación ante desastres para garantizar que las copias de seguridad tienen su propósito en una emergencia real.

Replicación continua de máquinas virtuales críticas para la empresa

Aunque las copias de seguridad protegen los datos y habilitan la recuperación en un punto específico en el tiempo, no ofrecen capacidades de conmutación por error inmediatas. La restauración desde una copia de seguridad puede llevar mucho tiempo, a menudo tardando horas. En el caso de las máquinas virtuales empresariales o críticas en las que incluso el tiempo de inactividad o la pérdida de datos mínimos son inaceptables, las tecnologías de replicación continua proporcionan un mecanismo para mantener una copia de up-to-date de las máquinas virtuales en una ubicación secundaria. Estas tecnologías permiten una conmutación por error rápida y una pérdida de datos mínima en caso de desastre. Dos tecnologías de replicación continua compatibles con Azure Local son Azure Site Recovery y Hyper-V Réplica.

Uso de Azure Site Recovery para replicar máquinas virtuales locales de Azure en Azure

Azure Site Recovery es la solución de recuperación ante desastres basada en la nube de Microsoft diseñada para replicar máquinas virtuales locales en Azure. Azure Site Recovery facilita la replicación de máquinas virtuales locales de Azure en Azure, lo que garantiza la protección de las cargas de trabajo críticas para la empresa. Este servicio transmite continuamente los cambios de las máquinas virtuales locales a Azure. Como resultado, en caso de una interrupción significativa en su sitio o clúster local, puede realizar un failover de su máquina virtual a Azure para mantener la continuidad operativa.

Puntos clave sobre Azure Site Recovery para Azure Local:

• Implementación:

  • Implementación automatizada: Azure Local creó una extensión en Azure Site Recovery para la implementación automatizada. La extensión de Azure Site Recovery puede detectar todos los nodos del clúster e implementar Azure Site Recovery en todos los nodos automáticamente y configurarlos con la directiva de replicación. Para más información, consulte Protección de cargas de trabajo de máquina virtual con Azure Site Recovery.
  • Implementación manual: la extensión de Azure Site Recovery para Azure Local está en versión preliminar y solo se aplica a entornos de prueba. Para aquellos clientes que necesitan una solución lista para producción, Azure Site Recovery se puede configurar manualmente en el clúster local de Azure mediante la opción de recuperación ante desastres de Hyper-V a Azure.

• Replicación frecuente: Azure Site Recovery puede lograr objetivos de punto de recuperación (RPO) tan bajos como 30 segundos.

• Conmutación automática:

  • Una vez que se haya implementado la replicación, puede iniciar una conmutación por error hacia Azure. Este proceso inicia la VM en Azure usando los datos replicados. Puede probar este proceso mediante una conmutación por error de prueba, que crea una copia en Azure en una red aislada para la comprobación sin apagar las máquinas virtuales locales.
  • Durante un desastre real, si el sitio primario está inactivo inesperadamente, se realiza una conmutación por error no planeada incluso si la máquina virtual de origen no se está ejecutando.
  • En escenarios como el mantenimiento de hardware o el reemplazo, puede iniciar una conmutación por error planeada. Esta conmutación por error apaga de manera controlada la máquina virtual para que pueda guardar su memoria en el disco y garantizar la ausencia de pérdida de datos.
  • Después de la conmutación por error, la máquina virtual se ejecuta en Azure.

• Regreso:

  • Cuando se mitiga el desastre y el clúster está operativo, Azure Site Recovery puede revertir la dirección de replicación y replicar los cambios realizados durante el funcionamiento de Azure en el clúster local de Azure. Después de la replicación inversa, puede revertir la máquina virtual, lo que permite que las operaciones vuelvan a las instalaciones locales.

  • Para una conmutación inversa exitosa, el entorno local debe estar en buen estado. Si el clúster no está disponible, puede registrar otro clúster local de Azure en el sitio de Azure Site Recovery Hyper-V y conmutar por recuperación la máquina virtual a un nodo de un clúster alternativo.

    Nota:

    • La conmutación por recuperación de una máquina virtual local de Azure en un clúster alternativo conmuta por recuperación la máquina virtual como una máquina virtual no administrada. Esto significa que todos los servicios dentro de la máquina virtual empiezan a funcionar, pero la máquina virtual no se puede administrar desde Azure hasta que se registra en el nuevo clúster local de Azure y se vuelve a conectar a su recurso que existe en Azure.
    • La reconexión significa que el recurso de Azure se actualiza con el nuevo grupo de recursos (opcional, también puede mantenerlo en el mismo grupo de recursos), la ubicación personalizada, la ruta de acceso de almacenamiento y la red lógica de la máquina virtual.
    • Si la máquina virtual se restaura en el mismo clúster, no son necesarios el registro y la reconexión. La conexión de Azure de la máquina virtual se restaura y se sigue administrando desde Azure siempre y cuando esté dentro de la ventana de reconexión de 45 días de Azure Arc.

Para más información y para instalar Azure Site Recovery, consulte Protección de cargas de trabajo de máquina virtual con Azure Site Recovery en Azure Local (versión preliminar).

Uso de Hyper-V réplica para la replicación continua de máquinas virtuales críticas para la empresa

Hyper-V Réplica es una característica integrada en Azure Local que permite la replicación asincrónica de máquinas virtuales entre dos hosts de Hyper-V o clústeres de conmutación por error. Puede usar esta tecnología para replicar máquinas virtuales entre dos clústeres locales de Azure independientes, lo que proporciona una solución de recuperación ante desastres local.

Al habilitar Hyper-V Réplica para una máquina virtual, crea una copia inicial de la máquina virtual (incluida su configuración y VHD) en un clúster o servidor de réplica designado. Hyper-V Réplica realiza un seguimiento de los cambios realizados en la máquina virtual principal y los escribe en los archivos de registro. Transmite estos registros al sitio de réplica, donde los aplica a la máquina virtual de réplica de forma asincrónica.

Puntos clave sobre el uso de Hyper-V réplica con Azure Local:

• Implementación:

  • Implementación manual: no se puede configurar Hyper-V Réplica a través de Azure Portal. Use PowerShell en los nodos locales de Azure para configurarlo. Como alternativa, los administradores pueden acceder de forma remota al clúster de Azure Local desde cualquier máquina Windows Server dentro de la misma red y completar la configuración a través de la interfaz de usuario del Administrador de clústeres de conmutación por error. Necesita permisos adecuados para conectarse a los clústeres locales de Azure y administrarlos.

  • Configuración: habilite los clústeres locales de Azure para que actúen como servidores de réplica, configure métodos de autenticación (normalmente Kerberos dentro de un dominio o basado en certificados para escenarios no unidos a un dominio o entre dominios), configure reglas de firewall para permitir el tráfico de replicación y, a continuación, habilite la replicación por máquina virtual. La configuración por máquina virtual (VM) incluye especificar el servidor de réplica o el clúster, seleccionar los discos duros virtuales (VHD) que se van a replicar, elegir la frecuencia de replicación y definir cuántos puntos de recuperación (instantáneas temporales) se deben mantener en el lado de la réplica. Hyper-V Réplica admite la replicación, la conmutación por error de prueba, la conmutación por error, la replicación inversa y la conmutación por recuperación para escenarios planeados y no planeados.

• Frecuencia de replicación: puede configurar la frecuencia de replicación para que se produzca cada 30 segundos, 5 minutos o 15 minutos.

• Conmutación automática:

  • Una vez que se haya implementado la replicación, puede iniciar una conmutación por error en el servidor de réplica. Esta acción inicia la VM en el servidor de réplica mediante los datos replicados. Puede probar esta acción mediante una conmutación por error de prueba, que crea una máquina virtual en una red aislada para la comprobación sin apagar la máquina virtual replicada.

  • Durante un desastre real, si el sitio primario está inactivo inesperadamente, puede realizar una conmutación por error no planeada incluso si la máquina virtual replicada no se está ejecutando.

    • En escenarios como el mantenimiento de hardware o el reemplazo, puede iniciar una conmutación por error planeada. Este proceso apaga de forma adecuada la máquina virtual replicada, lo que garantiza que su memoria se guarda en el disco para evitar la pérdida de datos.

  • Después del failover, su VM se ejecuta en el servidor de réplica.

    Nota:

    • La conmutación por error de una máquina virtual local de Azure al clúster de réplica conmuta por error la máquina virtual como una máquina virtual no administrada. Esto significa que todos los servicios dentro de la máquina virtual empiezan a funcionar, pero no se puede administrar la máquina virtual desde Azure hasta que se registre en el nuevo clúster local de Azure y se vuelva a conectar a su recurso que existe en Azure.
    • La reconexión significa que el recurso de Azure se actualiza con el nuevo grupo de recursos (opcional, también puede mantenerlo en el mismo grupo de recursos), la ubicación personalizada, la ruta de acceso de almacenamiento y la red lógica de la máquina virtual.
    • Es posible que el registro y la reconexión no sean necesarios si la conmutación por error es temporal y se espera que la máquina virtual regrese al clúster original una vez que se haya mitigado el desastre. Durante este período, la máquina virtual no se puede administrar desde Azure, pero sus servicios están operativos.

• Regreso:

  • Una vez mitigado el desastre y el clúster está operativo, Hyper-V Replica puede invertir la dirección de la replicación y duplicar los cambios realizados mientras se trabaja en el servidor de réplicas de regreso al clúster local original de Azure.

  • Después de la replicación inversa, puede revertir la máquina virtual, lo que permite que esta vuelva a su clúster de origen.

    Nota:

    Una vez que la máquina virtual recupera su clúster de origen, no se necesitan registro ni reconexión. La conexión de Azure de la máquina virtual se restaura y se sigue administrando desde Azure siempre y cuando esté dentro de la ventana de reconexión de 45 días de Azure Arc.

Para obtener más información, consulte los pasos de implementación en Configuración de Hyper-V réplica.

Funcionalidad

Al habilitar Hyper-V Réplica para una máquina virtual, crea una copia inicial de la máquina virtual (incluida su configuración y VHD) en un clúster o servidor de réplica designado. Hyper-V Réplica realiza un seguimiento de los cambios realizados en la máquina virtual principal y los escribe en los archivos de registro. Transmite estos registros al sitio de réplica y los aplica a la máquina virtual de réplica de forma asincrónica, en función de una frecuencia de replicación configurable (por ejemplo, cada 30 segundos, 5 minutos o 15 minutos).

La configuración implica habilitar los clústeres de Azure Local para que actúen como servidores de réplica, configurar métodos de autenticación (normalmente Kerberos dentro de un dominio o basados en certificados para escenarios que no están unidos a un dominio o entre dominios), configurar reglas de firewall para permitir el tráfico de replicación y, a continuación, habilitar la replicación por máquina virtual. La configuración por máquina virtual (VM) incluye especificar el servidor de réplica o el clúster, seleccionar los discos duros virtuales (VHD) que se van a replicar, elegir la frecuencia de replicación y definir cuántos puntos de recuperación (instantáneas temporales) se deben mantener en el lado de la réplica. Hyper-V Réplica admite la replicación, la conmutación por error de prueba, la conmutación por error, la replicación inversa y la conmutación por recuperación para escenarios planeados y no planeados.

Configuración

Debe configurar Hyper-V Replica mediante PowerShell en nodos locales de Azure, o bien puede configurarla de forma remota a través de la interfaz de usuario del Administrador de clústeres de conmutación por error en cualquier máquina Windows Server dentro de la misma red que las instancias de Azure Local. Necesita los permisos adecuados para conectarse y administrar las máquinas locales de Azure. No hay ninguna opción para configurar Hyper-V Réplica desde Azure Portal.

Para obtener más información, consulte los pasos de implementación en Configuración de Hyper-V réplica.

Consideraciones de red y rendimiento

Durante el proceso de replicación, el hardware y la red que usa afectan a los servicios que dependen de ellos. En función de la cantidad de datos replicados entre los sistemas de origen y de destino, este proceso consume una gran cantidad de recursos del sistema. El rendimiento del dispositivo se ve afectado hasta que se completa este proceso. Se requiere un ancho de banda de red adecuado entre los dos clústeres locales de Azure para que Hyper-V réplica funcione de forma óptima, especialmente con intervalos de replicación inferiores (por ejemplo, 30 segundos). Del mismo modo, el clúster de destino necesita suficientes operaciones de salida de entrada de almacenamiento por segundo (IOPS) para mantenerse al día con el tráfico de replicación entrante. Para obtener más información, consulte Optimización de características y rendimiento de Hyper-V Réplica (HVR).

Comparación de Azure Site Recovery y réplica de Hyper-V

Al elegir entre Azure Site Recovery y Hyper-V réplica para máquinas virtuales locales de Azure, tenga en cuenta las diferencias entre ambas soluciones:

Utilice tanto Azure Site Recovery como Hyper-V Replica: las organizaciones con sitios remotos que tienen clústeres únicos y centros más grandes con varios clústeres pueden extender Azure como sitio de recuperación ante desastres. Use Azure Site Recovery para sitios remotos y Hyper-V réplica para ubicaciones más grandes. Esta arquitectura permite que algunas máquinas virtuales se repliquen en Azure, mientras que otras se replican en un sitio secundario, lo que garantiza la flexibilidad y las estrategias de recuperación ante desastres adaptadas para diversas necesidades operativas.

Planes de recuperación y pruebas

Es esencial tener un plan de recuperación en el que se documenten todos los pasos necesarios para realizar el failover de las cargas de trabajo, incluida la secuencia correspondiente (por ejemplo, los controladores de dominio deben activarse antes que los servidores de aplicaciones) y cualquier ajuste de red necesario, como las actualizaciones de DNS y la redirección de usuarios. Hyper-V Réplica permite la creación de planes de recuperación, lo que permite la secuenciación de grupos de máquinas virtuales y la inclusión de scripts como parte del proceso de conmutación por error. Estos planes pueden ser manuales o scriptados a través de PowerShell.

Pruebe periódicamente el plan de recuperación ante desastres mediante simulados simulados. Realice un simulacro de conmutación por error al menos una vez al mes para garantizar la funcionalidad y mantener la habilidad del personal. Además, las pruebas revelan si se cumplen los objetivos de tiempo de recuperación (RTO), como el tiempo necesario para poner en marcha en Azure o en hardware secundario.

Para más información, consulte Estrategias de arquitectura para diseñar una estrategia de recuperación ante desastres.

Pasos siguientes

• Obtenga más información sobre la resistencia de las cargas de trabajo.