Continuidad empresarial y recuperación ante desastres para una migración de SAP

Artículo
08/15/2024

Este artículo se basa en las consideraciones y recomendaciones del Área de diseño de zonas de aterrizaje de Azure para BCDR. En este artículo se describen las restricciones únicas en las zonas de aterrizaje que admiten una plataforma SAP. SAP es una plataforma crítica, por lo que también debe incorporar otras instrucciones críticas en el diseño.

Escenario y ámbito

Incorpore principios en su arquitectura que aborden los escenarios locales de continuidad del negocio y recuperación ante desastres (BCDR). Estos principios también se aplican en Azure. Sin embargo, es posible que Azure tenga más capacidad de hardware que el entorno local para compensar un error de host. Para recuperar automáticamente incluso las máquinas virtuales de Azure más grandes, puede configurarlas para que se reinicien en otro servidor. Configure las implementaciones de Azure para que usen las mismas condiciones que las implementaciones locales. Si usa configuraciones de clúster de conmutación por error automática para implementar sistemas locales o hardware sin sistema operativo, impleméntelas de la misma manera en Azure. Las aplicaciones SAP que ejecutan los procesos de negocio más críticos de su organización requieren:

Disponibilidad de los procesos de servicio y negocio.
Objetivos de tiempo de recuperación (RTO) para escenarios de error o escenarios de desastre.
Objetivos de punto de recuperación (RPO) para escenarios de error.
Las tareas de administración operativa y del ciclo de vida, y la tecnología que se ejecuta durante escenarios de error. Estas tareas de administración incluyen la revisión de sistemas operativos invitados y sistemas de administración de bases de datos, o la clonación y actualización de sistemas SAP.

Sugerencia

Determine una solución de alta disponibilidad y recuperación ante desastres (HADR) para cada uno de los arquetipos de su entorno SAP desde el principio. Asegúrese de que la solución cubre todos los componentes de SAP.

Configure una solución HADR en Azure al principio, en un entorno como mínimo y manténgala activa. A continuación, los equipos pueden adquirir experiencia con las tecnologías de la solución, lo que podría diferir de las tecnologías existentes. Configure HADR con anticipación para ayudar a desarrollar y evolucionar sus procedimientos operativos estándar (SOP).

Planifique la alta disponibilidad, recuperación ante desastres y protección de copia de seguridad para cargas de trabajo de producción en cuanto el sistema esté activo.

En este artículo se tratan los siguientes aspectos de BCDR para un escenario de SAP a escala empresarial:

Alta disponibilidad en una región de Azure
Consideraciones sobre las operaciones de copia de seguridad y restauración
Criterios para decidir entre la recuperación en casos de desastre interregional y regional

Alta disponibilidad en una región de Azure

En las secciones siguientes se proporcionan consideraciones de diseño y recomendaciones de alta disponibilidad de una región de Azure para un escenario empresarial de SAP.

Consideraciones de diseño para una alta disponibilidad

Cuando se implementa la alta disponibilidad, el objetivo es proporcionar disponibilidad para el único punto de error del software de SAP, como:

Sistemas de administración de bases de datos.
Puntos únicos de error en una aplicación, como SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS) y SAP Central Services (SCS). Algunos ejemplos de alta disponibilidad son SAP NetWeaver y la arquitectura SAP S/4HANA.
Otras herramientas, como SAP Web Dispatcher.

En otros escenarios, no restrinja la disponibilidad a errores de infraestructura o errores de software. Aplique disponibilidad a todas las tareas necesarias de administración del ciclo de vida. Por ejemplo, puede aplicar revisiones al sistema operativo en las máquinas virtuales, el sistema de administración de bases de datos (DBMS) y el software de SAP. Para minimizar las interrupciones que puedan producirse durante operaciones planeadas de administración del ciclo de vida y de tiempo de inactividad, use herramientas comunes que ayuden a proteger los sistemas frente a interrupciones del servicio no planeadas.

