Recuperación ante desastres para máquinas virtuales de Azure Stack Hub

En este documento se describen las consideraciones de diseño y arquitectura de una solución que ofrece un enfoque optimizado para la recuperación ante desastres de cargas de trabajo de usuario que se ejecutan en máquinas virtuales (VM) hospedadas en Azure Stack Hub.

Architecture

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

Los componentes en la nube de la solución propuesta incluyen los siguientes servicios:

• Una suscripción de Azure que hospede todos los recursos en la nube que forman parte de esta solución.

• Un inquilino de Microsoft Entra ID asociado a la suscripción de Azure que proporciona autenticación de entidades de seguridad de Microsoft Entra para autorizar el acceso a los recursos de Azure.

• Un almacén de Azure Recovery Services en la región de Azure más cercana al centro de datos local que hospeda la implementación de Azure Stack Hub.

  Nota:

  La elección de la región de Azure más cercana al centro de datos local es específica del escenario de ejemplo incluido en este artículo. Desde el punto de vista de la recuperación ante desastres, sería preferible seleccionar una región de Azure fuera de la ubicación que hospeda el entorno de producción. Sin embargo, la decisión podría depender de factores adicionales, como la necesidad de minimizar la latencia de las fuentes de distribución de datos regionales o satisfacer los requisitos de residencia de datos.

• Un circuito de Azure ExpressRoute que conecta los centros de datos locales a la región de Azure que hospeda el almacén de Azure Recovery Services, configurado con emparejamiento privado y emparejamiento de Microsoft. El primero garantiza que se cumplan los requisitos de latencia después de una conmutación por error. El propósito del último es minimizar la cantidad de tiempo que se tarda en replicar los cambios entre las cargas de trabajo locales y el sitio de conmutación por error en Azure.

• Una cuenta de Azure Storage que hospede blobs que contengan archivos VHD creados por la replicación de los volúmenes de datos y del sistema operativo de las máquinas virtuales de Azure Stack Hub protegidas. Estos archivos VHD sirven como origen para los discos administrados de máquinas virtuales de Azure que se aprovisionan automáticamente después de una conmutación por error.

• Una red virtual de Azure que hospeda el entorno de recuperación ante desastres. Está configurada de manera que refleje el entorno de red virtual en la instancia de Azure Stack Hub que hospeda las cargas de trabajo de producción, incluidos componentes como equilibradores de carga y grupos de seguridad de red. Normalmente, esta red virtual se conecta a la red virtual de Azure Stack Hub a través de una conexión de ExpressRoute para facilitar la recuperación de nivel de carga de trabajo.

  Nota

  A veces, una conexión VPN de sitio a sitio basta en escenarios en los que los requisitos de objetivo de punto de recuperación (RPO) son menos estrictos.

• Una red virtual de Azure aislada destinada para conmutaciones por error de prueba, configurada de manera que refleje el entorno de red virtual en la instancia de Azure Stack Hub que hospeda las cargas de trabajo de producción, incluidos componentes como equilibradores de carga y grupos de seguridad de red.

Los componentes locales de la solución propuesta incluyen los siguientes servicios:

• Un sistema integrado de Azure Stack Hub en el modelo de implementación conectado. El sistema ejecuta la actualización actual (2002 a partir del 20/9) y se encuentra en el centro de datos local del cliente.

• Una suscripción de Azure Stack Hub y una red virtual o varias redes virtuales emparejadas que hospedan todas las máquinas virtuales locales de esta solución.

• Servidores de configuración y procesos de Azure Site Recovery que se ejecutan en máquinas virtuales de Azure Hub Stack de Windows Server 2016 o 2012 R2. Los servidores administran las comunicaciones con el almacén de Azure Recovery Services y el enrutamiento, la optimización y el cifrado del tráfico de replicación.

  Nota

  De manera predeterminada, un servidor de configuración hospeda un único servidor de procesos. Puede implementar servidores de procesos dedicados para dar cabida a un mayor volumen de tráfico de replicación.

• Máquinas virtuales de Azure Stack Hub que se van a proteger. Ejecutan versiones compatibles de los sistemas operativos Windows Server, CentOS y Ubuntu.

• El servicio Mobility de Site Recovery (también denominado agente de movilidad) que se ejecuta en máquinas virtuales protegidas. Realiza un seguimiento de los cambios en los discos locales, registra los cambios en los registros de replicación y replica los registros en el servidor de procesos. El servidor de procesos los enruta a la cuenta de almacenamiento de Azure de destino. Los registros se usan para crear puntos de recuperación para los discos administrados implementados mediante blobs almacenados en la cuenta de almacenamiento de Azure designada.

Componentes

• Microsoft Entra ID
• Azure Virtual Network
• Azure Recovery Services
• Azure ExpressRoute
• Azure Blob Storage
• Azure Stack Hub

Alternativas

La solución recomendada que se describe en este artículo no es la única manera de proporcionar funcionalidad de recuperación ante desastres para las cargas de trabajo basadas en máquinas virtuales de Azure Stack Hub. Los clientes tienen otras opciones, entre las que se incluyen:

• Una conmutación por error a otro stamp de Azure Stack Hub. Los usuarios que necesitan protegerse frente a una interrupción del sitio o del centro de datos podrían usar otra implementación de Azure Stack Hub para implementar las provisiones de recuperación ante desastres. Con las ubicaciones principal y secundaria, los usuarios pueden implementar aplicaciones en una configuración activo/pasivo en dos entornos. En el caso de cargas de trabajo menos críticas, podría ser aceptable utilizar la capacidad sin usar de la ubicación secundaria para restaurar aplicaciones a petición desde una copia de seguridad. También puede implementar un sitio de recuperación en otro centro de datos que, a su vez, usa Site Recovery para aprovisionar una réplica del sitio de recuperación en Azure. Varios factores determinan si el uso de Site Recovery con Azure como sitio de conmutación por error es una solución viable. Estos factores incluyen los reglamentos gubernamentales, las directivas corporativas y los requisitos de latencia.

  Nota

  A partir de julio de 2020, Site Recovery no admite este escenario, lo que significa que la implementación tendría que depender de una solución de un asociado o interna.

• Copia de seguridad y restauración. La copia de seguridad tanto de las aplicaciones como de los conjuntos de datos le permite recuperarse rápidamente del tiempo de inactividad provocado por datos dañados, eliminaciones involuntarias o interrupciones localizadas. En el caso de las aplicaciones basadas en máquinas virtuales de Azure Stack Hub, puede usar un agente invitado para proteger los datos de la aplicación, la configuración del sistema operativo y los datos almacenados en los volúmenes. La copia de seguridad de cualquier máquina virtual mediante un agente del sistema operativo invitado habitualmente incluye la captura de configuraciones del sistema operativo, archivos, carpetas, volúmenes, archivos binarios de aplicaciones y datos de aplicaciones. La recuperación de una aplicación de un agente requiere volver a crear la máquina virtual e instalar tanto el sistema operativo como el agente invitado. En ese momento, puede restaurar los datos en el sistema operativo invitado.

