Compartir a través de

SAP S/4HANA en Linux en Azure

En esta guía se presenta un conjunto de prácticas probadas para ejecutar S/4HANA y Suite en HANA en un entorno de alta disponibilidad (HA) que admite la recuperación ante desastres (DR) en Azure. La información de Fiori solo se aplica a las aplicaciones de S/4HANA.

Arquitectura

Diagrama de arquitectura que muestra SAP S/4HANA para máquinas virtuales Linux en un conjunto de disponibilidad de Azure.

Descargue un archivo de Visio de esta arquitectura.

Nota:

Para implementar esta arquitectura, asegúrese de que tiene las licencias necesarias para productos de SAP y cualquier otra tecnología que no sea de Microsoft.

En esta guía se describe un sistema de producción típico. Esta arquitectura usa varios tamaños de máquina virtual (VM). Para adaptarse a las necesidades de su organización, puede ajustar los tamaños o reducir esta configuración a una sola máquina virtual.

En esta guía, el diseño de red se simplifica para demostrar los principios arquitectónicos. No representa una red empresarial completa.

Esta arquitectura usa los siguientes componentes. Algunos servicios compartidos son opcionales.

Azure Virtual Network. El servicio De red virtual conecta los recursos de Azure entre sí con seguridad mejorada. En esta arquitectura, una red virtual se conecta a un entorno local a través de una puerta de enlace que está implementada en el concentrador de una topología en estrella tipo hub-and-spoke. La red radial es la red virtual que se usa tanto para las aplicaciones de SAP como para las capas de bases de datos.

Emparejamiento de red virtual. Esta arquitectura usa varias redes virtuales emparejadas. Esta topología ofrece la segmentación y el aislamiento de red para los servicios implementados en Azure. El emparejamiento conecta redes de forma transparente a través de la red troncal de Microsoft y no incurre en una penalización de rendimiento si se implementa dentro de una sola región. Se usan subredes independientes para cada nivel, incluido el nivel de aplicación (SAP NetWeaver) y el nivel de base de datos, y para componentes compartidos, como jump box y Windows Server Active Directory.

Máquinas virtuales. Esta arquitectura organiza las máquinas virtuales que ejecutan Linux en grupos para el nivel de aplicación y el nivel de base de datos de las maneras siguientes:

  • Nivel de aplicación. Esta capa de arquitectura incluye el clúster de servidores front-end de Fiori, el grupo de SAP Web Dispatcher, el clúster de servidores de aplicaciones y el clúster de SAP Central Services. Para lograr una alta disponibilidad de Central Services en Azure que se ejecuta en máquinas virtuales Linux, es necesario un servicio de recursos compartidos de archivos de red de alta disponibilidad, como Recursos compartidos de Network File System (NFS) en Azure Files, Azure NetApp Files, servidores de NFS en clúster o SIOS Protection Suite para Linux. Para configurar un recurso compartido de archivos de alta disponibilidad para el clúster de Central Services en Red Hat Enterprise Linux (RHEL), puede configurar GlusterFS en las máquinas virtuales de Azure que ejecutan RHEL. En SUSE Linux Enterprise Server (SLES) 15 SP1 y versiones posteriores o SLES para aplicaciones de SAP, puede usar discos compartidos de Azure en un clúster de Pacemaker como dispositivo de barrera para lograr la alta disponibilidad.

  • SAP HANA. El nivel de base de datos usa dos o más máquinas virtuales Linux en un clúster para lograr alta disponibilidad en una implementación escalada. La replicación del sistema de HANA (HSR) se usa para replicar contenidos entre los sistemas HANA principal y secundario. La tecnología de clústeres de Linux se utiliza para detectar fallos del sistema y facilitar la conmutación automática. Debe usar un mecanismo de barrera basado en almacenamiento o basado en la nube para asegurarse de que el sistema con errores está aislado o apagado para evitar un clúster con particiones. En las implementaciones de escalabilidad horizontal de HANA, puede lograr alta disponibilidad (HA) de la base de datos mediante una de las siguientes opciones:

    • Configure los nodos en espera de HANA mediante Azure NetApp Files sin el componente de agrupación en clústeres de Linux.

    • Escale horizontalmente sin nodos en espera mediante almacenamiento premium de Azure. Use la agrupación en clústeres de Linux para la conmutación por error.

  • Azure Bastion. Este servicio le permite conectarse a una máquina virtual mediante el explorador y Azure Portal o mediante el cliente nativo de Secure Shell (SSH) o protocolo de escritorio remoto (RDP) instalado en el equipo local. Si solo se usan RDP y SSH para la administración, considere la posibilidad de usar Azure Bastion. Pero si usa otras herramientas de administración, como SQL Server Management Studio o un front-end de SAP, use un jumpbox tradicional autoimplementado.

Servicio de DNS privado.Azure Private DNS ofrece un servicio de DNS fiable y seguro para su red virtual. Azure Private DNS administra y resuelve los nombre de dominio en la red virtual sin necesidad de configurar una solución DNS personalizada.

Equilibradores de carga. Para distribuir el tráfico a las máquinas virtuales de la subred del nivel de aplicación de SAP para aumentar la disponibilidad, use Azure Standard Load Balancer. Standard Load Balancer proporciona una capa de seguridad de forma predeterminada. Las máquinas virtuales que están tras Standard Load Balancer no tienen conectividad saliente a Internet. Para habilitar la conectividad saliente a Internet en las máquinas virtuales, debe actualizar la configuración de Standard Load Balancer. También puede usar Azure NAT Gateway para obtener conectividad saliente. Para la aplicación basada en web HA de SAP, use el SAP Web Dispatcher integrado u otro equilibrador de carga disponible comercialmente. Base la selección en lo siguiente:

  • El tipo de tráfico, como el tráfico HTTP o el tráfico de interfaz gráfica de usuario (GUI) de SAP.
  • Las funcionalidades de red que necesite, como la terminación Capa de sockets seguros (SSL).

