Configurar la recuperación ante desastres SAP en IBM Db2 en AWS

Creado por Ambarish Satarkar (AWS) y Debasis Sahoo () AWS

Entorno: producción	Tecnologías: Bases de datos; Operaciones	Carga de trabajo: SAP
AWSservicios: AmazonEC2; AWS Elastic Disaster Recovery

Resumen

Este patrón describe los pasos para configurar un sistema de recuperación ante desastres (DR) para SAP cargas de trabajo con IBM Db2 como plataforma de base de datos, que se ejecute en la nube de Amazon Web Services (AWS). El objetivo es proporcionar una solución de bajo costo para garantizar la continuidad empresarial en caso de interrupción.

El patrón emplea el enfoque de prueba piloto. Al instalar Pilot Light DRAWS, podrá reducir el tiempo de inactividad y mantener la continuidad empresarial. El enfoque piloto se centra en configurar un entorno de DR mínimoAWS, que incluya un SAP sistema y una base de datos Db2 en espera, que esté sincronizada con el entorno de producción.

Esta solución es escalable. Puede ampliarla a un entorno de recuperación de desastres a gran escala si lo necesita.

Requisitos previos y limitaciones

Requisitos previos 

• Una SAP instancia que se ejecuta en una instancia de Amazon Elastic Compute Cloud (AmazonEC2)

• Una base de IBM datos de Db2

• Un sistema operativo compatible con la matriz de disponibilidad del SAP producto () PAM

• Diferentes nombres de host de bases de datos físicas para los hosts de bases de datos de producción y espera

• Un depósito de Amazon Simple Storage Service (Amazon S3) en AWS cada región con la replicación entre regiones habilitada () CRR

Versiones de producto

• IBMBase de datos Db2, versión 11.5.7 o posterior

Arquitectura

Pila de tecnología de destino

• Amazon EC2

• Amazon Simple Storage Service (Amazon S3)

• Amazon Virtual Private Cloud (VPCinterconexión)

• Amazon Route 53

• IBMRecuperación ante desastres de alta disponibilidad de Db2 () HADR

Arquitectura de destino

Esta arquitectura implementa una solución de recuperación ante desastres para SAP cargas de trabajo con Db2 como plataforma de base de datos. La base de datos de producción se implementa en AWS la Región 1 y una base de datos en espera se implementa en una segunda región. La base de datos de espera se denomina sistema DR. La base de datos Db2 admite varias bases de datos de espera (hasta tres). Utiliza Db2 HADR para configurar la base de datos de recuperación ante desastres y automatizar el envío de registros entre las bases de datos de producción y en espera.

Si la disponibilidad de la región 1 se interrumpe a causa de un desastre, la base de datos en espera de la región de DR asume la función de base de datos de producción. SAPlos servidores de aplicaciones se pueden crear por adelantado o mediante AWSElastic Disaster Recovery o Amazon Machine Image (AMI) para cumplir con los requisitos del objetivo de tiempo de recuperación (RTO). Este patrón utiliza unAMI.

Db2 HADR implementa una configuración de producción en espera, en la que la producción actúa como servidor principal y todos los usuarios están conectados a él. Todas las transacciones se escriben en archivos de registro, que se transfieren al servidor en espera mediante /IP. TCP El servidor en espera actualiza su base de datos local enviando los registros transferidos, lo que ayuda a garantizar la sincronización con el servidor de producción.

VPCLa interconexión se utiliza para que las instancias de la región de producción y de la región DR puedan comunicarse entre sí. Amazon Route 53 dirige a los usuarios finales a las aplicaciones de Internet.

1. Cree un servidor AMI de aplicaciones en la región 1 y cópielo en la AMI región 2. AMIUtilícelo para lanzar servidores en la Región 2 en caso de desastre.

2. Configure la HADR replicación de Db2 entre la base de datos de producción (en la región 1) y la base de datos en espera (en la región 2).

3. En EC2 caso de desastre, cambie el tipo de instancia para que coincida con la instancia de producción.