• Copias de seguridad de instantáneas de discos. Es posible usar instantáneas para capturar una configuración de máquina virtual de Azure Stack Hub y los discos conectados a una máquina virtual detenida. Este proceso requiere hacer una copia de seguridad de los productos que se integran en las API de Azure Stack Hub para capturar la configuración de las máquinas virtuales y crear instantáneas de discos.

  Nota

  A partir de julio de 2020, no se admite el uso de instantáneas de discos para máquinas virtuales que se encuentren en ejecución. La creación de una instantánea de un disco conectado a una máquina virtual en ejecución puede reducir el rendimiento o afectar a la disponibilidad del sistema operativo o de la aplicación en la máquina virtual.

• Haga copias de seguridad y restaure las máquinas virtuales con una solución de copia de seguridad externa en el mismo centro de datos y, luego, replique las copias de seguridad en otra ubicación. De este modo, puede restaurar las máquinas virtuales de Azure Stack Hub en la misma instancia de Azure Stack Hub, o en una diferente, o en Azure.

Detalles del escenario

Azure Stack Hub incluye funcionalidad de recuperación automática, que proporciona corrección automática en una variedad de escenarios que implican errores localizados de sus componentes. Sin embargo, los errores a gran escala, incluidas las interrupciones que afectan a los bastidores de servidor o los desastres de nivel de sitio, requieren consideraciones adicionales. Estas consideraciones deben formar parte de la estrategia de recuperación ante desastres y continuidad empresarial para cargas de trabajo de usuario basadas en máquinas virtuales. Esta estrategia también debe tener en cuenta la recuperación de la infraestructura de Azure Stack, que es independiente de la recuperación de la carga de trabajo.

Las soluciones de recuperación de la carga de trabajo locales tradicionales son complejas de configurar, costosas y laboriosas de mantener y difíciles de automatizar, especialmente cuando se usa otra ubicación local, como el sitio de conmutación por error. Microsoft recomienda una solución alternativa que se basa en una combinación de los componentes en la nube y locales para ofrecer maneras resistentes, basadas en rendimiento, muy automatizadas y sencillas de implementar, proteger y lograr una estrategia de recuperación ante desastres rentable. El elemento principal de esta solución es Site Recovery, con el sitio de conmutación por error que reside en Azure.

Posibles casos de uso

Site Recovery con Azure como sitio de conmutación por error elimina todas estas desventajas. Puede usar sus funcionalidades para proteger servidores físicos y virtuales, incluidos los que se ejecutan en plataformas de virtualización VMware ESXi o de Microsoft Hyper-V. También puede usar las mismas funcionalidades para facilitar la recuperación de las cargas de trabajo que se ejecutan en máquinas virtuales de Azure Stack Hub.

Funcionalidad básica

Site Recovery es una solución de recuperación ante desastres que facilita la protección de equipos físicos y virtuales al proporcionar dos conjuntos de características:

• Replicación de cambios en discos del equipo que se encuentran entre las ubicaciones de recuperación ante desastres y de producción.
• Orquestación de conmutación por error y conmutación por recuperación entre estas dos ubicaciones.

Site Recovery ofrece tres tipos de conmutaciones por error:

• Probar la conmutación por error. Esta conmutación por error le ofrece la oportunidad de validar la configuración de Site Recovery en un entorno aislado, sin pérdida de datos ni impacto en el entorno de producción.
• Conmutación por error planeada. Esta conmutación por error ofrece la opción de iniciar la recuperación ante desastres sin pérdida de datos, normalmente como parte del tiempo de inactividad planeado.
• Conmutación por error no planeada. Esta conmutación por error actúa como último recurso en caso de que se produzca una interrupción no planeada que afecte a la disponibilidad del sitio principal y que pueda provocar la pérdida de datos.

Site Recovery admite varios escenarios, como conmutación por error y conmutación por recuperación entre dos sitios locales, conmutación por error y conmutación por recuperación entre dos regiones de Azure y migración desde las nubes de proveedores de terceros. Sin embargo, en el contexto de este artículo, el enfoque está en la replicación de discos locales de máquinas virtuales de Azure Stack Hub en Azure Storage y en la conmutación por error de máquina virtual y la conmutación por recuperación entre una pila de Azure Stack Hub y una región de Azure.

Los detalles de la arquitectura de Site Recovery y sus componentes dependen de varios criterios, entre los que se incluyen:

• Los tipos de equipos que se van a proteger (físicos y virtuales).
• En el caso de los entornos virtualizados, el tipo de hipervisor que hospeda las máquinas virtuales que se van a proteger (Hyper-V frente a VMware ESXi).
• En entornos de Hyper-V, el uso de System Center Virtual Machine Manager (SCVMM) para la administración de hosts de Hyper-V.

Con Azure Stack Hub, la arquitectura coincide con la que se aplica a los equipos físicos. Esto no es especialmente sorprendente, porque en ambos casos, Site Recovery no puede beneficiarse del acceso directo a un hipervisor. En su lugar, el mecanismo que realiza el seguimiento y la replicación de los cambios en los discos locales se implementa en el sistema operativo protegido.

Para ello, Site Recovery se basa en el servicio Mobility de Site Recovery (también conocido como agente de movilidad), que se implementa automáticamente en máquinas virtuales individuales a medida que las inscribe en el ámbito de la protección basada en Azure Site Recovery. En cada máquina virtual protegida, la instancia instalada localmente del agente de movilidad supervisa y reenvía continuamente los cambios en el sistema operativo y los discos de datos al servidor de procesos. Sin embargo, para optimizar y administrar el flujo de tráfico de replicación que se origina en máquinas virtuales protegidas, Site Recovery implementa un conjunto adicional de componentes que se ejecutan en una máquina virtual independiente, lo que se conoce como servidor de configuración.

El servidor de configuración coordina la comunicación con el almacén de Site Recovery y administra la replicación de datos. Además, el servidor de configuración hospeda un componente denominado servidor de procesos, que actúa como puerta de enlace, que recibe datos de replicación, los optimiza a través del almacenamiento en caché y la compresión, los cifra y, por último, los reenvía a Azure Storage. De hecho, el servidor de configuración funciona como el punto de integración entre Site Recovery y las máquinas virtuales protegidas que se ejecutan en Azure Stack Hub. Para implementar esa integración, implemente el servidor de configuración y regístrelo con el almacén de Azure Recovery Services.

