Como crear un sitio de recuperación ante desastres de SAP S/4HANA sobre AWS

Por Rodrigo Monge, Solutions Architect, AWS Public Sector

Introducción

Las organizaciones que ejecutan cargas de trabajo SAP, ya sea en AWS o en sus propios centros de datos, tienen el desafío de construir soluciones resilientes, que garanticen la continuidad del servicio ya que SAP soporta los procesos más críticos del negocio.

Existen múltiples estrategias para construir cargas de trabajo SAP resilientes, sin embargo, no todas las organizaciones tienen los mismos requerimientos de disponibilidad, recuperabilidad, mantenimiento y costos. El Pilar de Fiabilidad (Reliability Pillar) de nuestro AWS Well Architected Framework, ofrece un guía para poder balancear estos factores y elegir la mejor estrategia para su organización.

En este blog vamos a construir una solución de recuperación ante desastres (Disaster Recovery o DR) de un sistema SAP S/4HANA en una región de AWS hacia un sitio secundario en otra región de AWS utilizando diferentes estrategias de sincronización de datos. En nuestro escenario, el sistema SAP está compuesto por ASCS (ABAP SAP Central Services), PAS (Primary Application Server) y una base de datos SAP HANA.

La elección de la estrategia de configuración de un sitio de recupero ante desastres va a depender de las necesidades de RPO/RTO que su organización defina. La solución de este blog considera un RPO cercano a cero, que dependerá principalmente de la cantidad de operaciones de escritura de los componentes del sitio primario y del ancho de banda de red disponible para sincronizar esa demanda al sitio secundario. En la misma solución se considerada un RTO mayor a 30 minutos que va a depender de varios factores, como ser la cantidad de datos que tengan que cargarse en la memoria de la base de datos SAP HANA al momento de activación del sitio secundario, las tareas propias del failover y complementarias al mismo, como por ejemplo ajustes en temas de redes, DNS, firewalls, interfaces con otros sistemas, etc.

Nuestro whitepaper HA/DR options for SAP HANA on AWS ofrece más detalles sobre diferentes estrategias de sincronización de datos con diferentes necesidades de RPO/RTO.

Cabe mencionar que esta misma solución, siempre y cuando se mantengan los mismos objetivos de RPO/RTO, se puede ajustar para incorporar otros componentes. Por ejemplo aquellos entornos que utilicen otros componentes como SAP Web Dispatcher, SAP Fiori, SAP Router, etc; como así también sistemas SAP ejecutándose en un centro de datos propio y AWS como sitio de contingencia.

Arquitectura de la solución

AWS recomienda que las cargas de trabajo SAP que se ejecutan sobre una región de AWS cuenten con un esquema de Alta Disponibilidad (High-Availability) utilizando diferentes Zonas de Disponibilidad (Availability Zones), para luego sí, configurar un sitio de recuperación ante desastres. Con el objetivo de simplificar la configuración del proceso de contingencia, este blog no considera un sitio primario en Alta Disponibilidad. Para conocer más sobre mejores prácticas de arquitectura de SAP sobre, favor de acceder a la Guía Generales de SAP sobre AWS para más información.

Replicación continua de datos a nivel de bloques utilizando Cloudendure Disaster Recovery.
El Replication Server de Cloudendure gestiona la sincronización del almacenamiento origen hacia un área de Staging de bajo costo. Recibe los bloques modificados del sitio primario y los escribe en almacenamiento Amazon EBS (Elastic Block Store).
La instancia de contingencia de SAP S/4HANA (ASCS y PAS) se inicia únicamente durante el proceso de failover (activación del sistema de contingencia), generando un ahorro significativo en los costos de cómputo.
La carpeta /usr/sap/trans se accede a través del protocolo NFS sobre el servicio Amazon EFS (Elastic File System). El servicio AWS Datasync se encarga de realizar la replicación de los datos hacia la región de contingencia. Ese procedimiento no forma parte del alcance de este blog, pero puede revisar ese contenido en Como utilizar AWS Datasync para sincronizar Amazon EFS entre regiones de AWS?.
La replicación de la base de datos se realiza a través del método nativo de SAP HANA llamado SAP Hana System Replication (HSR).
La base de datos SAP HANA del sitio de contingencia podría correr sobre una instancia Amazon EC2 con menores recursos (Pilot Light), con el fin de reducir los costos del cómputo asociado. Esta configuración se puede verificar en Consideraciones de dimensionamiento de un sitio de contingencia de SAP HANA de menor tamaño.
Una única Private Hosted Zone de Amazon Route53 asociada tanto a la VPC del sitio primario como a la VPC del sitio secundario, para resolver las entradas de DNS de los servidores SAP S/4HANA (ASCS/PAS) y SAP HANA independientemente de la región que se encuentre activa. Esta resolución la vamos a utilizar por ejemplo en la configuración de SAP GUI y de SAP Hana Studio.