SAP y las bases de datos de SAP admiten clústeres de conmutación por error automática. En Windows, la característica de clústeres de conmutación por error de Windows Server 2022 admite la conmutación por error. En Linux, Linux Pacemaker o herramientas de socios como SIOS Protection Suite y Veritas InfoScale admiten la conmutación por error. En Azure, solo puede implementar un subconjunto de configuraciones de alta disponibilidad en su propio centro de datos.

Para obtener más información, consulte Escenarios admitidos para cargas de trabajo de SAP en máquinas virtuales de Azure y Escenarios admitidos para instancias grandes de SAP HANA.

En la capa de DBMS, el patrón de arquitectura común consiste en replicar las bases de datos al mismo tiempo y con diferentes pilas de almacenamiento que las que usan las máquinas virtuales principal y secundaria. Azure no admite arquitecturas en las que las máquinas virtuales principal y secundaria comparten almacenamiento para los datos del DBMS. Azure tampoco admite registros de transacciones ni registros de puesta al día. El principio rector es usar dos pilas de almacenamiento independientes, aunque estén basadas en recursos compartidos del sistema de archivos de red (NFS). Estas limitaciones son exclusivas de las soluciones de Azure y no de las soluciones locales.

Azure proporciona otras opciones porque admite el uso compartido de NFS y bloques de mensajes del servidor. Puede usar discos compartidos de Azure en Windows para componentes ASCS y SCS y escenarios específicos de alta disponibilidad. Configure los clústeres de conmutación por error por separado para los componentes de la capa de aplicaciones SAP y la capa de DBMS. Azure no admite arquitecturas de alta disponibilidad que combinen los componentes de la capa de aplicaciones SAP y la capa de DBMS en un clúster de conmutación por error.

La mayoría de los clústeres de conmutación por error para los componentes de la capa de aplicación de SAP y la capa de DBMS requieren una dirección IP virtual para un clúster de conmutación por error. Una excepción común es cuando usa Oracle Data Guard, que no requiere una dirección IP virtual. Azure Load Balancer debe controlar la dirección IP virtual para todos los demás casos. Puede usar un equilibrador de carga para cada configuración de clúster. Se recomienda usar la versión estándar del equilibrador de carga. Para obtener más información, consulte Conectividad del punto de conexión público para las máquinas virtuales con Azure Load Balancer estándar en escenarios de alta disponibilidad de SAP.

Para obtener más información, consulte Escenarios y arquitectura de alta disponibilidad para SAP NetWeaver.

En la tabla siguiente se muestran los acuerdos de nivel de servicio (SLA) de nivel de plataforma para varias opciones de implementación de alta disponibilidad. Los asociados que proporcionan los servicios administrados también proporcionan el SLA en el nivel de aplicación.

Nivel	Escenario de alta disponibilidad	SLA de plataforma
1	Zona de disponibilidad	99,99 %
2	Conjunto de disponibilidad	99,95 %
3	Máquina virtual única (recuperación automática)	99,90 %

Diferencias entre conjuntos de disponibilidad de Azure y zonas de disponibilidad

Antes de implementar la infraestructura de alta disponibilidad, determine si va a realizar la implementación con un conjunto de disponibilidad de Azure o una zona de disponibilidad, en función de la región que haya elegido. Las principales diferencias de las máquinas virtuales implementadas con un conjunto de disponibilidad son:

Las máquinas virtuales no se distribuyen entre diferentes zonas de disponibilidad.
El tipo de máquinas virtuales que se pueden implementar mediante un único conjunto de disponibilidad está restringido, ya que el host viene definido por la primera máquina virtual implementada en el conjunto. Por ejemplo, no puede combinar máquinas virtuales de la serie M y máquinas virtuales de la serie E en un conjunto de disponibilidad.