Como parte de la configuración de Site Recovery, se define el entorno de recuperación ante desastres previsto, incluidos los componentes de infraestructura como redes virtuales, equilibradores de carga o grupos de seguridad de red de la manera que refleja el entorno de producción. La configuración también incluye una directiva de replicación, que determina las capacidades de recuperación y consta de los siguientes parámetros:

• Umbral de RPO. Esta configuración representa el objetivo de punto de recuperación deseado que quiere implementar y determina la frecuencia con la que Site Recovery genera instantáneas de punto de recuperación consistentes entre bloqueos. Su valor no afecta a la frecuencia de replicación, ya que la replicación es continua. Site Recovery generará una alerta y, opcionalmente, una notificación por correo electrónico, si el RPO vigente actual proporcionado por Site Recovery supera el umbral especificado. Site Recovery genera instantáneas de punto de recuperación consistentes entre bloqueos cada cinco minutos.

  Nota

  Una instantánea coherente frente a bloqueos captura los datos que estaban en el disco cuando se tomó la instantánea. No incluye el contenido de la memoria. En la práctica, una instantánea coherente frente a bloqueos no garantiza la coherencia de datos para el sistema operativo o las aplicaciones instaladas localmente.

• Retención de punto de recuperación. Esta configuración representa la duración del período (en horas) de retención para cada instantánea de punto de recuperación. Las máquinas virtuales protegidas se pueden recuperar en cualquier punto de recuperación dentro de un período de retención. Site Recovery admite hasta 24 horas de retención para las máquinas virtuales replicadas en cuentas de Azure Storage con el nivel de rendimiento Premium. Hay un límite de retención de 72 horas al usar cuentas de Azure Storage con el nivel de rendimiento estándar.

• Frecuencia de las instantáneas coherentes con la aplicación. Esta configuración determina la frecuencia (en horas) con la que Site Recovery genera instantáneas consistente entre aplicaciones. Una instantánea coherente con la aplicación representa una instantánea en un momento dado de las aplicaciones que se ejecutan en una máquina virtual protegida. Hay un límite de 12 instantáneas consistentes entre aplicaciones. En el caso de las máquinas virtuales que ejecutan Windows Server, Site Recovery usa el Servicio de instantáneas de volumen (VSS). Site Recovery también admite instantáneas consistentes entre aplicaciones para Linux, pero se requiere la implementación de scripts personalizados. El agente de movilidad usa los scripts al aplicar una instantánea coherente con la aplicación.

  Nota

  Para más información sobre la implementación de instantáneas consistentes entre aplicaciones en máquinas virtuales de Azure Stack Hub que ejecutan Linux, consulte Preguntas generales acerca de Site Recovery.

Para cada disco de una máquina virtual de Azure Stack Hub protegida que designe, los datos se replican en un disco administrado correspondiente en Azure Storage. El disco almacena la copia del disco de origen y todas las instantáneas coherentes con la aplicación y coherentes frente a bloqueos del punto de recuperación. Como parte de una conmutación por error, elija una instantánea coherente con la aplicación o coherente frente a bloqueos del punto de recuperación que se debe usar al conectar el disco administrado a la máquina virtual de Azure, que actúa como réplica de la máquina virtual protegida de Azure Stack Hub.

Durante las operaciones de negocios habituales, las cargas de trabajo protegidas se ejecutan en máquinas virtuales de Azure Stack Hub, con cambios en los discos que se replican continuamente a través de interacciones entre el agente de movilidad, el servidor de procesos y el servidor de configuración en la cuenta de Azure Storage designada. Cuando se inicia una conmutación por error de prueba, planeada o no planeada, Site Recovery aprovisiona automáticamente las máquinas virtuales de Azure mediante las réplicas de discos de las máquinas virtuales de Azure Stack Hub correspondientes.

Tiene la opción de orquestar una conmutación por error mediante la creación de planes de recuperación que contengan pasos manuales y automatizados. Para implementar esta última opción, puede usar los runbooks de Azure Automation, que constan de scripts de PowerShell personalizados, flujos de trabajo de PowerShell o scripts de Python 2.

Una vez que el sitio principal vuelve a estar disponible, Site Recovery admite la reversión de la dirección de replicación, lo que le permite realizar una conmutación por recuperación con un tiempo de inactividad minimizado y sin pérdida de datos. Sin embargo, con Azure Stack Hub, este enfoque no está disponible. En su lugar, para la conmutación por recuperación, es necesario descargar los archivos de disco de la máquina virtual de Azure, cargarlos en Azure Stack Hub y conectarlos a las máquinas virtuales nuevas o existentes.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

Azure Stack Hub ayuda a aumentar la disponibilidad de la carga de trabajo a través de la resistencia inherente a su infraestructura. Esta resistencia proporciona alta disponibilidad para las máquinas virtuales de Azure Stack Hub protegidas por Azure Site Recovery y los componentes esenciales de la infraestructura de Site Recovery local, incluidos los servidores de configuración y de procesos.

Del mismo modo, tiene la opción de usar la resistencia de los componentes basados en la nube de la infraestructura de Site Recovery. De manera predeterminada, Azure Recovery Services tiene redundancia geográfica, lo que significa que su configuración se replica automáticamente en una región de Azure que forma parte de un par de regiones predefinido. Tiene la opción de cambiar la configuración de replicación a redundancia local si es suficiente para sus necesidades de resistencia. Tenga en cuenta que no puede cambiar esta opción si el almacén contiene elementos protegidos. La misma opción de resistencia está disponible para las cuentas de Azure Storage con el nivel de rendimiento estándar, aunque es posible cambiarla en cualquier momento.

Puede mejorar aún más el grado de esta resistencia diseñando e implementando soluciones que amplíen el ámbito de la protección de la carga de trabajo. Este es el valor adicional que ofrece Site Recovery. En el contexto de Site Recovery que se ejecuta en Azure Stack Hub, hay dos aspectos principales de la disponibilidad de la carga de trabajo que deben explorarse con más detalle:

• Conmutación por error a Azure
• Conmutación por recuperación a Azure Stack Hub

Tendrá que tener en cuenta ambos aspectos al desarrollar una estrategia de recuperación ante desastres controlada por objetivos de punto de recuperación (RPO) y objetivos de tiempo de recuperación (RTO). RTO y RPO representan los requisitos de continuidad estipulados por las funciones empresariales individuales dentro de una organización. RPO designa un período de tiempo que representa la pérdida máxima aceptable de datos después de un incidente que afecte a la disponibilidad de los datos. RTO designa la duración máxima aceptable del tiempo que puede tardar en restablecer funciones empresariales después de un incidente que afecte a la disponibilidad de estas funciones.

Conmutación por error a Azure

La conmutación por error en Azure es esencial para las consideraciones sobre disponibilidad en el contexto de la protección basada en Site Recovery de máquinas virtuales de Azure Stack Hub. Para maximizar la disponibilidad de la carga de trabajo, la estrategia de conmutación por error debe abordar la necesidad de minimizar la posible pérdida de datos (RPO) y el tiempo de conmutación por error (RTO).

