Blog

AWS SAP Disaster Recovery: pasos iniciales

[fa icon="calendar"] 16/12/2016 por Equipo de Redacción Linke IT

Equipo de Redacción Linke IT

aws sap disaster recovery

Si hablamos de la implementación y la gestión del entorno SAP con Amazon Web Services hay distintos aspectos que suelen tener una presencia clave en nuestro día a día. Por ejemplo, se puede determinar que AWS SAP Disaster Recovery es una herramienta que siempre debemos tener en mente, porque nunca sabemos qué puede llegar a ocurrir en nuestro sistema. Se trata de un tema muy comentado y fundamental a la vista de la importancia que llega a tener la tecnología de SAP en el correcto funcionamiento de las empresas. 

Importancia de la Recuperación de desastres

Para que veamos la importancia que tiene la función DR en el entorno de SAP solo hay que prestar atención a las cifras que recientemente publicó la firma de análisis IDC en base a unos estudios que realizaron entre empresas del listado Fortune 1000. El resultado al que llegaron fue que por una hora de inactividad en una de estas empresas, la entidad puede llegar a perder entre 500 mil y 1 millón de dólares. ¿Os imagináis qué puede significar un corte de varias horas para una de estas compañías? Según estos datos de IDC, las caídas de recursos de SAP en estas empresas pueden tener costes anuales de entre 1,25 mil millones y 2,5 mil millones de dólares al año.

Por eso es imprescindible que en nuestra empresa estemos al tanto de cómo actuar ante una situación problemática para que el desastre y la caída duren el menor tiempo posible. Eso es lo que lleva a que se valore la integración de planes DR en cualquier entorno de SAP. Esto implicará que si el sistema general de una empresa sufre un desastre que lo deje sin funcionamiento, como puede ser cualquier suceso no controlable (un incendio, por ejemplo), el plan de Disaster Recovery permitirá que todo funcione con normalidad, con una pérdida de datos mínima y poco tiempo de espera.

La buena noticia es que hay muchos planes de DR que podemos tener en cuenta y que la tecnología en nube ha ido dándole cada vez más apoyo a este tipo de soporte. Lo único que tendremos que hacer será elegir una solución de recuperación de sistemas que nos permita estar tranquilos, pero que se ajuste a nuestros requerimientos y presupuesto.

 

Disaster Recover, ¿por dónde empezamos?

Este es un tema apasionante que nos va a llevar varios artículos explicar a fondo, dado que creemos que hay mucho que decir sobre la recuperación de desastres en SAP. No obstante, queremos comenzar con lo básico y fundamental en esta ocasión. Eso nos lleva a decir que, de base, lo que vamos a hacer es fijarnos en los entornos de producción.

No hay que olvidar que el entorno de SAP puede ser realmente enorme dependiendo de cómo lo tengamos desplegado en nuestra empresa. Hay nuchísimos parámetros repartidos en distintos servidores, así que lo primero que debemos tener en cuenta es que la recuperación de desastres tiene que concentrarse en el entorno de producción.

Eso es fundamental salvo en aquellas empresas en las que no les importe invertir mucho más para cubrir otros entornos, dado que el de producción es el más sensible. No es que no debamos cuidar los demás, pero es cierto que pocas empresas lo hacen debido a que los costes se multiplican de forma importante.

 

No descuidar ningún detalle

Por otro lado, la recuperación de sistemas no puede ser alternativa a que hagamos copias de los archivos de log de las bases de datos. Recordemos que la información que utiliza SAP está almacenada en las bases de datos, como MS-SQL y Oracle. Los logs nos ayudan de forma importante porque muestran los cambios que se realizan en las bases de datos y nos permiten, al ser enviados a un sistema de recuperación remoto que hayamos configurado, obtener la información necesaria para que podamos devolver el sistema a su plenitud.

En este aspecto, Amazon remarca la importancia de tener conocimientos de las dos técnicas principales de replicado de datos y recuperación:

  • Sincrónica: La base de datos que tengamos en nuestro sistema principal no será la responsable de llevar a cabo ninguno de los cambios. Lo que pasará es que se crearán dos sitios idénticos para garantizar el formalizado del proceso.
  • Asincrónica: En el caso de la asincrónica la página principal sí que actuará como núcleo y se ocupará de gestionar los cambios, que se enviarán al sistema de recuperación de desastres.

 

Si te ha interesado este post, quizás también te interese esta guía gratuita en PDF:

Guía de Pricing de SAP en AWS

Categorías: SAP AWS

¡Suscríbete al blog!

Linke SAP en AWS
Test Cloud Amazon SAP HANA
Descarga la guía: Todo lo que necesitas saber sobre SAP en AWS
Guia HD & DR para SAP en AWS