activaciÓn de la contingencia para el sistema sap erp
TRANSCRIPT
ACTIVACIÓN DE LA CONTINGENCIA PARA
EL SISTEMA SAP ERP PRODUCTIVO DEL
CLIENTE ABBOTT LAFRANCOL COMO
PLAN DE RECUPERACIÓN ANTE
DESASTRES
Miguel Ángel García Calderón 20122005212
Universidad Distrital Francisco José De Caldas
Facultad de Ingeniería
Bogotá, Colombia
2020
ACTIVACIÓN DE LA CONTINGENCIA PARA
EL SISTEMA SAP ERP PRODUCTIVO DEL
CLIENTE ABBOTT LAFRANCOL COMO
PLAN DE RECUPERACIÓN ANTE
DESASTRES
INFORME FINAL DE GRADO
MODALIDAD DE GRADO: PASANTIA
Trabajo de grado presentado para optar al título de:
Ingeniero Electrónico
PRESENTA:
Miguel Ángel García Calderón
Código: 20122005212
DIRECTOR EXTERNO:
ING. Iván Leonardo Torres Patiño its specialist sap NetWeaver GTS delivery & integrated OPERATIONS IBM
DIRECTOR INTERNO:
ING. Gustavo Adolfo Puerto Leguizamo
docente facultad de ingeniería
Universidad distrital francisco José De caldas
Universidad Distrital Francisco José De Caldas
Facultad de Ingeniería
Bogotá, Colombia
2020
Contenido
1. RESUMEN ........................................................................................................................
1.1. Presentación de la empresa ........................................................................................
2. Planteamiento del problema ..............................................................................................
3. Justificación .......................................................................................................................
4. Objetivos ............................................................................................................................. 1
4.1. Objetivo general ....................................................................................................... 1
4.2. Objetivos específicos ............................................................................................... 1
5. DESCRIPCIÓN Y ANALISIS DE RESULTADOS ...................................................... 2
5.1. FASE 1: Estudio de la plataforma SAP (service application and products), bases de
datos DB2 Y sistema operativo AIX. ................................................................................. 2
5.1.0. SAP (service application and products) ............................................................... 2
5.1.1. SAP R/3 ................................................................................................................ 2
5.1.2. Arquitectura ........................................................................................................... 3
5.1.3. Matriz de Compatibilidad ................................................................................. 4
5.1.4. IBM DB2 ............................................................................................................... 5
5.1.5. Disponibilidad excepcional ................................................................................... 5
5.1.6. Escalabilidad masiva ............................................................................................. 5
5.1.7. Flexibilidad en el despliegue ................................................................................. 5
5.1.8. Menor costo total de propiedad ............................................................................. 5
5.1.9. HADR.................................................................................................................... 5
5.1.10. Recuperación ante desastres a la nube pública.................................................... 6
5.1.11. Recuperación ante desastres usando VMware SRM ........................................... 6
5.1.12. Recuperación ante desastres específica de HANA ............................................. 7
5.1.13. Una talla no sirve para todos .............................................................................. 7
5.1.14. MAXIMO ............................................................................................................ 7
5.1.15. Línea Base ........................................................................................................... 8
5.1.16. IBM PASSMAN ................................................................................................. 8
5.1.17. Plan de cambios ................................................................................................... 9
5.2. FASE 2: Análisis y realización de los eventos previos a las pruebas de alta
disponibilidad. ................................................................................................................... 10
5.2.0 ACTIVIDAD 1: Validar y confirmar información de la máquina de contingencia
con el cliente (IP - Host). .............................................................................................. 10
5.2.1. ACTIVIDAD 2: Realizar pruebas de conexión desde LAFRANCOL CALI hacia
el servidor de contingencia. ........................................................................................... 17
5.2.2. ACTIVIDAD 3: Verificación conectividad desde Calle 100 a Celta - máquina
contingencia. ................................................................................................................. 20
5.2.3. ACTIVIDAD 4: Verificación de actividad replica HADR en SAP. Toma de
evidencias. ..................................................................................................................... 21
5.2.4. ACTIVIDAD 5: Sincronización y backup de binarios PRD y CONTIGENCIA
(SRVLEP01 IP:10.182.1.28) ......................................................................................... 22
5.2.5. ACTIVIDAD 6: Agregar los siguientes espacios en el servidor de
CONTIGENCIA (SRVLEP01 IP:10.182.1.28). ........................................................... 31
5.3. FASE 3: Realización de pruebas de alta disponibilidad de la solución de
contingencia HADR durante la ventana del cambio. ........................................................ 37
5.3.0. ACTIVIDAD 1: Verificación de sincronía entre ambiente PRODUCCIÓN y
CONTIGENCIA vía HADR. ........................................................................................ 37
5.3.1. ACTIVIDAD 2: Suspensión de réplica HADR en ambiente producción. Toma
de evidencias. ................................................................................................................ 38
5.3.2. ACTIVIDAD 3: Habilitación de entorno de contingencia: Base de datos / SAP.
Toma de evidencias. ...................................................................................................... 39
5.3.3. ACTIVIDAD 4: Verificación de ambiente de contingencia y Entrega e Inicio de
pruebas por parte de LAFRANCOL, Toma de evidencias. .......................................... 41
5.4. FASE 4: Restauración del escenario de alta disponibilidad HADR, documentación y
socialización de resultados. ............................................................................................... 43
5.4.0. ACTIVIDAD 1: Validación del FileSystem /bk_replica y progreso del backup.
....................................................................................................................................... 43
5.4.1. ACTIVIDAD 2: Copiar backup hacia contingencia ERP PRD. ......................... 44
5.4.2. ACTIVIDAD 3: Restaurar backup proveniente de ERP PRD. ........................... 45
5.4.3. ACTIVIDAD 4: Subir base de datos, verificar consistencia y Configuración
HADR para iniciar proceso de réplica. ......................................................................... 46
6. Conclusiones y recomendaciones.................................................................................. 48
Bibliografía ........................................................................................................................... 49
1. RESUMEN
IBM es una empresa multinacional creada en 1911 por Herman Hollerith dedicada al sector
de tecnología e informática, IBM de Colombia y Compañía S.C.A se estableció en Colombia
en 1937, siendo la primera empresa en el país en iniciar la integración de la tecnología al
desarrollo. Hoy más de 80 años después es una de las más grandes multinacionales del país,
apoyando la innovación y el crecimiento económico de este, IBM de Colombia y Compañía
S.C.A y su programa de Trainee brinda la experiencia a estudiantes del mundo para realizar
su pasantía académica y formarlos laboralmente apostando por los IBMer del Futuro,
permitiéndoles enfrentarse al mundo laborar y conocer los procesos internos y externos de la
empresa [1].
1.1. Presentación de la empresa
Cuando hablamos del origen de IBM nos situamos en 1911, año en que se produce la fusión
de 3 compañías: International Time Recording Company, Computing Scale Company, y la
Tabulating Machine Company. De esta unión surge la Computing- Tabulating- Recording
Company (C-T-R) con centro en Nueva York y con 1.300 empleados, dedicada a construir
dispositivos de precisión (tabuladores, perforadoras, balanzas, molinillos de café, etc. Etc.).
En 1924 C-T-R diversifica su línea de productos y se convierte en IBM, cuyo gerente general
fue Thomas J. Watson. En ese entonces, la compañía se enfocó en la provisión a gran escala
de la construcción de equipos de tabulación para los negocios, balanzas comerciales y relojes
de registro. Durante los primeros 4 años la empresa se expandió a Europa, Asia, Australia y
Sudamérica.
De ser una compañía básicamente dedicada al hardware se transformó en una organización
que brinda servicios de valor agregado a sus clientes a través de consultoría, servicios de
tecnología y software. IBM trabaja por el progreso que importa y para lograrlo va ciudad por
ciudad, para llevar su tecnología para optimizar los sistemas que permitan mejorar la calidad
de vida de las personas. Sus valores y el trabajo por la innovación se mantienen y fortalecen
a través de los años. Con más de 400.000 empleados en más de 170 países, IBM está
comprometida con el desarrollo de las comunidades donde opera [2].
2. Planteamiento del problema
IBM y SAP trabajan juntos para diseñar y crear soluciones personalizadas para abordar las
necesidades específicas de sus clientes, desde la migración de SAP S / 4HANA a la gestión
de aplicaciones y la creación de cadenas de valor predictivas. Al mismo tiempo, estas
soluciones transformadoras ayudan a aumentar el valor del cliente, mejorar las experiencias
del cliente y ayudarlo a establecer una presencia digital más fuerte. Y con el fin de ayudar a
sus clientes se plantea la contingencia en pro de la prevención de cualquier tipo de desastre.
Para los clientes de IBM es de vital importancia mantener la alta disponibilidad de sus
servicios en todo momento [3].
Por esto se propone estas pruebas de contingencias para anteponer cualquier problema en la
prestación de servicio. Se podría indicar infinidad de sucesos que pueden o no pasar, pero de
antemano con la contingencia queremos estar seguros de prestar el mejor servicio. El plan de
recuperación ante desastres debe ejecutarse estableciendo el Objetivo de punto de
recuperación (RPO). RPO se refiere al período de tiempo máximo objetivo en el que los datos
pueden perderse debido a un desastre o cuántos datos puede permitirse perder en caso de un
desastre. El establecimiento de RPO depende de la solución de recuperación ante desastres.
Por ejemplo, en el enfoque tradicional, RPO depende del tamaño de los registros de su base
de datos. Para grandes registros, necesita un gran RPO [4].
Los desastres debidos a fallas en las aplicaciones, ataques cibernéticos o cualquier calamidad
causan tiempo de inactividad y pérdidas monetarias masivas para el negocio. Detiene el
negocio. A veces, la pérdida de datos y el tiempo de inactividad son tan largos y graves que
causan pérdidas irreparables a la reputación de la empresa. ¿Por qué necesita un plan de
recuperación ante desastres? En tal escenario, es vital asegurar un plan sólido de recuperación
ante desastres. SAP es una aplicación de misión crítica. La recuperación ante desastres
infalible no solo garantiza un ahorro de los costos, sino que también se considera una
estrategia de supervivencia.
3. Justificación
Entre las diversas opciones de recuperación ante desastres, la tecnología en la nube ha jugado
un papel importante, especialmente para las pequeñas y medianas empresas. Las opciones de
recuperación ante desastres brindan a las empresas una flexibilidad para elegir y planificar
en consecuencia. La recuperación ante desastres en el entorno SAP se refiere a la copia de
los archivos de registro de la base de datos. La información administrada por SAP se
almacena en la base de datos. En consecuencia, cualquier cambio en la base de datos se
representa en los registros. Cuando envía archivos de registro a un servidor remoto asignado
para la recuperación ante desastres, puede recuperar toda la información cuando sea necesario
[4].
El desarrollo de este proyecto permitirá Garantizar que el cliente cuente con una contingencia
en el momento que ocurra un desastre o en el momento que decida habilitar. Para este caso
se realizará la prueba de conexión cerrada para garantizar que siga funcionando la
contingencia de un sistema SAP ERP productivo se generan transacciones (facturación
electrónica en este caso) al momento de perder conexión con su servidor principal y pueda
seguir con su operación normal a través del servidor (contingencia) garantizando la alta
disponibilidad de los sistemas.
1
4. Objetivos
4.1. Objetivo general
• Habilitar la contingencia para el sistema SAP ERP (Enterprise Resource Planning)
productivo del cliente ABBOTT LAFRANCOL como plan de recuperación ante
desastres.
4.2. Objetivos específicos
• Determinar las actividades para validar y confirmar la información, conectividad y
configuración de la contingencia del cliente ABBOTT previas a las pruebas de alta
disponibilidad.
• Implementar pruebas de alta disponibilidad de la solución de contingencia HADR
(High Availability Disaster Recovery) para una base de datos DB2 en el sistema SAP
ERP del cliente ABBOTT - LAFRANCOL.
• Restaurar un escenario de alta disponibilidad HADR (High Availability Disaster
Recovery) para un base de datos DB2 en el sistema SAP ERP del cliente ABBOTT.
2
5. DESCRIPCIÓN Y ANALISIS DE RESULTADOS
La sección mostrada a continuación muestra la ejecución de las fases con la cual se desarrolló
el proyecto. Para ello se describen y ejecutan las actividades por cada uno de los objetivos
propuestos.
5.1. FASE 1: Estudio de la plataforma SAP (service application and
products), bases de datos DB2 Y sistema operativo AIX.
Para esta fase inicial se realiza el aprendizaje teórico del aplicativo SAP basado en el curso
titulado “Curso completo de SAP de cero a experto” y en el estado del arte la implementación
de este aplicativo.
5.1.0. SAP (service application and products)
SAP (Servicios, Aplicaciones y Productos para procesamiento de datos) fue fundada en 1972
como System analyses und Programmentwicklung por 5 exmiembros de IBM (Dietmar
Hopp, Hasso Plattner, Klaus Tschira, Claus Wellenreuther y Hans-Werner Hector) en
Weinheim (Alemania). En 2005, pasó a llamarse SAP AG (Aktiengesellschaft, es decir,
Corporation). SAP AG es la tercera mayor compañía de software, tras Microsoft e IBM y la
líder indiscutible en el campo de los ERPs. Actualmente hay unas 108.200 instalaciones de
SAP en 28000 empresas. Lo utilizan 12 millones de personas en más de 120 países. SAP está
en el centro de la revolución tecnológica actual. Como líder de mercado en software de
aplicaciones para empresas, SAP ayuda a las organizaciones a combatir los efectos de la
complejidad, generar nuevas oportunidades para la innovación y el crecimiento, y
mantenerse a la delantera de la competencia: [5].
5.1.1. SAP R/3
SAP R/3 es el producto más famoso y extendido de SAP AG y el ERP (Enterprise Resource
Planning o Sistema de planificación de recursos empresariales) más vendido. La R se refiere
a procesamiento en tiempo real y el 3 indica las 3 capas que incluye su arquitectura: cliente,
servidor de aplicación y base de datos. Es un sistema integrado (todo se guarda en una BD
accesible desde todo el sistema), fiable (no genera incoherencias), robusto (tiene pocos
fallos), transparente (todo el código del sistema es visible), abierto (muchas posibilidades de
acceso a programas externos), seguro (muchas posibilidades de control de accesos) y con el
respaldo de un gran soporte. Aunque como inconvenientes se le pueden achacar el ofrecer un
3
lenguaje de programación un poco limitado (aunque se está mejorando), el hecho de ser algo
complejo para los neófitos y el que su implantación sea bastante cara [5].
5.1.2. Arquitectura
El sistema R/3 opera utilizando el principio cliente/servidor aplicado a varios niveles. Es
altamente modular y se aplica fundamentalmente por medio del software, de forma que los
modos de interacción entre los diversos clientes y servidores puedan ser controlados. Cada
cliente (cada máquina que accede al servidor SAP R/3) usa un Front End llamado SAP GUI
(Graphic User Interface) [5].
Figura 5-1: Arquitectura SAP GUI.
Entre las ventajas de la arquitectura cliente/servidor está la de las capas de separación desde
el punto de vista del software y en las posibilidades de escalabilidad (incluir nuevos clientes
o servidores sin que el sistema se resienta) desde el punto de vista hardware.
Figura 5-2: Arquitectura cliente/servidor desde el punto de vista del software y el hardware.
4
Otra gran ventaja de R/3 es su característica de sistema abierto, gracias a la cual permite la
conexión de/con múltiples sistemas ajenos al ERP. Esto facilita muchas de las labores de
instalación de R/3 en las empresas y ofrece un incentivo más al cliente, pues muchas de ellas,
bien no quieren desprenderse de ciertas aplicaciones o no pueden por falta de medios, o bien
hay una falta de cobertura del producto SAP que adquieren, en el entorno que ocupan esas
aplicaciones [5].
Algunos de los protocolos que ofrece/cumple:
• TCP/IP para comunicarse con cualquier aplicación en red.
• RPC incluido en ABAP como RFC, es una interfaz de programación abierta que
permite a otros sistemas conectarse y usar las características de R/3.
• CPI-C usado para comunicaciones programa a programa en sistemas múltiples.
• SQL lenguaje de acceso a bases de datos.
• ODBC/OLE-DDE protocolos de comunicación con BD remotas.
• MAPI/EDI normas para transmisión de datos electrónicos (en comunicaciones
externas).
5.1.3. Matriz de Compatibilidad
La matriz de compatibilidad se soporta en diversas tecnologías. Está enfocado en llevar las
nuevas tecnologías a la nube. Permite expandir y trabajar en diferentes lenguajes de
programación.
Figura 5-3: Matriz de compatibilidad.
5
5.1.4. IBM DB2
IBM Db2 es la base de datos preferida para soluciones empresariales. Optimizada para
ofrecer el mejor rendimiento del sector y, al mismo tiempo, reducir costos, IBM Db2 ofrece
un gran rendimiento, flexibilidad, escalabilidad y fiabilidad para organizaciones de cualquier
tamaño [6].
5.1.5. Disponibilidad excepcional
Su acceso a datos altamente disponible y su fácil instalación y configuración le dan un valor
excepcional a Db2.
5.1.6. Escalabilidad masiva
Dé soporte a volúmenes masivos de datos a niveles de petabytes y, al mismo tiempo, acelere
drásticamente las consultas complejas para optimizar la eficiencia del negocio.
5.1.7. Flexibilidad en el despliegue
Las múltiples opciones de despliegue (híbrido, on premise, cloud) ofrecen flexibilidad para
dar soporte a un rango de cargas de trabajo. Además, las herramientas avanzadas facilitan la
gestión y ofrecen un rendimiento constante.
5.1.8. Menor costo total de propiedad
Gracias a la seguridad integrada, el cifrado nativo y la capacidad de utilizar la infraestructura
existente y el hardware genérico, Db2 reduce los costos operativos para disminuir el costo
total de propiedad. Las potentes tasas de compresión disminuyen los requisitos de
almacenamiento para mejorar la eficiencia [6].
5.1.9. HADR
Recuperación ante desastres de alta disponibilidad (HADR) La función Recuperación ante
desastres de alta disponibilidad (HADR) proporciona una solución de alta disponibilidad para
fallas parciales y completas del sitio. En un entorno HADR, log. Data se envía
continuamente desde una base de datos primaria a una o más bases de datos en espera y se
6
vuelve a aplicar a las bases de datos en espera. Cuando falla la base de datos primaria, las
aplicaciones son redirigidas a una base de datos en espera que automáticamente asume el rol
de la base de datos primaria. Una falla parcial del sitio puede ser causada por una falla de
hardware, red o software (DB2 o sistema operativo). Sin HADR, una falla parcial del sitio
requiere reiniciar el servidor del sistema de administración de la base de datos que contiene
la base de datos. El tiempo que lleva reiniciar la base de datos y el servidor donde se
encuentra es impredecible. Pueden pasar varios minutos antes de que la base de datos vuelva
a un estado coherente y esté disponible. Con HADR, una base de datos en espera puede
tomar el control en segundos. Además, puede redirigir a los clientes que usaron la base de
datos primaria original a la nueva base de datos primaria utilizando la redirección automática
de clientes de DB2 [7].
5.1.10. Recuperación ante desastres a la nube pública
Los servicios de nube pública como Amazon Web Services a menudo son elegidos por
empresas con cambios menos frecuentes a nivel de servidor web, aplicaciones front-end o
aplicaciones de interfaz. Aquí la copia de seguridad de los datos se realiza en el servidor
público y se actualiza de vez en cuando sea necesario. Esta es una opción económica ya que
el servidor se usa solo cuando es necesario, como en el caso de un desastre o actualización.
Sin embargo, al ejecutar SAP Business One, su base de datos siempre debe estar sincronizada
con el servidor y enviar actualizaciones. Sin embargo, debido a problemas de seguridad, la
nube pública no es la opción correcta para todos. Las empresas con presupuestos limitados
suelen optar por esta opción o cuando otras opciones son costosas [4].
5.1.11. Recuperación ante desastres usando VMware SRM
En contraste con el método tradicional de recuperación de desastres como se mencionó
anteriormente, que se basa en la replicación a nivel de base de datos enviando los archivos
de registro; VMware Site Recovery Manager realiza una replicación completa del
servidor. Aquí los archivos adicionales creados como parte de las operaciones de SAP
también se replican en el sitio de recuperación ante desastres.
Cuando utiliza VMware SRM, se crea una granja de VMware en su centro de datos primario
y también en el sitio de Recuperación ante desastres. La replicación de VMware SRM se
replica en las dos granjas, lo que permite un objetivo de tiempo de recuperación rápida (RTO)
para restaurar un proceso comercial después de la interrupción. Además, le permite
almacenar todos los archivos que no residen en la base de datos [4].
7
5.1.12. Recuperación ante desastres específica de HANA
HANA se ejecuta en su propio servidor de aplicaciones con su propio método de replicación
utilizando la herramienta de replicación HANA. Esta herramienta replica todo el dispositivo
HANA en otro sitio. Para replicar HANA del centro de datos principal a un sitio de
recuperación ante desastres, necesita dos bases de datos operativas de HANA, una en el
centro de datos principal y la otra en el sitio de recuperación.
La ventaja de usar este método es la excelente velocidad y rendimiento que ofrece la
replicación HANA. Sin embargo, siempre es mejor usar una solución asincrónica durante la
replicación para garantizar que la función de la base de datos HANA no se
interrumpa. Aunque es costosa, la recuperación ante desastres específica de HANA es la
mejor opción de recuperación que suelen utilizar los clientes que ya ejecutan SAP HANA
[4].
5.1.13. Una talla no sirve para todos
La solución de recuperación ante desastres depende de las instalaciones existentes del cliente,
el nivel de seguridad requerido y el presupuesto. En consecuencia, se puede implementar una
solución adecuada. Muchos clientes tienden a utilizar el enfoque tradicional debido a su
fiabilidad. Sin embargo, cuando no hay restricción de presupuesto, siempre es mejor buscar
soluciones superiores como VMware SRM.
La implementación de una solución VMware necesita un entorno SAP virtualizado y si un
cliente aún ejecuta SAP en servidores físicos y no planea la virtualización, entonces la
solución VMware es irrelevante. SAP Business One es un gran producto, pero necesita un
plan de recuperación ante desastres para garantizar su seguridad. Independientemente de lo
que elija, no será incorrecto afirmar que una empresa sin un plan de recuperación ante
desastres se encamina hacia un desastre [4].
IBM como compañía. ofrecen diferentes herramientas para la ejecución de sus proyectos.
Para este caso se requiere el de trabajo en equipo ya que intervienen diferentes divisiones en
pro de la correcta ejecución de la CONTINGENCIA. A continuación, se mostrará diferentes
herramientas y plataformas que son clave para validar y desarrollar los planes de cambio que
se consensan con el cliente.
5.1.14. MAXIMO
Esta plataforma es utilizada por IBM para llevar control de cada actividad realizada. Para
este caso el proyecto se realiza con la programación de las actividades las cuales tienen un
numero de SR (service requests) o change.
8
Figura 5-4: Plataforma máximo.
5.1.15. Línea Base
La línea base es una plataforma de búsqueda en la cual se puede validar información en
general de cada uno de los sistemas a trabajar tales como su cliente, producto, ambiente,
Hostname, dirección IP entre otros.
Figura 5-5: Línea base.
5.1.16. IBM PASSMAN
PASSMAN es un aplicativo que alberga los usuarios y las contraseñas de cada uno de los
sistemas tratados en la compañía. Encontramos usuarios de SAP, sistema operativo,
administración, base de datos etc.
9
Figura 5-6: IBM PASSMAN.
5.1.17. Plan de cambios
Todas las actividades propuestas para dar cumplimiento a los objetivos planteados en el
proyecto deben ser incluidas en un plan de cambios. El cual se envía a todas las áreas que
hacen parte del proyecto incluyendo el cliente, el cual llega a un acuerdo para poner en
marcha las actividades propuestas.
Figura 5-7: Formato plan de cambios.
10
5.2. FASE 2: Análisis y realización de los eventos previos a las pruebas de
alta disponibilidad.
Durante esta fase se realiza la validación y confirmación de la información de la máquina de
contingencia con el cliente (IP - Host). Adicionalmente se realiza pruebas de conexión desde
LAFRANCOL CALI hacia el servidor de contingencia por los puertos SAP establecidos.
LAFRANCOL asignara un recurso en Cali para realizar las pruebas de conexión. En el
margen de estas pruebas se realizará la Verificación de la conectividad desde Calle 100 a
Celta - máquina contingencia: puertos SAP y la verificación de actividad replica HADR en
SAP. Toma de evidencias. Sincronización y backup de binarios PRD y CONTIGENCIA
(SRVLEP01 IP:10.182.1.28).
Figura 5-8: Actividades previas a la contingencia.
5.2.0 ACTIVIDAD 1: Validar y confirmar información de la máquina de contingencia
con el cliente (IP - Host).
La actividad inicia con la apertura de 3 terminales para realizar las validaciones
correspondientes a cada sistema. La imagen Figura 5-10 corresponde a la máquina de la
contingencia:
Figura 5-9: Línea base Maquina contingencia.
11
Figura 5-10: IP asignadas a la máquina de contingencia (SRVLEP01).
Se realiza el ingreso a las IP asignadas a la máquina de contingencia (128.0.22.10;
10.128.1.28; 10.25.132.3; 10.244.1.44;).
La segunda terminal se trabaja desde el Sistema SOLMAN. El sistema SOLMAN tiene
instalado un servicio llamado saprouter, este servicio dirige las conexiones Asia los sistemas
satélites de LAFRANCOL (ERP y CONTINGENCIA). desde este sistema se realizarán
pruebas hacia la contingencia. Este saprouter también es utilizado por el proveedor SAP para
validar si tiene conexión a los sistemas satélite.
Figura 5-11: Conexión a los sistemas satélite de contingencia.
En la tercera ventana se abre una terminal en la que se tiene el SAP-RHEL. Desde SAP-
RHEL se realiza una prueba hacia la máquina de contingencia con un telnet a su IP
(10.244.1.44) desde el puerto 22 y se observa su conexión.
Figura 5-12: Conexión SAP-RHEL.
12
Se valida en la máquina de contingencia cual es el puerto que utiliza la aplicación. en este
caso el puerto es 3201.
Figura 5-13: Conexión SAP GUI máquina de contingencia.
Después se valida profile usando el comando cdpro para validar el puerto.
Figura 5-14: Validación profile máquina de contingencia.
Posterior a la validación de profiles se realizan unas pruebas hacia el puerto contingencia
desde SAP-RHEL. Puede que estas pruebas fallen ya que la aplicación no está arriba. Se
continúa realizando un telnet a la contingencia en el puerto 3201.
13
Figura 5-15: Prueba hacia máquina de contingencia desde sap-rhel.
Se tiene que garantizar que desde el sap-rhel (IP) se tenga habilitado el puerto 3201 de manera
bidireccional. Ahora se realiza la prueba desde el saprouter del sistema SOLMAN.
Figura 5-16: Información máquina SOLMAN desde línea base.
Con la información proporcionada en línea base se realiza la conexión al saprouter desde el
sistema SOLMAN.
Figura 5-17: Conexión saprouter desde SOLMAN.
14
Ahora se realiza un ping a las direcciones IP de la contingencia para validar su respuesta
desde el saprouter.
Figura 5-18: Validación alcance desde saprouter hacia contingencia.
Después se realiza un telnet a las IP de la contingencia desde el puerto 22 ssh con el que salta
el usuario entre maquinas a nivel de sistema operativo. que es el puerto; sé observa que
tampoco responde.
Figura 5-19: Validación alcance desde saprouter hacia contingencia puerto 22.
Posteriormente se realiza la misma prueba desde el puesto 3201 para validar su conexión.
15
Figura 5-20: Validación alcance desde saprouter hacia contingencia puerto 3201.
Desde el sistema SOLMAN no se encuentra alcance a la máquina de contingencia. Se
requiere que desde el servidor SRVSOL se tenga alcance a la maquina contingencia (IP) por
el puerto 22 y 3201.
Para la siguiente prueba se realiza una conexión desde la base de datos del sistema ERP
productivo para validar si se tiene alcance a la máquina de contingencia desde el usuario ssh
[email protected]. para poder conectarnos a la base de datos se realiza la validación de
la IP en línea base.
Figura 5-21: Información máquina ERP desde línea base.
Posteriormente se extraen las contraseñas de passman para ingresar al sistema ERP productivo.
Figura 5-22: Información de passman par sistema ERP productivo.
16
Figura 5-23: Ingreso al sistema ERP productivo desde terminal.
Se valida como esta guardado en el cat /etc /hosts de la contingencia.
Figura 5-24: validación IP contingencia desde sistema ERP productivo.
En la validación se puede observar que la contingencia esta guardada con la IP 10.182.1.28,
se realiza un telnet por el puerto 22 el cual muestra la conexión. La conexión en el puerto
3201 y 3200 no es realizada con éxito. IBM debe garantizar esa conexión para la prueba.
Figura 5-25: Conexión de la contingencia desde el puerto 22 desde sistema ERP.
17
Continuando con la validación se realiza el ingresando a la instancia central realizando un
telnet a la IP por el puerto 22.
Figura 5-26: Conexión a la instancia central desde terminal.
Figura 5-27: Validación conexión a la instancia central desde terminal.
5.2.1. ACTIVIDAD 2: Realizar pruebas de conexión desde LAFRANCOL CALI hacia
el servidor de contingencia.
La prueba número dos del plan de cambios consiste en realizar pruebas de conexión desde
LAFRANCOL CALI hacia el servidor de contingencia por los puertos SAP establecidos.
Para esta es necesario que LAFRANCOL asigne un recurso en CALI para realizar las pruebas
de conexión. En la Pruebas de los usuarios por conectarse a la IP de la contingencia.
18
La figura 5-28 muestra la evidencia que envía la persona encargada en Cali para realizar la
validación de la conexión. Esta validación se realiza con un ping a la IP 10.25.132.3 y un
tracert.
Figura 5-28: Validación conexión desde terminal a la contingencia.
La siguiente prueba se realiza desde IBM realizando la conexión al sistema productivo y
posteriormente se hace un ping a la IP 10.255.191.6 (IP Maquina de facturación electrónica)
para comprobar si funciona. Adicional a esta también se realiza un tracerout y un telnet por
el puerto 22 que es el puerto encargado de escuchar la comunicación desde el sistema ERP
productivo.
Prueba desde sistema ERP productivo:
En la Figuera 5-29 se puede visualizar que al realizar el ping a la máquina de LAFRANCOL
la comunicación se realiza con éxito ya que no tiene paquetes. Se realiza la traza la cual
funciona correctamente. Adicional a esto se realiza un telnet por el puerto 21 ya que la
información que envía SAP desde el sistema ERP productivo hacia ese servidor es
información por un protocolo de comunicación FTP cervices el cual utiliza este puerto.
19
Figura 5-29: Validación conexión desde sistema ERP a la máquina 10.255.191.6.
Prueba desde contingencia:
Posteriormente se realizo la misma prueba desde la máquina de la contingencia y se observa
que la conexión no se realiza de forma satisfactoria en ninguna de las dos pruebas (ping y
traceroute).
Figura 5-30: Validación conexión desde sistema ERP a la máquina 10.255.191.6.
20
Posterior a estas pruebas se realiza una solicitud a nivel de red para que se tenga conexión de
salida desde el servidor de contingencia hacia el servidor de facturación electrónica en
Lafrancol de marera bidireccional.
5.2.2. ACTIVIDAD 3: Verificación conectividad desde Calle 100 a Celta - máquina
contingencia.
Para realizar la verificación de la conectividad se realiza el ingreso a la maquina desde
sistema operativo. Para ello se abre una terminal y se realiza el ingreso con usuario de sap-
rhell. En la figura 5-31 y 5-32 se observa la validación.
Para realizar la validación se hace un telnet a la IP 10.244.1.44 que corresponde al sistema
ERP de la contingencia por el puerto 22(puerto ssh por donde se realiza la conexión desde
sistema operativo ya que es el puerto de administración).
Figura 5-31: Validación conexión desde Calle 100 a Celta - maquina contingencia desde puerto 22.
La prueba también es realizada en el puerto 3201(puerto por el que se establece la conexión
en SAP GUI) para este caso la conexión fue negada puesto que la contingencia no está
habilitada.
Figura 5-32: Validación conexión desde Calle 100 a Celta - maquina contingencia desde puerto 3201.
De esta manera se comprueba que se tiene acceso por los puertos de administración.
21
5.2.3. ACTIVIDAD 4: Verificación de actividad replica HADR en SAP. Toma de
evidencias.
Para realizar la validación se hace un ingreso por la terminal al sistema y se usa el comando
db2top para ver el estado de la réplica. En la figura 5-31 se observa que el roll en el que se
encuentre es de stanby y un estatus de conexión desde cuando esta activado para tomar y
replicar la información, se encuentra en un modo super Asynchonous ya que el nodo principal
está en calle 100 y el otro servidor se encuentra en celta ubicada a la salida de la calle 80.
Esta es la razón por la que se encuentra en este modo super Asynchonous. También se
observa información general como son los tiempos que tarde en escribir los logs entre otros.
Adicional a esto se observa la información del nodo primario (Hostname:db2lepbog) y el
nodo stanby (Hostname:db2lepcel). Para este caso el log que se está generando en el sistema
productivo es el S0242175.LOG. el log page va cambiando ya que los logs se van escribiendo
en la base de datos en páginas de 4k y esta replicando la información de forma síncrona del
nodo primario al stanby.
Figura 5-33: Validación replica HADR del nodo primario al stanby.
Del resultado de esta validación se puede concluir que nuestra replica HADR tiene una red
buena y un canal apropiado. En caso de tener una catástrofe se tiene segura la información
hasta ese instante.
22
5.2.4. ACTIVIDAD 5: Sincronización y backup de binarios PRD y CONTIGENCIA
(SRVLEP01 IP:10.182.1.28)
Para realizar la actividad se ingresa al sistema contingencia y al sistema productivo. Para ello
se usa SAP-RHEL como servidor de enrutamiento. El primer paso es validar la información
del sistema en línea base.
Figura 5-34: Validación sistema ERP desde línea base.
Para este caso la actividad inicia con el Sistema ERP productivo. La conexión se realiza con
el usuario LEDADM.
Figura 5-35: Extracción clave usuario LEDADM desde passman.
Figura 5-36: Ingreso sistema ERP productivo desde sistema operativo.
23
El paso para seguir es verificar todos los archivos que van a nivel de files.
Figura 5-37: Validación de archivos que van a nivel de files.
Después se valida el kernel del sistema ERP productivo, El cual se llevará a el sistema
contingencia. Usando el comando disp+work se encuentra que el sistema tiene un kernel
753 UNICODE y parche 401. Se realiza el mismo proceso en continencia (Figura 5-48).
Figura 5-38: Validación de el kernel para el sistema ERP productivo.
24
Ahora se valida la ruta donde están los archivos del sistema productivo con el comando cdexe
al igual que el sistema contingencia (Figura 5-47) y posterior a eso se realiza la copia entre
servidores. después de guardar la copia de exe en contingencia (Figura 5-49). Para ello vamos
a la ruta en el sistema productivo.
Figura 5-39: Validación de archivo exe desde sistema ERP productivo.
El paso para seguir es realizar la copia entre servidores para mover el archivo exe hacia la
contingencia. Antes de realizar esta actividad se realiza la validacion del tamaño del archivo.
Este archivo tiene un tamaño de tres gigas.
Figura 5-40: Validación del tamaño del archivo exe en sistema ERP productivo.
Ya realizada la validación del tamaño del archivo exe se indica la ubicación en donde se
quiere poner el archivo y con que usuario. Este debe ser el mismo con el que se logaron en
el sistema contingencia. Realizado este paso inicia el envió de la información.
25
Figura 5-41: Envió archivo exe de sistema productivo a contingencia.
Al culminar el traslado de los archivos se continua con la actividad.
Figura 5-42: finalización del traslado de los archivos exe de sistema productivo a contingencia.
Posterior al traslado de los archivos se realiza otra actividad que consiste en el cambio de
profile. Para ello primero se valida que profiles están en el sistema ERP productivo.
Figura 5-43: Validación profiles del sistema ERP productivo.
26
Ahora se realiza una copia de los profiles del sistema productivo usando el comando scp -rp
profile [email protected]:/sapmnt/LEP.
Figura 5-44: Copia de los profiles del sistema ERP productivo a sistema contingencia.
27
En paralelo se realizan las actividades propuestas en el sistema ERP desarrollo al sistema
Contingencia. Se hace el ingreso al sistema de la contingencia siguiendo los pasos avitualles.
Figura 5-45: Validación sistema contingencia desde línea base.
Se procede con la extracción de contraseñas para el ingreso con el usuario lepadm.
Figura 5-46: Validación usuario lepadm contingencia.
Figura 5-47: ingreso sistema contingencia.
28
En el sistema contingencia también se realiza la validación de kernel al igual que en el sistema
ERP productivo (Figura 5-38). Para este caso se tiene un kernel 722.
Figura 5-48: Validación kernel sistema contingencia.
Ahora se valida la ruta donde esta el kernel con el comando cdexe al igual que el sistema
productivo (Figura 5-39).
Figura 5-49: Validación ruta kernel desde contingencia.
Para enlistar los archivos se usa el comando ls -ltr.
29
Figura 5-50: Validación archivos kernel contingencia.
Ahora se realiza una copia al archivo exe el cual se remplazará por el archivo encontrado en
el sistema ERP productivo. Para realizar la copia se utiliza el comando mv exe y después se
coloca el nombre con el que se quiere guardar el archivo el cual quedara como respaldo.
Figura 5-51: Validación copia archivo exe en sistema contingencia.
En el sistema contingencia se crea la carpeta exe donde se están pasando los archivos del
sistema productivo para finalizar esta actividad.
Figura 5-52: creación carpeta exe con archivos provenientes del sistema ERP productivo.
30
En el sistema de contingencia se enlistan los profiles usando el comando df-gP para continuar
con la actividad faltante de este ítem.
Figura 5-53: Enlistar profiles del sistema contingencia.
Se realiza la validación de los profiles de contingencia los cuales se mostrarán en la siguiente
imagen.
Figura 5-54: Validación profiles sistema contingencia.
Continuando con la actividad se realiza el remplazo de los profiles del sistema ERP
productivo y se usa el comando mv profile profile.old para dejarlo como backup del file del
sistema contingencia.
Figura 5-55: Remplazo de los profiles del sistema ERP productivo a sistema contingencia.
31
Por último, se realiza la sincronización de los binarios.
Figura 5-56: Sincronización de los binarios en contingencia.
5.2.5. ACTIVIDAD 6: Agregar los siguientes espacios en el servidor de
CONTIGENCIA (SRVLEP01 IP:10.182.1.28).
Para iniciar esta prueba se debe tener en cuenta que el sistema ERP productivo es un sistema
distribuido donde la base de datos está en un host y la aplicación en otro. En el sistema de la
contingencia se tiene la base de datos y la aplicación en un mismo host. igualmente, con los
binarios de la aplicación. El paso para seguir es logarse en el host de la base de datos en el
sistema ERP productivo. Para realizar esta conexión nos dirigimos a PASSMAN para
solicitar las contraseñas y poder ingresar al sistema de manera satisfactoria.
Figura 5-57: Validación usuario contingencia.
Para ello se ingresa a la terminal y con el comando ssh db2lepqsrvlep02 ingresamos al
sistema y se enlistan los filesystem.
32
Figura 5-58: Validación profiles del sistema contingencia.
El paso para seguir es realizar la comparación entre el sistema ERP y la contingencia.
Figura 5-59: Validación sapdata del sistema ERP productivo.
33
Los filesystem almacenan la información de manera encriptada. Lo que se puede observar es
que los sapdata de la contingencia tienen espacios asignados diferentes al sistema productivo
e idealmente la contingencia debe contar con mayor capacidad ya que en caso de desastres
este realizara toda la generación de logs del sistema.
Para el caso de la contingencia se tiene la siguiente información:
Figura 5-60: Validación sapdata del sistema contingencia.
Posterior a la validación de los sapdata en los sistemas ERP productivo y sistema
contingencia se solicita Agregar los siguientes espacios en el servidor de CONTIGENCIA
(SRVLEP01 IP:10.182.1.28): /db2/LEP/sapdata1 -> 10GB; /db2/LEP/sapdata2 -> 10GB;
/db2/LEP/sapdata3 -> 10GB; /db2/LEP/sapdata4 -> 10GB ;/opt/IBM/ITM -> 5GB. Ahora se
realiza la validación de los logs que se están escribiendo en el sistema productivo con el
comando cd /db2/LEP/log_dir y posteriormente se enlista los file con el comando ls -ltr.
Figura 5-61: Validación de los logs que se escriben en /db2/LEP/log_dir.
34
Continuando con la actividad se realiza la validación del log que se está escribiendo en el
momento. Al realizar la validacion se observa el log que se esta escribiendo en ese instante
de tiempo.
Figura 5-62: Validación del log que se escribe en ese instante.
Para comprobar el log escrito vamos a db2top para validar que log se escribe actualmente
Figura 5-63: Validación del log que se escribe en ese instante en db2top.
Ahora se realiza la validación del ultimo log que fue recibido al sistema contingencia. Se
observa que el ultimo log enviado al sistema contingencia es el mismo que se evidencia en
el sistema productivo.
35
Figura 5-64: Validación del último log que se escribe en el sistema contingencia.
Cuando se recibe el log en contingencia este queda listo para ser aplicado a la base de datos.
Para el caso del siguiente filesystem también se requiere más espacio a la hora de realizar la
contingencia. Ya que al momento de realizar la prueba el sistema contingencia no solo
recibirá los logs para aplicar a la base de datos. En ese caso quedara como un sistema activo.
Figura 5-65: Validación de capacidades en el sistema productivo.
36
Por ello se solicita Agregar las 110 gigas faltantes en el servidor de CONTIGENCIA
(SRVLEP01 IP:10.182.1.28 en /db2/LEP/log_dir.
Figura 5-66: Validación de capacidades en el sistema contingencia.
37
5.3. FASE 3: Realización de pruebas de alta disponibilidad de la solución
de contingencia HADR durante la ventana del cambio.
Terminadas las actividades previas a la ventana se mostrará al cliente el funcionamiento del
esquema de HADR directamente en las máquinas de producción / contingencia. Y se
realizará la suspensión de la réplica HADR para tomar las evidencias. Posteriormente se
habilitará el entorno de contingencia: Base de datos / SAP y toma de evidencias. Estas
actividades incluyen la verificación de ambiente de contingencia y toma de evidencias de
estas. Para terminar esta fase se hará entrega e iniciará las pruebas por parte de ABBOTT
LAFRANCOL.
Figura 5-67: Actividades propias del cambio.
5.3.0. ACTIVIDAD 1: Verificación de sincronía entre ambiente PRODUCCIÓN y
CONTIGENCIA vía HADR.
Se realiza la toma de evidencia desde el nodo de producción y contingencia para validar que
los logs estén síncronos ingresando respectivamente a cada sistema con la transacción
db2top para continuar con las pruebas de alta disponibilidad.
Prueba desde el nodo producción:
Figura 5-68: Verificación sincronía contingencia desde sistema productivo.
38
Prueba desde el nodo contingencia:
Figura 5-69: Verificación sincronía contingencia desde sistema contingencia.
5.3.1. ACTIVIDAD 2: Suspensión de réplica HADR en ambiente producción. Toma de
evidencias.
Se realiza la detención en producción de la réplica Asia el sistema contingencia enviando el
comando db2 stop hadr on db LEP posteriormente se toma la evidencia. Tener en cuenta
la correcta conexión al sistema productivo(srvlep02) para realizar la detención de la réplica.
Figura 5-70: Suspensión de réplica HADR en ambiente producción.
Ahora se realiza la validación en el comando DB2STOP y se observa que el estatus de la
réplica. Se puede ver que el sistema ERP productivo ya no es parte del closter de HADR.
Figura 5-71: Validación suspensión de réplica HADR en ambiente producción.
39
Si se realiza la validación del db2stop desde el l nodo de contingencia se puede observar que
este es parte del nodo y dice que está desconectado ya que no está replicando.
Figura 5-72: Validación del db2stop desde el nodo de contingencia.
5.3.2. ACTIVIDAD 3: Habilitación de entorno de contingencia: Base de datos / SAP.
Toma de evidencias.
La primera prueba que se realiza es la ejecución del takeover en el ambiente del sistema
contingencia. La palabra TAKECOVER Se usa para abrir la conexión Asia la base de datos
de la contingencia, cuando se detiene la base de datos por otro motivo se utiliza un comando
diferente.
Figura 5-73: Ejecución del takeover en el ambiente del sistema contingencia.
Posterior a la ejecución del takeover se realiza la conexión a la base de datos db2lep en el
sistema contingencia. Para ello se realiza una conexión de prueba a la base de datos, para
validar la conexión se utiliza el /SID/LEP.
Figura 5-74: Conexión a la base de datos db2lep en el sistema contingencia.
40
Ahora se verifica la conexión de la base de datos en el ambiente del sistema contingencia. Se
ingresa al servidor srvlep01 y se realiza la validación usando el comando r3ttrans -d.
Figura 5-75: Validación conexión a la base de datos db2lep en el sistema contingencia.
Para confirmar el estado de la conexión de la base de datos se realiza la validación del
contenido del archivo usando el comando cat trans.log.
Figura 5-76: Validación contenido del archivo trans.log.
Se realiza el ingreso a la librería DIR para validar los valores establecidos y posterior a eso se enlista el contenido para
realizar la validación de la conexión nuevamente.
Figura 5-77: Validación de los valores establecidos a la librería DIR.
Nuevamente se realiza la validación de la conexión de la base de datos en el ambiente del sistema contingencia la cual
finaliza de forma satisfactoria.
Figura 5-78: Validación conexión a la base de datos db2lep en el sistema contingencia.
41
5.3.3. ACTIVIDAD 4: Verificación de ambiente de contingencia y Entrega e Inicio de
pruebas por parte de LAFRANCOL, Toma de evidencias.
La última actividad de esta etapa consiste en subir el sistema para habilitar el sistema
contingencia para que el cliente LAFRANCOL pueda realizar las pruebas respectivas. Para
habilitar la contingencia se utiliza el comando starsap R3.
Figura 5-79: Habilitar aplicación SAP en ambiente contingencia.
Después de subir el aplicativo SAP en el sistema contingencia se realiza la conexión a SAP
desde el aplicativo SAP GUI.
Figura 5-80: Conexión a SAP desde el aplicativo SAP GUI.
42
El sistema queda habilitado para que el cliente inicie las pruebas desde sus instalaciones en
Cali. A estas pruebas solo tiene acceso el cliente, por políticas de privacidad IBM no tiene
permitido interferir en esta etapa el proyecto y se continuara con la siguiente etapa cuando el
cliente indique la finalización de sus actividades.
43
5.4. FASE 4: Restauración del escenario de alta disponibilidad HADR,
documentación y socialización de resultados.
Por último, se realiza la restauración del escenario de alta disponibilidad HADR para dar por
finalizada la contingencia. Para ello se realizan diferentes tareas en un nuevo plan de cambios
donde se realiza la validación de FS /bk_replica y toma del backup a la cinta del sistema ERP
productivo. Se realizan las respectivas validaciones de espacios en el servidor de la
contingencia, canal de comunicación entre el sistema productivo y la contingencia, se
restaura backup proveniente de ERP PRD, se sube la base de datos (verificar consistencia –
funcionamiento). Para hacer entrega del sistema ERP desarrollo en su funcionamiento
habitual y garantizar la alta disponibilidad de los sistemas.
Figura 5-81: Plan de cambios restauración de alta disponibilidad.
5.4.0. ACTIVIDAD 1: Validación del FileSystem /bk_replica y progreso del backup.
Para realizar esta actividad se realiza el ingreso al sistema ERP productivo (Srvlep02) con el
usuario db2lep. En la imagen mostrada a continuación se muestran los comandos utilizados
para realizar la actividad. para ello se realiza un pwd para confirmar que estamos en el
filesystem /bk_replica, primero se lanza la copia de seguridad usando el comando Nohup
db2 backupdb lep online to /bk_replica compress without promting y luego se realiza
seguimiento de este. El comando nohup se utiliza para que el sistema no se cierre al momento
de hacer el backup como método de seguridad.
44
Figura 5-82: Backup del filesystem /bk_replica desde sistema ERP productivo.
para realizar seguimiento del backup se realiza la validación con el comando db2top opción
l el cual valida ese proceso en curso.
Figura 5-83: Seguimiento del backup desde sistema ERP productivo.
5.4.1. ACTIVIDAD 2: Copiar backup hacia contingencia ERP PRD.
Con el comando mkdir se crea un directorio para guardar el backup del sistema ERP
desarrollo y posterior a eso con el chmod se da permisos de lectura y escritura al directorio
creado previamente.
Con el comando mv se realiza el movimiento del backup en el directorio que se creó.
Después se valida que la copia de seguridad quedo guardado en el directorio este proceso es
realizado desde el sistema ERP productivo.
45
Figura 5-84: Movimiento del backup en el directorio creado.
Después de hacer el backup en el sistema ERP productivo se envia el directoria a la
contingencia.
Figura 5-85: Envió del directorio al sistema contingencia.
En el sistema contingencia también se realiza un backup antes de iniciar con la restauración
del sistema ERP productivo.
Figura 5-86: Backup previo a la restauración.
5.4.2. ACTIVIDAD 3: Restaurar backup proveniente de ERP PRD.
Para realizar la restauración del backup proveniente del sistema ERP productivo Se lanza el
comando de restauración nohup db2 RESTORE DATABASE.
46
Figura 5-87: Restauración del backup proveniente del sistema ERP productivo.
Para realizar el seguimiento del restore se valida con el comando db2top.
Figura 5-88: Validación ejecución restore.
5.4.3. ACTIVIDAD 4: Subir base de datos, verificar consistencia y Configuración
HADR para iniciar proceso de réplica.
Finalizado el restore Se sube la contingencia usando el comando db2 start hadr on db LEP
Figura 5-89: Subida de la Recuperación ante desastres de alta disponibilidad.
Se realiza el seguimiento a la memoria y gasto de recursos en el proceso mediante el comando
nmon. Adicional a esto la replica se activa usando el comando db2 start hadr.
Figura 5-90: Activación de la Recuperación ante desastres de alta disponibilidad.
47
Como ultima tarea de esta etapa de validación con el db2top opción a se realiza la validación
del estado da la réplica y su funcionamiento después de haber realizado el restore y activarla
recuperación ante desastres de alta disponibilidad.
Figura 5-91: Activación de la Recuperación ante desastres de alta disponibilidad.
48
6. Conclusiones y recomendaciones.
• La réplica HADR con la que se cuenta en IBM garantiza una buena red y un canal
apropiado, en caso de presentarse una catástrofe se tiene segura la información hasta
el ínstate en que ocurre el acontecimiento, ya que la sincronía de sus logs es de alta
precisión. Si se presenta una falla en la base de datos primaria las aplicaciones se
redirigen a la base de datos de la contingencia, la cual puede tomar el control del
sistema en segundos.
• Para evitar complicaciones al momento de activar la recuperación ante desastres de
alta disponibilidad (HADR), es necesario contar con la habilitación de la
comunicación entre todos los puertos que hacen parte de el procesamiento en tiempo
real de las capas que comprenden el sistema, las cuales incluyen su arquitectura
(Cliente), servidor de aplicación (SAP GUI) y base de datos (DB2) del servicio en
gestión.
• E En la administración SAP se requiere un buen plan de trabajo periódico y varias
actividades de validación del estado de los sistemas, actualización de componentes,
KERNEL, espacios de almacenamiento y demás para garantizar la disponibilidad y
buen funcionamiento de los sistemas al momento de realizar alguna actividad, los
cuales mitigan el riesgo en caso de algún desastre que ponga en riesgo la alta
disponibilidad.
49
Bibliografía
[1]. https://www.ibm.com/ibm/history/index.html
[2]. https://www.ibm.com/services/sap?mhsrc=ibmsearch_a&mhq=sap
[3]. https://www.sap.com/latinamerica/about.html
[4]. https://blogs.sap.com/2017/08/08/sap-business-one-disaster-recovery-plan-checklist/
[5]. https://yourlearning.ibm.com/#activity/IEC-10036573
[6]. https://www.ibm.com/analytics/es/es/technology/db2/index.html#db2-client-references
[7]. High Availability and Disaster Recovery Options for DB2 for Linux, UNIX, and
Windows.