Para minimizar la posible pérdida de datos, puede tener en cuenta lo siguiente:

• Maximización del rendimiento y minimización de la latencia del tráfico de replicación mediante las siguientes consideraciones de escalabilidad y rendimiento. Para más información, consulte la sección siguiente de este artículo.
• Aumento de la frecuencia de los puntos de recuperación coherentes con la aplicación para las cargas de trabajo de base de datos (hasta el máximo de un punto de recuperación por hora). Se crean puntos de recuperación coherentes con la aplicación a partir de instantáneas coherentes con la aplicación. Las instantáneas coherentes con la aplicación capturan los datos de la aplicación en el disco y en la memoria. Aunque este enfoque minimiza la posible pérdida de datos, tiene un importante inconveniente. Las instantáneas coherentes con la aplicación requieren el uso del Servicio de instantáneas de volumen en Windows o scripts personalizados en Linux para poner en reposo aplicaciones instaladas localmente. El proceso de captura puede afectar al rendimiento, especialmente si el uso de recursos es alto. No se recomienda usar baja frecuencia con las instantáneas consistentes entre aplicaciones en cargas de trabajo que no son de base de datos.

El método principal para minimizar el tiempo de conmutación por error implica el uso de planes de recuperación de Site Recovery. Un plan de recuperación organiza una conmutación por error entre los sitios primarios y secundarios y define la secuencia en la que los servidores protegidos conmutan por error. Puede personalizar un plan agregándole instrucciones manuales y tareas automatizadas. Su finalidad es hacer que el proceso sea coherente, preciso, repetible y automatizado.

Al crear un plan de recuperación, se asignan servidores protegidos a grupos de recuperación con el fin de realizar la conmutación por error. Los servidores de cada grupo conmutan por error juntos. Esto le ayuda a dividir el proceso de conmutación por error en unidades más pequeñas y más fáciles de administrar, que representan conjuntos de servidores que pueden conmutar por error sin depender de dependencias externas.

Para minimizar el tiempo de conmutación por error, como parte de la creación de un plan de recuperación, debe hacer lo siguiente:

• Defina grupos de máquinas virtuales de Azure Stack Hub que deben conmutar por error juntas.
• Defina las dependencias entre los grupos de máquinas virtuales de Azure Stack Hub para determinar la secuencia óptima de una conmutación por error.
• Automatice las tareas de conmutación por error, si es posible.
• Incluya acciones manuales personalizadas, si es necesario.

Defina un plan de recuperación y cree grupos de recuperación para capturar propiedades específicas de la aplicación. Por ejemplo, consideremos una aplicación tradicional de tres niveles con un back-end de SQL Server, un componente de middleware y un front-end web. Al crear un plan de recuperación, puede controlar el orden de inicio de los servidores en cada nivel, conectando en primer lugar los servidores que ejecutan instancias de SQL Server, seguidos de los del nivel de middleware y, después, de los servidores que hospedan el front-end web. Esta secuencia garantiza que para cuando el último servidor se inicia, la aplicación está en funcionamiento. Para implementarla, puede simplemente crear un plan de recuperación con tres grupos de recuperación que contengan servidores en los niveles respectivos.

Además de controlar la conmutación por error y el orden de inicio, también tiene la opción de agregar acciones a un plan de recuperación. En general, existen dos tipos de acciones:

• Automatizada. Esta acción se basa en los runbooks de Azure Automation, que implican uno de los dos tipos de tareas:
  • Aprovisionamiento y configuración de recursos de Azure, entre los que se incluyen, por ejemplo, la creación de una dirección IP pública y su asociación con la interfaz de red asociada a una máquina virtual de Azure.
  • Modificación de la configuración del sistema operativo y las aplicaciones que se ejecutan en una máquina virtual de Azure aprovisionada después de una conmutación por error.
• Manual. Esta acción no admite la automatización y se incluye en un plan de recuperación principalmente para fines de documentación.

Conmutación por recuperación a Azure Stack Hub

En escenarios basados en Site Recovery, la conmutación por recuperación, si se implementa correctamente, no implica pérdida de datos. Esto significa que el enfoque de la estrategia de conmutación por error es minimizar el tiempo de conmutación por recuperación (RTO). Sin embargo, como se mencionó anteriormente, cuando se conmuta por recuperación a Azure Stack Hub, no se puede depender de los planes de recuperación. En su lugar, la conmutación por recuperación implica la siguiente secuencia de pasos:

1. Detenga y desasigne las máquinas virtuales de Azure en el entorno de recuperación ante desastres.
2. Identifique el parámetro URI de cada uno de los discos administrados asociados a las máquinas virtuales que quiere descargar.
3. Descargue los archivos de disco duro virtual (VHD) identificados por los parámetros de URI que identificó en el paso anterior al entorno local.
4. Cargue los archivos VHD en Azure Stack Hub.
5. Asocie los VHD cargados a máquinas virtuales de Azure Stack Hub nuevas o existentes.
6. Inicie las máquinas virtuales de Azure Stack Hub.

El enfoque óptimo para minimizar el tiempo de la conmutación por recuperación es automatizarlo.

Consideraciones específicas de la carga de trabajo

Site Recovery se integra con las aplicaciones y roles basados en Windows Server, incluidos SharePoint, Exchange, SQL Server y Active Directory Domain Services (AD DS). Esto le permite usar las siguientes funcionalidades para implementar la protección y recuperación en el nivel de la aplicación:

• Integración con tecnologías de replicación de nivel de aplicación, como Grupos de disponibilidad AlwaysOn de SQL Server, Grupos de disponibilidad de base de datos de Exchange (DAG) y replicación de AD DS.
• Instantáneas coherentes con la aplicación para aplicaciones de uno o varios niveles.
• Una biblioteca de automatización enriquecida que proporciona scripts específicos de la aplicación y preparados para la producción que pueden descargarse e integrarse con los planes de recuperación.

También tiene la opción de usar mecanismos de replicación específicos de la carga de trabajo para proporcionar resistencia en el nivel de sitio. Se trata de una opción que se usa normalmente al implementar la recuperación ante desastres para controladores de dominio de AD DS, SQL Server o Exchange, que admiten la replicación de forma nativa. Aunque esto requiere el aprovisionamiento de máquinas virtuales de Azure que hospedan estas cargas de trabajo en el entorno de recuperación ante desastres, lo que aumenta el costo, ofrece las siguientes ventajas:

• Reduce el tiempo necesario para la conmutación por error y la conmutación por recuperación.
• Simplifica la conmutación por error en el nivel de la carga de trabajo, adaptándose a los escenarios en los que no se requiere la conmutación por error de nivel de sitio.