El proceso de configuración del sitio de contingencia que se realiza en este blog, utiliza diferentes herramientas de sincronización datos: Cloudendure Disaster Recovery para una replicación (a nivel de bloques) de los servidores de la capa aplicativa, AWS Datasync para la sincronización de los datos contenidos en el servicio Amazon EFS y SAP Hana System Replication (HSR) como herramienta nativa de replicación de bases de datos SAP HANA. La elección de HSR en lugar a Cloudendure para replicar SAP HANA, se debe al hecho de poder reducir el RTO de la capa de base de datos, transferir menos datos entre sitios (transacciones de la base de datos en lugar de bloques de sistema operativo) y delegar la consistencia de los datos al motor de base de datos.

Pre-requisitos:

Contar con un sistema SAP S/4HANA instalado. En caso que quiera realizar una instalación y configuración recomendamos el uso de AWS Launch Wizard for SAP. Este servicio ayuda a los clientes a desplegar aplicaciones SAP en AWS mediante la orquestación del aprovisionamiento de recursos subyacentes de AWS mediante AWS CloudFormation y AWS Systems Manager. Aquí un video explicando Como desplegar SAP HANA en AWS en menos de 2 horas utilizando AWS Launch Wizard for SAP.
Para la configuración de SAP Hana System Replication:

- Nodos primario y secundario de SAP HANA ya instalados con la siguiente configuración:
  - Nombre de host diferentes
  - Mismo HANA system ID
  - Mismo HANA instance number
  - Iniciar cada instancia SAP HANA de forma independiente
- Si no utiliza un DNS server, asegúrese de actualizar el archivo /etc/hosts con ambos nombres de host, tanto el primario como secundario.
- Asegúrese de que la versión de software del Nodo secundario debe ser igual o más reciente que la versión del sistema principal
- Tome un backup completo de la base de datos SYSTEM y de la base de datos TENANT
- La base de datos del sistema secundario debe encontrarse con los servicios de SAP HANA abajo
- Asegúrese que se establezcan los siguientes parámetros de configuración dentro del archivo global.ini
  - [persistence] log_mode = normal
- Prepare el sistema secundario copiando las claves SSFS del sistema del sistema principal al sistema secundario.
  Copie manualmente SSFS_<SID> .DAT y SSFS_<SID> .KEY del host principal al secundario.
  Estos archivos están en la ruta /<SID>/global/security/rsecssfs/data y /<SID>/global/security/rsecssfs/key respectivamente

Fuente: https://help.sap.com/viewer/4e9b18c116aa42fc84c7dbfd02111aba/2.0.04/en-US/86267e1ed56940bb8e4a45557cee0e43.html

Para la replicación utilizando Cloudendure Disaster Recovery
- Configurar VPC Peering (inter-region VPC peering connection) entre la VPC de la región primaria y la VPC de la región secundaria. También podría realizarse la conectividad entre regiones a través del servicio AWS Transit Gateway.
- Revisar los requerimientos del agente de Cloudendure que se va a instalar sobre cada uno de los servers que forme parte de alcance de nuestro disaster recovery, a excepción de SAP Hana que va a utilizar otro método de sincronización de datos

Configuración SAP Hana System Replication

Abrir la aplicación Hana Studio
Tomar un backup completo tanto de la base de datos SYSTEM como de la base de datos TENANT (HDB en nuestro caso).
Configurar nuestro sistema primario. Configuration and Monitoring -> Configure System Replication

Seleccionar Enable System Replication
Asignar un nombre lógico que identifique nuestro sistema primario.
Configurar nuestro sistema secundario. Configuration and Monitoring -> Configure System Replication.
Seleccionar Register secondary System

Asignar un nombre lógico a nuestro sistema secundario, y configurar el modo de replicación y el modo de operación.

Modos de Replicación:

Synchronous in-memory (SYNCMEM): El sistema secundario envía un acuse de recibo al sistema primario tan pronto como se reciben los datos en la memoria.
Synchronous (SYNC): El sistema secundario envía un acuse de recibo al sistema primario tan pronto como se reciben los datos y se persisten en los volúmenes de registro (log volumes) en el disco.
Asynchronous (ASYNC): El sistema primario envía redo log buffers al sistema secundario de forma asíncrona. El sistema primario confirma una transacción (commit) cuando se ha escrito en el archivo de registro (log file) del sistema primario y se ha enviado al sistema secundario a través de la red. No espera la confirmación del sistema secundario.
Esta opción proporciona un mejor rendimiento porque no es necesario esperar la confirmación de la escritura del log. Se garantiza la consistencia de la base de datos en todos los servicios del sistema secundario. Sin embargo, es más vulnerable a la pérdida de datos.

Fuente: https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/c039a1a5b8824ecfa754b55e0caffc01.html

Modos de Operación:

delta_datashipping: Este modo establece una replicación del sistema en la que ocasionalmente (de forma predeterminada, cada 10 minutos) se lleva a cabo un envío de datos delta (data shipping) además del envío de registros continuo (log shipping). El redo log enviado no se reproduce en el sitio secundario. Durante el takeover (proceso de transición hacia el sistema secundario), el redo log debe reproducirse hasta el último envío de datos delta (data shipping) recibido.
Logreplay: En este modo de operación, se realiza un envío de redo log después de que la replicación del sistema se configuró inicialmente con un envío de datos completo. El redo log se reproduce continuamente en el sistema secundario inmediatamente después de la llegada, lo que hace que este paso sea innecesario durante el takeover. Este modo no requiere envíos de datos delta. Debido a esto, se reduce la cantidad de datos que deben transferirse al sistema secundario.
logreplay_readaccess: Este modo es necesario para la replicación en un sistema secundario Activo / Activo (habilitado para lectura). Es similar al modo de operación de logreplay con respecto al envío de registros continuo, la aplicación del redo log en el sistema secundario, así como el envío de datos completo inicial requerido y la adquisición.

Fuente: https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/627bd11e86c84ec2b9fcdf585d24011c.html

Especificar el Host del sistema primario en la sección Source System Information (HDB)

Para revisar el estado de la replicación inicial, posicionarse en la pestaña Landscape -> System Replication, para ver progreso de la replicación.

Durante la fase de sincronización inicial, el estado es representado con un triángulo amarillo (). Una vez completada la fase de sincronización, el estado muestra un cuadrado verde (), dando confirmación que los sistemas están en sincronía.

También es posible confirmarlo a través de un comando en la consola SQL.

Configuración Cloudendure Disaster Recovery

En esta sección vamos a configurar la réplica de los componentes ASCS y PAS de SAP S/4HANA. Para más detalles sobre la configuración de Cloudendure se puede consultar la documentación oficial del servicio.

Acceder a la consola https://console.cloudendure.com/ y crear un nuevo proyecto de tipo Disaster Recovery.
Configurar las credenciales de AWS que va a utilizar el servicio Cloudendure para realizar sobre la cuenta de AWS. El detalle sobre los privilegios requeridos por las credenciales de AWS se puede verificar en el acceso The Project must have these permissions dentro de la misma pantalla de configuración.
En Replication Settings configurar los parámetros globales del proyecto, en nuestro escenario se modificarán los valores de:

Las regiones origen y destino de nuestros sitios primarios y de contingencia
El tipo de instancia utilizada por el Replication Server
La Subnet donde se va a desplegar el Replication Server
El Security Group asociado al Replication Server
El tipo de Conectividad entre las regiones. En nuestro caso, contamos con una configuración de VPC Peering, con lo cual vamos a seleccionar la opción Use VPN or DirectConnect (using a Private IP) y Disable public IP

Para más información sobre las opciones configuración se puede consultar la documentación del servicio.

Instalar el agente de Cloudendure sobre el servidor del cual es requerido configurar un ambiente de contingencia. La documentación detalla más información al respecto.

En este punto empieza a sincronizar los datos desde el servidor origen y se inicia un Replication Server en la región de destino, de acuerdo a los parámetros configurados en la sección Replication Settings del proyecto.
Durante el proceso de sincronización, es posible configurar el Blueprint del ambiente de contingencia. La documentación detalla más información sobre este punto.

