SAP S/4HANA en Linux en Azure

Esta guía presenta un conjunto de procedimientos probados para ejecutar S/4HANA y Suite en HANA en un entorno de alta disponibilidad que admita la recuperación ante desastres (DR) en Azure. La información de Fiori solo se aplica a las aplicaciones de S/4HANA.

Architecture

Descargue un archivo Visio de esta arquitectura.

Esta guía describe un sistema de producción común. Esta arquitectura se implementa con tamaños de máquina virtual (VM) que puede cambiar para acomodarlos a las necesidades de la organización. Para satisfacer sus necesidades empresariales, puede reducir esta configuración a una sola máquina virtual.

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

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

Azure Virtual Network. El servicio Virtual Network conecta los recursos de Azure entre sí de forma segura. 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 redes virtuales. Esta arquitectura utiliza varias redes virtuales que están emparejadas. Esta topología ofrece la segmentación y el aislamiento de red para los servicios implementados en Azure. El emparejamiento conecta las redes de forma transparente a través de la red troncal de Microsoft y no provoca una reducción del rendimiento si se implementa en una sola región. Las subredes independientes se usan para cada aplicación de nivel (SAP NetWeaver), la base de datos y para los servicios compartidos, como jumpbox y Windows Server Active Directory.

Máquinas virtuales. Esta arquitectura usa máquinas virtuales que se ejecutan en Linux para la capa de aplicación y la capa de base de datos, agrupadas como se indica a continuación:

• Capa 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 ejecutan en máquinas virtuales Linux, se requiere un servicio de recurso compartido de archivos de red de alta disponibilidad, como Recursos compartidos de NFS en Azure Files, Azure NetApp Files, servidores de Sistema de archivos de red (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 15 SP1 y versiones posteriores o SLES para aplicaciones de SAP, puede usar discos compartidos de Azure en un clúster de Pacemaker 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 conseguir alta disponibilidad en una implementación de escala vertical. La replicación del sistema de HANA (HSR) se usa para replicar contenidos entre los sistemas HANA principal y secundario. La agrupación en clústeres de Linux se usa para detectar errores del sistema y facilitar la conmutación automática por error. Se puede usar un mecanismo de barrera basado en el almacenamiento o basado en la nube para garantizar que el sistema con errores se aísla o se cierra para evitar el síndrome de cerebro dividido. En las implementaciones de escalabilidad horizontal de HANA, puede lograr una alta disponibilidad 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 conectar a una máquina virtual mediante su navegador y Azure Portal, o a través de SSH nativo o un cliente RDP que tenga instalado en su máquina local. Si solo se usan RDP y SSH para la administración, Azure Bastion es una solución excelente. 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 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 de nivel de aplicación de SAP para la alta disponibilidad, se recomienda el uso de Azure Standard Load Balancer. Tenga en cuenta que Standard Load Balancer proporciona una capa de seguridad de manera 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 alta disponibilidad de la aplicación basada en web de SAP, use SAP Web Dispatcher integrado u otro equilibrador de carga disponible de forma comercial. Base la selección en lo siguiente:

• El tipo de tráfico, como HTTP o la GUI de SAP.
• Los servicios de red que necesita, 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 estos componentes:

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Servidor de replicación en cola (ERS)

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

Standard Load Balancer también admite clústeres SAP de varios identificadores de seguridad (varios SID). En otras palabras, varios sistemas SAP en SLES o RHEL pueden compartir una infraestructura de alta disponibilidad común para reducir costes. Se recomienda evaluar el ahorro de costos y evitar la colocación de demasiados sistemas en un clúster. Azure no admite más de 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 (capa OSI 4 - TCP y UDP). 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 los atributos adicionales de una solicitud HTTP, como una ruta de acceso de identificador URI o un encabezado host. Este tipo de enrutamiento se conoce como equilibrio de carga de capa de aplicación (OSI capa 7). S/4HANA ofrece 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.

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 atraviesen Internet, pero también se puede usar una conexión de sitio a sitio. Para reducir la latencia, Global Reach de ExpressRoute y FastPath de ExpressRoute son opciones de conectividad que se describen más adelante en este artículo.

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 de zona que se basa 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 con ubicación por proximidad favorece la coubicación, por lo que las máquinas virtuales residen en el mismo centro de datos para minimizar la latencia de la aplicación.

Grupos de seguridad de red. Para restringir el tráfico de entrada, de salida e interno de las subredes en la red virtual, puede crear grupos de seguridad de red.

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 los 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 la ejecución de SAP NetWeaver en las máquinas virtuales, consulte Implementación y planeamiento de Azure Virtual Machines para SAP NetWeaver. 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 y las métricas de rendimiento (SAPS) de Azure, consulte la Nota de SAP 1928533. (Para acceder a las notas de SAP, debe tener una cuenta de SAP Service Marketplace). Para una lista de máquinas virtuales de Azure certificadas para la base de datos de HANA, consulte el directorio de hardware SAP HANA admitido y certificado por SAP.

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 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 la red perimetral. Web Dispatcher insertado en ASCS es una opción especial. Si usa esta opció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 aborda los muchos requisitos y presupone que se usa el modelo insertado de Fiori FES. Todos los componentes de la tecnología se instalan en el propio sistema S/4, lo que significa que cada sistema S/4 tiene su propio launchpad de Fiori. La configuración de alta disponibilidad para este modelo de implementación es la del sistema S/4; no se requieren clústeres ni máquinas virtuales adicionales. Por ese motivo, el diagrama de arquitectura no muestra el componente de FES.

Para una descripción de las opciones de implementación principales, ya sean insertadas o centrales, en función de los escenarios, consulte Opciones de implementación de SAP Fiori y recomendaciones de 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 realiza una implementación de centro de conectividad que se ajusta solo a unos pocos casos de uso estrecho.

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 que tiene funcionalidad en clúster o de varios hosts: usa una capa de base de datos del servidor en espera, una capa de ASCS en clúster 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. Use Azure Web Application Firewall en Application Gateway como componente crítico para evitar amenazas. Use Microsoft Entra ID con SAML para la autenticación de usuarios y el inicio de sesión único para SAP Fiori.

Para ver algunos ejemplos de diseño de entrada y salida accesibles por Internet, consulte Conexiones a Internet entrantes y salientes para SAP en Azure.

Grupo de servidores de aplicaciones

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 los usuarios de inicio de sesión, para usar SM61 para los grupos de servidores por lote, para usar RZ12 para los grupos llamada de función remota (RFC), etc. Estas transacciones usan la funcionalidad de equilibrio de carga que se encuentra en el servidor de mensajes de Central Services para distribuir las sesiones o cargas de trabajo entrantes entre el grupo de servidores de aplicaciones de SAP que gestiona SAP GUI y el tráfico de RFC.

Clúster de SAP Central Services

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. Pero la máquina virtual se convierte en un único punto de error (SPOF) para el entorno de SAP. En el caso de una implementación de Central Services de alta disponibilidad, use NFS en Azure Files o el servicio Azure NetApp Files y un clúster de Central Services.

Otra opción consiste en usar discos compartidos de Azure para lograr la alta disponibilidad. En SLES 15 SP1 y posteriores o SLES para aplicaciones de SAP, puede configurar un clúster de Pacemaker mediante el uso de discos compartidos de Azure para Linux.

Como alternativa, puede usar un recurso compartido de archivos NFS para el almacenamiento compartido de clúster de Linux.

En una implementación de Azure, los servidores de aplicaciones se conectan a Central Services de alta disponibilidad mediante los nombres de host virtual de Central Services o servicios ERS. Estos nombres de host se asignan a la configuración IP de front-end del clúster del equilibrador de carga. Load Balancer admite varias direcciones IP de front-end, por lo que Central Services y las direcciones IP virtuales (VIP) de ERS se pueden configurar un equilibrador de carga.

Ahora se puede acceder por todos a la compatibilidad con clústeres de Linux para 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.

Redes

En esta arquitectura se usa una topología de red en estrella tipo hub-and-spoke, donde la red virtual de concentrador actúa como punto central de conectividad con una red local. 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 de interfaz de red (NIC)

En las implementaciones de SAP locales tradicionales, se implementan varias tarjetas de interfaz de red por máquina para aislar el tráfico administrativo del empresarial. En Azure, la red virtual es una red definida por el software que envía todo el tráfico a través del mismo tejido de red. Por tanto, no es necesario usar varias NIC para las consideraciones de rendimiento. Pero si la organización necesita separar el tráfico, puede implementar varias tarjetas de interfaz de red por máquina virtual, conectar cada una de ellas a una subred diferente y, después, usar grupos de seguridad de red para aplicar las distintas directivas de control de acceso.

Las NIC de Azure admiten varias direcciones IP. Esta asistencia se alinea con la práctica recomendada de SAP de usar nombres de host virtual para instalaciones, como se describe en la nota de SAP 962955. Para acceder a las notas de SAP, necesita una cuenta de SAP Service Marketplace.

Subredes y grupos de seguridad de red

Esta arquitectura divide el espacio de direcciones de la red virtual en subredes. Puede asociar cada subred con un grupo de seguridad de red en el que se definen las directivas de acceso para la subred. Coloque los servidores de aplicaciones en una subred independiente. Esto le permite protegerlos más fácilmente mediante la administración de las directivas de seguridad de la subred, en lugar de los servidores individuales.

Cuando un grupo de seguridad de red se asocia a una subred, este se aplica a todos los servidores de la subred y ofrece un control más exhaustivo de los servidores. Configure grupos de seguridad de red medianteAzure portal, PowerShell o la CLI de Azure.

Global Reach de ExpressRoute

Si el entorno de red incluye dos circuitos ExpressRoute o más, Global Reach de ExpressRoute puede ayudar a reducir los saltos de red y la latencia. Esta tecnología es una configuración de emparejamiento de rutas de Protocolo de puerta de enlace de borde (BGP) 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. Actualmente solo está disponible para el emparejamiento privado en circuitos ExpressRoute.

En este momento, no hay ninguna lista de control de acceso (ACL) de red ni otros atributos que se puedan cambiar en Global Reach. De este modo, todas las rutas aprendidas por un circuito ExpressRoute determinado (del entorno local y Azure) se anuncian a través del emparejamiento del circuito al otro circuito ExpressRoute. Se recomienda establecer el filtrado de tráfico de red en el entorno local para restringir el acceso a los recursos.

FastPath de ExpressRoute

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 las aplicaciones 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 otras redes virtuales están emparejadas con la que está conectada a ExpressRoute, el tráfico de la red local a las otras redes virtuales radiales se seguirá enviando a la puerta de enlace de red virtual. La solución es conectar todas las redes virtuales directamente al circuito de ExpressRoute.

Equilibradores de carga

SAP Web Dispatcher controla el equilibrio de carga del tráfico HTTP(S) en un grupo de servidores de aplicaciones SAP. Este equilibrador de carga de software ofrece servicios de capa de aplicación (denominados de capa 7 en el modelo de red ISO) que admiten la terminación SSL y otras funciones de descarga.

Load Balancer 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 la dirección IP de origen, el puerto de origen, la dirección IP de destino, el puerto de destino y el 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. Es importante tener en cuenta que Standard Load Balancer es seguro de manera predeterminada y ninguna máquina virtual detrás de Standard Load Balancer tiene conectividad de salida 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 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 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.

Storage

Algunos clientes utilizan el almacenamiento estándar para sus servidores de aplicaciones. Dado que no se admiten los discos administrados estándar, como se indica en la nota de SAP 1928533, se recomienda usar discos administrados de Azure Premium o Azure NetApp Files en todos los casos. Tenga en cuenta que una actualización reciente de la nota de SAP 2015553 excluye el uso de almacenamiento HDD estándar y SSD estándar 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. Para comprender cómo afecta el tipo de almacenamiento al Acuerdo de Nivel de Servicio de disponibilidad de la máquina virtual, consulte SLA para Virtual Machines. En escenarios de alta disponibilidad, las características de discos compartidos de Azure están disponibles en SSD prémium de Azure y Almacenamiento en disco Ultra de Azure. Para más información, consulte Introducción a los discos administrados de Azure.

Puede usar discos compartidos de Azure con Windows Server, SLES 15 SP 1 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 un dispositivo de bloque STONITH (SBD). Ofrece un voto de cuórum en una situación de creación de 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.

Para los escenarios de recursos compartidos de NFS, Azure NetApp Files proporciona disponibilidad para recursos compartidos de NFS que se pueden usar para los volúmenes /hana/shared, /hana/data y /hana/log. Para conocer la garantía de disponibilidad, consulte SLA para Azure NetApp Files. Si usa recursos compartidos NFS basados en Azure NetApp Files para los volúmenes /hana/data y /hana/log, debe usar 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. También puede considerar la posibilidad de usar el nivel Standard de Azure NetApp Files como destino de copia de seguridad o la opción de copia de seguridad de archivos 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.

El Almacenamiento en disco Ultray el nivel de almacenamiento Ultra de Azure NetApp Files reducen considerablemente la latencia de disco y benefician a las aplicaciones críticas para el rendimiento y a los servidores de bases de datos de SAP.

SSD prémium v2 de Azure está diseñado para cargas de trabajo críticas para el rendimiento, como SAP. Consulte Implementación de SSD prémium v2 para más información sobre las ventajas de esta solución de almacenaje y sus limitaciones actuales.

Consideraciones de rendimiento

Los servidores de aplicaciones de SAP se comunican constantemente con los servidores de bases de datos. Para aplicaciones de cargas de trabajo críticas que se ejecuten en cualquier plataforma de base de datos, incluyendo SAP HANA, habilite Acelerador de escritura para el volumen de registro si está usando SSD prémium v1. Esto puede mejorar la latencia de 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, las instancias de máquina virtual con cuatro o más vCPU admiten redes aceleradas.

Para más información acerca de los requisitos de rendimiento de SAP HANA, consulte la nota de SAP 1943937: Herramienta de comprobación de la configuración del hardware. (Para acceder a las notas de SAP, debe tener una cuenta de SAP Service Marketplace).

Para lograr un rendimiento del ancho de banda de disco y un IOPS altos, las prácticas habituales de optimización del rendimiento del volumen de almacenamiento se aplican a su diseño de Storage. Por ejemplo, si combina varios discos para crear un volumen de disco con secciones, puede mejorar el rendimiento de E/S. Al habilitar la caché de lectura en el contenido de almacenamiento que cambia con poca frecuencia, puede mejorar la velocidad de recuperación de datos. Para obtener recomendaciones sobre las configuraciones de almacenamiento para varios tamaños de máquina virtual al ejecutar SAP HANA, consulte Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA.

SSD prémium v2 de Azure está diseñado para cargas de trabajo críticas para el rendimiento, como SAP. Consulte Tipos de discos administrados de Azure para más información sobre sus ventajas, limitaciones y escenarios de uso óptimos.

El Almacenamiento en disco Ultra es una nueva generación de almacenamiento que satisface 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 MB/s sin necesidad de reiniciar la máquina virtual. Cuando el Almacenamiento en disco Ultra está disponible, se recomienda Almacenamiento en disco Ultra en lugar del Acelerador de escritura.

Algunas aplicaciones de SAP requieren una comunicación frecuente con la base de datos. La latencia de red entre las capas de aplicación y de la base de datos, debido a la distancia, 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 coubicació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. Para ver scripts y utilidades que están disponibles en GitHub para grupos de selección de ubicación por proximidad, consulte Grupos con ubicación por proximidad de Azure.

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 las zonas de disponibilidad, lo que puede mejorar la disponibilidad del servicio, tal y como se describe más adelante en este artículo. 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 dispone de características de rendimiento únicas que permiten un ajuste en tiempo real que satisface las necesidades de los entornos de SAP más exigentes. Para conocer las consideraciones de rendimiento que debe tener en cuenta al usar Azure NetApp Files, consulte Ajuste del tamaño de la base de datos HANA en Azure NetApp Files.

Consideraciones sobre escalabilidad

En la capa 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 completa, vea "Aplicaciones de SAP en Azure: productos y tipos de VM de Azure compatibles" en la nota de SAP 1928533. (Para acceder a las notas de SAP, debe tener una cuenta de SAP Service Marketplace). Hay más tipos de máquina virtual certificados continuamente, por lo que puede escalar o reducir verticalmente en la misma implementación en la nube.

En la capa de base de datos, esta arquitectura se ejecuta en aplicaciones S/4 de SAP HANA 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 (4 x 24) para aplicaciones de procesamiento de transacciones en línea (OLTP). Para más información, consulte Directorio de hardware certificado y compatible con SAP HANA.

Consideraciones sobre disponibilidad

La redundancia de recursos es el tema general en las soluciones de infraestructura de alta disponibilidad. Para los Acuerdos de Nivel de Servicio de disponibilidad de máquinas virtuales de una sola instancia para varios tipos de almacenamiento, consulte SLA para Virtual Machines. Para aumentar la disponibilidad del servicio en Azure, implemente recursos de máquina virtual con Virtual Machine Scale Sets con orquestación flexible, zonas de disponibilidad o conjuntos de disponibilidad.

En esta instalación distribuida de la aplicación SAP, la instalación base se replica para lograr una alta disponibilidad. Para 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 (FD=1), zonas de disponibilidad y conjuntos de disponibilidad, para mejorar la disponibilidad de los recursos. Para una descripción completa de las opciones de implementación disponibles y su aplicabilidad en diferentes regiones de Azure (incluidas las distintas zonas, dentro de una sola zona o en una región sin zonas), consulte Escenarios y arquitectura de alta disponibilidad para SAP NetWeaver.

Web Dispatcher en el nivel de servidores de aplicaciones

Puede lograr una alta disponibilidad mediante instancias redundantes de Web Dispatcher. Para más información, consulte SAP Web Dispatcher en la documentación de SAP. El nivel de disponibilidad depende del tamaño de la aplicación que está detrás de Web Dispatcher. En implementaciones pequeñas con pocos problemas de escalabilidad, puede localizar Web Dispatcher con las máquinas virtuales de ASCS. De este modo, se ahorra en el mantenimiento independiente del sistema operativo y se obtiene una alta disponibilidad al mismo tiempo.

Central Services en el nivel de servidores de aplicaciones

Para lograr una 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 SUSE DRBD 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 mediante Azure Files o Azure NetApp Files. Como nota, 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 los de /sapmnt, /saptrans en las instalaciones de SAP.

Azure NetApp Files admite la alta disponibilidad de ASCS en SLES. Para obtener información detallada sobre ASCS en la alta disponibilidad de RHEL, consulte SIOS Protection Suite para Linux.

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

Otra opción consiste en usar discos compartidos de Azure para lograr la alta disponibilidad. En SLES 15 SP 1 y versiones posteriores o SLES para SAP, puede configurar un clúster de Pacemaker mediante discos compartidos de Azure para lograr una alta disponibilidad.

En Azure Standard Load Balancer, puede habilitar el puerto de alta disponibilidad y evitar la necesidad de configurar reglas de equilibrio de carga para muchos puertos de 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 ASCS y BD HANA, se recomienda habilitar DSR. Si las máquinas virtuales del grupo de back-end requieren conectividad de salida pública, se requiere más configuración.

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 conseguir alta disponibilidad mediante el equilibrio de la carga de tráfico dentro de un grupo de servidores de aplicaciones.

Nivel de ASCS

Como con la capa de servidores de aplicaciones, Pacemaker es la solución de alta disponibilidad de HANA implementada comúnmente para Linux.

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 característica de replicación nativa del sistema de la capa de base de datos proporciona conmutación por error manual o automática entre los nodos replicados:

• Para la conmutación por error manual, implemente más de una instancia de HANA y use HSR.
• Para la conmutación automática por error, use HSR y la extensión de alta disponibilidad (HAE) de Linux adecuada para su distribución de Linux. Linux HAE proporciona los servicios de clúster a los recursos de HANA, detecta eventos de error y orquesta la conmutación por error de los servicios errantes en el nodo en buen estado.

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

Las zonas de disponibilidad puede 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 única zona se tratan como si estuvieran en un único dominio de error o de actualización. 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 al menos tres zonas disponibles. Pero no se garantiza la distancia máxima entre los centros de datos de estas zonas. Para implementar un sistema SAP multinivel entre zonas, debe conocer la latencia de red dentro de una zona y en las zonas de destino, y el grado de confidencialidad de las aplicaciones implementadas para 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 (tipos de máquinas virtuales) en las zonas seleccionadas

Ejemplo de implementación activa/pasiva

En esta implementación de ejemplo, el estado activo/pasivo se refiere al estado del servicio de la 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 son necesarios.

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 ubicados en la misma zona, se minimiza la latencia de red.

Ejemplo de implementación activa/activa

En una implementación activa/activa, se crean dos conjuntos de servidores de aplicaciones en dos zonas. En cada zona, dos servidores de aplicaciones de cada conjunto están inactivos o apagados. 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 pueden tener una latencia de red más prolongada al conectarse a los servicios de ASCS y base de datos 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 conocer las estrategias de recuperación ante desastres y los detalles de implementación, consulte Introducción a la recuperación ante desastres e instrucciones de infraestructura para la carga de trabajo de SAP y Directrices de recuperación ante desastres para la aplicación SAP.

Consideraciones sobre el costo

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

Para más información, consulte la sección acerca de los costos del artículo sobre elmarco de buena arquitectura de Microsoft Azure.

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.

En general, existen varias opciones de pago para las máquinas virtuales:

• Para las cargas de trabajo sin tiempo predecible de finalización o consumo de recursos, considere la posibilidad de usar la opción de pago por uso.

• Considere la posibilidad de usar Azure Reservations si es capaz de usar una máquina virtual durante un período de más de uno o tres años. Las reservas de máquinas virtuales pueden reducir significativamente los costes. Es posible que pague tan solo el 72% del coste de un servicio de pago por uso.

• Use las máquinas virtuales de acceso puntual de Azure para ejecutar cargas de trabajo que se puedan interrumpir y no requieran la finalización dentro de un período de tiempo predeterminado o un Acuerdo de Nivel de Servicio. Azure implementa máquinas virtuales de acceso puntual cuando hay capacidad disponible, y las expulsa cuando necesita recuperar dicha capacidad. Los costes asociados a las máquinas virtuales de acceso puntual son inferiores a los 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

• Azure Reserved Virtual Machine Instances puede reducir el costo total de propiedad mediante la combinación de tarifas de Azure Reserved Virtual Machine Instances con una suscripción de pago por uso para que pueda administrar los costos en cargas de trabajo predecibles y variables. Para más información sobre esta oferta, consulte Azure Reserved Virtual Machine Instances.

Para obtener información general sobre los precios, consulte Precios de Linux Virtual Machines.

Load Balancer

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 (NAT) 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 Azure 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.

Azure Center for SAP solutions

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. Además, la experiencia de implementación guiada de Azure Center for SAP solutions crea los componentes de proceso, almacenamiento y redes necesarios para ejecutar el sistema SAP. Después, le ayuda a 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. Para más información, consulte Azure Center for SAP solutions.

Backup

Puede realizar copias de seguridad de los datos de SAP HANA de muchas maneras. Después de migrar a Azure, siga usando cualquier solución de copia de seguridad existente 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 tiene la certificación BackInt de 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.

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 por medio del control de acceso basado en roles de Azure (RBAC de Azure).

• Conceda acceso a las máquinas virtuales de Azure mediante el protocolo ligero de acceso a directorios (LDAP), Microsoft Entra ID, 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.

Supervisión

Para maximizar la disponibilidad y el rendimiento de las aplicaciones y los servicios en Azure, utilice Azure Monitor, una completa solución que permite recopilar, analizar y responder a los datos de telemetría tanto en la nube como en entornos locales. 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 sobre la seguridad

SAP tiene su propio motor de administración de usuarios (UME) para controlar el acceso basado en rol y la autorización en la aplicación y bases de datos de SAP. Para más información, consulte Seguridad de SAP HANA: una introducción.

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. El costo de la transferencia de datos es una razón para colocar servidores front-end activos que ejecutan aplicaciones Fiori en la misma red virtual que los sistemas S/4. La alternativa es colocarlas en la red perimetral y conectarlas a S/4 a través de un emparejamiento de red virtual.

Para la seguridad de la infraestructura, los datos se cifran tanto en tránsito como en reposo. La sección "Consideraciones de seguridad" de SAP en Azure: Guía de planeamiento e implementación empieza a afrontar la seguridad de la red que se aplica a S/4HANA. Esa guía también especifica los puertos de red que se deben abrir en los firewalls para permitir la comunicación de la aplicación.

Para cifrar discos de máquina virtual de Linux, dispone de varias opciones, como se describe en Introducción a las opciones de cifrado de discos administrados. Para el cifrado de datos en reposo de SAP HANA, se recomienda usar la tecnología de cifrado nativa de SAP HANA. Para obtener información sobre la compatibilidad con Azure Disk Encryption en distribuciones, versiones e imágenes específicas de Linux, consulte Azure Disk Encryption para VM Linux.

Para el cifrado de datos en reposo de SAP HANA, se recomienda usar la tecnología de cifrado nativa de SAP HANA.

Comunidades

Las comunidades pueden responder preguntas y ayudarle a configurar una implementación correcta. Tenga en cuenta estos recursos:

• Blog Ejecución de aplicaciones SAP en la plataforma de Microsoft
• Soporte técnico de la comunidad de Azure
• SAP Community
• Stack Overflow SAP

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribió el siguiente colaborador.

Autor principal:

• Ben Trinh | Arquitecto principal

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

Pasos siguientes

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

• Implementación de SAP S/4HANA o BW/4HANA en Azure
• Implementación y planeamiento de Azure Virtual Machines para SAP NetWeaver
• Uso de Azure para hospedar y ejecutar escenarios de carga de trabajo de SAP

Recursos relacionados

• Ejecución de cargas de trabajo SAP de producción mediante Oracle Database en Azure