Standard Load Balancer admite varias direcciones IP virtuales de front-end. Esta compatibilidad es ideal para implementaciones de clúster que incluyen los siguientes componentes:

  • Programación avanzada de aplicaciones empresariales (ABAP) SAP Central Services (ASCS)
  • Servidor de replicación en cola

Estos dos componentes pueden compartir un equilibrador de carga para simplificar la solución.

Standard Load Balancer también admite clústeres SAP de múltiples identificadores de sistema (multi-SID). Esta característica permite que varios sistemas SAP en SLES o RHEL compartan una infraestructura de alta disponibilidad común para ayudar a reducir los costos. Se recomienda evaluar el ahorro de costos y evitar la colocación de demasiados sistemas en un clúster. Azure admite hasta cinco SID por clúster.

Puerta de enlace de aplicación. Azure Application Gateway es un equilibrador de carga de tráfico web que puede usar para administrar el tráfico a las aplicaciones web. Los equilibradores de carga tradicionales funcionan en la capa de transporte, conocida como capa 4 de interconexión de sistemas abiertos (OSI), mediante el protocolo de control de transmisión y el protocolo de datagramas de usuario. En función del puerto y la dirección IP de origen, estos enrutan el tráfico a un puerto y una dirección IP de destino. Application Gateway puede tomar decisiones de enrutamiento basadas en atributos adicionales de una solicitud HTTP, como la ruta de acceso uniforme del identificador de recursos o los encabezados de host. Este tipo de enrutamiento se conoce como capa de aplicación o nivel OSI 7, equilibrio de carga. S/4HANA proporciona servicios de aplicaciones web a través de Fiori. Puede equilibrar la carga de este front-end de Fiori, que consta de aplicaciones web, mediante Application Gateway. Si utiliza direcciones IP públicas, asegúrese de que usen el SKU de IP estándar. Evite la SKU de dirección IP básica porque está previsto que se retire el 30 de septiembre de 2025.

Puerta de enlace. Una puerta de enlace conecta redes distintas, y extiende la red local a una red virtual de Azure. Azure ExpressRoute es el servicio de Azure recomendado para crear conexiones privadas que no pasen por la red pública de Internet. También puede usar una conexión de sitio a sitio. Para ayudar a reducir la latencia, use Global Reach de ExpressRoute o FastPath de ExpressRoute.

Puerta de enlace con redundancia de zona. Puede implementar puertas de enlace de ExpressRoute o de red privada virtual (VPN) en varias zonas para protegerse frente a errores de zona. Esta arquitectura usa puertas de enlace de red virtual con redundancia de zona para lograr resistencia en lugar de una implementación zonal basada en la misma zona de disponibilidad.

Grupo con ubicación por proximidad. Este grupo lógico impone una restricción en las máquinas virtuales implementadas en un conjunto de disponibilidad o en un conjunto de escalado de máquinas virtuales. Un grupo de selección de ubicación por proximidad ayuda a aplicar la colocación asegurándose de que las máquinas virtuales se implementan en el mismo centro de datos. Esta configuración reduce la distancia física entre los recursos para minimizar la latencia de la aplicación.

Nota:

Para obtener una estrategia de configuración actualizada, consulte Opciones de configuración para minimizar la latencia de red con las aplicaciones de SAP. En este artículo se describen los posibles compromisos en la flexibilidad de despliegue al optimizar un sistema SAP para la latencia de red.

Grupos de seguridad de red (NSG). Para restringir el tráfico entrante, saliente y dentro de la subred en una red virtual, puede crear NSGs.

Grupos de seguridad de aplicaciones. Para definir directivas de seguridad de red pormenorizadas que se basan en de las cargas de trabajo, centradas en aplicaciones, use los grupos de seguridad de aplicación en lugar de direcciones IP explícitas. Puede agrupar máquinas virtuales por nombre y proteger las aplicaciones seguras mediante el filtrado del tráfico desde segmentos de confianza de la red.

Azure Storage. Azure Storage proporciona persistencia de datos para una máquina virtual en forma de disco duro virtual (VHD). Se recomienda usar discos administrados de Azure.

Recomendaciones

En esta arquitectura se describe una pequeña implementación en el nivel de producción. La implementación varía en función de los requisitos empresariales, por lo que debe tener en cuenta estas recomendaciones como punto de partida.

Máquinas virtuales

En las granjas y clústeres de servidores de aplicaciones, ajuste el número de máquinas virtuales según sus requisitos. Para más información sobre cómo ejecutar SAP NetWeaver en máquinas virtuales, consulte Guía de implementación y planeación de Azure Virtual Machines. La guía también se aplica a las implementaciones de SAP S/4HANA.

Para más información sobre la compatibilidad de SAP con los tipos de máquina virtual de Azure y para las métricas de rendimiento, consulte la nota de SAP 1928533. (Para acceder a las notas de SAP, debe tener una cuenta de SAP Service Marketplace). Para obtener una lista de las máquinas virtuales de Azure certificadas para la base de datos de HANA, consulte Directorio de hardware de SAP HANA certificado y compatible.

SAP Web Dispatcher

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 un clúster de recuperación ante errores o la configuración de Web Dispatcher en paralelo. Para las comunicaciones accesibles desde Internet, una solución independiente en la red perimetral es la arquitectura recomendada para satisfacer los requisitos de seguridad. Embedded Web Dispatcher en ASCS es una configuración avanzada. Si usa esta configuración, considere el ajuste de tamaño adecuado debido a la carga de trabajo adicional en ASCS.

Servidor front-end de Fiori (FES)

Esta arquitectura cumple varios requisitos y supone que se usa el modelo feS de Fiori insertado. Todos los componentes de tecnología se instalan directamente en el sistema S/4, por lo que cada sistema S/4 tiene su propio Launchpad Fiori. El sistema S/4 administra la configuración de alta disponibilidad para este modelo de implementación. Este enfoque elimina la necesidad de clústeres o máquinas virtuales adicionales. Por este motivo, el diagrama de arquitectura no incluye el componente FES.

