Sancor Seguros migró su Sistema SAP a AWS en 8 semanas

Por Mauro Auer, Líder de Infraestructura y Redes en Grupo Sancor Seguros

y Alexis Winer, Sr. Advisory Consultant para el Sector Público en AWS

y Leandro Santi, Arquitecto de Soluciones para el Sector Público en AWS

Grupo Sancor Seguros es un conjunto de empresas ubicadas en la ciudad de Sunchales (provincia de Santa Fé – Argentina) dedicado al mercado de seguros. Actualmente lidera el mercado asegurador argentino y brinda protección a más de siete millones de asegurados a través de sus subsidiarias en Argentina, Uruguay, Paraguay y Brasil. Conformada en el año 1945, Sancor Seguros es una entidad jurídica cooperativa independiente que se ha expandido en el rubro asegurador como así también hacia la industria de la medicina prepaga con la constitución de la sociedad controlada “Prevención Salud” y a la industria financiera con “Banco del Sol”.

En el año 2020, cuando la pandemia generada por el COVID-19 nos forzó a todos a trabajar desde casa, nuestro personal de IT del Grupo Sancor Seguros debía resolver el desafío de evolucionar sus ambientes SAP, buscando incrementar la disponibilidad y gobernabilidad de los mismos, sin descuidar la eficiencia en costos de la plataforma. Para ello, la empresa llevó adelante un proceso de selección de tecnología, y como resultado del mismo, se decidió migrar todos los ambientes SAP hacia AWS.

Desafíos

Durante la concepción del proyecto de migración de ambientes de SAP, identificamos algunos desafíos:

Proyectos concurrentes. La migración de ambientes debía ser realizada en paralelo con otros proyectos de gran visibilidad dentro del grupo: la segunda etapa del proyecto de implementación de SAP que incluía las funcionalidades de cobranzas, sumado al despliegue de los paquetes de soporte de SAP para mantener al día los componentes de software. Asimismo, se buscó reducir al mínimo la ventana de indisponibilidad de los ambientes de SAP.

Ventana de tiempo acotada y multiplicidad de entornos. Por las ventanas de implementación de los proyectos concurrentes mencionados y adicionales restricciones contractuales del proveedor anterior, la migración debía hacerse dentro de una cantidad de tiempo acotada, en un lapso máximo de 3 meses, a lo largo de 7 entornos con más de 25 servidores involucrados de manera directa en el proceso de migración.

Diversidad de ambientes. Los ambientes originales corrían sobre infraestructura basada en diferentes versiones y variantes de Linux (Red Hat Enterprise Linux RHEL/SUSE). Con el objeto de unificar y simplificar la gestión de IT, la nueva plataforma debía implementar una versión de RHEL vigente a lo largo de todos los ambientes.

Agilidad en las interacciones. Buscamos un proveedor que nos permitiera adoptar mecanismos de interacción ágiles y así poder reducir tiempos en la toma de decisiones y en la implementación de cambios. Por ejemplo, contar con la posibilidad de integrar recursos especializados del equipo de Servicios Profesionales de AWS y de nuestro partner con la especialidad en SAP, agregar equipos en los ambientes o modificar los recursos asignados a algunos de ellos.

Acuerdo de nivel de servicios. Encontramos en la propuesta de AWS la posibilidad de desplegar todos los ambientes de SAP basados en servicios de nube con niveles de SLA bien definidos como Amazon EC2, Amazon S3 y Amazon Site-to-Site VPN, entre otros.

Performance de la interconexión datacenter-nube. Habíamos tenido una experiencia previa en donde la performance de la interconexión con la infraestructura de nube (en términos de latencia y ancho de banda contra la región) no permitió adoptar este escenario. Si bien todos los ambientes de SAP ya se encontraban en una nube, necesitábamos validar que la interconexión con la nube de AWS no generara un problema.

Esquema de recuperación ante desastres. La plataforma de origen no contaba con un esquema definido para recuperación ante desastres, debido entre otras cosas a los altos costos asociados de duplicar la infraestructura de servidores en la plataforma que nos brindaba el servicio. Encontramos en la propuesta de AWS una alternativa que resultó novedosa, y al final del día permitió implementar un esquema de recuperación ante desastres con un buen equilibro entre bajos costos y performance (Recovery Point Objective – RPO tendiendo a cero con un bajo Recovery Time Objective – RTO) gracias a una arquitectura de tipo «pilot light«.