4. En la Región 1, LOGARCHMETH1 se establece en db2remote: S3 path.

5. En la Región 2, LOGARCHMETH1 se establece en db2remote: S3 path.

6. La replicación entre regiones se realiza entre los buckets de S3.

Herramientas

AWSservicios

• Amazon Elastic Compute Cloud (AmazonEC2) proporciona capacidad informática escalable en la AWS nube. Puede lanzar tantos servidores virtuales como necesite y escalarlos o reducirlos con rapidez.

• Amazon Route 53 es un servicio DNS web escalable y de alta disponibilidad.

• Amazon Simple Storage Service (Amazon S3) es un servicio de almacenamiento de objetos basado en la nube que le ayuda a almacenar, proteger y recuperar cualquier cantidad de datos.

• Amazon Virtual Private Cloud (AmazonVPC) le ayuda a lanzar AWS recursos en una red virtual que haya definido. Esta red virtual se parece a una red tradicional que utilizaría en su propio centro de datos, con las ventajas de utilizar la infraestructura escalable que ofreceAWS. Este patrón utiliza la VPCinterconexión.

Prácticas recomendadas

• La red desempeña un papel clave a la hora de decidir el modo de HADR replicación. Para la recuperación ante desastres en todas AWS las regiones, le recomendamos que utilice el SUPERASYNC modo Db2 HADR ASYNC o Db2. 

• Para obtener más información sobre los modos de replicación de Db2HADR, consulte la IBM documentación.

• Puede usar la consola AWS de administración o la interfaz de línea de AWS comandos (AWSCLI) para crear un nuevo AMI SAP sistema existente. A continuación, puede utilizarla AMI para recuperar el SAP sistema existente o para crear un clon.

• AWSSystems Manager Automation puede ayudar con las tareas comunes de mantenimiento e implementación de las EC2 instancias y otros AWS recursos.

• AWSproporciona varios servicios nativos para monitorear y administrar su infraestructura y sus aplicacionesAWS. Servicios como Amazon CloudWatch y se AWS CloudTrail pueden usar para monitorear la infraestructura y API las operaciones subyacentes, respectivamente. Para obtener más información, consulte SAPIBMDb2 HADR with Pacemaker. AWS

Epics

Prepare el entorno

Tarea	Descripción	Habilidades requeridas
Compruebe el sistema y los registros.	Confirme que la producción SAP en el sistema Db2 esté configurada. Confirme que la copia de seguridad de registros esté habilitada y configurada para guardar los registros en el bucket de S3. Puede comprobarlo mediante el parámetro LOGARCHMETH1 de Db2. Cree uno AMI de los servidores de aplicaciones adicionales.	AWSadministrador, administrador de SAP Basis

Configure los servidores y la replicación