Seguridad

La administración de la recuperación ante desastres de cargas de trabajo basadas en máquinas virtuales de usuario en escenarios híbridos garantiza consideraciones de seguridad adicionales. Estas consideraciones se pueden agrupar en las siguientes categorías:

• Cifrado en tránsito. Esto incluye la comunicación entre máquinas virtuales de Azure Stack Hub protegidas, componentes de Site Recovery locales y componentes de Site Recovery basados en la nube:

  • El agente de movilidad instalado en las máquinas virtuales protegidas siempre se comunica con el servidor de procesos mediante Seguridad de la capa de transporte (TLS) 1.2.
  • Sin embargo, la comunicación del servidor de configuración a Azure y del servidor de procesos a Azure podría usar TLS 1.1 o 1.0. Para aumentar el nivel de seguridad de la conectividad híbrida, considere la posibilidad de exigir el uso de TLS 1.2.

  Nota

  Para obtener más información sobre la configuración del cifrado basado en TLS 1.2, consulte Configuración del registro de Seguridad de la capa de transporte (TLS) y Actualización para habilitar TLS 1.1 y TLS 1.2 como protocolos seguros de forma predeterminada de WinHTTP en Windows.

• Cifrado en reposo. Esto incluye máquinas virtuales de Azure y Azure Storage en el sitio de recuperación ante desastres.

  • Azure Storage está cifrado en reposo para todas las cuentas de almacenamiento que usan el Estándar de cifrado avanzado de 256 bits y es compatible con el Estándar federal de procesamiento de información 140-2. El cifrado se habilita automáticamente y no se puede deshabilitar. De manera predeterminada, el cifrado usa claves administradas por Microsoft, pero los clientes tienen la opción de usar sus propias claves almacenadas en Azure Key Vault.
  • Los discos administrados de las máquinas virtuales de Azure se cifran automáticamente mediante el cifrado del lado servidor de Azure Managed Disks, que también se aplica a sus instantáneas, confiando en el uso de claves de cifrado administradas por la plataforma.

Además, puede aplicar acceso restringido a las cuentas de Azure Storage que hospedan el contenido de los discos replicados de Site Recovery. Para ello, habilite la identidad administrada para el almacén de Recovery Services y asígnele los siguientes roles de control de acceso basado en roles (Azure RBAC) de Azure en el nivel de cuenta de Azure Storage:

• Cuentas de almacenamiento basadas en Resource Manager (nivel de rendimiento estándar):
  • Colaborador
  • Colaborador de datos de blobs de almacenamiento
• Cuentas de almacenamiento basadas en Resource Manager (nivel de rendimiento premium):
  • Colaborador
  • Propietario de datos de blobs de almacenamiento

El almacén de Azure Recovery Services ofrece mecanismos que protegen aún más su contenido, incluidas las siguientes protecciones:

• Azure RBAC. Esto permite la delegación y segregación de responsabilidades según el principio de privilegios mínimos. Hay tres roles integrados relacionados con Site Recovery que restringen el acceso a las operaciones de Site Recovery:
  • Colaborador de Site Recovery. Este rol tiene todos los permisos necesarios para administrar las operaciones de Site Recovery en un almacén de Azure Recovery Services. Sin embargo, un usuario con este rol no puede crear ni eliminar el almacén, ni tampoco asignar derechos de acceso a otros usuarios. Este rol es ideal para administradores de recuperación ante desastres que pueden habilitar y administrar la recuperación ante desastres para un inquilino de Azure Stack Hub.
  • Operador de Site Recovery. Este rol tiene permisos para ejecutar y administrar operaciones de conmutación por error y por recuperación. Un usuario con este rol no puede habilitar ni deshabilitar la replicación, crear ni eliminar almacenes, registrar una nueva infraestructura ni asignar derechos de acceso a otros usuarios. Este rol es ideal para un operador de recuperación ante desastres que puede conmutar por error desde máquinas virtuales de Azure Stack Hub cuando se lo indican los propietarios de las aplicaciones y los administradores de TI en un escenario desastroso real o simulado.
  • Lector de Site Recovery. Este rol tiene permisos para realizar el seguimiento de todas las operaciones de administración de Site Recovery. Este rol es más adecuado para el personal de TI responsable de la supervisión del estado de las máquinas virtuales de Azure Stack Hub protegidas y la generación de vales de soporte, si es necesario.
• Bloqueos de recursos de Azure. Tiene la opción de crear y asignar bloqueos de solo lectura y eliminación a un almacén de Site Recovery para mitigar el riesgo de que el almacén se modifique o elimine de forma accidental o malintencionada.
• Eliminación temporal. El propósito de la eliminación temporal es ayudar a proteger el almacén y sus datos de eliminaciones accidentales o malintencionadas. Con la eliminación temporal, el contenido eliminado se conserva durante 14 días adicionales, lo que permite su recuperación durante ese período. La retención adicional de 14 días del contenido del almacén no conlleva ningún costo. La eliminación temporal está habilitada de manera predeterminada.
• Protección de las operaciones que afectan a la seguridad. El almacén de Azure Recovery Services permite habilitar una capa adicional de autenticación cada vez que se intenta realizar una operación susceptible a la seguridad, como la deshabilitación de la protección. Esta validación adicional ayuda a garantizar que los usuarios autorizados realizan dichas operaciones.
• Supervisión y alertas por actividad sospechosa. Azure Recovery Services proporciona supervisión y alertas integradas de eventos susceptibles a la seguridad relacionados con las operaciones del almacén.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Al considerar el costo de la solución de recuperación ante desastres basada en Site Recovery que se describe en este artículo, debe tener en cuenta los componentes locales y basados en la nube. El modelo de precios de Azure Stack Hub determina los precios de los componentes locales. Al igual que con Azure, Azure Stack Hub ofrece un acuerdo de pago por uso, disponible a través de contratos Enterprise y el programa Proveedor de soluciones en la nube. Este acuerdo incluye un precio mensual para cada máquina virtual de Windows Server. Si tiene la opción de usar las licencias de Windows Server existentes, puede reducir significativamente el costo a los precios de la máquina virtual base. Sin embargo, con Site Recovery, normalmente solo necesitará una única máquina virtual de Azure Stack Hub por inquilino, que es necesaria para implementar el servidor de configuración específico del inquilino.

Los cargos relacionados con Azure están asociados al uso de los siguientes recursos:

• Azure Recovery Services. Los precios vienen determinados por el número de instancias protegidas. Cabe destacar que ninguna instancia protegida incurre en cargos por Site Recovery durante los primeros 31 días.

