Continuidad empresarial y recuperación ante desastres para Azure VMware Solution
Este escenario de escala empresarial ayuda a mejorar la continuidad empresarial y recuperación ante desastres (BCDR). Azure VMware Solution proporciona nubes privadas que contienen clústeres de VMware vSphere creados a partir de una infraestructura dedicada de Azure sin sistema operativo. La solución proporciona un mínimo de tres hosts ESXi hasta un máximo de 16 hosts por clúster. Todas las nubes privadas aprovisionadas tienen VMware vCenter Server, VMware vSAN, VMware vSphere y VMware NSX-T Data Center. Para más información sobre el Acuerdo de Nivel de Servicio (SLA) de Azure VMware Solution, consulte SLA para Azure VMware Solution.
Tanto si tiene un entorno local como una instancia de Azure VMware Solution, debe tener en cuenta varios factores de BCDR para prepararse para un desastre. Un sólido plan de BCDR tiene como objetivo proteger a una empresa de la pérdida de datos, de las pérdidas financieras y del tiempo de inactividad en caso de que se produzca un evento perturbador. En el árbol de decisión siguiente se muestran varias opciones de BCDR disponibles para Azure VMware Solution.
Nota
Un entorno piloto se establece con una configuración mínima, solo con componentes básicos para admitir un conjunto crítico de aplicaciones. Sin embargo, se puede escalar horizontalmente y generar más hosts para hacer frente a la mayor parte de la carga si se produce una conmutación por error. Para la recuperación ante desastres de cargas de trabajo de Azure VMware Solution con un uso intensivo de memoria y proceso, se requiere la misma cantidad de almacenamiento en el sitio secundario.
Consideraciones de diseño de continuidad empresarial
Las directivas de almacenamiento de vSAN de VMware en Azure VMware Solution se implementan teniendo en cuenta la disponibilidad del almacenamiento. Cuando el clúster tiene entre tres y cinco hosts, el número de errores de host que se toleran sin pérdida de datos es igual a uno. Cuando el clúster tiene entre 6 y 16 hosts, el número de errores de host que se toleran antes de que se produzca una pérdida de datos es igual a dos. Las directivas de almacenamiento de vSAN de VMware se pueden aplicar por VM. Aunque estas directivas son las predeterminadas, puede modificarlas para que se adapten a sus requisitos personalizados. Para obtener más información, consulte los conceptos de almacenamiento de Azure VMware Solution.
La alta disponibilidad de vSphere está habilitada de forma predeterminada en Azure VMware Solution. La directiva de admisión de alta disponibilidad reserva capacidad de proceso y memoria para un único nodo. Esta reserva garantiza suficiente capacidad para reiniciar las cargas de trabajo en otro nodo de un clúster de Azure VMware Solution.
Alta disponibilidad con clúster extendido: con Azure VMware Solution, los hosts ESXi implementados en un clúster de vSphere estándar residen tradicionalmente en una sola zona de disponibilidad de Azure y están protegidos por la alta disponibilidad de vSphere. Sin embargo, las cargas de trabajo no están protegidas de los errores de la zona de disponibilidad. Para protegerse frente a un error, un único clúster de vSAN puede abarcar dos zonas de disponibilidad independientes, lo que se conoce como clúster extendido de vSAN. Para más información, consulte Implementación de clústeres extendidos de vSAN.
Elija una solución de copia de seguridad validada para las máquinas virtuales de VMware vSphere, como Microsoft Azure Backup Server o una solución de copia de seguridad de un asociado.
Para información sobre las características admitidas en las soluciones de copia de seguridad de asociados, consulte la documentación del asociado correspondiente.
Nota:
Las configuraciones de vCenter Server y HCX Manager (si están habilitadas) de la nube privada de Azure VMware Solution se encuentran dentro de una programación de copia de seguridad diaria y la configuración de NSX lo está dentro de una programación de copia de seguridad horaria. Las copias de seguridad se conservan durante un mínimo de tres días.
Los componentes de Azure VMware Solution, como vCenter Server, NSX-T Manager o HCX Manager, son servicios administrados cuya copia de seguridad administra Azure. Para restaurar una copia de seguridad, cree una solicitud de soporte técnico de Azure.
Recomendaciones de diseño de la continuidad empresarial
Use Azure Backup Server para hacer una copia de seguridad de la nube privada de Azure VMware Solution. Para más información, consulte Copia de seguridad de máquinas virtuales de VMware vSphere con Azure Backup. Entre las topologías de implementación admitidas se incluyen el Agente de MARS y Data Protection Manager. Cada topología de implementación tiene su propia matriz de compatibilidad y sus propias restricciones y limitaciones.
Implemente Azure Backup Server en la misma región de Azure que la nube privada de Azure VMware Solution. Este método de implementación reduce los costos de tráfico, facilita la administración y conserva la topología principal o secundaria. Consulte en la guía de selección de las regiones de Azure los procedimientos recomendados de implementación para la región de Azure.
Azure Backup se puede implementar como una máquina virtual de infraestructura como servicio (IaaS) de Azure o dentro de la nube privada de Azure VMware Solution. Es muy recomendable implementarlo fuera de la nube privada de Azure VMware Solution. Implemente el servicio Backup en una red virtual de Azure y asegúrese de que esta red virtual esté conectada a la misma instancia de ExpressRoute conectada a la nube privada de Azure VMware Solution. La ejecución de Backup Server fuera de la nube privada de Azure VMware Solution ayuda a reducir el consumo de vSAN, ya que vSAN es un recurso de capacidad limitada dentro de la nube privada de Azure VMware Solution.
Azure Backup Server implementado como una máquina virtual IaaS de Azure.
Azure Backup Server implementado como una máquina virtual de Azure VMware Solution.
Use la lista de comprobación de requisitos de rendimiento de la aplicación para llegar a la capacidad y el tipo de disco adecuados, como HDD, SSD o Ultra. Tenga en cuenta la SKU de la máquina virtual IaaS de Azure que admite el tipo de disco y la capacidad para las operaciones de copia de seguridad.
Use el planificador de capacidad de Azure Backup Server para determinar el número de servidores, almacenamiento e IOPS necesarios para cada uno de ellos. Al proporcionar el valor "Tamaño total de la carga de trabajo (GB)*" en el planificador de capacidades, use el valor medio entre "almacenamiento usado" y el "almacenamiento asignado" de todas las máquinas virtuales de vCenter de las que desee realizar una copia de seguridad.
Use grupos de almacenamiento con Azure Backup Server para mejorar el rendimiento o el número de IOPS del disco. Use el almacenamiento en capas en Backup Server para mejorar las operaciones. Establezca el valor de configuración DisableWriteAutoTiering en 1 en el volumen MABS para que todo el nivel de rendimiento esté disponible para almacenar los metadatos ReFS.
Identifique el número de trabajos de copia de seguridad paralelos y las operaciones de restauración que se ejecutarán en Azure Backup Server. Actualmente, se admiten ocho trabajos de copia de seguridad paralelos. Mida la cantidad de tiempo necesario para realizar copias de seguridad y restaurar cargas de trabajo críticas en varias ejecuciones. Valide que los tiempos de copia de seguridad y restauración cumplan los requisitos de RPO y RTO para Azure Backup Server. Asegúrese de que el almacén de datos vSAN de AVS tenga suficiente capacidad para contener la copia de seguridad restaurada.
Agregue las excepciones antivirus necesarias para archivos y carpetas de Azure Backup Server, tal y como se documenta aquí si se ejecuta algún software antivirus o antimalware en Azure Backup Server. Al usar el agente de protección DPM en cualquier máquina virtual de Azure VMware Solution para la copia de seguridad de aplicaciones (por ejemplo, SQL o SharePoint, entre otras), deshabilite la supervisión en tiempo real de dpmra.exe.
Configure las reglas de grupo de seguridad de red (NSG) adecuadas en la subred que aloja Azure Backup Server para permitir la comunicación de red desde el agente de protección DPM que se ejecuta en la máquina virtual protegida en Azure VMware Solution. El agente de protección DPM se comunica con Azure Backup Server en cualquier puerto dinámico entre el 1024 y el 65535.
Actualmente, Azure Backup Server no admite la restauración entre regiones para la nube privada de Azure VMware Solution. Consulte la sección sobre las soluciones de copia de seguridad de asociados y la recuperación ante desastres cuando se requiera la recuperación de Azure VMware Solution entre regiones.
Consideraciones de diseño acerca de la recuperación ante desastres
Alinee los requisitos empresariales con los objetivos de tiempo de recuperación (RTO), la capacidad y los objetivos de punto de recuperación (RPO) de las aplicaciones. Planee y diseñe en consonancia para lograr estos objetivos con la tecnología de replicación más adecuada. Por ejemplo, replique bases de datos SQL de forma nativa mediante grupos de disponibilidad de SQL AlwaysOn o use una herramienta de recuperación ante desastres como VMware Site Recovery Manager.
Determine el sitio de recuperación ante desastres de destino para la nube privada protegida de Azure VMware Solution. Este sitio influye en qué herramientas de recuperación ante desastres son las adecuadas para el entorno. Por ejemplo, si desea recuperar cargas de trabajo de Azure VMware Solution en máquinas virtuales Azure IaaS nativas, puede considerar Azure Site Recovery o Zerto.
Determine qué subconjunto de cargas de trabajo de Azure VMware Solution requieren protección en caso de producirse un evento de recuperación ante desastres. Considere la posibilidad de clasificar las cargas de trabajo en función de la prioridad: P0 para cargas de trabajo críticas para la empresa y P1, P2, P3 para otras cargas de trabajo que son importantes, pero no tan críticas para que la empresa funcione. El plan de continuidad empresarial del cliente define los niveles de prioridad, lo que ayuda a controlar los costos asociados a la implementación de la recuperación ante desastres.
En la mayoría de los casos, los entornos que no son de producción, como desarrollo, prueba o UAT, no necesitan conmutar por error a un sitio secundario. Debe ejecutar el piloto en el sitio secundario con capacidad reducida para cargas de trabajo críticas y de producción con el fin de ahorrar costos. Para obtener más capacidad, puede escalar horizontalmente para agregar hosts ESXi al clúster durante el evento de recuperación ante desastres.
En el caso de implementaciones piloto especialmente, asegúrese de que ha protegido toda la cuota de host necesaria en el sitio secundario para que no tenga que esperar a la capacidad necesaria durante el escalado horizontal completo. Consulte Solicitud de cuota de host para Azure VMware Solution.
Configure roles de dominio funcionales, como controladores de dominio de Active Directory, en el entorno secundario.
Las soluciones de asociados como JetStream y Zerto están disponibles con carácter general y validadas para Azure VMware Solution. Estas admiten la mayoría de los escenarios de recuperación ante desastres y pueden proporcionar una recuperación más rápida con un RPO casi de cero.
VMware Site Recovery Manager, JetStream y Zerto admiten la migración de ubicaciones de terceros a Azure VMware Solution.
VMware HCX también es una solución de recuperación ante desastres rentable. Sin embargo, no se recomienda para cargas de trabajo de producción grandes debido a la orquestación manual.
Para la recuperación ante desastres entre las nubes privadas de Azure VMware Solution en distintas regiones de Azure, debe habilitar ExpressRoute Global Reach entre ambos circuitos ExpressRoute de back-end. Estos circuitos crean conectividad entre la nube privada principal y la secundaria cuando es necesario para soluciones como VMware SRM y VMware HCX.
Para la recuperación ante desastres entre las nubes privadas de Azure VMware Solution de la misma región de Azure, debe habilitar Azure VMware Solution Interconnect. Esta característica crea un vínculo de enrutamiento entre las redes de administración y carga de trabajo de las nubes privadas de Azure VMware Solution para permitir la comunicación entre las nubes. Asegúrese de que el espacio de direcciones IP enrutado en cada nube sea único y no se superponga.
Al trabajar con la recuperación ante desastres, puede usar el mismo espacio de direcciones IP de la región principal de Azure en la región secundaria de Azure. Sin embargo, requiere trabajos adicionales de diseño e ingeniería.
Conservar las mismas direcciones IP: las máquinas virtuales del sitio secundario de Azure VMware Solution se pueden recuperar con la misma dirección IP de origen que el sitio principal. Para aplicar este método, cree redes VLAN o segmentos NSX-T aislados en el sitio secundario y asegúrese de que ninguna de estas VLAN o segmentos aislados estén conectados al entorno. Modifique las rutas de recuperación ante desastres para reflejar que la subred se ha movido al sitio secundario y la nueva ubicación de direcciones IP. Aunque este método funciona, también crea una sobrecarga de ingeniería cuando se pretende una recuperación de desastres totalmente automatizada.
Use direcciones IP diferentes: también puede usar diferentes direcciones IP para las VM recuperadas. Si la máquina virtual se mueve a un sitio secundario, el plan de recuperación dentro de VMware Site Recovery Manager detallará la asignación de IP personalizada. Seleccione este mapa para el cambio de dirección IP. Las máquinas virtuales se incorporan a los nuevos segmentos NSX-T y se asignan nuevas direcciones IP. Las herramientas pueden variar con cada solución de recuperación ante desastres.
Factores importantes para escenarios de recuperación ante desastres parcial y completa:
VMware Site Recovery Manager admite la recuperación parcial, que solo recupera un subconjunto de máquinas virtuales, y la recuperación ante desastres completa. Entre dos sitios de Azure VMware Solution de la región 1 y la región 2, todas o algunas de las máquinas virtuales pueden conmutar por error.
El requisito de retención de direcciones IP de origen para las máquinas virtuales recuperadas determina si es posible la recuperación ante desastres parcial frente a la completa.
Para mantener la dirección IP de origen mientras se realiza la recuperación ante desastres parcial en Site Recovery Manager, la puerta de enlace de subred debe moverse al sitio secundario.
Nota
La recuperación ante desastres activa-en espera no requiere la extensión de capa 2.
Recomendaciones de diseño para la recuperación ante desastres
Use VMware Site Recovery Manager cuando trabaje con Azure VMware Solution en sitios principales y secundarios. Los sitios primarios y secundarios también se conocen como sitios protegidos y de recuperación, respectivamente.
Introducción de alto nivel a la replicación continua de vSphere.
Ejemplo detallado de replicación continua de vSphere entre sitios principales y secundarios.
En el caso de las aplicaciones críticas para la empresa, Zerto y JetStream están disponibles como soluciones de recuperación ante desastres para la nube privada de Azure VMware Solution. JetStream y Zerto se crean sobre la base de la protección continua de datos (CDP), mediante el marco de la API de VMware vSphere para el filtrado de E/S (VAIO), que permite una pérdida de datos mínima o casi nula. También permite la recuperación ante desastres rentable con recursos mínimos.
Utilice Azure Site Recovery o Zerto, si las máquinas virtuales Azure IaaS son el objetivo de recuperación ante desastres para la nube privada Azure VMware Solution.
Minimice la entrada manual usando planes de recuperación automatizados en cada una de las soluciones de recuperación ante desastres correspondientes. Estos planes son útiles al trabajar con soluciones de VMware Site Recovery Manager o de asociados. Un plan de recuperación agrupa máquinas en grupos de recuperación para la conmutación por error. Así, ayudan a definir un proceso de recuperación sistemático mediante la creación de unidades independientes que se pueden conmutar por error.
Configure pruebas de humo o simulacros de recuperación ante desastres al menos una vez al año para garantizar que los planes de recuperación funcionen según lo previsto. Las capacidades de orquestación de la herramienta de recuperación de desastres elegida determinan l nivel de esfuerzo implicado en la ejecución de estos simulacros.
Use pares regionales geopolíticos como entorno de recuperación ante desastres secundario. Algunas de las ventajas de los pares regionales son la recuperación de regiones por orden de prioridad, las actualizaciones secuenciales, el aislamiento físico y la residencia de datos.
Mantenga espacios de direcciones diferentes para evitar la superposición de direcciones IP entre los dos sitios. Por ejemplo, puede usar
192.168.0.0/16para la región 1 y10.0.0.0/16para la 2.Use la conectividad de ExpressRoute Global Reach entre las nubes privadas principal y secundaria de diferentes regiones. Consulte más consideraciones de red y recomendaciones en el área de diseño correspondiente.
Pasos siguientes
Obtenga información sobre las consideraciones y recomendaciones para la implementación inicial de Azure VMware Solution e instrucciones para la automatización operativa.