Tarea	Descripción	Habilidades requeridas
Cree los servidores SAP y bases de datos.	Para implementar la infraestructura en la región de DR, utilice un AWS CloudFormation script o una AMI de las instancias de producción. Como parte del enfoque piloto, puede utilizar una EC2 instancia más pequeña de la misma familia que la instancia de producción. Por ejemplo, si su tipo de instancia de producción es r6i.12xlarge, puede usar el tipo de instancia r6i.xlarge para la compilación de DR. De cualquier modo, asegúrese de asignar la misma capacidad de almacenamiento a la instancia de DR para restaurar la copia de seguridad de la base de datos de producción. Cree puntos de montaje para /sapmnt/<SID>/ Amazon Elastic File System (AmazonEFS) y asegúrese de que está configurado para replicarse desde el sistema principal. Realice una copia FULL de seguridad de la base de datos (en línea o fuera de línea) del sistema de producción. Usará esta copia de seguridad para crear la base de datos de DR. En el sistema de recuperación ante desastres, utilice el método de copia del sistema SAP Software Provisioning Manager (SWPM) y utilice la copia del sistema con copia de seguridad y restauración con fines de alta disponibilidad y recuperación ante desastres para crear el sistema de recuperación ante desastres. SAP Cuando se lo pidaSWPM, restaure la base de datos en DR con la copia de seguridad que tomó de la producción. La base de datos de DR estará en estado pendiente de avance de transacciones. El estado pendiente de avance de transacciones se establece de forma predeterminada una vez restaurada la copia de seguridad completa. El estado pendiente de avance de transacciones indica que la base de datos está en proceso de restauración, y que es posible que se necesite aplicar algunos cambios. Para obtener más información, consulte la IBMdocumentación.	SAPAdministrador de bases
Compruebe la configuración.	Para configurar el archivado de registrosHADR, tanto las bases de datos de producción como las de DR deben poder recuperar los registros automáticamente de todas las ubicaciones de archivo de registros. Compruebe que el parámetro LOGARCHMETH1 de la base de datos de DR esté establecido en la misma ubicación que en la base de datos de producción. Si no se puede acceder a la misma ubicación debido a las limitaciones regionales, asegúrese de que el sistema de DR pueda recuperar automáticamente los registros del sistema principal. Para habilitar los puertos TCP /IP para permitir la replicación de bases de datos, modifique /etc/services los hosts de producción y DR añadiendo las dos entradas siguientes. En el código, <SID> hace referencia al ID de sistema (SID) de la base de datos Db2 (por ejemplo,). PR1 <SID>_HADR_1 55001/tcp # DB2 HADR Port1 <SID>_HADR_2 55002/tcp # DB2 HADR Port2 Confirme que ambos puertos permiten el tráfico entrante y saliente entre las bases principal y en espera. Compruebe /etc/hosts en los hosts de producción y DR para asegurarse de que los nombres de host de los hosts de producción y espera apuntan a las direcciones IP correctas.	AWSadministrador, administrador de SAP Basis
Configure la replicación de la base de datos de producción a la base de datos de DR (mediante ASYNC el modo).	En la base de datos de producción, ejecute los siguientes comandos para actualizar los parámetros. db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST1 db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_1 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST2 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_2 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid> db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120 db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000 db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240 db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON En la base de datos DR, ejecute los siguientes comandos para actualizar los parámetros. db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST2 db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_2 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST1 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_1 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid> db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120 db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000 db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240 db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON Estos parámetros son necesarios para proporcionar información HADR relacionada a ambas bases de datos. En la base de datos Db2, HADR se activa en función de los valores de cada uno de los parámetros previamente establecidos. Para obtener más información sobre estos parámetros, consulte la IBMdocumentación. Comience HADR primero con la base de datos en espera recién creada mediante el siguiente comando. db2 deactivate db <SID> db2 start hadr on db <SID> as standby Comience HADR en la base de datos de producción mediante el siguiente comando. db2 deactivate db <SID> db2 start hadr on db <SID> as primary Compruebe si las bases de datos Db2 en producción y en espera están sincronizadas, y si el envío de registros está en curso. Para supervisar el estado de la HADR replicación, utilice el siguiente db2pd comando. db2pd -d <SID> -hadr Para obtener más información sobre la supervisiónHADR, consulte la IBMdocumentación.	SAPAdministrador de bases

Pruebe las tareas de conmutación por error de DR