• Azure Storage. Los precios reflejan una combinación de los siguientes factores:

  • Nivel de rendimiento
  • Volumen de datos almacenados
  • Volumen de transferencia de datos de salida
  • Cantidad y tipos de operaciones realizadas (solo para el nivel de rendimiento estándar)
  • Redundancia de datos (solo para el nivel de rendimiento estándar)

• Azure ExpressRoute. Los precios se basan en uno de estos dos modelos:

  • Datos ilimitados. Este modelo incluye un precio mensual con todas las transferencias de datos de entrada y salida incluidas.
  • Datos medidos. Este modelo incluye un precio mensual con todas las transferencias de datos de entrada sin cargos y las transferencias de datos de salida se cobran por GB.

  Nota

  Esta valoración no incluye el costo de las conexiones físicas que ofrecen los proveedores de conectividad de terceros.

• Máquinas virtuales de Azure. Los precios de las máquinas virtuales de Azure reflejan una combinación de dos componentes:

  • Costo de proceso. El tamaño de la máquina virtual, su tiempo de actividad y el modelo de licencia de su sistema operativo determinan el costo.
  • Tipo de disco administrado. El nivel de rendimiento y el tamaño del disco determinan el costo.

  Nota

  Se debe tener en cuenta que la hidratación elimina la necesidad de ejecutar máquinas virtuales de Azure durante las operaciones empresariales normales, con cargas de trabajo que se ejecutan en Azure Stack Hub, lo que reduce considerablemente los costos de proceso de las implementaciones basadas en Site Recovery, especialmente en comparación con las soluciones de recuperación ante desastres tradicionales.

  Nota

  Los precios de los recursos varían entre las regiones de Azure.

  Nota

  Para más información sobre los precios, consulte Precios de Azure.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

Las principales consideraciones sobre la capacidad de administración de la recuperación ante desastres basada en Site Recovery de máquinas virtuales de Azure Stack Hub incluyen las siguientes:

• Implementación de Site Recovery en Azure Stack Hub
• Procedimientos de conmutación por error y conmutación por recuperación
• Delegación de roles y responsabilidades
• DevOps

Implementación de Site Recovery en Azure Stack Hub

Para implementar Site Recovery en Azure Stack Hub en un entorno de un solo inquilino de tamaño pequeño o mediano, puede seguir el proceso de aprovisionamiento manual controlado por la interfaz gráfica del almacén de Recovery Services en Azure Portal. En el caso de las implementaciones de varios inquilinos, es posible que quiera considerar la posibilidad de automatizar partes del proceso de implementación, ya que normalmente tendrá que configurar una máquina virtual de servidor de configuración independiente y un almacén de Recovery Services independiente para cada inquilino. También tiene la opción de automatizar la implementación del agente de movilidad siguiendo el procedimiento descrito en Preparación de una máquina de origen para la instalación de inserción del agente de Mobility.

Procedimientos de conmutación por error y conmutación por recuperación

Para simplificar la administración de la conmutación por error, considere la posibilidad de implementar planes de recuperación para todas las cargas de trabajo protegidas. Para más información, consulte la sección Confiabilidad que aparece anteriormente en este artículo. También encontrará recomendaciones para optimizar la administración del procedimiento de conmutación por recuperación.

Delegación de roles y responsabilidades

El planeamiento y la implementación de la recuperación ante desastres de cargas de trabajo basadas en máquinas virtuales de Azure Stack Hub mediante Site Recovery normalmente implica la interacción de las partes interesadas:

• Los operadores de Azure Stack Hub administran la infraestructura de Azure Stack Hub, asegurándose de que hay suficientes recursos de proceso, almacenamiento y red necesarios para implementar una solución integral de recuperación ante desastres y poner estos recursos a disposición de los inquilinos. También colaboran con los propietarios de la aplicación y los datos para ayudar a determinar el enfoque óptimo para implementar sus cargas de trabajo en Azure Stack Hub.
• Los administradores de Azure administran los recursos de Azure necesarios para implementar soluciones híbridas de recuperación ante desastres.
• Los administradores de Microsoft Entra administran los recursos de Microsoft Entra, incluidos los objetos de usuario y de grupo que se usan para aprovisionar, configurar y administrar los recursos de Azure.
• El personal de TI de los inquilinos de Azure Stack Hub diseña, implementa y administra Site Recovery, incluida la conmutación por error y la conmutación por recuperación.
• Los usuarios de Azure Stack Hub deben proporcionar los requisitos de RPO y RTO y enviar solicitudes para implementar la recuperación ante desastres para sus cargas de trabajo.

Asegúrese de que se conocen perfectamente tanto los roles como las responsabilidades atribuidos a los propietarios y operadores de las aplicaciones en el contexto de protección y recuperación. Los usuarios son los responsables de proteger las máquinas virtuales. Los operadores son responsables del estado operativo de la infraestructura de Azure Stack Hub.

DevOps

Aunque la configuración de la recuperación de nivel de máquina virtual mediante Site Recovery es principalmente una responsabilidad de las operaciones de TI, hay algunas consideraciones específicas de DevOps que deben incorporarse en una estrategia de recuperación ante desastres completa. Azure Stack Hub facilita la implementación de la infraestructura como código (IaC), que incorpora la implementación automatizada de diversas cargas de trabajo, incluidas las aplicaciones y los servicios basados en máquinas virtuales. Puede usar esta capacidad para optimizar el aprovisionamiento de escenarios de recuperación ante desastres basados en Site Recovery, lo que simplifica la configuración inicial en escenarios de varios inquilinos.

Por ejemplo, puede usar las mismas plantillas de Azure Resource Manager para aprovisionar todos los recursos de red necesarios para alojar las cargas de trabajo basadas en máquinas virtuales en un stamp de Azure Stack Hub para su aplicación en una única operación coordinada. Puede usar la misma plantilla para aprovisionar un conjunto de recursos coincidente en Azure para aprovisionar un sitio de recuperación ante desastres. Para tener en cuenta las diferencias entre los dos entornos, puede especificar diferentes valores de parámetros de plantilla en cada caso.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.

Al planear la implementación de Site Recovery en Azure Stack Hub, debe tener en cuenta la cantidad de recursos de procesamiento, almacenamiento y red asignados a los servidores de configuración y de procesos. Es posible que necesite ajustar el tamaño estimado de la máquina virtual de Azure Stack Hub que hospeda los componentes de Site Recovery después de la implementación para dar cabida a los cambios en los requisitos de procesamiento o almacenamiento. Tiene tres opciones básicas para ajustar el tamaño:

• Implementar el escalado vertical. Esto implica modificar la cantidad y el tipo de procesador, memoria y recursos de disco de la máquina virtual de Azure Stack Hub que hospeda el servidor de configuración, incluido el servidor de procesos. Para calcular los requisitos de recursos, puede usar la información de la tabla siguiente:

  Tabla 1: Requisitos de tamaño del servidor de procesos y de configuración

  CPU	Memoria	Disco de caché	Frecuencia de cambio de datos	Máquinas protegidas
  8 vCPU (2 sockets x 4 núcleos a 2,5 GHz)	16 GB	300 GB	500 GB o menos	< 100 máquinas
  12 vCPU (2 sockets x 6 núcleos a 2,5 GHz)	18 GB	600 GB	500 GB - 1 TB	De 100 a 150 máquinas
  16 vCPU (2 sockets x 8 núcleos a 2,5 GHz)	32 GB	1 TB	1 - 2 TB	De 150 a 200 máquinas

• Implementar el escalado horizontal. Esto implica el aprovisionamiento o desaprovisionamiento de máquinas virtuales de Azure Stack Hub con el servidor de procesos instalado para que coincida con las demandas de procesamiento de las máquinas virtuales de Azure Stack Hub protegidas. En general, si debe escalar horizontalmente la implementación a más de 200 máquinas de origen o si la tasa de renovación diaria total supera los dos terabytes (TB), necesitará servidores de procesos adicionales para controlar el tráfico de replicación. Para calcular el número de servidores de procesos adicionales y la configuración, consulte Recomendaciones de tamaño para el servidor de procesos.

• Modificar la directiva de replicación. Esto implica cambiar los parámetros de la directiva de replicación, centrándose en las instantáneas coherentes con la aplicación.

Desde el punto de vista de redes, existen varios métodos diferentes para ajustar el ancho de banda disponible para el tráfico de replicación:

• Modificar el tamaño de la máquina virtual. El tamaño de las máquinas virtuales de Azure Stack Hub determina el ancho de banda de red máximo. Sin embargo, es importante tener en cuenta que no hay ninguna garantía de ancho de banda. En su lugar, las máquinas virtuales pueden utilizar la cantidad de ancho de banda disponible hasta el límite determinado por su tamaño.

• Reemplazar los conmutadores de vínculo superior. Los sistemas de Azure Stack Hub admiten una variedad de conmutadores de hardware, que ofrecen varias opciones de velocidades de vínculo superior. Cada nodo de clúster de Azure Stack Hub tiene dos vínculos superiores para la parte superior de los conmutadores del rack para la tolerancia a errores. El sistema asigna la mitad de la capacidad de vínculo superior para la infraestructura crítica. El resto es la capacidad compartida para los servicios de Azure Stack Hub y todo el tráfico de los usuarios. Los sistemas implementados con velocidades más rápidas tienen más ancho de banda disponible para el tráfico de replicación.

  Nota

  Aunque es posible separar el tráfico de red mediante la conexión de un segundo adaptador de red a un servidor, con máquinas virtuales de Azure Stack Hub, todo el tráfico de la máquina virtual a Internet comparte el mismo vínculo superior. Un segundo adaptador de red virtual no segrega el tráfico en el nivel de transporte físico.

• Modificar el rendimiento de la conexión de red a Azure. Para dar cabida a grandes volúmenes de tráfico de replicación, considere la posibilidad de usar Azure ExpressRoute con emparejamiento de Microsoft para las conexiones entre las redes virtuales de Azure Stack Hub y Azure Storage. Azure ExpressRoute amplía las redes locales a la nube de Microsoft mediante una conexión privada que facilita un proveedor de conectividad. Puede comprar circuitos de ExpressRoute para una amplia gama de anchos de banda, desde 50 megabits por segundo (Mbps) hasta 100 gigabits por segundo.

  Nota

  Para más información sobre la implementación de Azure ExpressRoute en escenarios de Azure Stack Hub, consulte Conexión de Azure Stack Hub con Azure mediante Azure ExpressRoute.

• Modificar la limitación del tráfico de replicación en el servidor de procesos. Puede controlar la cantidad de ancho de banda que usa el tráfico de replicación en las máquinas virtuales que hospedan servidores de procesos desde la interfaz gráfica del agente de Microsoft Azure Recovery Services. Entre las funcionalidades admitidas se incluye la configuración de los límites de horas laborables y no laborables, con los valores de ancho de banda entre 512 kilobits por segundo y 1023 Mbps. También puede aplicar la misma configuración mediante el cmdlet Set-OBMachineSetting de PowerShell.

• Modificar el ancho de banda de red asignado por máquina virtual protegida en el servidor de procesos. Para ello, modifique el valor de la entrada UploadThreadsPerVM en la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication. De manera predeterminada, el valor se establece en 4, pero puede aumentarlo a 32 si hay suficiente ancho de banda de red disponible.

Implementación de este escenario

Requisitos previos

La implementación de la solución recomendada depende del cumplimiento de los siguientes requisitos previos:

• Acceso a una suscripción de Azure, con permisos suficientes para aprovisionar y administrar todos los componentes en la nube de los componentes de Azure Site Recovery, entre los que se incluyen:

  • El almacén de Azure Recovery Services en la región de Azure designada como el sitio de recuperación ante desastres para el entorno de producción de Azure Stack Hub.
  • Una cuenta Azure Storage que hospede contenido de discos replicados de máquinas virtuales de Azure Stack Hub.
  • Una red virtual de Azure que represente el entorno de recuperación ante desastres al que se conectarán las máquinas virtuales de Azure hidratadas después de una conmutación por error planeada o no planeada.
  • Una red virtual de Azure aislada que represente el entorno de prueba al que se conectarán las máquinas virtuales de Azure hidratadas después de una conmutación por error de prueba.
  • Una conectividad basada en ExpressRoute de Azure entre el entorno local, las redes virtuales de Azure y la cuenta de Azure Storage que se usa para hospedar copias de archivos VHD con contenido replicado desde discos de máquinas virtuales de Azure Stack Hub protegidas.

• Una suscripción de usuario de Azure Stack Hub. Todas las máquinas virtuales de Azure Stack Hub protegidas por un servidor de configuración de Site Recovery individual deben pertenecer a la misma suscripción de usuario de Azure Stack Hub.

• Una red virtual de Azure Stack Hub. Todas las máquinas virtuales protegidas deben tener conectividad directa con las máquinas virtuales que hospedan el componente del servidor de procesos (de manera predeterminada, es la máquina virtual del servidor de configuración).

• Una máquina virtual de Windows Server de Azure Stack Hub que hospedará el servidor de configuración y un servidor de procesos. La máquina virtual debe pertenecer a la misma suscripción y estar conectada a la misma red virtual que las máquinas virtuales de Azure Stack Hub que deben protegerse. Además, la máquina virtual debe:

  • Cumplir los requisitos de hardware y software del servidor de configuración de Site Recovery.
  • Satisfacer la documentación de requisitos de red de conectividad externa.

  Nota

  Las consideraciones de almacenamiento y rendimiento adicionales para los servidores de configuración y de procesos se describen con más detalle más adelante en esta arquitectura.

  • Satisfacer los requisitos de conectividad interna. En concreto, las máquinas virtuales de Azure Stack Hub que quiere proteger deben ser capaces de comunicarse con:

    • El servidor de configuración a través del puerto TCP 443 (HTTPS) entrante para la administración de replicación.
    • El servidor de procesos a través del puerto TCP 9443 para proporcionar datos de replicación.

    Nota

    Puede cambiar el puerto usado por el servidor de procesos para la conectividad externa e interna como parte de su configuración al ejecutar la configuración unificada de Site Recovery.