Al implementar la arquitectura de alta disponibilidad en diferentes zonas de disponibilidad, puede tener un SLA mayor para las máquinas virtuales. Para obtener más información, consulte SLA de máquinas virtuales de Azure. En función de la región de Azure, puede detectar diferentes condiciones de latencia de red en el tráfico de red entre las máquinas virtuales. Para más información, vea Configuraciones de cargas de trabajo de SAP con zonas de disponibilidad de Azure.

Si elige un enfoque de implementación zonal, tenga en cuenta cómo la latencia entre zonas para la región de Azure elegida podría afectar a las opciones de diseño de arquitectura y rendimiento. Tenga en cuenta la latencia entre el servidor de aplicaciones y la base de datos y entre los dos nodos de base de datos.

Si utiliza una implementación zonal activa/pasiva para el nivel de servidor de aplicaciones en el que los servidores de aplicaciones deben conectarse a la base de datos en la misma zona de disponibilidad, configure la automatización y cree un SOP para permitir una recuperación rápida y automatizada si se produce una conmutación por error de la base de datos.

Si usa zonas de disponibilidad en la solución SAP, diseñe también todos los demás servicios y componentes de infraestructura de Azure en el entorno de SAP para la redundancia de zona, a fin de lograr una verdadera redundancia de zona. Entre los ejemplos de servicios y componentes que se deben tener en cuenta se incluyen las puertas de enlace de Azure ExpressRoute, Load Balancer, Azure Files, Azure NetApp Files, proxies inversos, firewalls, servicios de antivirus e infraestructura de copia de seguridad.

Recomendaciones de diseño para alta disponibilidad

Azure proporciona varias opciones para ayudar a cumplir los contratos de nivel de servicio de infraestructura de la aplicación. Debe elegir la misma opción para los tres componentes de SAP: servicios centrales, el servidor de aplicaciones y la base de datos. Para obtener más información sobre los SLA para máquinas virtuales, conjuntos de disponibilidad y zonas de disponibilidad, consulte SLA para servicios en línea.
Al implementar máquinas virtuales en un conjunto de disponibilidad, la alineación con dominios de error y actualización impide que las máquinas virtuales estén en el mismo hardware de host, lo que proporciona protección contra errores de hardware. Cuando se implementan máquinas virtuales a través de zonas de disponibilidad y se usan diferentes zonas, se crean las máquinas virtuales en diferentes ubicaciones físicas. Esta configuración proporciona protección adicional contra problemas de alimentación, refrigeración o red que afectan a los centros de datos de la zona en su conjunto. Pero no se pueden implementar conjuntos de disponibilidad de Azure en una zona de disponibilidad de Azure, a menos que use grupos con ubicación por proximidad.