Para obtener más información sobre las opciones de implementación, consulte Opciones de implementación de SAP Fiori y recomendaciones del entorno del sistema. Por motivos de simplicidad y rendimiento, las versiones del programa entre los componentes de tecnología Fiori y las aplicaciones S/4 se emparejan de forma estricta. Esta configuración hace que una implementación del centro sea adecuada solo para algunos casos de uso específicos.

Si usa la implementación del concentrador de FES, FES es un complemento para la pila clásica de ABAP de SAP NetWeaver. Configure la alta disponibilidad de la misma manera que protege una pila de aplicaciones de ABAP de tres niveles, con la funcionalidad de agrupación en clúster o de varios hosts. Use una capa de base de datos de servidor en espera, una capa ASCS agrupada con NFS de alta disponibilidad para el almacenamiento compartido y al menos dos servidores de aplicaciones. La carga equilibra al tráfico a través de un par de instancias de Web Dispatcher que se pueden agrupar en clúster o en paralelo. En el caso de las aplicaciones Fiori accesibles desde Internet, se recomienda una implementación del centro de FES en la red perimetral. Usa Azure Web Application Firewall en Application Gateway como componente crítico para desviar amenazas. Utiliza Microsoft Entra ID con el Lenguaje de Marcado de Reclamaciones de Seguridad para la autenticación de usuarios y el inicio de sesión único para SAP Fiori.

Diagrama de arquitectura que muestra el flujo de datos entre Internet y dos redes virtuales, uno con SAP Fiori y otro con SAP S/4HANA.

Descargue un archivo de Visio de esta arquitectura.

Para más información, consulte Conexiones de Internet entrantes y salientes para SAP en Azure.

Grupo de servidores de aplicaciones

Para administrar grupos de inicio de sesión para servidores de aplicaciones de ABAP, use los siguientes códigos de transacción:

  • SMLG: Equilibra la carga de los usuarios de inicio de sesión.
  • SM61: Administrar grupos de servidores por lotes.
  • RZ12: Gestionar grupos de llamadas a funciones remotas (RFC).

Estas transacciones dependen de la funcionalidad de equilibrio de carga en el servidor de mensajes de Central Services para distribuir las sesiones entrantes y las cargas de trabajo en el grupo de servidores de aplicaciones de SAP que administran la GUI de SAP y el tráfico RFC.

Clúster de SAP Central Services

Los servicios centrales de SAP incluyen una única instancia del servidor de mensajes y el servicio de replicación en cola. A diferencia de los procesos de trabajo de los servidores de aplicaciones, estos componentes son puntos únicos de error en la pila de aplicaciones de SAP. Puede implementar Central Services en una sola máquina virtual cuando el contrato de nivel de servicio (SLA) de disponibilidad de máquina virtual de instancia única de Azure cumpla sus necesidades. Si el Acuerdo de Nivel de Servicio requiere una mayor disponibilidad, debe implementar estos servicios en un clúster de alta disponibilidad. Para obtener más información, consulte Central Services en el nivel de servidores de aplicaciones.

Redes

Esta arquitectura utiliza una topología hub-spoke, donde la red virtual del hub actúa como punto central de conectividad a una red interna. Los radios son redes virtuales que se emparejan con el concentrador. Puede usar los radios para aislar las cargas de trabajo. El tráfico fluye entre el centro de datos local y el concentrador a través de una conexión de puerta de enlace.

Tarjetas adaptadoras de red

Las implementaciones de SAP locales tradicionales implementan varias tarjetas de interfaz de red (NIC) por máquina para separar el tráfico administrativo del tráfico empresarial. En Azure, la red virtual es una red definida por software que enruta todo el tráfico a través de un único tejido de red. Como resultado, no necesita varias NIC por motivos de rendimiento. Si su organización necesita separar el tráfico, puede implementar varias NIC para cada máquina virtual, conectar cada NIC a una subred diferente y, a continuación, usar grupos de seguridad de red para ayudar a aplicar diferentes directivas de control de acceso.

Las NIC de Azure admiten varias direcciones IP. Esta compatibilidad se alinea con la práctica que SAP recomienda usar nombres de host virtuales para instalaciones en la nota de SAP 962955.

Subredes y NSGs

Esta arquitectura divide el espacio de direcciones de la red virtual en subredes. Puede asociar cada subred a un grupo de seguridad de red que defina las directivas de acceso para la subred. Coloque los servidores de aplicaciones en una subred independiente. Este enfoque facilita la protección de los servidores de aplicaciones mediante la administración de las directivas de seguridad de subred en lugar de los servidores individuales.

Al asociar un grupo de seguridad de red a una subred, el grupo de seguridad de red se aplica a todos los servidores de la subred y proporciona un control específico sobre los servidores. Configure NSG a través de Azure Portal, Azure PowerShell o la CLI de Azure.

Global Reach de ExpressRoute

Si el entorno de red incluye dos o más circuitos ExpressRoute, Global Reach de ExpressRoute puede ayudarle a reducir los saltos de red y reducir la latencia. Esta tecnología es una configuración de emparejamiento de rutas de Protocolo de puerta de enlace de borde entre dos circuitos ExpressRoute o más para unir dos dominios de enrutamiento de ExpressRoute. Global Reach reduce la latencia cuando el tráfico de red atraviesa más de un circuito ExpressRoute. Solo está disponible para el emparejamiento privado en circuitos ExpressRoute.

Global Reach no admite cambios en las listas de control de acceso de red ni en otros atributos. Todas las rutas aprendidas por un circuito ExpressRoute, tanto del entorno local como de Azure, se anuncian a través del emparejamiento del circuito al otro circuito ExpressRoute. Se recomienda configurar el filtrado del tráfico de red local para restringir el acceso a los recursos.

FastPath

FastPath implementa intercambios de Microsoft Edge en el punto de entrada de la red de Azure. FastPath reduce los saltos de red para la mayoría de los paquetes de datos. Como resultado, FastPath reduce la latencia de red, mejora el rendimiento de la aplicación y es la configuración predeterminada para las nuevas conexiones de ExpressRoute a Azure.