Tarea	Descripción	Habilidades requeridas
Planifique el tiempo de inactividad empresarial de producción para la prueba de DR.	Asegúrese de planificar el tiempo de inactividad empresarial necesario en el entorno de producción para probar el escenario de conmutación por error de DR.	SAPAdministrador de bases
Crear un usuario de prueba.	Cree un usuario de prueba (o cualquier cambio de prueba) que pueda validarse en el host de DR para confirmar la replicación del registro tras la conmutación por error de DR.	SAPAdministrador de bases
En la consola, detenga las EC2 instancias de producción.	En este paso se inicia un cierre imprevisto para simular un escenario de desastre.	AWSadministrador de sistemas
Amplíe la EC2 instancia de recuperación ante desastres para adaptarla a los requisitos.	En la EC2 consola, cambie el tipo de instancia en la región de DR. Detenga la instancia: si la instancia se está ejecutando, debe detenerla para poder cambiar el tipo de instancia. En la EC2 consola, selecciona la instancia y elige Detener. Modifique el tipo de instancia: en la EC2 consola, seleccione la instancia y elija Acciones, Configuración de instancia y Cambiar tipo de instancia. Seleccione el tipo de instancia que coincida con la instancia principal y elija Aplicar. Iniciar la instancia: cuando se complete el cambio de tipo de instancia, inicie la instancia desde la EC2 consola. Para ello, seleccione la instancia y elija Iniciar. Para iniciar la base de datos Db2, utilice el comando siguiente. db2start db2 start HADR on db <SID> as standby	SAPAdministrador de base
Inicie la toma de control.	Desde el sistema de DR (host2), inicie el proceso de toma de control y active la base de datos de recuperación de desastres como principal. db2 takeover hadr on database <SID> by force Si lo desea, puede configurar los siguientes parámetros para ajustar automáticamente la asignación de memoria de la base de datos en función del tipo de instancia. El valor INSTANCE_MEMORY se puede decidir en función de la parte dedicada de la memoria que se va a asignar a la base de datos Db2. db2 update db cfg for <SID> using INSTANCE_MEMORY <FIXED VALUE> IMMEDIATE; db2 get db cfg for <SID> | grep -i DATABASE_MEMORY AUTOMATIC IMMEDIATE; db2 update db cfg for <SID> using self_tuning_mem ON IMMEDIATE; Verifique el cambio usando los siguientes comandos. db2 get db cfg for <SID> | grep -i MEMORY db2 get db cfg for <SID> | grep -i self_tuning_mem	SAPAdministrador de Basis
Inicie el servidor de aplicaciones SAP en la región RD.	Con el sistema de producción AMI que utilizó, lance un nuevo servidor de aplicaciones adicional en la región de RD.	SAPAdministrador de bases
Realice la validación antes de iniciar la SAP aplicación.	Valide las entradas /etc/hosts y /etc/fstab. Monte /sapmnt/<SID>/ en el sistema de DR. Valide que el sistema de archivos de DR /sapmnt/<SID>/ esté sincronizado con el /sapmnt/<SID>/ de producción. Inicie sesión con el usuario <sid>adm, ejecute R3trans -d y verifique el resultado del archivo trans.log. El archivo trans.log se genera en la misma ubicación en la que se ejecutó el comando R3trans -d.	AWSadministrador, administrador de SAP Basis
Inicie la SAP aplicación en el sistema DR.	Inicie la SAP aplicación en el sistema DR mediante el <sid>adm usuario. Utilice el siguiente código, que XX representa el número de instancia del servidor de Servicios SAP ABAP SAP Centrales (ASCS) y YY el número de instancia del servidor de SAP aplicaciones. sapconrol -nr XX -function StartService <SID> sapconrol -nr XX -function StartSystem sapconrol -nr YY -function StartService <SID> sapconrol -nr YY -function StartSystem	SAPAdministrador de bases
Realice SAP la validación.	Esto se lleva a cabo como una prueba de DR para proporcionar pruebas o comprobar que la replicación de los datos en la región de DR se realiza correctamente.	Ingeniero de pruebas

Lleve a cabo tareas de conmutación por recuperación en DR

Tarea	Descripción	Habilidades requeridas
Inicie los servidores de producción SAP y de bases de datos.	En la consola, inicie las EC2 instancias que alojan SAP y la base de datos en el sistema de producción.	SAPAdministrador de bases
Inicie la base de datos de producción y configúrelaHADR.	Inicie sesión en el sistema de producción (host1) y compruebe que la base de datos está en modo de recuperación ejecutando el siguiente comando. db2start db2 start HADR on db P3V as standby db2 connect to <SID> Compruebe que el HADR estado esconnected. El estado de la replicación debe ser peer. db2pd -d <SID> -hadr Si la base de datos no es incoherente y no se encuentra en estado connected y peer, es posible que sea necesario realizar una copia de seguridad y una restauración para que la base de datos (en host1) se sincronice con la base de datos actualmente activa (host2 en la región de DR). En ese caso, restaure la copia de seguridad de la base de datos de la región de DR host2 a la base de datos de la región de producción host1.	SAPAdministrador de bases
Conmute por recuperación la base de datos a la región de producción.	En un business-as-usual escenario normal, este paso se realiza en un tiempo de inactividad programado. Las aplicaciones que se ejecutan en el sistema de DR se detienen, y la base de datos se conmuta por recuperación a la región de producción (región 1) para reanudar las operaciones desde la región de producción. Inicie sesión en el servidor de SAP aplicaciones de la región DR y detenga la SAP aplicación. Desmonte /sapmnt/<SID> del sistema de DR y asegúrese de que los cambios se replican de forma inversa al sistema de producción /sapmnt/<SID>. Inicie sesión en el servidor de base de datos (host1) de la región de producción y tome el control. db2 takeover hadr on database <SID> Compruebe el HADR estado: HADR_ROLE debe estar PRIMARY encendido host1 y StandBy encendidohost2. db2pd -d <SID> -hadr	SAPAdministrador de bases
Realice la validación antes de iniciar la SAP aplicación.	Valide las entradas /etc/hosts y /etc/fstab. Monte /sapmnt/<SID>/ en el sistema de producción. Asegúrese de que esté sincronizado con el sistema de DR /sapmnt/<SID>/. Inicie sesión con el usuario <sid>adm, ejecute R3trans -d y verifique el resultado del archivo trans.log. El archivo trans.log se genera en la misma ubicación en la que se ejecutó el comando R3trans -d.	AWSadministrador, administrador de SAP Basis
Inicie la SAP aplicación.	Inicie la SAP aplicación en el sistema de producción mediante el <sid>adm usuario. Utilice el siguiente código, que XX representa el número de instancia de su SAP ASCS servidor y YY el número de instancia de su servidor de SAP aplicaciones. sapconrol -nr XX -function StartService <SID> sapconrol -nr XX -function StartSystem sapconrol -nr YY -function StartService <SID> sapconrol -nr YY -function StartSystem  Para confirmar que los servidores de aplicaciones están disponibles, inicie sesión SAP y realice las comprobaciones mediante las SM51 transacciones SICK and.	SAPAdministrador de bases

Resolución de problemas

Problema	Solución
Archivos de registro clave y comandos para solucionar problemas HADR relacionados	db2 get db cfg | grep -i hadr db2pd -d sid -hadr Db2diag.log (Por lo general, este archivo se encuentra dentro del directorio db2dump, y la ruta de db2dump está definida por el parámetro DIAGPATH).
SAPnota para solucionar HADR problemas en Db2 UDB	Consulte la SAP nota 1154013 -DB6: Problemas de base de datos en el entorno. HADR (Necesita las credenciales SAP del portal para acceder a esta nota).

Recursos relacionados

• Enfoques de recuperación ante desastres para bases de datos Db2 en AWS (entrada del blog)

• SAPonAWS: IBM Db2 HADR con Pacemaker

• Procedimiento paso a paso para configurar la HADR replicación entre bases de datos DB2

• Wiki de Db2 HADR

Información adicional

Con este patrón, puede configurar un sistema de recuperación ante desastres para un SAP sistema que se ejecute en la base de datos Db2. En una situación de desastre, la empresa debería poder continuar dentro de los requisitos del objetivo de tiempo de recuperación (RTO) y del objetivo de punto de recuperación (RPO) definidos:

• RTOes el tiempo máximo aceptable entre la interrupción del servicio y su restablecimiento. Este valor determina el período de tiempo que se considera aceptable cuando el servicio no está disponible.

• RPOes el tiempo máximo aceptable desde el último punto de recuperación de datos. Esto determina qué se considera una pérdida de datos aceptable entre el último punto de recuperación y la interrupción del servicio.

Para más FAQs informaciónHADR, consulte la SAPnota #1612105 -DB6: FAQ sobre la recuperación ante desastres de alta disponibilidad de Db2 (HADR). (Necesita las credenciales SAP del portal para acceder a esta nota).