Manos a la obra

Durante la etapa de evaluación del proyecto trabajamos con el equipo de AWS realizando pruebas de conectividad entre nuestros datacenters y la nube haciendo uso de la infraestructura de borde que AWS posee en Argentina. Al activar AWS Global Accelerator nos fue posible enrutar el tráfico de la VPN hacia la ubicación de borde más cercana a nuestros datacenter: de esta manera logramos optimizar el camino de red de la conexión, permitiendo que nuestro tráfico de la VPN ingrese a AWS con una menor cantidad de saltos, usando tráfico nacional en lugar de tráfico internacional.

Fig. 1: cantidad total de saltos (hops) conexión VPN normal vs. VPN acelerada.

Como puede verse en la figura 1, activar la aceleración de la VPN contra nuestro datacenter permitió reducir la cantidad de saltos entre ambos extremos de terminación del túnel, optimizando el ruteo de los datagramas gracias a que los mismos ingresan a la red de AWS con menor cantidad de saltos, enrutando hacia la región con un camino libre de congestión para lograr una mejor performance para nuestras aplicaciones. También se pudo comprobar que las velocidades de transferencia hacia la nube se incrementaron 2.5 veces, combinando las optimizaciones en el acceso a la nube (reducción en la cantidad de saltos) con el uso de tráfico nacional en lugar de tráfico internacional.

NB: para mayor información sobre el impacto de AWS Global Accelerator en la performance de la interconexión, puede visitar el blog post «Achieve up to 60% better performance for internet traffic with AWS Global Accelerator» y «Measuring AWS Global Accelerator performance and analyzing results«.

Comienza la migración

El proyecto de implementación comenzó en los últimos días de diciembre 2020. El equipo de Servicios Profesionales de AWS (ProServe) fue responsable de liderar el proyecto incorporando a los partners de AWS Seidor y Moebius que tienen la especialidad de SAP. El equipo de AWS ProServe desplegó inicialmente AWS Control Tower para crear una estructura de gobierno multi-cuenta, integrándola con los datacenter del grupo mediante Site-to-Site VPN utilizando Global Accelerator para realizar la terminación del túnel de la VPN utilizando la infraestructura de borde que AWS posee en el territorio de la Argentina.

La arquitectura para el esquema de recuperación ante desastres fue propuesta por el equipo experto de ProServe SAP en base a un esquema de replicación híbrido, teniendo en cuenta las necesidades planteadas por el negocio:

• Replicación nativa sincrónica para SAP HANA-DB sin carga en memoria (preload) de datos en la instancia secundaria, adoptando un esquema de tipo “pilot light” para la optimización de los costos que permite que la instancia que realiza la replicación de HANA tenga menor tamaño y costo que su contraparte de producción (en nuestro caso, ¼ del tamaño), permitiendo así replicar los datos en forma continua sin que esto genere una duplicación de los costos de infraestructura para la base de datos.
• Replicación del resto de los equipos del landscape mediante la herramienta CloudEndure Disaster Recovery, que implementa un esquema de replicación continua para los datos de los discos de los servidores, permitiendo replicar los cambios a nivel de bloques en segundos y (cuando sea necesario) desplegar toda la infraestructura en el sitio de recuperación ante desastres en pocos minutos, sin el costo de mantener instancias EC2 encendidas durante la operación normal. Para la solución de CloudEndure sólo se utilizan instancias económicas (1 instancia de tipo t2 por cada 10 volúmenes replicados) y discos magnéticos de bajo costo.

Fig. 2: arquitectura de disaster recovery para el ambiente SAP PROD (pilot-light):

replicación de storage mediante CloudEndure, replicación nativa HANA-DB.

En el diagrama de arquitectura de la figura 2 podemos ver que el sitio de recuperación ante desastres fue implementado en una zona de disponibilidad dedicada dentro de la misma región, buscando por un lado minimizar los costos de replicación y transferencia de datos, y por el otro contar con una baja latencia entre el sitio principal y el secundario (típicamente en el orden de 1 a 2 milisegundos), permitiendo el uso de un esquema de replicación sincrónica para el motor de la base de datos.