Para los circuitos ExpressRoute existentes, póngase en contacto con el Soporte técnico de Azure para activar FastPath.

FastPath no admite el emparejamiento de red virtual. Si una red virtual conectada a ExpressRoute se empareja con otras redes virtuales, el tráfico de la red local a las otras redes virtuales periféricas se seguirá redirigiendo a través de la puerta de enlace de red virtual. Para solucionar este problema, conecte todas las redes virtuales directamente al circuito ExpressRoute.

Equilibradores de carga

SAP Web Dispatcher controla el equilibrio de carga del tráfico HTTP y HTTPS a un grupo de servidores de aplicaciones de SAP. Este equilibrador de carga de software proporciona servicios de capa de aplicación, conocida como capa 7 en el modelo de red ISO, que son capaces de realizar la terminación de SSL y otras funciones de liberación de carga.

Load Balancer (equilibrador de carga) es un servicio de capa de transmisión de red (capa 4), que equilibra el tráfico de los flujos de datos mediante un hash de cinco tuplas. El hash se basa en una dirección IP de origen, un puerto de origen, una dirección IP de destino, un puerto de destino y un tipo de protocolo. Load Balancer se usa en configuraciones de clúster para dirigir el tráfico a la instancia del servicio principal o a un nodo en buen estado si hay un error. Se recomienda que use Standard Load Balancer de Azure para todos los escenarios de SAP. Standard Load Balancer es seguro de forma predeterminada y ninguna máquina virtual detrás de Standard Load Balancer tiene conectividad saliente a Internet. Para habilitar la conectividad de salida a Internet en las máquinas virtuales, debe ajustar la configuración de Standard Load Balancer.

Para el tráfico de clientes de GUI de SAP que se conectan a un servidor SAP a través del protocolo Dynamic Information and Action Gateway (DIAG) o RFC, el servidor de mensajes de Central Services equilibra la carga a través de los grupos de inicio de sesión del servidor de aplicaciones de SAP. No se necesita ningún equilibrador de carga adicional.

Almacenamiento

Algunos clientes utilizan el almacenamiento estándar para sus servidores de aplicaciones. Dado que no se admiten discos administrados estándar, se recomienda usar SSD Premium de Azure o Azure NetApp Files en todos los escenarios. Una actualización reciente de la nota de SAP 2015553 excluye el uso del almacenamiento HDD estándar de Azure y el almacenamiento SSD estándar de Azure para algunos casos de uso específicos.

Puesto que los servidores de aplicaciones no hospedan datos empresariales, también puede usar los discos premium P4 y P6 más pequeños para ayudar a gestionar el costo. En el caso de las aplicaciones SAP, se recomienda encarecidamente usar Discos SSD de Azure v1, SSD v2 o Ultra. Para comprender cómo afecta el tipo de almacenamiento al Acuerdo de Nivel de Servicio de disponibilidad de la máquina virtual, consulte Acuerdos de Nivel de Servicio para servicios en línea. En escenarios de alta disponibilidad, las características de disco compartido de Azure están disponibles en SSD Premium de Azure y Azure Ultra Disk Storage. Para más información, consulte Discos administrados de Azure y tipos de discos administrados de Azure.

Puede usar discos compartidos de Azure con Windows Server, SLES 15 SP1 y versiones posteriores, o SLES para SAP. Cuando se usa un disco compartido de Azure en clústeres de Linux, el disco compartido de Azure actúa como barrera de un dispositivo de bloque de nodos con errores. Incluye un voto de cuórum cuando se crean particiones de red de clúster. Este disco compartido no tiene un sistema de archivos y no admite escrituras simultáneas desde varias máquinas virtuales que sean miembro del clúster.

Azure NetApp Files tiene funcionalidades integradas de uso compartido de archivos para NFS y SMB.

En los casos de recursos compartidos de NFS, Azure NetApp Files aporta alta disponibilidad para recursos compartidos de NFS que se pueden usar para los volúmenes /hana/shared, /hana/data y /hana/log. Para obtener la garantía de disponibilidad, consulte Acuerdos de Nivel de Servicio para servicios en línea. Si usa recursos compartidos NFS basados en Azure NetApp Files para los volúmenes /hana/data y /hana/log, debe utilizar el protocolo NFS v4.1. Para el volumen /hana/shared, se admite el protocolo NFS v3.

En el almacén de datos de copia de seguridad, se recomienda el uso de los niveles 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. Además, considere la posibilidad de usar el nivel Estándar de Azure NetApp Files como destino de copia de seguridad o la opción de copia de seguridad de Azure NetApp Files. En el caso del disco administrado, el nivel de datos de copia de seguridad recomendado es el nivel de acceso de archivo o el nivel de acceso esporádico de Azure.

Ultra Disk Storage y El nivel Ultra de Azure NetApp Files reducen significativamente la latencia de disco y mejoran el rendimiento de las aplicaciones críticas y los servidores de bases de datos de SAP.

SSD Premium v2 está diseñado para cargas de trabajo críticas para el rendimiento, como SAP. Para obtener más información sobre las ventajas y limitaciones de esta solución de almacenamiento, consulte Implementación de una versión 2 de SSD Premium.

Consideraciones sobre el rendimiento

Los servidores de aplicaciones de SAP se comunican constantemente con los servidores de bases de datos. Para aplicaciones críticas para el rendimiento, que se ejecutan en cualquier plataforma de base de datos, incluido SAP HANA, habilite Acelerador de escritura para el volumen de log si utiliza SSD Premium v1. Este enfoque puede mejorar la latencia en la escritura de registros. SSD prémium v2 no usa Acelerador de escritura. Acelerador de escritura está disponible para las VM de la serie M.

Para optimizar las comunicaciones entre servidores, utilice la red acelerada. La mayoría de los tamaños de instancia de máquina virtual de uso general y optimizados para procesos que tienen dos o más vCPU admiten redes aceleradas. En las instancias que admiten hyperthreading (multihilo simultáneo), las instancias de máquina virtual con cuatro o más vCPU admiten redes aceleradas.

Debe optimizar la pila TCP/IP y los búferes de Linux en la interfaz de red para lograr un rendimiento coherente. Siga la configuración recomendada de Microsoft. Por ejemplo, ajustará elementos como:

  • Parámetros de kernel para optimizar los búferes de memoria de lectura y escritura
  • Control de congestión de ancho de banda en cuello de botella y tiempo de propagación de ida y vuelta (BBR)
  • Ajuste de los parámetros TCP para ofrecer una mejor coherencia y rendimiento
  • Búferes cíclicos de NIC para TX/RX

Para obtener más información sobre los requisitos de rendimiento de SAP HANA, consulte la nota de SAP 1943937.

Para lograr operaciones de entrada/salida elevadas por segundo (IOPS) y rendimiento de ancho de banda de disco, siga los procedimientos comunes para la optimización del rendimiento del volumen de almacenamiento. Por ejemplo, combinar varios discos para crear un volumen de disco seccionado puede mejorar el rendimiento de entrada y salida (E/S). Habilitar la caché de lectura en el contenido de almacenamiento que cambia con poca frecuencia también puede acelerar la recuperación de datos. Para obtener más información, consulte Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA.

SSD Premium v2 está diseñado para cargas de trabajo críticas para el rendimiento, como SAP. Para más información sobre sus ventajas, limitaciones y escenarios de uso óptimos, consulte Tipos de disco administrado de Azure.

Almacenamiento en disco Ultra es una nueva generación de almacenamiento que cubre IOPS intensivas y las demandas de ancho de banda de transferencia de aplicaciones como SAP HANA. Puede cambiar dinámicamente el rendimiento de los discos Ultra y configurar de forma independiente métricas como IOPS y MBps sin reiniciar la máquina virtual. Se recomienda usar Ultra Disk Storage en lugar del Acelerador de escritura cuando sea posible.

Algunas aplicaciones de SAP requieren una comunicación frecuente con la base de datos. Debido a la distancia, la latencia de red entre las capas de aplicación y base de datos puede afectar negativamente al rendimiento de la aplicación. Los grupos con ubicación por proximidad de Azure establecen una restricción de selección de ubicación para las máquinas virtuales que se implementan en conjuntos de disponibilidad. Dentro de la construcción lógica de un grupo, la colocación y el rendimiento se favorecen sobre la escalabilidad, la disponibilidad y el costo. Los grupo con ubicación por proximidad pueden mejorar considerablemente la experiencia del usuario en la mayoría de las aplicaciones de SAP.

No se admite la colocación de una aplicación virtual de red (NVA) entre las capas de aplicación y de base de datos de cualquier pila de aplicaciones de SAP. La aplicación virtual de red requiere una cantidad significativa de tiempo para procesar paquetes de datos. Como resultado, ralentiza de forma inaceptable el rendimiento de la aplicación.

También se recomienda tener en cuenta el rendimiento al implementar recursos con zonas de disponibilidad, lo que puede mejorar la disponibilidad del servicio. Considere la posibilidad de crear un perfil de latencia de red claro entre todas las zonas de una región de destino. Este enfoque le ayudará a decidir la selección de ubicación de los recursos para la latencia mínima entre las zonas. Para crear este perfil, ejecute una prueba mediante la implementación de máquinas virtuales pequeñas en cada zona. Entre las herramientas recomendadas para la prueba se incluyen PsPing e Iperf. Después de las pruebas, quite estas máquinas virtuales. Para obtener una herramienta de prueba de latencia de red de dominio público que puede usar en su lugar, consulte Prueba de latencia de zona de disponibilidad.

Azure NetApp Files tiene características de rendimiento únicas que permiten el ajuste en tiempo real para satisfacer las necesidades de los entornos sap más exigentes. Para conocer las consideraciones sobre el rendimiento al usar Azure NetApp Files, consulte Ajuste de tamaño de la base de datos de HANA en Azure NetApp Files.

Consideraciones sobre escalabilidad

En el nivel de aplicación de SAP, Azure proporciona una amplia gama de tamaños de máquina virtual para escalar verticalmente y escalar horizontalmente. Para obtener una lista inclusiva, consulte Aplicaciones de SAP en Azure: productos admitidos y tipos de máquina virtual de Azure en la nota de SAP 1928533. Hay más tipos de máquina virtual certificados continuamente, por lo que puede escalar verticalmente por encima o por debajo en la misma implementación en la nube.

En el nivel de base de datos, esta arquitectura ejecuta aplicaciones de SAP S/4HANA en máquinas virtuales de Azure que pueden escalar verticalmente hasta 24 terabytes (TB) en una instancia. Si la carga de trabajo supera el tamaño máximo de máquina virtual, puede usar una configuración de varios nodos para hasta 96 TB (cuatro instancias de 24 TB) para aplicaciones de procesamiento de transacciones en línea. Para obtener más información, consulte Directorio de hardware de SAP HANA certificado y compatible.

Consideraciones de disponibilidad

La redundancia de recursos es el tema general en las soluciones de infraestructura de alta disponibilidad. Para obtener acuerdos de nivel de servicio de disponibilidad de máquinas virtuales de instancia única para varios tipos de almacenamiento, consulte Acuerdos de Nivel de Servicio para servicios en línea. Para aumentar la disponibilidad del servicio en Azure, implemente recursos de máquina virtual mediante Conjuntos de escalado de máquinas virtuales de Azure, que proporciona orquestación flexible, zonas de disponibilidad y conjuntos de disponibilidad.

El modelo de implementación de conjuntos de disponibilidad regionales de Azure es una opción compatible. Sin embargo, se recomienda adoptar los conjuntos de escalado de máquinas virtuales con el modelo de zonas de disponibilidad para nuevas implementaciones de SAP para mejorar la disponibilidad y aumentar la flexibilidad de implementación.

En esta instalación distribuida de la aplicación SAP, la instalación base se replica para lograr alta disponibilidad. En cada capa de la arquitectura, el diseño de la alta disponibilidad varía.

Enfoques de implementación

En Azure, la implementación de cargas de trabajo de SAP puede ser regional o zonal, en función de los requisitos de disponibilidad y resistencia de las aplicaciones SAP. Azure proporciona diferentes opciones de implementación, como Virtual Machine Scale Sets con orquestación flexible (una configuración de dominio de error), zonas de disponibilidad y conjuntos de disponibilidad, para mejorar la disponibilidad de los recursos.

A medida que las implementaciones de clientes en Azure han crecido a lo largo de los años, Microsoft ha mejorado los modelos de implementación de máquinas virtuales de Azure para incluir conjuntos de escalado de máquinas virtuales para ayudar a garantizar la elasticidad y la resistencia de la nube. Teniendo en cuenta las opciones de implementación disponibles, se recomienda encarecidamente usar la implementación zonal del conjunto de escalado flexible de Azure para todas las nuevas implementaciones. Para obtener más información sobre la implementación entre zonas, dentro de una sola zona y en regiones sin zonas, consulte Arquitectura de alta disponibilidad y escenarios para SAP NetWeaver.

Web Dispatcher en el nivel de servidores de aplicaciones

Puede lograr una alta disponibilidad mediante instancias redundantes de Web Dispatcher. Para obtener más información, consulte SAP Web Dispatcher. El nivel de disponibilidad depende del tamaño de la aplicación que está detrás de Web Dispatcher. En implementaciones pequeñas que tienen pocos problemas de escalabilidad, puede colocar Web Dispatcher con las máquinas virtuales de ASCS. Este enfoque le ayuda a ahorrar en el mantenimiento independiente del sistema operativo y obtener alta disponibilidad al mismo tiempo.

Central Services en el nivel de servidores de aplicaciones

Para alta disponibilidad de Central Services en máquinas virtuales Linux de Azure, use la extensión de alta disponibilidad adecuada para la distribución de Linux seleccionada. Es habitual colocar los sistemas de archivos compartidos en el almacenamiento NFS de alta disponibilidad mediante el dispositivo de bloque replicado distribuido de SUSE o Red Hat GlusterFS. Para proporcionar un NFS de alta disponibilidad y eliminar la necesidad de un clúster NFS, puede usar otras soluciones rentables o sólidas, como NFS a través de Azure Files o Azure NetApp Files. Los recursos compartidos de Azure NetApp Files pueden hospedar los archivos de registro y datos de SAP HANA. Esta configuración habilita el modelo de implementación de escalabilidad horizontal de HANA con nodos en espera, mientras que NFS mediante Azure Files es adecuado para el uso compartido de archivos que no son de base de datos de alta disponibilidad.

NFS mediante Azure Files ahora admite los recursos compartidos de archivos de alta disponibilidad para SLES y RHEL. Esta solución funciona bien para recursos compartidos de archivos de alta disponibilidad, como /sapmnt y /saptrans en instalaciones de SAP.

Azure NetApp Files tiene compatibilidad con la alta disponibilidad de ASCS en SLES. Para obtener más información sobre ASCS en RHEL HA, consulte SIOS Protection Suite for Linux.

El agente mejorado de barrera de Azure está disponible para SUSE y Red Hat y proporciona una conmutación por error de servicio mucho más rápida que la versión anterior del agente.

Otra opción de barrera es usar discos compartidos de Azure para el dispositivo de barrera. En SLES 15 SP1 o SLES para SAP 15 SP1 y versiones posteriores, puede configurar un clúster de Pacemaker mediante discos compartidos de Azure. Esta opción es sencilla y no requiere un puerto de red abierto como el agente de barrera de Azure.

Una configuración de Pacemaker compatible recientemente y más sencilla en SLES 15 y versiones posteriores es HA SAP NetWeaver con montaje simple y NFS en SLES para máquinas virtuales de aplicaciones de SAP. En esta configuración, los recursos compartidos de archivos de SAP se quitan de la administración del clúster, lo que facilita el funcionamiento. Use esta configuración de alta disponibilidad para todas las implementaciones nuevas.

Para administrar aún más los costos de un entorno de SAP grande, el clúster de Linux admite la instalación de varios SID de ASCS en Azure. El uso compartido de un clúster de disponibilidad entre varios sistemas SAP simplifica el panorama de SAP y reduce los costos de operación.

En Standard Load Balancer, puede habilitar el puerto de alta disponibilidad y evitar la necesidad de configurar reglas de equilibrio de carga para muchos puertos SAP. En general, si habilita la característica de devolución de servidor directo (DSR) al configurar un equilibrador de carga, las respuestas de servidor a las consultas de cliente pueden omitir el equilibrador de carga. Esta característica también se conoce como IP flotante. El equilibrador de carga puede ser local o en Azure. Esta conexión directa evita que el equilibrador de carga se convierta en el cuello de botella en la ruta de transmisión de datos. En el caso de los clústeres de base de datos asCS y HANA, se recomienda habilitar DSR. Si las máquinas virtuales del grupo de back-end requieren conectividad de salida pública, se requiere una configuración adicional.

Para el tráfico de clientes de la GUI de SAP que se conectan a un servidor SAP a través del protocolo DIAG o RFC, el servidor de mensajes de Central Services equilibra la carga mediante los grupos de inicio de sesión del servidor de aplicaciones de SAP. No se necesita ningún equilibrador de carga adicional.

Servidores de aplicaciones en su nivel correspondiente

Puede lograr alta disponibilidad mediante el equilibrio de carga del tráfico dentro de un grupo de servidores de aplicaciones.

Nivel de base de datos

En la arquitectura de esta guía se muestra un sistema de base de datos de SAP HANA de alta disponibilidad que consta de dos máquinas virtuales de Azure. La función de replicación nativa del sistema de la capa de base de datos incluye una recuperación manual o automática ante errores entre los nodos replicados.

  • Para la conmutación por error manual, implemente más de una instancia de HANA y use HSR.

  • Para la recuperación ante errores, use HSR y la extensión de alta disponibilidad (HAE) de Linux para su distribución de Linux. Linux HAE proporciona servicios de clúster para recursos de HANA, detecta eventos de error y coordina la conmutación por error de los servicios con fallas a un nodo saludable.

Implementación de máquinas virtuales en zonas de disponibilidad

Las zonas de disponibilidad pueden mejorar la disponibilidad del servicio. Las zonas hacen referencia a ubicaciones separadas físicamente dentro de una región de Azure específica. Mejoran la disponibilidad de la carga de trabajo y protegen los servicios de aplicación y las máquinas virtuales frente a interrupciones del centro de trabajo. Las máquinas virtuales de una sola zona se tratan como si estuvieran en un único dominio de actualización o error. Cuando se selecciona la implementación en zonas, las máquinas virtuales de la misma zona se distribuyen en los dominios de error y de actualización en función de la mejor opción.

En las regiones de Azure que admiten esta característica, hay disponibles un mínimo de tres zonas. No se garantiza la distancia máxima entre los centros de datos de estas zonas. Para implementar un sistema SAP de varios niveles entre zonas, debe conocer la latencia de red dentro de una zona y entre zonas de destino y la sensibilidad de las aplicaciones implementadas a la latencia de red.

Tome en cuenta estas consideraciones cuando decida implementar recursos en zonas de disponibilidad:

  • Latencia entre máquinas virtuales de una zona
  • Latencia entre las máquinas virtuales de las zonas seleccionadas
  • Disponibilidad de los mismos servicios de Azure o tipos de máquina virtual en las zonas elegidas

Nota:

No se recomiendan zonas de disponibilidad para la recuperación ante desastres. Un sitio de recuperación de desastres debe estar a al menos 160 kilómetros del sitio primario para tener en cuenta los desastres naturales. No se puede garantizar la distancia exacta entre los centros de datos.

Ejemplo de implementación activa/pasiva

En esta implementación de ejemplo, el estado activo/pasivo se refiere al del servicio de aplicación dentro de las zonas. En la capa de aplicación, los cuatro servidores de aplicaciones activos del sistema SAP se encuentran en la zona 1. Otro conjunto de cuatro servidores de aplicaciones pasivos se integra en la zona 2, pero está apagado. Solo se activan cuando es necesario.

Los clústeres de dos nodos para Central Services y la base de datos se ajustan en dos zonas. Si se produce un error en la zona 1, Central Services y los servicios de bases de datos se ejecutarán en la zona 2. Los servidores de aplicaciones pasivos de la zona 2 se activan. Con todos los componentes de este sistema SAP colocados en la misma zona, se minimiza la latencia de red.

Ejemplo de implementación activa/activa

En una implantación activa/activa, se construyen dos conjuntos de servidores de aplicaciones a través de dos zonas. En cada zona, hay activos dos servidores de aplicaciones en cada conjunto. Como resultado, hay servidores de aplicaciones activos en ambas zonas en las operaciones normales.

Los servicios de ASCS y base de datos se ejecutan en la zona 1. Los servidores de aplicaciones de la zona 2 podrían tener una latencia de red más larga cuando se conectan a los servicios de base de datos y ASCS debido a la distancia física entre las zonas.

Si la zona 1 se queda sin conexión, ASCS y los servicios de base de datos conmutan por error a la zona 2. Los servidores de aplicaciones inactivos se pueden conectar para proporcionar capacidad total para el procesamiento de las aplicaciones.

Consideraciones de recuperación ante desastres

Cada nivel de la pila de aplicaciones de SAP usa un enfoque diferente para proporcionar protección de recuperación ante desastres. Para obtener información sobre estrategias de recuperación ante desastres e implementación, consulte Introducción a la recuperación ante desastres e instrucciones de infraestructura para cargas de trabajo de SAP y directrices de recuperación ante desastres para aplicaciones de SAP.

Nota:

Si se produce un desastre regional que provoca un evento de conmutación por error masivo para muchos clientes de Azure en una región, no se garantiza la capacidad de recursos de la región de destino. Al igual que todos los servicios de Azure, Site Recovery sigue agregando características y funcionalidades. Para obtener la información más reciente sobre la replicación de Azure a Azure, consulte la matriz de compatibilidad.

Para ayudar a garantizar la capacidad de recursos disponible para una región de recuperación ante desastres, use la reserva de capacidad a petición. Azure le permite combinar el descuento de su instancia reservada con la reserva de capacidad para reducir costes.

Consideraciones sobre los costos

Puede usar la calculadora de precios de Azure para calcular los costos.

Para más información, consulte Optimización de costos de Azure Well-Architected Framework.

Máquinas virtuales

En esta arquitectura se usan máquinas virtuales que ejecutan Linux para las capas de administración, aplicación SAP y base de datos.

Existen varias opciones de pago para las máquinas virtuales:

  • En el caso de las cargas de trabajo que no tienen un tiempo predecible de finalización o consumo de recursos, considere la opción de pago por uso.

  • Considere la posibilidad de usar reservas de Azure si puede confirmar el uso de una máquina virtual durante un período de un año o de tres años. Las reservas de máquinas virtuales pueden reducir significativamente los costes. Puede ahorrar hasta un 72 % en comparación con las modalidades de pago por uso.

  • Use máquinas virtuales puntuales de Azure para ejecutar cargas de trabajo que se pueden interrumpir y no requieren finalización dentro de un período de tiempo predeterminado o SLA. Azure implementa máquinas virtuales de acceso puntual cuando hay capacidad disponible, y las expulsa cuando necesita recuperar dicha capacidad. Los costos de las máquinas virtuales Spot son menores que los costos de otras máquinas virtuales. Considere la posibilidad de usar VM de acceso puntual para estas cargas de trabajo:

    • Escenarios informáticos de alto rendimiento, trabajos de procesamiento por lotes o aplicaciones de representación visual

    • Entornos de prueba, incluidas las cargas de trabajo de integración continua y entrega continua

    • Aplicaciones sin estado a gran escala

  • Las instancias reservadas de máquinas virtuales de Azure pueden reducir el costo total de propiedad al combinar las tarifas de las instancias reservadas de máquinas virtuales de Azure con una suscripción de pago por uso, de modo que pueda administrar los costos entre cargas de trabajo predecibles y variables. Para más información, consulte Azure Reserved Virtual Machine Instances.

Para obtener información general sobre los precios, consulte Precios de máquinas virtuales Linux.

Equilibrador de carga

En este escenario, los equilibradores de carga de Azure se usan para distribuir el tráfico a las máquinas virtuales en la subred del nivel de aplicación.

Se le cobrará solo el número de reglas de equilibrio de carga y de salida configuradas. Las reglas de traducción de direcciones de red de entrada son gratuitas. Cuando no hay configurada ninguna regla, la instancia de Standard Load Balancer no se cobra por hora.

ExpressRoute

En esta arquitectura, ExpressRoute es el servicio de redes que se usa para crear conexiones privadas entre una red local y redes virtuales de Azure.

Toda la transferencia de datos entrantes es gratuita. Toda la transferencia de datos de salida se cobra en función de una tasa predeterminada. Para más información, consulte Precios de ExpressRoute.

Consideraciones de administración y operaciones

Para ayudar a mantener el sistema en ejecución en producción, tenga en cuenta los siguientes puntos.

Centro de Azure para soluciones de SAP

Azure Center for SAP solutions es una solución integral que permite crear y ejecutar sistemas SAP como una carga de trabajo unificada en Azure, y que proporciona una base de datos más eficiente para la innovación. La experiencia de implementación guiada de soluciones de Azure Center para SAP crea los componentes de proceso, almacenamiento y redes necesarios para ejecutar el sistema SAP. Después, puede automatizar la instalación del software de SAP según los procedimientos recomendados de Microsoft. Puede aprovechar las capacidades de administración de los sistemas SAP nuevos y existentes basados en Azure.

Copia de seguridad

Puede realizar copias de seguridad de los datos de SAP HANA de muchas maneras. Después de migrar a Azure, siga usando las soluciones de copia de seguridad existentes que tenga. Azure proporciona dos enfoques nativos para la copia de seguridad. Puede hacer una copia de seguridad de SAP HANA en máquinas virtuales o usar Azure Backup en el nivel de archivo. Azure Backup está certificado Backint por SAP. Para más información, consulte Preguntas frecuentes de Azure Backup y Matriz de soporte para copias de seguridad de bases de datos SAP HANA.

Nota:

Solo las implementaciones de contenedor único o de escalado vertical de HANA admiten instantáneas de almacenamiento de Azure.

Administración de identidades

Use un sistema de administración de identidades centralizado para controlar el acceso a los recursos en todos los niveles.

  • Proporcione acceso a los recursos de Azure mediante el control de acceso basado en rol (RBAC) de Azure.

  • Conceda acceso a máquinas virtuales de Azure mediante el protocolo ligero de acceso a directorios, el identificador de Microsoft Entra, Kerberos u otro sistema.

  • Ofrezca acceso a las propias aplicaciones mediante los servicios que proporciona SAP o use OAuth 2.0 y Microsoft Entra ID.

Monitorización

Para maximizar la disponibilidad y el rendimiento de las aplicaciones y los servicios en Azure, use 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. Azure Monitor muestra cómo funcionan las aplicaciones e identifica de manera proactiva los problemas que les afectan y los recursos de los que dependen. Para las aplicaciones de SAP que se ejecutan en SAP HANA y otras soluciones de base de datos principales, consulte Azure Monitor para soluciones de SAP para obtener información sobre cómo Azure Monitor para SAP puede ayudarle a administrar la disponibilidad y el rendimiento de los servicios de SAP.

Consideraciones de seguridad

SAP tiene su propio motor de administración de usuarios para controlar el acceso basado en rol y la autorización dentro de la aplicación y las bases de datos de SAP. Para obtener más información, consulte Introducción a la seguridad de SAP HANA.

Para mejorar la seguridad de la red, considere la posibilidad de usar una red perimetral que use una aplicación virtual de red (NVA) para crear un firewall delante de la subred para Web Dispatcher los grupo de servidores de front-end de Fiori. Para minimizar los costos de transferencia de datos, implemente servidores front-end activos que hospedan aplicaciones Fiori dentro de la misma red virtual que los sistemas S/4. Como alternativa, puede configurar estos servidores front-end en la red perimetral, que aprovecha el emparejamiento de redes virtuales para establecer la conectividad con los sistemas S/4.

Para la seguridad de la infraestructura, los datos se cifran tanto en tránsito como en reposo. Para obtener información sobre la seguridad de red que se aplica a S/4HANA, consulte Seguridad para el entorno de SAP.

Para cifrar discos de máquina virtual Linux, tiene varias opciones. Para el cifrado de datos en reposo de SAP HANA, se recomienda usar la tecnología de cifrado nativa de SAP HANA. Para obtener compatibilidad con Azure Disk Encryption en distribuciones, versiones e imágenes específicas de Linux, consulte Azure Disk Encryption para máquinas virtuales Linux.

Nota:

No use el cifrado de datos en reposo de HANA y Azure Disk Encryption en el mismo volumen de almacenamiento. Para HANA, use el cifrado de datos de HANA a través del cifrado del lado servidor de Azure Disk Storage. El uso de claves administradas por el cliente puede afectar al rendimiento de E/S.

Comunidades

Las comunidades pueden responder preguntas y ayudarle a configurar una implementación correcta. Considere la posibilidad de utilizar los siguientes recursos:

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autor principal:

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

Pasos siguientes

Para obtener más información y ejemplos de cargas de trabajo de SAP que usan algunas de las mismas tecnologías que esta arquitectura, consulte los siguientes artículos: