Directrices de recuperación ante desastres para una aplicación de SAP
Para configurar la recuperación ante desastres (DR) para una carga de trabajo de SAP en Azure, debe probar, ajustar y actualizar el proceso con regularidad. Probar la recuperación ante desastres ayuda a identificar la secuencia de servicios dependientes necesarios antes de desencadenar la conmutación por error de recuperación ante desastres de la carga de trabajo de SAP o iniciar el sistema en el sitio secundario. Normalmente, las organizaciones tienen sus sistemas SAP conectados a los servicios de Active Directory (AD) y del Sistema de nombres de dominio (DNS) para funcionar correctamente. Al configurar la recuperación ante desastres para la carga de trabajo de SAP, asegúrese de que estén en funcionamiento los servicios de AD y DNS antes de recuperar SAP y otros sistemas que no son de SAP para asegurarse de que la aplicación funciona correctamente. Para obtener instrucciones sobre la protección de Active Directory y DNS, aprenda a proteger Active Directory y DNS. La recomendación de recuperación ante desastres para la aplicación SAP descrita en este documento está en el nivel abstracto. Debe diseñar la estrategia de recuperación ante desastres en función de su configuración específica y documentar el escenario de un extremo a otro.
Recomendaciones sobre la recuperación ante desastres para cargas de trabajo de SAP
En los sistemas SAP NetWeaver distribuidos, normalmente los servicios centrales, la base de datos y el almacenamiento compartido (NFS/SMB) son un único punto de error (SPOF). Para mitigar el efecto de los distintos SPOF, es necesario configurar la redundancia de estos componentes. La redundancia de estos componentes de SPOF en la región primaria se logra mediante la configuración de la alta disponibilidad. La configuración de la alta disponibilidad del componente protege al sistema SAP frente a errores o catástrofes locales. No obstante, para proteger las aplicaciones de SAP frente a desastres geográficos dispersos, se debe implementar una estrategia de recuperación ante desastres para todos los componentes de SAP.
En el caso de los sistemas SAP que se ejecutan en máquinas virtuales, puede usar Azure Site Recovery para crear un plan de recuperación ante desastres. A continuación, se muestra el enfoque de recuperación ante desastres recomendado para cada componente de un sistema SAP. En este documento, no se tratan los motores de SAP independientes que no son NetWeaver, como TREX y aplicaciones que no son de SAP.
| Componentes | Recomendación |
|---|---|
| SAP Web Dispatcher | Replicar la máquina virtual con Azure Site Recovery |
| Servicios centrales de SAP | Replicar la máquina virtual con Azure Site Recovery |
| Servidor de aplicaciones de SAP | Replicar la máquina virtual con Azure Site Recovery |
| Base de datos de SAP | Usar el método de replicación que ofrece la base de datos |
| Almacenamiento compartido | Replicar el contenido mediante el método adecuado para cada tipo de almacenamiento |
SAP Web Dispatcher
El componente SAP Web Dispatcher funciona como equilibrador de carga para el tráfico de SAP entre los servidores de aplicaciones de SAP. Tiene diferentes opciones para lograr la alta disponibilidad del componente SAP Web Dispatcher en la región primaria. Para más información sobre esta opción, consulte Alta disponibilidad de SAP Web Dispatcher y Configuración de la alta disponibilidad de SAP Web Dispatcher en Azure.
- Opción 1: Alta disponibilidad mediante una solución en clúster.
- Opción 2: Alta disponibilidad con distribuidores web de SAP en paralelo.
Para lograr la recuperación ante desastres para una configuración de SAP Web Dispatcher de alta disponibilidad en la región primaria, puede usar Azure Site Recovery. En el caso de los distribuidores web en paralelo (opción 2) que se ejecutan en la región primaria, puede configurar Azure Site Recovery para lograr la recuperación ante desastres. Pero para SAP Web Dispatcher configurado mediante la opción 1 en la región primaria, debe realizar algunos cambios adicionales después de la conmutación por error para tener una configuración de alta disponibilidad similar en la región de recuperación ante desastres. Como la configuración SAP Web Dispatcher, la alta disponibilidad con la solución en clúster se configura de forma similar a los servicios centrales de SAP. Siga las mismas directrices que se mencionan para los servicios centrales de SAP.
Servicios centrales de SAP
Los servicios centrales de SAP contienen servidor en cola y de mensajes, que es uno de los únicos puntos de error de la aplicación SAP. En un sistema SAP, solo puede haber una instancia de este tipo y se puede configurar para la alta disponibilidad. Consulte Alta disponibilidad para los servicios centrales de SAP para comprender las diferentes soluciones de alta disponibilidad para la carga de trabajo de SAP en Azure.
La configuración de la alta disponibilidad para los servicios centrales de SAP protege los recursos y los procesos frente a incidentes locales. Para lograr la recuperación ante desastres para los servicios centrales de SAP, puede usar Azure Site Recovery. Azure Site Recovery replica las máquinas virtuales y los discos administrados conectados, pero hay consideraciones adicionales para la estrategia de recuperación ante desastres. Consulte la sección siguiente para obtener más información, en función del sistema operativo usado para los servicios centrales de SAP.
En el caso de un sistema SAP, la redundancia de los componentes SPOF en la región primaria se logra mediante la configuración de la alta disponibilidad. Para lograr una configuración de alta disponibilidad similar en la región de recuperación ante desastres después de una conmutación por error, debe tener en cuenta puntos adicionales. Esto incluye volver a configurar el clúster, asegurarse de que los directorios compartidos de SAP están disponibles y de replicar máquinas virtuales y sus discos administrados en el sitio de recuperación ante desastres con Azure Site Recovery. En Linux, la alta disponibilidad de la aplicación de SAP se puede lograr mediante la solución en clúster Pacemaker. En el diagrama siguiente, se muestran los distintos componentes implicados en la configuración de la alta disponibilidad para los servicios centrales de SAP con Pacemaker. Se debe tener en cuenta cada componente para tener configurada una alta disponibilidad similar en el sitio de recuperación ante desastres. Si ha configurado SAP Web Dispatcher mediante la solución en clúster de Pacemaker, también se aplicará una consideración similar.
Equilibrador de carga interno
Azure Site Recovery replica las máquinas virtuales en el sitio de recuperación ante desastres, pero no replica el equilibrador de carga de Azure. Deberá crear un equilibrador de carga interno independiente en el sitio de recuperación ante desastres antes o después de la conmutación por error. Si crea un equilibrador de carga interno de antemano, cree un grupo de back-end vacío y agregue las máquinas virtuales después del evento de conmutación por error.
Solución en clúster de Pacemaker
Las configuraciones de un clúster de Pacemaker residen en archivos locales de las máquinas virtuales, que se replican en el sitio de recuperación ante desastres con Azure Site Recovery. La configuración del clúster de Pacemaker tal cual no funcionará de manera predeterminada en las máquinas virtuales después de la conmutación por error. Se requiere una reconfiguración adicional del clúster para que la solución funcione.
Consulte estos blogs para obtener información sobre la reconfiguración del clúster de Pacemaker en la región de recuperación ante desastres en función del tipo de almacenamiento y el mecanismo de barrera.
- Conmutación por error del clúster de alta disponibilidad de ASCS/ERS de SAP con un dispositivo SBD (con un servidor de destino iSCSI) en la región de recuperación ante desastres mediante Azure Site Recovery.
- Conmutación por error del clúster de alta disponibilidad de ASCS de SAP (en el sistema operativo Linux) en la región de recuperación ante desastres mediante Azure Site Recovery.
Directorios compartidos de SAP para Linux
La configuración de alta disponibilidad de SAP NetWeaver o la plataforma ABAP usa el servidor de replicación de puesta en cola para lograr la redundancia de nivel de aplicación para el servicio de puesta en cola del sistema SAP con la configuración en clúster de Pacemaker. La configuración de alta disponibilidad de los servicios centrales de SAP (ASCS y ERS) utiliza montajes NFS. Por lo tanto, debe asegurarse de que los archivos binarios de SAP y los datos de estos montajes NFS se repliquen en el sitio de recuperación ante desastres. Azure Site Recovery replica las máquinas virtuales y el disco administrado local conectado, pero no replica los montajes NFS. En función del tipo de almacenamiento NFS configurado para la configuración, debe asegurarse de que los datos se replican y están disponibles en el sitio de recuperación ante desastres. La metodología de replicación entre regiones para cada almacenamiento se presenta en un nivel abstracto. Debe confirmar los pasos exactos para replicar el almacenamiento y realizar las pruebas.
| Directorios compartidos de SAP | Replicación entre regiones |
|---|---|
| NFS en Azure Files | Personalizado (por ejemplo, rsync) |
| NFS en ANF | Sí (replicación entre regiones) |
| Clúster NFS | Personalizado |
Sugerencia
Se recomienda implementar uno de los servicios NFS propios de Azure: NFS en Azure Files o volúmenes NFS ANF para almacenar datos compartidos en un sistema SAP de alta disponibilidad. Tenga en cuenta que estamos dejando de lado las arquitecturas de referencia de SAP, que usan clústeres NFS.
Mecanismo de barrera
Independientemente del sistema operativo (SLES o RHEL) y su versión, Pacemaker requiere un mecanismo de barrera válido para que toda la solución funcione correctamente. En función del tipo de mecanismo de barrera que tuviera configurado en la región primaria, debe asegurarse de que esté configurado el mismo mecanismo de barrera en el sitio de recuperación ante desastres después de la conmutación por error.
| Mecanismo de barrera | Recomendación sobre la recuperación ante desastres entre regiones |
|---|---|
| SBD con un servidor de destino iSCSI | Replicar el servidor de destino iSCSI mediante Azure Site Recovery. En las máquinas virtuales de recuperación ante desastres, vuelva a detectar el disco iSCSI. |
| Agente de barrera de Azure | Habilitar las identidades del sistema administradas (MSI) en las máquinas virtuales de recuperación ante desastres. Asignar roles personalizados. Actualizar el recurso del agente de barrera en el clúster. |
| SBD con un disco compartido de Azure* | Configurar un nuevo disco compartido de Azure en la región de recuperación ante desastres. Conectar el disco compartido de Azure a las máquinas virtuales de recuperación ante desastres después de la conmutación por error. Configurar el dispositivo SBD de disco compartido de Azure. |
*ZRS para el disco compartido de Azure está disponible en regiones limitadas.
Nota:
Se recomienda tener el mismo mecanismo de barrera para la región primaria y la de recuperación ante desastres para facilitar el funcionamiento y la conmutación por error. No se recomienda tener un mecanismo de barrera diferente después de la conmutación por error al sitio de recuperación ante desastres.
Servidores de aplicaciones de SAP
En la región primaria, la redundancia de los servidores de aplicaciones de SAP se logra mediante la instalación de instancias en varias máquinas virtuales. Para tener recuperación ante desastres para los servidores de aplicaciones de SAP, se puede configurar Azure Site Recovery para cada máquina virtual del servidor de aplicaciones. En el caso de los almacenamientos compartidos (sistema de archivos de transporte, sistema de archivos de datos de interfaz) que están conectados a los servidores de aplicaciones, siga el procedimiento de recuperación ante desastres adecuado en función del tipo de almacenamiento compartido.
Servidores de bases de datos de SAP
Para las bases de datos que ejecutan la carga de trabajo de SAP, use la tecnología nativa de replicación de DBMS para configurar la recuperación ante desastres. 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. La tecnología de replicación de cada base de datos es diferente, por lo que debe seguir las directrices de la base de datos correspondiente. En la tabla siguiente se muestra la lista de bases de datos usadas para cargas de trabajo de SAP y la recomendación de recuperación ante desastres correspondiente.
| Base de datos | Recomendación de recuperación ante desastres |
|---|---|
| SAP HANA | Replicación del sistema HANA (HSR) |
| Oracle | Oracle Data Guard (FarSync) |
| IBM DB2 | Recuperación ante desastres de alta disponibilidad (HADR) |
| Microsoft SQL | Microsoft SQL Always On |
| ASE de SAP | ASE HADR Always On |
| SAP MaxDB | Base de datos en espera |
Para una solución optimizada para costo, incluso puede usar la opción de copia de seguridad y restauración para la estrategia de recuperación ante desastres de base de datos.
Copia de seguridad y restauración
La copia de seguridad y restauración es otra solución que puede usar para lograr la recuperación ante desastres para las cargas de trabajo de SAP si el RTO empresarial y el RPO no son críticos. Puede usar Copia de seguridad de Azure, un servicio de copia de seguridad basado en la nube para realizar copias de diferentes componentes de la carga de trabajo de SAP, como máquinas virtuales, discos administrados y bases de datos compatibles. Para más información sobre la configuración y las limitaciones generales de compatibilidad para escenarios e implementaciones de Azure Backup, consulte Matriz de compatibilidad para Azure Backup.
| Servicios | Componente | Compatibilidad de Azure Backup |
|---|---|---|
| Compute | Máquinas virtuales de Azure | Compatible |
| Storage | Azure Managed Disks, incluidos los discos compartidos | Compatible |
| Storage | Recurso compartido de archivos de Azure: SMB (Estándar o Premium) | Compatible |
| Storage | Blobs de Azure | Compatible |
| Storage | Recurso compartido de archivos de Azure: NFS (Estándar o Premium) | No compatible |
| Storage | Azure NetApp Files | No compatible |
| Base de datos | Base de datos de SAP HANA en máquinas virtuales de Azure | Compatible |
| Base de datos | SQL Server en máquinas virtuales de Azure | Compatible |
| Base de datos | Oracle | Admitido* |
| Base de datos | IBM DB2, SAP ASE | No compatible |
Nota:
*Azure Backup admite bases de datos de Oracle mediante la copia de seguridad de máquinas virtuales de Azure para instantáneas coherentes con la base de datos.
Azure Backup no admite todos los almacenamientos y bases de datos de Azure que se usan para la carga de trabajo de SAP.
Azure Backup almacena las copias de seguridad en el almacén de Recovery Services, que replica los datos en función del tipo de replicación elegido (LRS, ZRS o GRS). En el caso del almacenamiento con redundancia geográfica (GRS), los datos de copia de seguridad se replican en una región secundaria emparejada. Con la característica de restauración entre regiones habilitada, puede restaurar los datos del tipo de administración admitido en la región secundaria.
La copia de seguridad y restauración es un enfoque más tradicional optimizado para costo, pero tiene la desventaja de un RTO superior. Dado que tiene que restaurar todas las aplicaciones de la copia de seguridad si hay una conmutación por error a la región de recuperación ante desastres. Por lo tanto, debe analizar sus necesidades empresariales y, en consecuencia, diseñar una estrategia de recuperación ante desastres.