Ejecución de SAP BW/4HANA con máquinas virtuales Linux en Azure

Bastion
Managed Disks
Virtual Machines
Virtual Network
SAP HANA en Azure (instancias grandes)

El ejemplo siguiente se centra específicamente en la capa de la aplicación SAP BW/4HANA. Es idónea para un entorno de producción a pequeña escala de SAP BW/4HANA en Azure donde lo prioritario es que haya una alta disponibilidad.

Arquitectura

La arquitectura de referencia muestra un conjunto de procedimientos probados para ejecutar SAP HANA en un entorno de alta disponibilidad y escalabilidad vertical que admita recuperación ante desastres en Azure.

Componentes

Esta arquitectura utiliza las siguientes tecnologías:

  • Azure Virtual Network (VNet) conecta los recursos de Azure entre sí y a un entorno local de forma segura. En esta arquitectura, se emparejan varias redes virtuales.

  • Se utilizan máquinas virtuales Linux para la capa de la aplicación, lo que incluye:

    • El grupo de servidores de SAP BusinessObjects (BOBJ).
    • El grupo de SAP Web Dispatcher.
    • El grupo de servidores de aplicaciones.
    • El clúster de SAP Central Services.
  • Los conjuntos de disponibilidad agrupan dos o más máquinas virtuales en clústeres de hosts de Azure para lograr una alta disponibilidad y un Acuerdo de Nivel de Servicio más elevado.

  • Las zonas de disponibilidad mejoran la disponibilidad de la carga de trabajo al distribuirse sus servidores entre más de un centro de datos en una región de Azure.

  • Los equilibradores de carga dirigen el tráfico a las máquinas virtuales de la subred de aplicaciones. Para lograr una alta disponibilidad, en este ejemplo se usa SAP Web Dispatcher y Azure Standard Load Balancer. Estos dos servicios también admiten la extensión de capacidad mediante el escalado horizontal, aunque se puede usar asimismo Azure Application Gateway u otros productos de asociados, según el tipo de tráfico y la funcionalidad que necesite, como la terminación y el reenvío de Capa de sockets seguros (SSL).

  • Los grupos de seguridad de red están asociados a una subred o a las tarjetas de interfaz de red de una máquina virtual. Se utilizan grupos de seguridad de red para restringir el tráfico entrante, saliente y dentro de la subred de la red virtual.

  • Azure Bastion proporciona acceso seguro mediante Azure Portal a las máquinas virtuales que se ejecutan en Azure, sin utilizar un jumpbox y su dirección IP pública asociada. Este mecanismo limita la exposición a Internet.

  • Azure Managed Disks. Se recomiendan los discos de almacenamiento Premium o Ultra. Estos tipos de almacenamiento proporcionan persistencia de datos para las máquinas virtuales con la carga de trabajo de SAP.

  • Azure NetApp Files admite almacenamiento compartido cuando se utiliza un clúster. También admite almacenamiento compartido cuando se necesita un almacenamiento de alto rendimiento que pueda hospedar archivos de datos y de registro de SAP HANA. Azure NetApp Files está totalmente administrado y es lo suficientemente escalable como para satisfacer las peticiones de la mayoría de las aplicaciones. Proporciona un rendimiento sin sistema operativo, latencia inferior a milisegundos y administración de datos integrada para las cargas de trabajo empresariales complejas en:

    • SAP HANA.
    • Informática de alto rendimiento.
    • Aplicaciones de línea de negocio.
    • Recursos compartidos de archivos de alto rendimiento.
    • Infraestructura de escritorio virtual.
  • Power BI permite a los usuarios acceder a los datos de SAP BW/4HANA, y visualizarlos, desde el escritorio de Windows. La instalación requiere el conector de SAP BW (implementación 2.0).

    Microsoft Power BI Desktop importa datos de diversos orígenes de SAP, como SAP BW/4HANA, para su análisis y visualización. También Power BI sirve de complemento al universo de SAP BusinessObjects al ofrecer un contexto empresarial o una capa semántica sobre la información sin procesar.

  • Azure Backup es una solución de protección de datos con certificación de SAP Backint para SAP HANA en implementaciones de instancia única y de escala vertical. Azure Backup también protege a las máquinas virtuales de Azure con cargas de trabajo generales.

  • Azure Site Recovery se recomienda como parte de una solución de recuperación ante desastres automatizada para la implementación de una aplicación de SAP NetWeaver de varios niveles. En la matriz de compatibilidad se detallan las funcionalidades y restricciones de esta solución.