Si elige un enfoque de implementación por zonas, los DBMS de SAP, los servicios centrales y las capas de aplicación se ejecutan en distintas zonas de disponibilidad. Pero lo más probable es que cada zona de disponibilidad tenga varios servidores de aplicaciones. En este escenario, los servidores de aplicaciones de cada zona no se benefician automáticamente de los dominios de error y de actualización. Puede usar conjuntos de disponibilidad para obtener esas ventajas. Para obtener más información, consulte Grupos con ubicación por proximidad de Azure para una latencia de red óptima con SAP.
Al crear conjuntos de disponibilidad, use el número máximo de dominios de error y de actualización disponibles. Por ejemplo, si implementa más de dos máquinas virtuales en un conjunto de disponibilidad, use el número máximo de dominios de error (tres). Y use suficientes dominios de actualización para limitar el efecto de posibles errores de hardware físico, interrupciones de red o interrupciones de alimentación, además del mantenimiento planificado de Azure. El número predeterminado de dominios de error es dos y no se puede cambiar en línea más adelante.
En una implementación de conjunto de disponibilidad, cada componente de un sistema SAP debe estar en un conjunto de disponibilidad propio. Los servicios centrales de SAP, la base de datos y las máquinas virtuales de la aplicación deben estar en sus propios conjuntos de disponibilidad.
Al usar grupos con ubicación por proximidad de Azure en una implementación en un conjunto de disponibilidad, asegúrese de que los tres componentes de SAP (servicios centrales, servidor de aplicaciones y base de datos) estén en el mismo grupo con ubicación por proximidad.
Si usa grupos con ubicación por proximidad, use uno para cada identificación del sistema SAP (SID). Los grupos no se extienden entre zonas de disponibilidad o regiones de Azure.
Al usar grupos con ubicación por proximidad de Azure en una implementación en zonas de disponibilidad, asegúrese de que los dos componentes de SAP (servicios centrales y servidor de aplicaciones) estén en el mismo grupo con ubicación por proximidad. Las máquinas virtuales de base de datos de las dos zonas ya no forman parte de los grupos con ubicación por proximidad. Los grupos con ubicación por proximidad para cada zona ahora están limitados con la implementación de la máquina virtual que ejecuta las instancias de ASCS y SCS de SAP. La ventaja de esta configuración es que tiene más flexibilidad para cambiar el tamaño de las máquinas virtuales. También puede cambiar fácilmente a nuevos tipos de máquinas virtuales en la capa DBMS o en la capa de aplicación del sistema SAP.
Azure no admite la combinación de ASCS y la alta disponibilidad de la base de datos en un único clúster de Linux Pacemaker. Se deben separar en clústeres individuales. Puede combinar hasta cinco clústeres de varios servicios centrales en un par de máquinas virtuales.
Use Load Balancer estándar frente a clústeres de ASCS y base de datos.
Ejecute todos los sistemas de producción en SSD prémium de Azure y use Azure NetApp Files o Almacenamiento en disco Ultra de Azure. Como mínimo, asegúrese de que el disco del sistema operativo esté en el nivel prémium para que pueda mejorar el rendimiento y obtener el mejor SLA.
Implemente ambas máquinas virtuales en el par de alta disponibilidad en un conjunto de disponibilidad o en zonas de disponibilidad. Asegúrese de que estas máquinas virtuales tengan el mismo tamaño y la misma configuración de almacenamiento.
Use la tecnología de replicación de base de datos nativa para sincronizar la base de datos en un par de alta disponibilidad.
Utilice uno de los siguientes servicios para ejecutar clústeres de servicios centrales de SAP, en función del sistema operativo:
- Un clúster de SUSE Linux Enterprise Server Pacemaker admite un agente de barrera de Azure y hasta tres dispositivos de aislamiento de nodo.
- Un clúster de Red Hat Enterprise Linux Pacemaker admite un agente de barrera de Azure y no admite dispositivos de aislamiento de nodo.
- Un clúster de Windows.
- Software de clúster certificado por SAP que no es de Microsoft.
Configure los parámetros de tiempo de espera del clúster recomendados en la documentación de los servicios centrales y los clústeres de base de datos.

Almacenamiento para cargas de trabajo de SAP

Elija las opciones de almacenamiento adecuadas al diseñar para lograr resistencia en la carga de trabajo de SAP. Un diseño de almacenamiento de Azure adecuado para las cargas de trabajo de SAP puede minimizar la latencia y maximizar el rendimiento. Tenga en cuenta la implementación y cómo las instrucciones siguientes pueden ayudar a tomar decisiones arquitectónicas para la implementación de SAP en Azure. Para obtener más información, consulte Tipos de almacenamiento de Azure para cargas de trabajo de SAP.
Debe ejecutar SAP HANA en Azure solo en tipos de almacenamiento certificados por SAP. Debe ejecutar determinados volúmenes en determinadas configuraciones de disco. Por ejemplo, las configuraciones pueden habilitar el Acelerador de escritura o usar el almacenamiento SSD prémium. También debe asegurarse de que el sistema de archivos que se ejecuta en el almacenamiento sea compatible con el DBMS que se ejecuta en la máquina. Para más información, vea Configuraciones de almacenamiento para SAP HANA.

Además de los discos de datos administrados de Azure que están conectados a máquinas virtuales, varias soluciones de almacenamiento compartido nativas de Azure ejecutan aplicaciones SAP en Azure. La configuración de alta disponibilidad puede diferir porque Azure Site Recovery no admite algunos servicios de almacenamiento que están disponibles en Azure. Utilice los siguientes tipos de almacenamiento para las cargas de trabajo de SAP.

Tipo de almacenamiento	Compatibilidad con la configuración de alta disponibilidad
Discos compartidos de Azure (almacenamiento con redundancia local (LRS) o almacenamiento con redundancia de zona (ZRS))	Clúster de conmutación por error de Windows Server 2022. Para obtener más información sobre la configuración, consulte Diseño de la alta disponibilidad de SAP con clústeres de conmutación por error de Windows Server 2022.
NFS en Azure Files (LRS o ZRS)	Clúster basado en Pacemaker en entornos Linux. Asegúrese de comprobar la disponibilidad de NFS en varias regiones.
NFS en Azure NetApp Files	Clúster basado en Pacemaker en entornos Linux. Para obtener más información, consulte Azure NetApp Files para máquinas virtuales de SAP.
SMB en Azure Files (LRS o ZRS)	Clúster de conmutación por error de Windows Server 2022. Para más información sobre la configuración, consulte Instalación de SAP NetWeaver de alta disponibilidad con SMB de Azure Files.
SMB en Azure NetApp Files	Clúster de conmutación por error de Windows Server 2022. Para obtener más información sobre la configuración, consulte Alta disponibilidad para SAP NetWeaver con Azure NetApp Files (SMB) para aplicaciones SAP.

En lugar de servicios de almacenamiento compartido nativos de Azure, puede usar clústeres NFS tradicionales (basados en la replicación de dispositivos de bloques replicados distribuidos), GlusterFS o un volumen compartido de clúster con Espacios de almacenamiento directo como solución de almacenamiento compartido alternativa para ejecutar cargas de trabajo de SAP en Azure. Estas opciones son especialmente útiles cuando los servicios de almacenamiento compartido nativo de Azure no están disponibles en la región de Azure de destino o no admiten la arquitectura de destino. Para obtener más información sobre la disponibilidad del servicio de almacenamiento, consulte Productos de Azure por región.
Para obtener información sobre las opciones de almacenamiento disponibles para las cargas de trabajo de SAP en Azure, consulte Recomendaciones y directrices de almacenamiento para configurar la recuperación ante desastres.

Copia de seguridad y restauración

En las secciones siguientes se describen las consideraciones de diseño y las recomendaciones para la copia de seguridad y restauración en un escenario de SAP.

Aunque la copia de seguridad y restauración no se suele considerar una solución de alta disponibilidad adecuada para una carga de trabajo de SAP de producción, la tecnología proporciona otras ventajas. La mayoría de las empresas que usan aplicaciones de SAP deben seguir normas de cumplimiento que requieren el almacenamiento a largo plazo de las copias de seguridad. En otros casos, también es necesario tener una copia de seguridad desde la que se pueda restaurar. En esta guía se supone que ya ha establecido la copia de seguridad y la restauración y que sigue los procedimientos recomendados para las aplicaciones de SAP, lo que significa que puede:

Realizar una recuperación a un momento dado de las bases de datos de producción en cualquier momento y en un plazo que se ajuste al RTO. La recuperación a un momento dado normalmente proporciona protección para errores operadores, como la eliminación de datos, ya sea en la capa de DBMS o mediante SAP.
Mantener un almacén para conservar las copias de seguridad a largo plazo a fin de ajustarse a las normas de cumplimiento.
Usar las copias de seguridad de la base de datos para clonar el sistema SAP y restaurarlas en otro servidor o máquina virtual.
Usar datos de la base de datos de producción desde las copias de seguridad de base de datos para actualizar sistemas que no sean de producción.
Realizar copias de seguridad de servidores y máquinas virtuales de aplicaciones de SAP, discos o instantáneas de máquinas virtuales.
Realizar una copia de seguridad de un sistema SAP HANA con la replicación habilitada.
Realizar una copia de seguridad de instantáneas de la instancia de base de datos de SAP HANA.

Si realiza una copia de seguridad y restauración locales, deberá incorporar estas funcionalidades a los sistemas SAP en Azure. Si está satisfecho con la solución actual, compruebe si el proveedor de copia de seguridad admite implementaciones de Azure o si ha configurado una solución de software como servicio (SaaS) en Azure.

Azure ofrece un servicio de SaaS de copia de seguridad llamado Azure Backup, que toma instantáneas de máquina virtual y administra la transmisión de las copias de seguridad de SQL Server y SAP HANA. Si usa Azure NetApp Files para almacenar las bases de datos de SAP HANA, puede ejecutar copias de seguridad basadas en instantáneas de almacenamiento coherentes con HANA.

También puede usar Azure Backup para realizar copias de seguridad de bases de datos que tengan habilitada la replicación del sistema (HSR) de SAP HANA. Azure Backup administra automáticamente las copias de seguridad cuando se produce una conmutación por error y elimina la necesidad de intervención manual. La copia de seguridad también proporciona:

Protección inmediata sin copias de seguridad completas de corrección para poder proteger instancias de HANA o nodos de la configuración de HSR como un único contenedor de HSR.
Ventaja de la copia de seguridad instantánea y restauración instantánea.
Un enfoque basado en instantáneas coherente con HANA que se integra con Backint para SAP HANA. Puede usar Backup como un único producto para todo el entorno de HANA y para cualquier tamaño de base de datos.

Para obtener más información, consulte Sistema de base de datos de SAP HANA con replicación habilitada y Copia de seguridad de instantáneas de instancia de SAP HANA.

Recomendaciones de diseño para copias de seguridad y restauración

Puede usar Azure Backup para realizar copias de seguridad de las máquinas virtuales del servidor de aplicaciones de SAP y de servicios centrales.
Puede usar una copia de seguridad de SAP HANA para implementaciones de HANA de hasta 8 TB. Para obtener más información, consulte Matriz de compatibilidad para la copia de seguridad de bases de datos de SAP HANA en máquinas virtuales de Azure.
Si utiliza una solución de copia de seguridad de infraestructura como servicio, dimensione la infraestructura de copia de seguridad para asegurarse de que pueda realizar copias de seguridad de todos los sistemas del tamaño de producción simultáneamente o, como en un escenario de la vida real, dentro de los plazos previstos. Use una configuración de producción o una configuración similar para áreas como redes y seguridad.
Pruebe los tiempos de copia de seguridad y recuperación para verificar que cumplan con los requisitos de RTO para restaurar todos los sistemas simultáneamente después de un desastre.
Idealmente, evite la extracción de las copias de seguridad de Azure en la infraestructura de copia de seguridad local, especialmente en bases de datos de gran tamaño. Este enfoque puede afectar a la cantidad de ancho de banda que usan los circuitos ExpressRoute.
Pruebe la copia de seguridad y las herramientas de recuperación como parte del plan de pruebas de rendimiento.

Recuperación ante desastres

En las secciones siguientes se describen las consideraciones de diseño y las recomendaciones para la recuperación ante desastres en un escenario de SAP.

Consideraciones de diseño acerca de la recuperación ante desastres

El mapa de regiones de Azure incluye más de 65 regiones de Azure y no todas ellas ejecutan los mismos servicios. Para implementaciones de software de SAP más grandes, especialmente las que usan SAP HANA, busque regiones de Azure que ofrezcan máquinas virtuales de la serie M o máquinas virtuales de la serie Mv2 de Azure. Azure Storage también empareja diferentes regiones para replicar un subconjunto más pequeño de tipos de almacenamiento en otra región. Para más información, consulte Continuidad empresarial y recuperación ante desastres (BCDR): regiones emparejadas de Azure.

Los principales desafíos de emparejar regiones de Azure para cargas de trabajo de SAP son:

Los pares no siempre son coherentes con los servicios de máquina virtual de la serie M o Mv2. Muchas organizaciones que implementan sus sistemas SAP no usan regiones emparejadas de Azure. En su lugar, eligen regiones en función de la disponibilidad de los tipos de máquina virtual necesarios.
Puede replicar el almacenamiento estándar entre regiones emparejadas, pero no puede usar el almacenamiento estándar para almacenar las bases de datos o los discos duros virtuales. Solo puede replicar las copias de seguridad entre las regiones emparejadas que use. Para todos los demás datos, ejecute la replicación mediante características nativas de DBMS, como SQL Server Always On o la replicación del sistema SAP HANA. Use una combinación de Site Recovery, herramientas como rsync o robocopy y otro software que no sea de Microsoft para la capa de aplicación de SAP.
Si se produce un desastre, varios clientes afectados de una región de Azure conmutan por error a la región de recuperación ante desastres emparejada correspondiente. Esta situación da lugar a una competencia de recursos para activar máquinas virtuales inactivas en la región de recuperación ante desastres. La solución alternativa consiste en ejecutar sistemas que no sean de producción en la región de recuperación ante desastres y usar los mismos recursos para hospedar réplicas de recuperación ante desastres de sistemas de producción. Este uso de doble propósito de las infraestructuras de Azure en la región de recuperación ante desastres le ayuda a evitar las restricciones de capacidad de recursos.

Otra consideración importante es proteger la capacidad operativa necesaria en la región de recuperación ante desastres. Si se produce un desastre, es posible que tenga que ejecutar la aplicación de SAP durante un período mínimo de tiempo con una capacidad de TI mínima y por recursos humanos críticos solo mientras trabaja para recuperar el funcionamiento normal en la región primaria. Esta estrategia requiere que tenga una infraestructura de TI mínima disponible en la región de recuperación ante desastres.

Después de definir las regiones de Azure, debe elegir un patrón de implementación:

¿Implementará sistemas de producción en la región primaria?
¿Implementará sistemas SAP que no son de producción en la región de recuperación ante desastres?
¿Va a usar una arquitectura que agrupe todos los sistemas SAP en la región primaria? Esta configuración garantiza que la región de recuperación ante desastres solo se use para la recuperación ante desastres.

La mayoría de las organizaciones usan las dos regiones para los sistemas de SAP operativos. Las organizaciones que ejecutan copias completas de los sistemas de producción como sistemas de prueba de regresión empresarial suelen planificar el uso del sistema de prueba de regresión empresarial de la línea de productos de SAP como un destino de recuperación ante desastres.

Al elegir una región de recuperación ante desastres, asegúrese de tener conectividad de ExpressRoute con esa región. Si tiene varios circuitos de ExpressRoute que se conectan a Azure, al menos uno de esos circuitos se debe conectar a la región principal de Azure. Los demás se deben conectar a la región de recuperación ante desastres. Este tipo de arquitectura le conecta a la red de Azure en una área geográfica o geopolítica diferente y ayuda a proteger su conexión si una catástrofe afecta a una de las regiones de Azure.

Algunas organizaciones usan una arquitectura de alta disponibilidad y recuperación ante desastres combinada que agrupa a ambas en la misma región de Azure. Pero la agrupación de alta disponibilidad con la recuperación ante desastres no es lo ideal. Azure Availability Zones admite esta arquitectura. La distancia entre zonas de disponibilidad dentro de una región de Azure no es tan grande como la distancia entre dos regiones de Azure, por lo que un desastre natural podría poner en peligro los servicios de aplicaciones en la región en la que se produce. También debe tener en cuenta la latencia entre los servidores de aplicaciones de SAP y los servidores de bases de datos. De acuerdo con la nota 1100926 de SAP, un tiempo de ida y vuelta menor o igual a 0,3 ms es un buen valor, y un tiempo menor o igual a 0,7 ms es un valor moderado. Por lo tanto, para las zonas con latencias altas, tenga procedimientos operativos para garantizar que los servidores de aplicaciones SAP y los servidores de bases de datos siempre se ejecuten en la misma zona. Las organizaciones eligen esta arquitectura por los siguientes motivos:

El cumplimiento es suficiente con las configuraciones que admiten distancias menores entre la implementación de producción y un destino de recuperación ante desastres.
La soberanía de los datos es un factor.
Hay factores geopolíticos implicados.
Es una opción de bajo coste que admite errores zonales, a veces combinados con la transferencia de copia de seguridad a la región secundaria para catástrofes naturales que afectan a un radio grande.

Otro factor que tener en cuenta al elegir la región de recuperación ante desastres es el RPO y el RTO de la conmutación por error al sitio de recuperación ante desastres. Cuanto mayor sea la distancia entre la región de producción y las regiones de recuperación ante desastres, mayor será la latencia de red. La replicación se realiza de forma asincrónica entre regiones de Azure, pero la latencia de red puede afectar al rendimiento que se puede replicar y al objetivo de RPO. Para minimizar su RPO, puede utilizar una arquitectura combinada de alta disponibilidad y recuperación ante desastres. Pero esta configuración supone un riesgo potencialmente mayor a causa de desastres naturales a gran escala.

Recomendaciones de diseño para la recuperación ante desastres

Asegúrese de que el enrutamiento de interdominios sin clases (CIDR) para la red virtual principal no entra en conflicto ni se superpone con el de la red virtual del sitio de recuperación ante desastres.
Configure conexiones de ExpressRoute desde el entorno local a las regiones de recuperación ante desastres de Azure primaria y secundaria.
Considere la posibilidad de configurar conexiones VPN desde el entorno local a las regiones de recuperación ante desastres de Azure principal y secundaria. Use este método como alternativa al uso de ExpressRoute.
Use Site Recovery para replicar un servidor de aplicaciones en un sitio de recuperación ante desastres. Site Recovery también ayuda a replicar las máquinas virtuales del clúster de servicios centrales en el sitio de recuperación ante desastres. Al invocar la recuperación ante desastres, debe volver a configurar el clúster de Linux Pacemaker en el sitio de recuperación ante desastres. Por ejemplo, es posible que tenga que reemplazar la dirección IP virtual o SBD o ejecutar corosync.conf.
Replique el contenido del almacén de claves, como certificados, secretos o claves, en todas las regiones para poder descifrar los datos en la región de recuperación ante desastres.
Use la replicación entre regiones de Azure NetApp Files para sincronizar volúmenes de archivos entre la región primaria y la región de recuperación ante desastres.
Use la replicación de base de datos nativa, en lugar de Site Recovery, para sincronizar los datos en el sitio de recuperación ante desastres.
Empareje las redes virtuales de recuperación ante desastres y la principal. Por ejemplo, para la replicación del sistema HANA, debe emparejar una red virtual de base de datos de SAP HANA con la red virtual de base de datos de SAP HANA del sitio de recuperación ante desastres.
Si usa el almacenamiento de Azure NetApp Files para las implementaciones de SAP, cree, como mínimo, dos cuentas de Azure NetApp Files en el nivel Premium en dos regiones diferentes.
Considere la posibilidad de agrupar sistemas en función de su importancia empresarial y la dependencia de proximidad en función del rendimiento de la aplicación. Para minimizar el efecto empresarial de una interrupción regional, implemente cada grupo en una región independiente en una construcción de región emparejada. Por ejemplo, para minimizar el efecto de una interrupción regional, puede implementar dos sistemas críticos de componentes centrales de ERP que atiendan a dos unidades de negocio diferentes, en el sur y el oeste del Reino Unido.

Paso siguiente

Opciones de implementación para SAP en Azure

Compartir a través de