Una vez finalizada la sincronización, el servidor SAP S/4HANA (ASCS/PAS) figura en estado Ready For Testing con un progreso Continuous Data Replication.

Acceso a SAP S/4HANA primario a través de SAP GUI

Configurar una zona privada dentro del servicio Amazon Route53 para contener las entradas de DNS de los servidores SAP HANA y SAP S/4HANA. Es requisito asociar las VPCs origen y destino para facilitar la resolución de nombres de host.

Probar la resolución por nombre de DNS del host s4hana.local. Esta entrada está asociada al servidor SAP S/4HANA en la región primaria.

Utilizar esta entrada de DNS dentro de la configuración de SAP GUI

Verificar el estado con la herramienta SAP GUI

Failover SAP HANA hace el sitio secundario:

Si bien es posible controlar el proceso de failover de SAP HANA a través de comandos del sistema operativo, en esta ocasión vamos a realizarlo a través de la aplicación SAP HANA Studio.

Ingresar a la aplicación SAP HANA Studio
Posicionarse sobre el sistema secundario en el servidor de contingencia, y buscar la opción Configuration and Monitoring -> Configure System Replication
Seleccionar la opción Perform takeover y confirmar la acción.

Luego de realizados estos pasos, estamos en condiciones de realizar el failover de la capa aplicativa de SAP S/4HANA. Estos pasos se van a realizar sobre la consola de Cloudendure.

Failover SAP S/4HANA hacia el sitio secundario:

Conectarse a la consola de Cloudendure https://console.cloudendure.com/
Definir el Blueprint del servidor SAP S/4HANA en el menú Machines -> ingresar a la configuración del servidor -> Blueprint.
Seleccionar el servidor SAP S/4HANA en la consola de Cloudendure y ejecutar Launch 1 Target Machine -> Recovery Mode.
Antes de activar la opción Recovery Mode, recomendamos realizar una prueba (Test Mode) de la activación del SAP S/4HANA en el sitio secundario con el objetivo de poder validar el procedimiento mismo y su impacto.

Seleccionar el Punto de Recuperación (Recovery Point), por defecto la consola propone tomar un último Snapshot, sin embargo es posible seleccionar una imagen de un punto anterior.
Monitorear el Job desde el menú Job Progress hasta que el estado figure como Job Finished
Confirmar el estado del servidor como Failed Over dentro de la consola de Cloudendure
En el servicio Amazon EC2 de la consola de AWS, se puede identificar una nueva instancia lanzada en la región secundaria. Ingresar a este nuevo servidor a través de SSH utilizando la misma llave SSH que utilizamos en el servidor primario.
Es necesario realizar cambios luego del Failover de los servidores SAP HANA y SAP S/4HANA:

Modificar las entradas en la zona privada de Amazon Route53 de modo tal que las instancias apunten a las direcciones IP de la región secundaria
Actualizar los archivos /etc/hosts tanto en el servidor SAP HANA como en el SAP S/4HANA
Montar la unidad compartida de Amazon EFS sobre el servidor secundario de SAP S/4HANA (/usr/sap/trans)
Si bien estas actividades se pueden llevar a cabo de forma manual, es recomendable automatizarlas con el fín de reducir el tiempo de operación y los posibles errores humanos.
A modo de ejemplo, en nuestro caso vamos a utilizar scripts específicamente construidos para automatizar tareas de esta solución. Estos scripts fueron ejecutados con el usuario root de sistema operativo. Durante el proceso de ejecución del script, se reemplazaron las variables ZONE_TAG y NAME_TAG por los valores relevantes a esta configuración.

En Ejecutar primero el siguiente script (hana_post_launch.sh) en el server SAP HANA de la región de contingencia
NOTA: se proporciona este script de ejemplo, pero los valores pueden cambiar dependiendo de la configuración de cada entorno de su organización

#!/bin/bash
 