Alternativas

  • Para ayudar a proteger los archivos del host global de SAP en SAP Central Services y el directorio de transporte de SAP, puede implementar servidores Network File System (NFS) en una configuración de clúster de conmutación por error.

  • SIOS Protection Suite, disponible en Azure Marketplace, se puede usar para proteger los archivos de host global de Central Services en lugar de NFS o Azure NetApp Files.

  • Azure Application Gateway es un equilibrador de carga del tráfico web. En un único servicio, proporciona terminación de SSL, un servicio Web Application Firewall (WAF) y otras características prácticas de alta disponibilidad y escalabilidad. En algunas implementaciones de SAP se ha usado como puerta de enlace para el front-end de SAP Fiori en su entorno de producción.

Detalles del escenario

SAP BW/4HANA es una solución de almacenamiento de datos empresariales diseñada para la nube y optimizada para la plataforma SAP HANA. El ejemplo siguiente se centra específicamente en la capa de la aplicación SAP BW/4HANA. Es idónea para un entorno de producción a pequeña escala de SAP BW/4HANA en Azure donde lo prioritario es que haya una alta disponibilidad.

Esta carga de trabajo de ejemplo también aprovecha la base de dos arquitecturas de referencia de SAP en Azure: SAP NetWeaver (Windows) para AnyDB en máquinas virtuales y SAP S/4HANA para máquinas virtuales Linux en Azure. Se utiliza un enfoque de implementación similar para las cargas de trabajo de SAP BW/4HANA. La capa de la aplicación se implementa mediante máquinas virtuales que se pueden cambiar de tamaño para adaptarse a las necesidades de su organización.

El diseño de red se ha simplificado para mostrar los principios de arquitectura recomendados para una implementación empresarial de Azure basada en una topología de red en estrella tipo hub-and-spoke.

Nota

Al implementar cargas de SAP en Azure, son muchos los aspectos de implementación que se deben tener en cuenta. Puede encontrar más ideas e información adicional en la lista de comprobación de planeamiento e implementación de SAP en Azure.

Para más información sobre la capa de persistencia de datos, consulte:

Posibles casos de uso

Este escenario es pertinente para los casos de uso siguientes:

  • Implementación de la capa de aplicación de SAP separada de la capa de DBMS

  • Escenarios de recuperación ante desastres (DR)

  • Implementaciones de la capa de aplicación de SAP

Recomendaciones

Esta arquitectura está diseñada para lograr alta disponibilidad, escalabilidad y resistencia. Para obtener los mejores resultados en Azure, tenga en cuenta las recomendaciones de esta sección. Además, muchas de las recomendaciones sobre la ejecución de SAP S/4HANA en Azure también se aplican a las implementaciones de SAP BW/4HANA. Para más información sobre SAP S/4HANA en Azure, consulte la arquitectura de referencia.

Máquinas virtuales

Para obtener información sobre la compatibilidad de SAP tanto con los tipos de máquina virtual de Azure como con las métricas de rendimiento (SAPS), consulte la nota de SAP 1928533, en la que se explican las aplicaciones de SAP en Azure: los productos y los tipos de máquina virtual de Azure compatibles (para acceder a esta y otras notas de SAP, se requiere una cuenta de SAP Service Marketplace).

Para saber si un tipo de máquina virtual se ha certificado para implementaciones de escala horizontal de SAP HANA, consulte la columna Scale-out (Escalabilidad horizontal) en el directorio de hardware de SAP HANA.

Grupo de servidores de aplicaciones

En el grupo de servidores de aplicaciones, puede ajustar el número de máquinas virtuales según sus requisitos. Azure está certificado para ejecutar SAP BW/4HANA en Red Hat Enterprise Linux y SUSE Linux Enterprise.

Para administrar los grupos de inicio de sesión de los servidores de aplicaciones ABAP, es habitual usar la transacción SMLG para equilibrar la carga de diferentes grupos como:

  • Usuarios de inicio de sesión.
  • SM61 para grupos de servidores por lotes.
  • RZ12 para grupos RFC.

Estas transacciones utilizan la funcionalidad de equilibrio de carga en el servidor de mensajes de Central Services para distribuir las sesiones entrantes o la carga de trabajo entre el grupo de servidores de aplicaciones de SAP para SAPGUI y el tráfico de RFC.

Clúster de SAP Central Services

En este ejemplo se muestra un clúster de alta disponibilidad que utiliza Azure NetApp Files como solución de almacenamiento de archivos compartidos. La alta disponibilidad para el clúster de Central Services requiere un almacenamiento compartido. Azure NetApp Files proporciona una opción sencilla de alta disponibilidad para que no tenga que implementar ninguna infraestructura de clústeres de Linux. Una alternativa consiste en configurar un servicio NFS de alta disponibilidad.

También puede implementar Central Services en una sola máquina virtual con discos administrados Premium y obtener un Acuerdo de Nivel de Servicio del 99,9 % de disponibilidad.

Las máquinas virtuales que se usan para los servidores de aplicaciones admiten varias direcciones IP por NIC. Esta característica admite la práctica recomendada de SAP de usar nombres de host virtual en las instalaciones, como se describe en la nota de SAP 962955. Los nombres de host virtual desacoplan los servicios de SAP de los nombres de host físico y facilitan la migración de los servicios de un host físico a otro. Este principio también se aplica a las máquinas virtuales en la nube.

Los servidores de aplicaciones se conectan a los servicios de Central Services de alta disponibilidad mediante los nombres de host virtual de los servicios de Central Services o de ERS. Estos nombres de host se asignan a la configuración IP de front-end del clúster del equilibrador de carga. Un equilibrador de carga admite varias direcciones IP de front-end. Se pueden enlazar las direcciones IP virtuales tanto de Central Services como las de ERS a un único equilibrador de carga.

Instalación de varios identificadores de seguridad (SID)

Azure también admite alta disponibilidad en una instalación de varios SID de los clústeres de Linux y Windows que hospedan Central Services (ASCS/SCS). Para más información sobre la implementación en un clúster de Pacemaker, consulte la documentación sobre varios SID de Azure para:

Grupos de selección de ubicación de proximidad

En esta arquitectura de ejemplo también se usa un grupo con ubicación por proximidad para reducir la latencia de red entre las máquinas virtuales. Este tipo de grupo coloca una restricción de ubicación en las implementaciones de máquina virtual y minimiza la distancia física entre ellas. La selección de ubicación del grupo varía como se indica a continuación:

  • En una instalación con un único SID, se deben colocar todos los servicios centrales y servidores de aplicaciones en el grupo con ubicación por proximidad delimitado mediante la base de datos de SAP HANA.

  • En una instalación de varios SID, tiene la libertad de asociar Central Services y servidores de aplicaciones a cualquier grupo con ubicación por proximidad único que esté delimitado por contenedores SAP HANA de distintos SID.

Base de datos

SAP BW/4HANA está diseñado para la plataforma de base de datos de SAP HANA. Azure proporciona tres opciones de escalabilidad e implementación:

Storage

En este ejemplo se utilizan discos administrados Premium para el almacenamiento no compartido de los servidores de aplicaciones. También se utiliza Azure NetApp Files para el almacenamiento compartido de clúster.

No se admiten discos administrados estándar, como se indica en la Nota de SAP 1928533. No se recomienda el uso de almacenamiento estándar para las instalaciones de SAP.

Para el almacén de datos de copia de seguridad, se recomienda usar los niveles de almacenamiento de acceso esporádico y de archivo de Azure. Estos niveles de almacenamiento son formas rentables de almacenamiento de datos de larga duración a los que se accede con poca frecuencia.

Redes

Aunque no es obligatorio, la topología en estrella tipo hub-and-spoke se implementa normalmente para proporcionar aislamiento lógico y límites de seguridad en entornos de SAP. Para más detalles sobre las redes, consulte la arquitectura de referencia de SAP S/4HANA.

La red virtual de centro (hub) funciona como un punto central de conectividad a una red local. Los radios (spokes) son redes virtuales que se emparejan con el centro y que se pueden usar para aislar las cargas de trabajo. El tráfico fluye entre este centro y el centro de datos local mediante una conexión de puerta de enlace.

La mayoría de las implementaciones de clientes incluyen uno o varios circuitos ExpressRoute que conectan redes locales a Azure. Para reducir la demanda de ancho de banda de red, una alternativa de menor costo es la red privada virtual (VPN).

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.

SAP BW/4HANA está diseñado para tareas de almacenamiento de datos en tiempo real. Los servidores de aplicaciones de SAP llevan a cabo comunicaciones constantes con los servidores de bases de datos, por lo que reducir la latencia de las máquinas virtuales de aplicaciones hacia la base de datos contribuye a mejorar el rendimiento de la aplicación. El almacenamiento en caché de disco y la selección de ubicación del servidor son dos estrategias que ayudan a reducir la latencia entre estos dos componentes.

En el caso de aplicaciones críticas para el rendimiento que se ejecutan en cualquier plataforma de base datos, entre las que se incluye SAP HANA, use discos administrados Premium y habilite el Acelerador de escritura para el volumen de registro. El Acelerador de escritura está disponible para máquinas virtuales de la serie M y mejora la latencia de escritura. Sin embargo, si están disponible, use discos administrados Ultra en lugar de los discos Premium sin el Acelerador de escritura. Las funcionalidades de los discos Ultra siguen evolucionando. Para ver si estos discos cumplen los requisitos, revise la información más reciente sobre el ámbito de servicio de los discos Ultra. Realice esta revisión especialmente si la implementación incluye las características de resiliencia de Azure como conjuntos de disponibilidad, zonas de disponibilidad y replicación entre regiones.

Para ayudar a mejorar el rendimiento mediante la reducción de la distancia física entre las aplicaciones y la base de datos, use un grupo con ubicación por proximidad, como se mencionó anteriormente. Puede encontrar scripts y utilidades en GitHub.

Para optimizar las comunicaciones entre servidores, use Redes aceleradas, que está disponible para máquinas virtuales admitidas, como D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 y Ms/Mms. En todas las implementaciones de SAP, se requiere Redes aceleradas, en especial cuando se usa Azure NetApp Files.

Para lograr un rendimiento alto de ancho de banda de disco y E/S por segundo, las prácticas habituales de optimización del rendimiento del volumen de almacenamiento se aplican al diseño de Azure Storage. Por ejemplo, la combinación de varios discos para crear un volumen de disco con secciones mejora el rendimiento de E/S. La habilitación de la caché de lectura en el contenido de almacenamiento que cambia con poca frecuencia mejora la velocidad de recuperación de datos.

Escalabilidad

En esta arquitectura de ejemplo se describe una implementación de nivel de producción pequeña con la flexibilidad de poder ampliarse según sus requisitos.

En el nivel de aplicación de SAP, Azure ofrece una amplia variedad de tamaños de máquina virtual tanto para el escalado vertical como para el horizontal. Para obtener una lista inclusiva, consulte la nota de SAP 1928533. A medida que se siguen certificando más tipos de máquinas virtuales, se puede escalar o reducir verticalmente en la misma implementación de nube.

Disponibilidad

La redundancia de recursos es el tema general en las soluciones de infraestructura de alta disponibilidad. Si su organización tiene un Acuerdo de Nivel de Servicio menos estricto, use máquinas virtuales de Azure de instancia única con discos Premium, que ofrecen un Acuerdo de Nivel de Servicio de tiempo de actividad.

Para maximizar la disponibilidad de aplicaciones, puede implementar recursos redundantes en un conjunto de disponibilidad o en Availability Zones. Para más información, consulte la arquitectura de referencia de SAP S/4HANA.

Esta arquitectura coloca las máquinas virtuales que desempeñan el mismo rol en un conjunto de disponibilidad. Esta configuración ayuda a cumplir los Acuerdos de Nivel de Servicio al proteger contra el tiempo de inactividad ocasionado por las interrupciones de mantenimiento no planeado de la infraestructura de Azure. Se necesitan dos o más máquinas virtuales por conjunto de disponibilidad para obtener un Acuerdo de Nivel de Servicio superior.

Azure Load Balancer

Azure Load Balancer es un servicio de capa de transmisión de red (capa 4). En las configuraciones de clúster, Azure Load Balancer dirige el tráfico a la instancia del servicio principal o a un nodo en buen estado si hay un error. Se recomienda usar Standard Load Balancer de Azure para todos los escenarios de SAP. Ofrece una implementación de seguridad por diseño y bloquea el tráfico saliente del grupo de back-end a menos que habilite la conectividad saliente a los puntos de conexión públicos.

Además, si decide implementar cargas de trabajo de SAP en Azure Availability Zones, Standard Load Balancer tiene en cuenta la zona.

Web Dispatcher

En este diseño de ejemplo se utiliza SAP Web Dispatcher simplemente como mecanismo de equilibrio de carga HTTP(s) para el tráfico de SAP entre los servidores de aplicaciones de SAP. Para lograr una alta disponibilidad del componente Web Dispatcher, Azure Load Balancer implementa el clúster de conmutación por error o la configuración de Web Dispatcher en paralelo. Consulte SAP Web Dispatcher en la documentación de SAP.

Como equilibrador de carga de software, Web Dispatcher ofrece servicios de capa adicionales que pueden realizar la terminación de SSL y otras funciones de descarga. Estos servicios de capa se conocen como capa 7 en el modelo de red ISO.

No se necesita ningún otro equilibrador de carga para el tráfico desde clientes de la GUI de SAP que conectan un servidor SAP mediante el protocolo DIAG o llamadas a funciones remotas (RFC). El servidor de mensajes de Central Services equilibra la carga mediante grupos de inicio de sesión en el servidor de aplicaciones de SAP.

El componente Web Dispatcher se usa como equilibrador de carga para el tráfico SAP que circula entre los servidores de aplicaciones de SAP. Para lograr una alta disponibilidad de SAP Web Dispatcher, Azure Load Balancer implementa el clúster de conmutación por error o la configuración de Web Dispatcher en paralelo.

Para las comunicaciones orientadas a Internet, la arquitectura recomendada para satisfacer los aspectos relacionados con la seguridad sería una solución independiente en DMZ.

Web Dispatcher insertado en ASCS es una opción especial, y se debe tener en cuenta el tamaño adecuado debido a la carga de trabajo extra en ASCS.

Central Services

Para proteger la disponibilidad de SAP Central Services (ASCS) en máquinas virtuales Linux de Azure, debe usar la extensión de alta disponibilidad (HAE) adecuada para la distribución de Linux seleccionada. HAE proporciona software de agrupación en clústeres de Linux y componentes de integración específicos del sistema operativo para la implementación.

Para evitar un problema de cerebro dividido del clúster, puede configurar barreras de nodos de clúster mediante un dispositivo de bloqueo iSCSI STONITH (SBD), como se muestra en este ejemplo. O bien, puede usar el agente de barrera de Azure. El agente de barrera de Azure mejorado proporciona una conmutación por error de servicios mucho más rápida en comparación con la versión anterior del agente en los entornos de Red Hat y SUSE.

Otros servidores de aplicaciones en su nivel correspondiente

Para conseguir una alta disponibilidad para los servidores de aplicaciones principales de SAP y otros servidores de aplicaciones, equilibre la carga del tráfico dentro del grupo de servidores de aplicaciones.

Recuperación ante desastres

Azure admite varias opciones de recuperación ante desastres en función de sus requisitos. Los servidores de aplicaciones de SAP no contienen datos empresariales, por lo que puede crear servidores de aplicaciones de SAP en una región secundaria antes de apagarlos. Las actualizaciones de software y los cambios de configuración de tales servidores se deben replicar en el lado de recuperación ante desastres, ya sea manualmente o de forma programada. Puede crear una máquina virtual en la región de recuperación ante desastres para ejecutar el rol de Central Services, que tampoco conserva los datos empresariales. Para más información, consulte la arquitectura de referencia de SAP S/4HANA.

Supervisión

Para maximizar la disponibilidad y el rendimiento de las aplicaciones y los servicios, utilice Azure Monitor. Azure Monitor es una solución completa para recopilar, analizar y actuar en la telemetría desde los entornos local y en la nube.

Para proporcionar una supervisión basada en SAP del rendimiento de los recursos y servicios de la infraestructura de SAP, utilice la extensión Azure SAP Enhanced Monitoring. Para obtener más información, consulte la nota de SAP 2191498 "SAP on Linux with Azure: Enhanced Monitoring" (SAP en Linux con Azure: supervisión mejorada).

Azure Monitor, que ahora incluye Azure Log Analytics y Azure Application Insights, proporciona herramientas avanzadas para recopilar y analizar la telemetría. Le ayuda a maximizar el rendimiento y la disponibilidad de los recursos y aplicaciones en el entorno local y en la nube. Azure Monitor se puede usar para supervisar y alertar a los administradores de las anomalías de la infraestructura y las aplicaciones, y para automatizar las reacciones a condiciones predefinidas.

Para proporcionar una supervisión basada en SAP de los recursos y un rendimiento del servicio de la infraestructura de SAP, use la extensión Azure SAP Enhanced Monitoring. Esta extensión introduce las estadísticas de supervisión de Azure en la aplicación de SAP para la supervisión de sistema operativo y las funciones de DBA Cockpit. La supervisión mejorada de SAP es un requisito obligatorio para ejecutar SAP en Azure. Para más información, consulte la nota de SAP 2191498 – "SAP on Linux with Azure: Enhanced Monitoring" (SAP en Linux con Azure: supervisión mejorada). (Para acceder a las notas de SAP, debe tener una cuenta de Marketplace del servicio SA).

La dirección en el futuro para una solución de supervisión de un extremo a otro nativa de Azure para SAP BW/4HANA es Azure Monitor para soluciones de SAP. Azure Monitor para SAP se encuentra actualmente en versión preliminar pública. Solo está disponible en un conjunto limitado de regiones, por lo que debe evaluar cuidadosamente si cumple sus requisitos.

Azure Monitor para SAP brinda un conjunto inicial completo de métricas y telemetría para la supervisión. Las definiciones de métricas se almacenan como consultas SQL en JSON y se pueden modificar para satisfacer sus necesidades. El conjunto inicial de métricas está disponible en GitHub aquí.

Copia de seguridad

En el caso de los servidores de aplicaciones y de SAP ASCS, se recomienda usar Azure Backup para proteger el contenido de la máquina virtual. Azure Backup proporciona copias de seguridad independientes y aisladas para evitar la destrucción accidental de datos originales. Las copias de seguridad se almacenan en un almacén de Recovery Services con administración integrada de puntos de recuperación. La configuración y la escalabilidad son sencillas, las copias de seguridad están optimizadas y puede restaurarlas fácilmente cuando sea necesario.

La copia de seguridad del nivel de base de datos varía en función de si se implementa SAP HANA en máquinas virtuales o en instancias grandes de Azure. Consulte las consideraciones de administración y operaciones de SAP HANA en máquinas virtuales Linux.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

SAP cuenta con su propio motor de administración de usuarios (UME) para controlar el acceso y la autorización basados en rol en la aplicación y en las bases de datos de SAP. Para más información, consulte la Guía de seguridad de SAP BW∕4HANA.

En la arquitectura de referencia de SAP S/4HANA se proporcionan otros aspectos de seguridad de la infraestructura, que se aplican a SAP BW/4HANA.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Más información sobre las tecnologías de los componentes:

Explore las arquitecturas relacionadas: