El siguiente artículo está orientado a explicar cómo debemos organizarnos de cara a una implementación de SAP en Azure, desde el punto de vista de infraestructura, y en él trataré de dar algunos tips que en base a mis recientes experiencias considero que pueden ser interesantes para alguien que se enfrenta a una implantación de este tipo por primera vez. No queremos adentrarnos en el funcionamiento o la instalación del propio SAP, sino analizarlo desde el punto de vista de arquitectura en Azure.

SAP

SAP SE es una empresa alemana de aplicaciones empresariales, una de las más importantes del sector a nivel mundial.

Sus principales líneas de software son:

·       ERP (Planificación de Recursos Empresariales) para finanzas y gestión de la tesorería.

·       CRM (Administración de Relaciones con Cliente) y experiencias de cliente.

·       Analíticas.

En este artículo nos vamos a centrar en los requisitos específicos de la arquitectura necesaria para usar SAP S/4HANA, el cual estaría dentro de la categoría de ERP.

Arquitecturas SAP en Azure:

Montar un SAP en Azure nos ofrece todas las ventajas operacionales, de almacenamiento, flexibilidad, automatización, seguridad, costes, etc. de los que ya nos tienen acostumbrados los proveedores cloud.

En las siguientes líneas os mostraré una instalación Greenfield en IaaS (infraestructure as a service) de SAP S/4 HANA, por tanto, quedarán fuera del mismo cualquier opción de SAP en SaaS de Azure, en el propio cloud de SAP, herramientas de migración, etc. Este tipo de implantaciones son a priori más interesantes ya que puedes definir toda la arquitectura desde cero, aunque se pierde la capacidad de analizar la volumetría de los entornos existentes, lo cual nos ayudaría de un primer vistazo para establecer una relación de la cantidad de equipos que se van a necesitar y el tamaño de estos, tal como tendríamos en una instalación del tipo brownfield, pero nos brinda la posibilidad de trabajar sobre un lienzo en blanco.

Las principales recomendaciones de Microsoft, a alto nivel, para una arquitectura de SAP S/4 HANA en Azure son las siguientes:

-        Tener nuestro entorno replicado en dos regiones de Azure. Esto nos permitirá tener nuestro entorno totalmente redundado y que en caso de desastre podamos realizar una rápida recuperación del servicio.

-        Dentro de cada región también tendremos que tomar ciertas consideraciones para garantizar que nuestro servicio tenga la mayor disponibilidad posible; Azure nos garantiza ciertos SLA (Service Level Agreement) para cada tipo de recursos, tomando en cuenta todas las recomendaciones podemos hacer los entornos más seguros y ampliar el SLA inicial como os muestro a continuación:

• 99,9% de SLA en máquinas virtuales.
• 99,95% de SLA si añadimos una segunda máquina virtual en otro Availability Set de la misma región.
• 99,99% de SLA si añadimos en una segunda región una réplica completa de nuestro entorno.

-        Otra de las principales recomendaciones a alto nivel que nos encontramos en Azure es que cada entorno está aislado en una suscripción, lo cual nos permite un aislamiento de permisos que nos da un extra de seguridad. Si por ejemplo delegamos la administración del entorno de desarrollo de nuestra plataforma a una empresa para que nos mantenga los aplicativos, esta solo tendrá acceso a ese entorno y no podrá romper nada por error en los entornos productivos.

-        Para las instalaciones de SAP donde la velocidad es una de las mayores prioridades, nos recomiendan el uso de PPG (proximity placement group), lo cual establece un grupo de proximidad y permite reducir la latencia entre todos los servidores que incluyamos dentro de él. Se trata de una agrupación lógica que se usa para asegurarse de que los recursos de Azure que instalamos se encuentran físicamente cercanos entre sí.

Os dejo un esquema a alto nivel de cómo quedaría un entorno típico de SAP según las best practices de Microsoft y SAP:

Detalle de la arquitectura de la región primaria:

Una vez visto una arquitectura en dos zonas a alto nivel, os enseño un plano de arquitectura detallado de cómo debe ser una de las regiones. Para construir la región secundaria únicamente debemos duplicar esta:

HUB:

En esta suscripción deberíamos incluir todos los elementos de interconexión entre entornos, los equipos de salto (bastión), así como todos los elementos que sean comunes o que puedan usar otros componentes dentro de cualquiera de los Spokes (Directorio Activo, Almacenamiento compartido, etc).

En la suscripción de HUB también deberíamos instalar un firewall que nos proporcionará tanto un nivel extra de seguridad, como un elemento de interconexión para comunicar todos los Spokes con el HUB.

Por último, en la suscripción de HUB colocaríamos el VNP Gateway, el cual nos permitirá conectar nuestro on-premise con Azure, mediante Express Route o conexión de VPN tradicional.

Spokes:

Cada Spoke tiene distinto número de servidores. Entendemos que para un entorno de desarrollo no necesitaríamos alta disponibilidad y no tenemos tampoco porque instalar el paquete completo de componentes de SAP. Por ejemplo, puede que no queramos instalar SAP FIORI o SAP Process Orchestration, o que únicamente nos interese tener estos componentes en producción, pero no en los entornos inferiores. Por lo que el número de servidores por entorno se puede simplificar.

Sistemas Operativos:

Otro punto a tener en cuenta es el sistema operativo que vamos a elegir para montar los servidores que veíamos antes. Por motivos de compatibilidad entre componentes, certificaciones de SAP e integraciones con otras herramientas, es recomendable que todos los equipos tengan el mismo sistema operativo. Teniendo en cuenta esto, es muy recomendable que se monte sobre un sistema SUSE o Red Hat, ya que SAP HANA solo está soportado para las distribuciones de esos sistemas operativos. Dentro del Marketplace de Azure encontramos un gran abanico de imágenes posibles e incluso algunas de estas imágenes ya vienen optimizadas para SAP o con ciertos paquetes de SAP preinstalados, que nos ayudarán en la instalación y configuración del software. En una instalación reciente llevada a cabo, elegimos estas imágenes para nuestra instalación.

Servidores SAP HANA: SUSE Enterprise Linux for SAP 15 +24x7 Support

Resto de servidores: SUSE Linux Enterprise Server (SLES) 15 SP2 with 24x7 Integrated Support

Ambas imágenes tienen un modelo de licenciamiento de dichos sistemas operativos en formato Pay As You Go, integrado en los servicios de Azure. Pero también están disponibles en la modalidad BYOS (bring your own subscription).

Size de servidores:

Los servidores SAP deben cumplir con un estricto tamaño en lo que a RAM, CPU y Disco se refiere para conseguir la certificación de SAP, es decir, debemos ser muy escrupulosos a la hora de elegir el tamaño de nuestros servidores, especialmente los SAP HANA y sus requisitos mínimos para asegurarnos de que los productos de SAP van a correr en condiciones óptimas, y de esta manera garantizar que en el caso de encontrarnos con algún problema no sea de rendimiento de los equipos y SAP nos atienda y ayude a resolver el mismo.

Para ello, tanto Microsoft como SAP tienen páginas de referencia donde encontraremos los datos necesarios para poder tener la garantía de que estamos eligiendo el tamaño correcto para nuestros servidores:

Microsoft: Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA - Azure Virtual Machines | Microsoft Docs

SAP: Certified and Supported SAP HANA® Hardware Directory

A modo de simplificación podemos decir que la recomendación es usar tamaños DS y E para entornos no productivos y tamaños M para producción.

Discos:

Los discos es uno de los aspectos más importantes a tener en cuenta a la hora de montar una base de datos SAP HANA, ya que requiere que la escritura en disco sea lo más ágil posible. Para logar esto Microsoft nos recomienda elegir discos pequeños y combinarlos en RAID 0 hasta lograr el almacenamiento que deseamos.

Nosotros siempre vamos a pensar en el tamaño total de disco que queremos en nuestro servidor, pero para que SAP certifique nuestros equipos, debemos cumplir con un determinado IOPS (Inputs Outputs Per Second) y para lograr tanto la velocidad de lectura y escritura, como el tamaño deseado, la recomendación es el uso de un número determinado de discos de un tamaño menor, que todos combinados en RAID 0 nos permitan alcanzar tanto la velocidad como el tamaño del almacenamiento que necesitamos.

Si volvemos a la web que os mostraba antes, vemos una serie de tablas donde nos recomiendan tanto el size de los equipos como la configuración de los discos:

En este ejemplo tendríamos que seleccionar 4 discos Premium de tipo P6 (64 Gb cada uno) para el /hana/data.

Backup:

Como cualquier otra aplicación, el backup en SAP también algo fundamental. Desde finales de 2020 Azure Back se ha integrado con SAP HANA y se ha convertido en la solución de copia de seguridad nativa y cuenta con la certificación BackInt de SAP. Esta integración con Azure Backup hace que sea muy fácil de usar, ya que no difiere de cómo planificaríamos cualquier otro backup dentro de dicha herramienta para una máquina virtual, Azure Files o el resto de backups nativos que nos ofrece:

Tras seleccionar SAP HANA, si hemos configurado correctamente nuestra máquina virtual y creado los usuarios pertinentes dentro de la BBDD, el sistema automáticamente tendrá visibilidad de la BBDD y pasaremos a configurar las políticas de nuestro backup:

A modo de conclusión, y aunque el mundo SAP es mucho más extenso, esta es una pequeña muestra sobre las lecciones aprendidas a partir de nuestras recientes experiencias y algunos de los consejos que el personal de Microsoft con los que hemos trabajado nos han dado.

Autor del artículo

David Martínez Bonaque, senior specialist de Consultoría Tecnológica de Deloitte