De esta manera, la arquitectura permite lograr un equilibrio entre los tiempos de recuperación ante desastres (RPO tendiendo a cero, bajo RTO) y costos, gracias a que en el sitio secundario para recuperación ante desastres sólo fue necesario desplegar 1 servidor de tipo t2 con los volúmenes magnéticos de las instancias de aplicación (sin desplegar el plano de cómputo, que sólo se activa ante la contingencia), y una instancia para la base de datos HANA de ¼ del tamaño del original productivo (y por lo tanto, ¼ parte del costo para este componente).

Los ambientes fueron migrados siguiendo un esquema concurrente detallado en la figura 3:

Fig. 3: plan de alto nivel. Aquí podemos ver el trabajo en paralelo de los diferentes tracks de la migración,

buscando completar la puesta en marcha del ambiente productivo antes del deadline contractual.

Como podemos ver en este diagrama, los trabajos de implementación comenzaron con un ambiente de PILOTO, el cual tiene características similares al ambiente de producción (PROD). En el mismo se hicieron todas las configuraciones iniciales, pruebas, capacitaciones, culminando con dos pruebas finales end-to-end para aplicar los mecanismos de contingencia ante desastres (mediante actividades de simulacro o gamedays). En los mismos se ejecutaron transacciones sobre las instancias de contingencia y, tras realizar la vuelta hacia atrás también se validó que los cambios realizados en contingencia fueran replicados correctamente. A lo largo de este proceso, pudimos realizar los ajustes necesarios en los procedimientos (playbooks), documentando los tiempos de referencia obtenidos en dichos procesos para dejarlos a disposición de la compañía ante un eventual pedido de auditoría. El proceso de validación contribuyó también a identificar los equipos que deben estar involucrados durante una contingencia e identificar las acciones requeridas por cada uno.

Adicionalmente, y aunque no figura en este plan ya que se trataba de un proyecto paralelo, mientras se iban desplegando los ambientes subsiguientes (DEV, QA, PREPROD), pudimos utilizar dicho entorno PILOTO para el proyecto de actualización de Support Packages, que corría en paralelo al proyecto de migración. Este segundo proyecto, que no presentó inconvenientes, nos permitió aterrizar en AWS con SAP actualizado.

Este proceso de implementación -que comenzó en los últimos días de diciembre 2020- fue completado hacia la segunda semana de febrero 2021, es decir, una semana antes de lo previsto. Esto permitió que la empresa no necesite renovar el contrato de mantenimiento para la infraestructura original de SAP, reemplazándolo por un esquema con mayores prestaciones para el negocio.

Resultados

La migración exitosa de los ambientes de SAP del grupo permitió reducir en un 60% los costos totales de mantenimiento a lo largo de un plazo de 3 años, gracias a la combinación de un esquema de contratación flexible sumado a los programas que AWS posee para migrar cargas de trabajo basadas en SAP. Asimismo, se logró mejorar el esquema de continuidad de negocio mediante la adopción de una arquitectura de tipo «pilot light», logrando un buen equilibrio entre costos y prestaciones (RPO tendiendo a cero, bajo RTO), control y visibilidad total para el equipo de Sancor sobre nuestra plataforma SAP. Por último, durante los proyectos de migración y actualización de support packages, pudimos experimentar la agilidad de provisión de nuevos entornos, que pasaron de casi un mes en la plataforma anterior a horas en el nuevo esquema.

Próximos pasos

La implementación de esta arquitectura híbrida combinada con las capacidades de gobierno permitirá encarar la siguiente etapa de implementación de nueva funcionalidad para el proyecto de evolución de SAP (etapa 3 del proyecto) con mayor agilidad y predictibilidad para el negocio de la empresa.

Sobre los autores

Mauro Auer es Líder de Infraestructura y Redes en Grupo Sancor Seguros

Alexis Winer es Sr. Advisory Consultant para el Sector Público en AWS

Leandro Santi es Arquitecto de Soluciones para el Sector Público en AWS