Introducción a la recuperación ante desastres e instrucciones de infraestructura para la carga de trabajo de SAP
Muchas organizaciones que ejecutan aplicaciones empresariales críticas en Azure configuran tanto la estrategia de alta disponibilidad (HA) como la de recuperación ante desastres (DR). El propósito de la alta disponibilidad es aumentar el Acuerdo de Nivel de Servicio de los sistemas empresariales mediante la eliminación de únicos puntos de error en la infraestructura del sistema subyacente. Las tecnologías de alta disponibilidad reducen el efecto de un error de infraestructura no planeado y ayudan con el mantenimiento planeado. La recuperación ante desastres se define como directivas, herramientas y procedimientos que permiten la recuperación o continuación de sistemas e infraestructuras tecnológicos esenciales a consecuencia de desastres de origen humano o natural geográficamente generalizado.
Para lograr una alta disponibilidad para la carga de trabajo de SAP en Azure, las máquinas virtuales normalmente se implementan en un conjunto de disponibilidad, zonas de disponibilidad o en un conjunto de escalado flexible para proteger las aplicaciones frente al mantenimiento de la infraestructura o errores dentro de la región. Pero la implementación no protege las aplicaciones frente a desastres generalizados dentro de la región. Por lo tanto, para proteger las aplicaciones frente a desastres regionales, la estrategia de recuperación ante desastres para las aplicaciones debe estar en vigor. La recuperación ante desastres es un enfoque documentado y estructurado diseñado para ayudar a una organización a ejecutar los procesos de recuperación en respuesta a un desastre, y para proteger o minimizar la interrupción de los servicios de TI y promover la recuperación.
En este documento se proporcionan detalles sobre cómo proteger las cargas de trabajo de SAP frente a catástrofes a gran escala mediante la implementación de un enfoque estructurado de recuperación ante desastres. Los detalles de este documento se presentan en un nivel abstracto, en función de distintos servicios de Azure y componentes de SAP. La estrategia exacta de recuperación ante desastres y el orden de recuperación de la carga de trabajo de SAP se deben probar, documentar y ajustar con regularidad. Además, el documento se centra en la estrategia de recuperación ante desastres de Azure a Azure para la carga de trabajo de SAP.
Consideraciones generales sobre el plan de recuperación ante desastres
La carga de trabajo de SAP en Azure se ejecuta en máquinas virtuales en combinación con diferentes servicios de Azure para implementar diferentes capas (servicios centrales, servidores de aplicaciones, servidor de bases de datos) de una aplicación de SAP NetWeaver típica. En general, se debe planear una estrategia de recuperación ante desastres para todo el panorama de TI que se ejecuta en Azure, lo que significa tener en cuenta también las aplicaciones que no son de SAP. Es posible que la solución empresarial que se ejecute en sistemas SAP no se ejecute en su totalidad, si los servicios o recursos dependientes no se recuperan en el sitio de recuperación ante desastres. Por lo tanto, debe elaborar un plan de recuperación ante desastres completo bien definido teniendo en cuenta todos los componentes y sistemas.
En el caso de la recuperación ante desastres en Azure, las organizaciones deben tener en cuenta diferentes escenarios que pueden desencadenar la conmutación por error.
- Disponibilidad de aplicaciones o procesos empresariales de SAP.
- La falta de disponibilidad de servicios de Azure (como máquinas virtuales, almacenamiento, equilibrador de carga, etc.) en una región, debido a un error generalizado.
- Posibles amenazas y vulnerabilidades para la aplicación (por ejemplo, ataque DDoS de capa de aplicación)
- El cumplimiento empresarial requiere tareas operativas para probar la estrategia de recuperación ante desastres (por ejemplo, el ejercicio de errores de recuperación ante desastres que se realizará cada año según el cumplimiento).
Para lograr el objetivo de recuperación para diferentes escenarios, la organización debe describir el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) para su carga de trabajo en función de los requisitos empresariales. RTO describe la cantidad de tiempo que la aplicación puede estar fuera de servicio, normalmente medida en horas, minutos o segundos. Mientras que el RPO describe la cantidad de datos transaccionales que las empresas pueden perder para que se reanuden las operaciones normales. La identificación de RTO y RPO de un negocio es fundamental, ya que ayudará a diseñar una estrategia de recuperación ante desastres de forma óptima. Los componentes (proceso, almacenamiento, base de datos, etc.) implicados en la carga de trabajo de SAP se replican en la región de recuperación ante desastres mediante diferentes técnicas (servicios nativos de Azure, tecnología de replicación de base de datos nativa, scripts personalizados). Cada técnica proporciona un RPO diferente, que se debe tener en cuenta al diseñar una estrategia de recuperación ante desastres. En Azure, puede usar algunos de los servicios nativos de Azure, como Azure Site Recovery o Azure Backup que pueden ayudar a lograr el RTO y el RPO de las cargas de trabajo de SAP. Consulte el Acuerdo de Nivel de Servicio de Azure Site Recovery y Azure Backup para alinearse de forma óptima con el RTO y el RPO.
Consideración de diseño para la recuperación ante desastres en Azure
Hay diferentes elementos que se deben tener en cuenta al diseñar una solución de recuperación ante desastres en Azure. Los principios y conceptos que se consideran para diseñar soluciones de recuperación ante desastres locales también se aplican a Azure. Pero en Azure, la selección de regiones es una parte clave de la estrategia de diseño para la recuperación ante desastres. Por lo tanto, tenga en cuenta los siguientes puntos al elegir la región de recuperación ante desastres en Azure.
Los requisitos de cumplimiento normativo o empresarial pueden especificar un requisito de distancia entre un sitio principal y de recuperación ante desastres. Un requisito de distancia ayuda a proporcionar disponibilidad si se produce un desastre natural en una geografía más amplia. En tal caso, una organización puede elegir otra región de Azure como su sitio de recuperación ante desastres. Las regiones de Azure a menudo están separadas por una gran distancia que pueden ser cientos o incluso miles de kilómetros como en el Estados Unidos. Debido a la distancia, la latencia de ida y vuelta de red será mayor, lo que puede dar lugar a un RPO mayor.
Los clientes que quieran imitar su estrategia de recuperación ante desastres metropolitana local en Azure pueden usar zonas de disponibilidad para la recuperación ante desastres. Pero la estrategia de recuperación ante desastres de zona a zona puede no cumplir con los requisitos de resiliencia si hay desastres naturales generalizados geográficamente.
En Azure, cada región se empareja con otra región dentro de la misma geografía (excepto el Sur de Brasil). Este enfoque permite la replicación de recursos proporcionada por la plataforma en toda la región. La ventaja de elegir la región emparejada se puede encontrar en el documento de pares de regiones. Cuando una organización decide usar regiones emparejadas de Azure, es necesario tener en cuenta varios puntos adicionales para una carga de trabajo de SAP:
No todos los servicios de Azure ofrecen replicación entre regiones en una región emparejada.
Es posible que los servicios y características de Azure emparejados en regiones de Azure no sean simétricas. Por ejemplo, es posible que las SKU de máquina virtual de Azure NetApp Files como la serie M disponible en la región primaria no estén disponibles en la región emparejada. Para comprobar si el producto o los servicios de Azure están disponibles en una región, consulte Productos de Azure por región.
La opción GRS está disponible para la cuenta de almacenamiento con el tipo de almacenamiento estándar que replica datos en una región emparejada. Pero el almacenamiento estándar no es adecuado para DBMS de SAP o discos de datos virtuales.
El servicio de copia de seguridad de Azure usado para realizar copias de seguridad de soluciones compatibles solo puede replicar copias de seguridad entre regiones emparejadas. Para todos los demás datos, ejecute sus propias replicaciones con características de DBMS nativas como SQL Server Always On, la replicación del sistema de SAP HANA y otros servicios. Use una combinación de Azure Site Recovery, rsync o robocopy y otro software de terceros para la capa de aplicación de SAP.
Implementación de cargas de trabajo de SAP de referencia
Después de identificar una región de recuperación ante desastres, es importante que la amplitud de los servicios principales de Azure (como red, proceso o almacenamiento) que haya configurado en la región primaria esté disponible y se pueda configurar en la región de recuperación ante desastres. La organización debe desarrollar un patrón de implementación de recuperación ante desastres para la carga de trabajo de SAP. El patrón de implementación varía y debe alinearse con las necesidades de la organización.
- Implemente la carga de trabajo de SAP de producción en la región primaria y la carga de trabajo que no sea de producción en la región de recuperación ante desastres.
- Implemente toda la carga de trabajo de SAP (producción y no producción) en la región primaria. La región de recuperación ante desastres solo se usa si hay una conmutación por error.
En la siguiente arquitectura de referencia se muestra el sistema SAP NetWeaver típico que se ejecuta en Azure junto con la alta disponibilidad en la región primaria. El sitio secundario que se muestra a continuación es el sitio de recuperación ante desastres donde se restaurarán los sistemas SAP después de un evento de desastre. Las regiones de recuperación ante desastres y principal forman parte de la misma suscripción. Para lograr la recuperación ante desastres para la carga de trabajo de SAP, debe identificar la estrategia de recuperación para cada capa de SAP junto con los distintos servicios de Azure que usa la aplicación.
Las organizaciones deben planear y diseñar una estrategia de recuperación ante desastres para todo su panorama de TI. Normalmente, los sistemas SAP que se ejecutan en el entorno de producción se integran con diferentes servicios e interfaces, como Active Directory, DNS, aplicación de terceros, etc. Por lo tanto, también debe incluir los sistemas que no son de SAP y otros servicios en el planeamiento de la recuperación ante desastres. Este documento se centra en el planeamiento de recuperación para aplicaciones SAP. Pero puede expandir el tamaño y el ámbito del planeamiento de recuperación ante desastres para los componentes dependientes para ajustarse a sus requisitos.
Componentes de infraestructura de la solución de recuperación ante desastres para la carga de trabajo de SAP
Una carga de trabajo de SAP que se ejecuta en Azure usa distintos componentes de infraestructura para ejecutar una solución empresarial. Para planear la recuperación ante desastres para esta solución, es esencial que todos los componentes de infraestructura configurados en la región primaria estén disponibles y también se puedan configurar en la región de recuperación ante desastres. Deben tenerse en cuenta los siguientes componentes de infraestructura al diseñar una solución de recuperación ante desastres para la carga de trabajo de SAP en Azure.
- Red
- Proceso
- Storage
Red
ExpressRoute amplía las redes locales a la nube de Microsoft mediante una conexión privada con la ayuda de un proveedor de conectividad. Al diseñar la arquitectura de recuperación ante desastres, debe tenerse en cuenta la creación de una sólida conectividad de red de back-end mediante un circuito ExpressRoute con redundancia geográfica. Se recomienda configurar al menos un circuito ExpressRoute desde el entorno local a la región primaria. Y los demás deben conectarse a la región de recuperación ante desastres. Consulte el artículo Diseño de Azure ExpressRoute para la recuperación ante desastres, que describe distintos escenarios para diseñar la recuperación ante desastres para ExpressRoute.
Nota:
Considere la posibilidad de configurar una VPN de sitio a sitio (S2S) que sirva de copia de seguridad de Azure ExpressRoute. Para más información, consulte Uso de VPN S2S como copia de seguridad para el emparejamiento privado de Azure ExpressRoute.
Las red virtual y las subredes abarcan todas las zonas de disponibilidad de una región. Para la recuperación ante desastres en dos regiones, debe configurar redes virtuales y subredes independientes en la región de recuperación ante desastres. Consulte Acerca de la conexión en red en la recuperación ante desastres de máquinas virtuales de Azure para más información sobre la configuración de conexión en red en la región de recuperación ante desastres.
Azure Standard Load Balancer proporciona elementos de red para el diseño de alta disponibilidad de los sistemas SAP. En el caso de los sistemas en clúster, Standard Load Balancer proporciona la dirección IP virtual para el servicio de clúster, como las instancias de ASCS/SCS y las bases de datos que se ejecutan en máquinas virtuales. Para ejecutar un sistema SAP de alta disponibilidad en el sitio de recuperación ante desastres, se debe crear un equilibrador de carga independiente y la configuración del clúster debe ajustarse en consecuencia.
Azure Application Gateway es un equilibrador de carga del tráfico web. Con su funcionalidad de Web Application Firewall, el servicio adecuado para exponer aplicaciones web a Internet con una seguridad mejorada. Azure Application Gateway puede dar servicio a clientes públicos (internet), privados o ambos, en función de la configuración. Después de la conmutación por error, para aceptar tráfico HTTP entrante similar en la región de recuperación ante desastres, se debe configurar una instancia de Azure Application Gateway independiente en la región de recuperación ante desastres.
A medida que los componentes de conexión en red (como la red virtual, el firewall, etc.) se crean por separado en la región de recuperación ante desastres, debe asegurarse de que la carga de trabajo de SAP en la región de recuperación ante desastres se adapte a los cambios de conexión en red, como la actualización de DNS, el firewall, etc.
Las redes virtuales de ambas regiones son independientes y para establecer comunicación entre ambas, debe habilitarse el emparejamiento de redes virtuales entre las dos regiones.
Máquinas virtuales
En Azure, los distintos componentes de un único sistema SAP se ejecutan en máquinas virtuales con diferentes tipos de SKU. Para la recuperación ante desastres, se puede habilitar la protección de una aplicación (SAP NetWeaver y aplicación que no sea de SAP) que se ejecuta en máquinas virtuales de Azure mediante la replicación de componentes con Azure Site Recovery en otra región o zona de Azure. Con Azure Site Recovery, las máquinas virtuales de Azure se replican continuamente desde el sitio principal al de recuperación ante desastres. Según la región de recuperación ante desastres de Azure seleccionada, es posible que el tipo de SKU de máquina virtual no esté disponible en el sitio de recuperación ante desastres. Debe asegurarse de que los tipos de SKU de máquina virtual necesarios también están disponibles en la región de recuperación ante desastres de Azure. Compruebe los productos de Azure por región para ver si el tipo de SKU de familia de máquina virtual necesario está disponible.
Importante
Si el sistema SAP está configurado con un conjunto de escalado flexible con FD=1, debe usar PowerShell para configurar Azure Site Recovery para la recuperación ante desastres. Actualmente, es el único método disponible para configurar la recuperación ante desastres para las máquinas virtuales implementadas en el conjunto de escalado.
En el caso de las bases de datos que se ejecutan en máquinas virtuales de Azure, se recomienda usar tecnología nativa de replicación de bases de datos para sincronizar los datos con el sitio de recuperación ante desastres. Es posible que las máquinas virtuales de gran tamaño en las que se ejecutan las bases de datos no estén disponibles en todas las regiones. Si usa zonas de disponibilidad para la recuperación ante desastres, debe comprobar que las SKU de máquina virtual correspondientes están disponibles en la zona del sitio de recuperación ante desastres.
Nota:
No se recomienda el uso de Azure Site Recovery para bases de datos, ya que no garantiza la coherencia de la base de datos y tiene una limitación en la renovación de datos.
Dado que las aplicaciones de producción se ejecutan en la región primaria en todo momento, las instancias de reserva se usan normalmente para economizar los costos de Azure. Si usa instancias reservadas, debe disponer de una suscripción de 1 o 3 años que puede no ser rentable para el sitio de recuperación ante desastres. Además, la configuración de Azure Site Recovery no garantiza la capacidad de la SKU de máquina virtual necesaria durante la conmutación por error. Para asegurarse de que la capacidad de SKU de máquina virtual está disponible, puede considerar la opción de habilitar la reserva de capacidad a petición. Reserva la capacidad de proceso en una región de Azure o en una zona de disponibilidad de Azure durante cualquier intervalo de tiempo sin compromiso. Azure Site Recovery está integrado con la reserva de capacidad a petición. Con esta integración, puede usar la potencia de las reservas de capacidad con Azure Site Recovery para reservar capacidad de proceso en el sitio de recuperación ante desastres y garantizar las conmutaciones por error. Para más información, lea Limitaciones y restricciones de la reserva de capacidad a petición.
Una suscripción de Azure tiene cuotas para familias de máquinas virtuales (por ejemplo, familia Mv2) y otros recursos. A veces, las organizaciones quieren usar una suscripción de Azure diferente para la recuperación ante desastres. Cada suscripción (principal y recuperación ante desastres) puede tener cuotas diferentes asignadas a cada familia de máquinas virtuales. Asegúrese de que la suscripción usada para el sitio de recuperación ante desastres tiene suficientes cuotas de proceso disponibles.
Storage
Al habilitar Azure Site Recovery para que una máquina virtual configure la recuperación ante desastres, los discos de datos locales y del sistema operativo conectados a las máquinas virtuales se replican en el sitio de recuperación ante desastres. Durante la replicación, las escrituras en disco de la máquina virtual se envían a una cuenta de almacenamiento en la caché de la región de origen. Desde ahí, los datos se envían a la región de destino y los puntos de recuperación se generan a partir de los datos. Cuando se realiza la conmutación por error de una máquina virtual durante la recuperación ante desastres, se usa un punto de recuperación para restaurar la máquina virtual en la región de destino. Pero Azure Site Recovery no admite todos los tipos de almacenamiento que están disponibles en Azure. Para más información, consulte Matriz de compatibilidad de Azure Site Recovery para almacenamientos.
Además de los discos de datos administrados de Azure conectados a máquinas virtuales, se usan diferentes soluciones de almacenamiento nativo de Azure para ejecutar la aplicación SAP en Azure. El enfoque de recuperación ante desastres para cada solución de almacenamiento de Azure puede diferir, ya que no todos los servicios de almacenamiento disponibles en Azure son compatibles con Azure Site Recovery. A continuación se muestra la lista del tipo de almacenamiento que se usa normalmente para la carga de trabajo de SAP.
Tipo de almacenamiento Recomendación de estrategia de recuperación ante desastres Disco administrado Azure Site Recovery NFS en Azure Files (LRS o ZRS) Script personalizado para replicar datos entre dos sitios (por ejemplo, rsync) NFS en Azure NetApp Files Uso de Replicación entre regiones de volúmenes de Azure NetApp Files Disco compartido de Azure (LRS o ZRS) Solución personalizada para replicar datos entre dos sitios SMB en Azure Files (LRS o ZRS) Uso de RoboCopy para copiar archivos entre dos sitios SMB en Azure NetApp Files Uso de Replicación entre regiones de volúmenes de Azure NetApp Files En el caso de las soluciones de almacenamiento personalizadas, como el clúster NFS, debe asegurarse de que se ha implementado la estrategia de recuperación ante desastres adecuada.
Es posible que distintos servicios de almacenamiento nativos de Azure (como Azure Files, Azure NetApp Files, discos compartidos de Azure) no estén disponibles en todas las regiones. Por lo tanto, para tener una configuración de SAP similar en la región de recuperación ante desastres después de la conmutación por error, asegúrese de que el servicio de almacenamiento correspondiente se ofrece en el sitio de recuperación ante desastres. Para obtener más información, consulte Productos de Azure disponibles por región.
Si usa zonas de disponibilidad para la recuperación ante desastres, tenga en cuenta los siguientes puntos:
- La característica Azure NetApp Files no depende aún de la zona. En la actualidad, la característica Azure NetApp Files no se implementa en todas las zonas de disponibilidad de una región de Azure. Puede ocurrir que el servicio Azure NetApp Files no esté disponible en la zona de disponibilidad elegida para la estrategia de recuperación ante desastres.
- La replicación entre regiones de volúmenes de Azure NetApp Files solo está disponible en pares de regiones fijas, no entre zonas.
Si ha configurado el almacenamiento con la integración de Active Directory, también se debe realizar una configuración similar en la cuenta de almacenamiento del sitio de recuperación ante desastres.
Los discos compartidos de Azure requieren un software de clústeres, como el clúster de conmutación por error de Windows Server (WSFC), que controle la comunicación del nodo de clúster, así como el bloqueo de escritura. Por lo tanto, para tener una estrategia de recuperación ante desastres para discos compartidos de Azure, también es necesario que un software de clúster administre los discos compartidos en el sitio de recuperación ante desastres. A continuación, puede usar el script para copiar datos del disco compartido conectado a un clúster de la región primaria al disco compartido conectado a otro clúster de la región de recuperación ante desastres.