• Las VM de Azure Stack Hub que se van a proteger, ejecutando cualquiera de los sistemas operativos compatibles. Para proteger las VM de Azure Stack Hub que ejecutan sistemas operativos de Windows Server, debe:

  • Crear una cuenta de Windows con derechos de administrador. Puede especificar esta cuenta al habilitar Site Recovery en estas máquinas virtuales. El servidor de procesos utiliza esta cuenta para instalar el servicio Mobility de Site Recovery. En un entorno de grupo de trabajo, asegúrese de deshabilitar el control de acceso de usuarios remotos en los sistemas operativos de Windows Server de destino. Para ello, establezca el valor de la entrada de registro LocalAccountTokenFilterPolicyDWORD de la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System en 1.
  • Habilite el uso compartido de archivos e impresoras y las reglas de Instrumental de administración de Windows en el firewall de Microsoft Defender.

• Para proteger las máquinas virtuales de Azure Stack Hub que ejecutan sistemas operativos de Linux, debe:

  • Crear una cuenta de usuario raíz. Puede especificar esta cuenta al habilitar Site Recovery en estas máquinas virtuales. El servidor de procesos utiliza esta cuenta para instalar el servicio Mobility de Site Recovery.
  • Instalar los paquetes OpenSSH, OpenSSH Server y OpenSSL más recientes.
  • Habilitar y ejecutar el puerto 22 de Secure Shell (SSH).
  • Habilitar la autenticación de contraseña y del subsistema de FTP segura.

Pasos de implementación generales

A nivel general, la implementación de la recuperación ante desastres basada en Site Recovery en Azure Stack Hub consta de las siguientes fases:

1. Preparar las máquinas virtuales de Azure Stack Hub que se van a proteger mediante Azure Site Recovery. Asegurarse de que las máquinas virtuales cumplan los requisitos previos de Site Recovery enumerados en la sección anterior.

2. Cree y configure un almacén de Azure Recovery Services. Configure un almacén de Azure Recovery Services y especifique lo que quiere replicar. Las actividades y los componentes de Site Recovery se configuran y administran mediante el almacén.

3. Configure el entorno de replicación de origen. Aprovisione un servidor de procesos y un servidor de configuración de Site Recovery mediante la instalación de valores binarios de Instalación unificada de Site Recovery y regístrelos en el almacén.

   Nota

   Puede volver a ejecutar la Instalación unificada de Site Recovery para implementar servidores de procesos adicionales en máquinas virtuales de Azure Stack Hub.

4. Configuración del entorno de replicación de destino. Cree o seleccione una cuenta de Azure Storage existente y una red virtual de Azure en la región de Azure que hospedará el sitio de recuperación ante desastres. Durante la replicación, el contenido de los discos de las máquinas virtuales de Azure Stack Hub protegidas se copia en la cuenta de Azure Storage. Durante la conmutación por error, Site Recovery aprovisiona automáticamente máquinas virtuales de Azure que sirven como réplicas de máquinas virtuales de Azure Stack Hub protegidas y las conecta a la red virtual de Azure.

5. Habilite la replicación. Configure las opciones de replicación y habilite la replicación de las máquinas virtuales de Azure Stack Hub. El servicio Mobility se instala automáticamente en cada máquina virtual de Azure Stack Hub para la que está habilitada la replicación. Site Recovery inicia la replicación de cada máquina virtual de Azure Stack Hub según la configuración de directiva que haya definido.

6. Realización de una conmutación por error de prueba. Después de establecer la replicación, compruebe que la conmutación por error funcione según lo esperado. Para ello, realice una conmutación por error de prueba.

7. Realice una conmutación por error planeada o no planeada. Después de realizar una conmutación por error de prueba correctamente, está listo para realizar una conmutación por error planeada o no planeada en Azure. Tiene la opción de designar las máquinas virtuales de Azure Stack Hub que se van a incluir en la conmutación por error.

8. Realice una conmutación por recuperación. Cuando esté listo para la conmutación por recuperación, detenga las máquinas virtuales de Azure correspondientes a las máquinas virtuales de Azure Stack Hub en las que se produjo el error, descargue los archivos de disco en el almacenamiento local, cárguelos en Azure Stack Hub y asócielos a una máquina virtual nueva o existente.

Resumen

En conclusión, Azure Stack Hub es una oferta única, que difiere en muchos aspectos de otras plataformas de virtualización. Como tal, garantiza consideraciones especiales en lo que respecta a la estrategia de continuidad empresarial para sus cargas de trabajo. Al usar los servicios de Azure, puede simplificar el diseño y la implementación de esta estrategia. En este artículo de arquitectura de referencia, analizamos el uso de Microsoft Azure Site Recovery para proteger las cargas de trabajo basadas en máquinas virtuales de Azure Stack Hub en el modelo de implementación conectada. Este enfoque permite a los clientes beneficiarse de la resistencia y la capacidad de administración de Azure Stack Hub, así como de la hiperescala y la presencia global de la nube de Azure.

Es importante tener en cuenta que la solución de recuperación ante desastres que se describe aquí se centra exclusivamente en las cargas de trabajo basadas en máquinas virtuales de Azure Stack Hub. Esta es solo parte de una estrategia general de continuidad empresarial que debe tener en cuenta otros tipos de carga de trabajo y escenarios de Azure Stack Hub que afectan a su disponibilidad.

Pasos siguientes

Documentación del producto:

• Acerca de Site Recovery
• Introducción a Azure Stack Hub
• ¿Qué es Microsoft Entra ID?
• ¿Qué es Azure Blob Storage?
• ¿Qué es Azure ExpressRoute?
• ¿Qué es Azure Virtual Network?

Módulos de Microsoft Learn:

• Azure Stack Hub
• Configurar Microsoft Entra ID
• Configuración de cuentas de almacenamiento
• Configurar redes virtuales
• Diseño e implementación de Azure ExpressRoute
• Diseño de una solución de Site Recovery en Azure

Recursos relacionados

• Diseño de arquitectura híbrida
• Copia de seguridad de archivos y aplicaciones en Azure Stack Hub
• Conexiones híbridas
• Recurso compartido de archivos híbrido con recuperación ante desastres para trabajos tanto remotos como de sucursales locales