IP_ADDRESS=$(curl http://169.254.169.254/latest/meta-data/local-ipv4)
INSTANCE_ID=$(curl http://169.254.169.254/latest/meta-data/instance-id)
AVAILABILITY_ZONE=$(curl http://169.254.169.254/latest/meta-data/placement/availability-zone)
REGION=$(curl -s http://169.254.169.254/latest/dynamic/instance-identity/document | grep -oP '\"region\"[[:space:]]*:[[:space:]]*\"\K[^\"]+')
ZONE_TAG=XXXXXXXXXXXXXXXXXXXXXX
NAME_TAG=YYYYYYYYYYYYYYYYYYYYYY
 
####### Update Amazon Route53 Private Zone Record for S4H
aws route53 change-resource-record-sets --hosted-zone-id $ZONE_TAG --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{"Name":"'$NAME_TAG'","Type":"A","TTL":300,"ResourceRecords":[{"Value":"'$IP_ADDRESS'"}]}}]}'

Luego ejecutar el siguiente script (s4hana_post_launch.sh) en el server SAP S/4HANA de la región de contingencia
NOTA: se proporciona este script de ejemplo, pero los valores pueden cambiar dependiendo de la configuración de cada entorno de su organización

#!/bin/bash
 
IP_ADDRESS=$(curl http://169.254.169.254/latest/meta-data/local-ipv4)
INSTANCE_ID=$(curl http://169.254.169.254/latest/meta-data/instance-id)
AVAILABILITY_ZONE=$(curl http://169.254.169.254/latest/meta-data/placement/availability-zone)
REGION=$(curl -s http://169.254.169.254/latest/dynamic/instance-identity/document | grep -oP '\"region\"[[:space:]]*:[[:space:]]*\"\K[^\"]+')
ZONE_TAG=XXXXXXXXXXXXXXXXXXXXXX
NAME_TAG=ZZZZZZZZZZZZZZZZZZZZZZ
 
####### Mount EFS Filesystem for /usr/sap/trans
FILE_SYSTEM=$(aws efs describe-file-systems --query "FileSystems[*].{FileSystemId:FileSystemId , Name:Name}" --output text |grep S4H_Transport_Domain| cut -f1)
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport ${FILE_SYSTEM}.efs.${REGION}.amazonaws.com:/ /usr/sap/trans
 
####### Update Amazon Route53 Private Zone Record for S4H
aws route53 change-resource-record-sets --hosted-zone-id $ZONE_TAG --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{"Name":"'$NAME_TAG'","Type":"A","TTL":300,"ResourceRecords":[{"Value":"'$IP_ADDRESS'"}]}}]}'
 
####### Update /etc/hosts
host_name=$(hostname)
# find existing instances in the host file and save the line numbers
matches_in_hosts="$(grep -n $host_name /etc/hosts | grep -v "#" | cut -f1 -d:)"
host_entry="${IP_ADDRESS} ${host_name}.local ${host_name}"
 
if [ ! -z "$matches_in_hosts" ]
then
    echo "Updating existing hosts entry."
    # iterate over the line numbers on which matches were found
    while read -r line_number; do
        # replace the text of each line with the desired host entry
        sudo sed -i "${line_number}s/.*/${host_entry} /" /etc/hosts
    done <<< "$matches_in_hosts"
else
    echo "Adding new hosts entry."
    echo "$host_entry" | sudo tee -a /etc/hosts > /dev/null
fi
####### Update /etc/hosts SAP HANA
 
####### Update Amazon Route53 Private Zone Record for S4H
NAME_TAG=YYYYYYYYYYYYYYYYYYY
IP_ADDRESS_SAPHANA=$(aws route53 list-resource-record-sets --hosted-zone-id $ZONE_TAG --query "ResourceRecordSets[?Name == '$NAME_TAG'].ResourceRecords[*]" --output text | cut -f1)
 
####### Update /etc/hosts S$HANA
host_name=saphanaprd
# find existing instances in the host file and save the line numbers
matches_in_hosts="$(grep -n $host_name /etc/hosts | grep -v "#" | cut -f1 -d:)"
host_entry="${IP_ADDRESS_SAPHANA} ${host_name}.local ${host_name}"
 
if [ ! -z "$matches_in_hosts" ]
then
    echo "Updating existing hosts entry."
    # iterate over the line numbers on which matches were found
    while read -r line_number; do
        # replace the text of each line with the desired host entry
        sudo sed -i "${line_number}s/.*/${host_entry} /" /etc/hosts
    done <<< "$matches_in_hosts"
else
    echo "Adding new hosts entry."
    echo "$host_entry" | sudo tee -a /etc/hosts > /dev/null
fi

Verificar que private hosted zone de Amazon Route53 se encuentre actualizada apuntando las entradas hacia los servidores de la región de contingencia.

Iniciar los servicios de SAP S/4HANA (ASCS & PAS)

Prueba del entorno de contingencia en la región secundaria:

Ejecutar SAP GUI y verificar que la base de datos SAP HANA esté apuntando al servidor de la región de contingencia.

Failback SAP HANA hacia el sitio primario original:

Una vez restaurado el servicio en nuestra región primaria, es posible optar por tomar un respaldo de nuestro ambiente de contingencia y posterior restauración sobre la región primaria, o bien realizar el mismo procedimiento configuración del sitio de contingencia en el sentido inverso (Failback).

Para invertir el sentido de replicación de SAP HANA a través de SAP HSR (Hana System Replication) se va a llevar a cabo exactamente el mismo proceso realizado anteriormente. Para más detalles puede consultar la documentación de SAP HSR.

Failback SAP S/4HANA hacia el sitio primario original:

Conectarse a la consola de Cloudendure https://console.cloudendure.com/
Ejecutar Project Actions -> Prepare For Failback

Ingresar a la configuración del servidor SAP S/4HANA, el cual es necesario invertir el sentido de la réplica, y acceder a la sección Failback Settings. Luego elegir los parámetros que va a utilizar Cloudendure para desplegar el servicio sobre el sitio primario original, en nuestro caso modificar la subnet donde es deseado se despliegue el Replication Server, y asegurarse que la replicación se va a realizar a través de IPs privadas. Este mismo proceso lanza la sincronización del servidor SAP S/4HANA hacia el almacenamiento conectado al Replication Server.

Una vez finalizado el proceso de sincronización, actualizar el Blueprint con los parámetros que teníamos definidos anteriormente.

Ejecutar Launch Target Machine -> Recovery Mode.
Seleccionar el Punto de Recupero (Recovery Point)
Monitorear el proceso a través del menú Job Progress
Una vez finalizado el proceso de Failback, invertir los roles de sitio primario y secundario dentro de la configuración de Cloudendure, ejecutando Project Actions -> Return to Normal Operation.
Esta operación no sólo vuelve a asignar los roles originales de sitio primario y secundario, sino que además lanza la sincronización del servidor SAP S/4HANA hacia el sitio de contingencia

Sincronizar la unidad de Amazon EFS (/usr/sap/trans) en sentido inverso utilizando la herramienta AWS Datasync. Ese procedimiento no forma parte del alcance de este blog, puede consultar esa configuración en Como configurar AWS datasync para transferir datos entre Amazon EFS.
Ejecutar el script hana_post_launch.sh en el servidor SAP HANA primario original
Ejecutar el script s4hana_post_launch.sh en el servidor SAP S/4HANA primario original
Verificar que las entradas en la zona privada de Amazon Route53 sean correctas, apuntando a las direcciones IP de la región primaria
Verificar que el archivo /etc/hosts tenga la correcta configuración en los servidores SAP HANA y SAP S/4HANA
Iniciar los servicios de SAP S/4HANA (ASCS & PAS)
Verificar el correcto acceso a través de SAP GUI

Resumen

Si bien existen diferentes estrategias a la hora de crear un sitio de recupero ante desastres para un sistema SAP, en este blog demostramos lo fácil y rápido que es hacerlo a través de Cloudendure Disaster Recovery en combinación con SAP Hana System Replication (HSR). Es importante mencionar que una única solución no aplica a todos los escenarios, es fundamental tener en cuenta los requerimientos y necesidades de cada organización, y a partir de ahí trabajar en las soluciones que podrían dar respuesta a ellas.

Como mencionamos anteriormente, esta solución se puede ajustar a otros escenarios. Por ejemplo podríamos pensar un sitio de contingencia dentro de la misma región primaria, sacando provecho de las diferentes de zonas de disponibilidad.

Otra alternativa de solución de recuperación ante de desastres de SAP puede ser utilizando una estrategia pasiva con herramientas como AWS Backint Agent

Recomendamos acceder a nuestro entrenamiento gratuito de Cloudendure Disaster Recovery para más información sobre las configuraciones utilizadas en este blog.

Sobre el autor

Rodrigo Monge es arquitecto de soluciones en Amazon Web Services.

Blog de Amazon Web Services (AWS)