Ejecución de SAP HANA en Azure (instancias grandes)

Esta arquitectura de referencia muestra un conjunto de prácticas probadas para ejecutar SAP HANA en Azure (instancias grandes) con alta disponibilidad y recuperación ante desastres. Esta oferta se llama HANA (instancias grandes) o HLI y se implementa en los servidores físicos de las regiones de Azure. Esta solución muestra un escenario de escalado vertical sencillo para demostrar los conceptos básicos de la implementación y el funcionamiento de un sistema SAP HANA en Azure. Para ver las opciones, consulte otros escenarios de instalación de HANA (instancias grandes).

Architecture

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

La arquitectura consta de los siguientes componentes de infraestructura.

• Red virtual. El servicio Azure Virtual Network (red virtual) conecta recursos de Azure entre sí de forma segura y se subdivide en subredes diferentes para cada capa. Los niveles de aplicación SAP se implementan en Azure Virtual Machines (VM) para conectarse a la capa de base de datos HANA que reside en instancias de gran tamaño.

• Red de revisión de HLI 4.5. A partir de julio de 2021, la revisión actualizada de HLI Rev 4 está disponible. Esta implementación actualizada [rev4.5] incluye muchas mejoras en la infraestructura, como las redes de 100 Gb/s para el almacenamiento NFS y una mejor redundancia de red del servidor de base de datos. En este diseño, los servidores HLI se implementan en centros de datos de Azure próximos físicamente a las máquinas virtuales de Azure en las que se ejecutan los servidores de aplicaciones SAP. Cuando se usa junto con una configuración [ExpressRoute FastPath][fastpath], Rev 4.5 eleva el rendimiento de la aplicación. Estas características de redes también admiten las implementaciones de Rev 3 y Rev 4.

• Máquinas virtuales (VM) . Las VM se utilizan tanto en el nivel de aplicación SAP como en el nivel de servicios compartidos. Este último incluye JumpBox, que los administradores usan para configurar HANA (instancias grandes) y para proporcionar acceso a otras VM. Para ubicar los servidores de aplicaciones SAP en el mismo centro de datos con las unidades de HANA (instancias grandes), use grupos con ubicación por proximidad.

• HANA (instancias grandes) . Se ha certificado que este servidor físico cumple los estándares de SAP HANA Tailored Datacenter Integration (TDI) para ejecutar SAP HANA. Esta arquitectura utiliza dos instancias de HANA (instancias grandes): una unidad de proceso principal y otra secundaria. La alta disponibilidad en la capa de datos se proporciona a través de HANA System Replication (HSR).

• Par de alta disponibilidad. Un grupo de hojas de HANA (instancias grandes) se administra de forma conjunta para proporcionar confiabilidad y redundancia a las bases de datos.

• Microsoft Enterprise Edge (MSEE) . MSEE es un punto de conexión de un proveedor de conectividad o del perímetro de la red que atraviesa un circuito de ExpressRoute.

• Tarjetas de interfaz de red (NIC) . Para habilitar la comunicación, el servidor de HANA (instancias grandes) proporciona cuatro tarjetas de interfaz de red virtuales de forma predeterminada. Esta arquitectura requiere una para la comunicación del cliente, otra para la conectividad de nodo a nodo que necesita HSR, una tercera para el almacenamiento de HANA (instancias grandes) y una cuarta para el iSCSI que se usa en la agrupación en clústeres de alta disponibilidad.

• Almacenamiento de Network File System (NFS) . El servidor de NFS admite el recurso compartido de archivos de red que proporciona persistencia de datos seguros para HANA (instancias grandes).

• ExpressRoute. ExpressRoute es el servicio de redes de Azure recomendado para crear conexiones privadas entre una red local y redes virtuales de Azure que no pasan por la red pública de Internet. Las máquinas virtuales de Azure se conectan a HANA (instancias grandes) mediante otra conexión de ExpressRoute. La conexión de ExpressRoute entre la red virtual de Azure y HANA (instancias grandes ) se configura como parte de la oferta de Microsoft.

• Puerta de enlace. La puerta de enlace de ExpressRoute se utiliza para conectar la red virtual Azure usada para el nivel de aplicación SAP a la red de HANA (instancias grandes). Use las SKU Alto rendimiento o Ultrarrendimiento.

• Recuperación ante desastres (DR) . Entre las opciones de recuperación ante desastres se incluyen HANA System Replication (HSR), la copia de seguridad y restauración de archivos de HANA o la replicación de almacenamiento. Previa solicitud, el equipo de administración de servicios de Microsoft puede configurar los volúmenes y servidores de almacenamiento. Usted es responsable de programar la instantánea de almacenamiento, probar el sistema y familiarizarse con el proceso de recuperación. Otras consideraciones se aplican a la capa de aplicación de SAP NetWeaver y SAP S/4HANA en Azure.

Recomendaciones

Las recomendaciones pueden variar, así que use estas como punto de partida.

Proceso de HANA (instancias grandes)

HANA (instancias grandes) son servidores físicos que se basan en la arquitectura de CPU de Intel Broadwell y Cascade Lake, y están configurados en un sello de instancias grandes (es decir, un conjunto específico de hojas o servidores). Una unidad de proceso equivale a un servidor o a una hoja y una marca consta de varios servidores u hojas. En un sello de instancias grandes, los servidores no se comparten y se dedican a ejecutar la implementación de un cliente de SAP HANA.

Hay varias SKU disponibles para HANA (instancias grandes), que admiten instancias individuales de hasta 24 TB (120 TB de escalabilidad horizontal) de memoria para BW/4HANA u otras cargas de trabajo de SAP HANA.

Elija una SKU que cumpla los requisitos de tamaño que determinó en las sesiones de arquitectura y diseño. Asegúrese siempre de que el tamaño se aplica a la SKU correcta. Tanto las funcionalidades como los requisitos de implementación varían en función del tipo y la disponibilidad varía en función de la región. También puede pasar de una SKU a otra mayor.

Microsoft le ayuda a establecer la configuración de las instancias grandes, pero es responsabilidad suya comprobar la del sistema operativo. Asegúrese de revisar las últimas notas de SAP relativas a su versión exacta de Linux.

Storage

El diseño del almacenamiento se implementa en función de la recomendación de TDI para SAP HANA. HANA (instancias grandes) incluye una configuración de almacenamiento específica para las especificaciones estándar de TDI. Sin embargo, se puede adquirir almacenamiento adicional en incrementos de 1 TB.

Para admitir los requisitos de los entornos de misión crítica, lo que incluye la recuperación rápida, se usa NFS, no el almacenamiento conectado de forma directa. El servidor de almacenamiento de NFS para HANA (instancias grandes) está hospedado en un entorno de varios inquilinos, en el que los inquilinos se segregan y se protegen mediante el uso del aislamiento de los procesos, la red y el almacenamiento.

Para lograr una alta disponibilidad en el sitio principal, use diferentes diseños de almacenamiento. Por ejemplo, en una escalabilidad horizontal con varios hosts, el almacenamiento se comparte. Otra opción de alta disponibilidad es la replicación basada en aplicaciones, como HSR. Sin embargo, en el caso de la recuperación ante desastres, se usa una replicación de almacenamiento que usa instantáneas.

Redes

Esta arquitectura utiliza redes físicas y virtuales. La red virtual forma parte de la infraestructura como servicio (IaaS) de Azure y se conecta a una red física discreta de HANA (instancias grandes) a través de circuitos ExpressRoute. Una puerta de enlace entre locales conecta las cargas de trabajo de la red virtual de Azure con los sitios locales.

Todas las implementaciones de HANA (instancias grandes) desde julio de 2019 usan sellos Rev 4, que se implementan cerca de los hosts de VM de Azure usados para los servidores de aplicaciones SAP. Como resultado, la implementación de Rev 4 minimiza la latencia de red entre las capas de aplicación y de base de datos.

Las redes de HANA (instancias grandes) están aisladas entre sí por motivos de seguridad. Las instancias que residen en diferentes regiones no se comunican entre sí, excepto para la replicación del almacenamiento dedicado. Sin embargo, para usar HSR, es necesario que haya comunicaciones entre las distintas regiones. Se pueden usar [Azure Global Reach][globalreach], tablas de enrutamiento de IP o servidores proxy para habilitar HSR entre regiones.

Todas las redes virtuales de Azure que se conectan a HANA (instancias grandes) en una región se pueden interconectar a través de ExpressRoute a HANA (instancias grandes) en una región secundaria.

El circuito ExpressRoute para HANA (instancias grandes) se incluye de forma predeterminada durante el aprovisionamiento. Para la configuración se necesita un diseño de red específico, que incluye el enrutamiento de dominios y los intervalos de direcciones de Enrutamiento de interdominios sin clases (CIDR) necesarios. Para más información, consulte Infraestructura y conectividad con SAP HANA en Azure (instancias grandes).

Para reducir la latencia de red y mejorar el rendimiento, considere la posibilidad de habilitar FastPath (también conocido como MSEE v2). Esta configuración de red permite el tráfico del entorno local a la red virtual de Azure y de la red virtual a HANA (instancias grandes) para omitir la puerta de enlace de Azure.

Consideraciones

Escalabilidad

Para escalar o reducir verticalmente, puede elegir entre la gran cantidad tamaños de servidores que están disponibles para HANA (instancias grandes). Están clasificados por categorías como Tipo I y Tipo II, y personalizados para las diferentes cargas de trabajo. Elija un tamaño que puede aumentar al mismo ritmo que la carga de trabajo durante los tres años siguientes. También están disponibles los compromisos de un año.

Una implementación escalada de múltiples hosts suele utilizarse para implementaciones de BW/4HANA como un tipo de estrategia de creación de particiones en una base de datos. En el momento de redactar este documento, BW/4HANA en HANA (instancias grandes) se puede escalar horizontalmente a 120 TB. Para realizar escalados horizontales, planee la colocación de las tablas HANA antes de la instalación. Desde una perspectiva de la infraestructura, varios hosts están conectados a un volumen de almacenamiento compartido, lo que permite que los hosts en espera tomen el control rápidamente en caso de que se produzca un error en uno de los nodos de trabajo de proceso del sistema de HANA.

S/4HANA y SAP Business Suite en HANA en una sola hoja se pueden escalar verticalmente a hasta 24 TB con un nodo de una sola instancia. HANA (instancias grandes) y la infraestructura de almacenamiento de Azure también admiten implementaciones escaladas de S/4HANA y BW/4HANA. Para las SKU específicas certificadas para la escalabilidad horizontal, consulte el [directorio de hardware certificado de SAP][directorio].

Los requisitos de memoria de HANA aumentan a medida que aumenta el volumen de datos. Use el consumo de memoria actual del sistema como base para predecir el consumo futuro y, después, asigne la petición a uno de los tamaños de HANA (instancias grandes).

Si ya tiene implementaciones de SAP, SAP proporciona informes que puede usar para comprobar los datos que usan los sistemas existentes y para calcular los requisitos de memoria de una instancia de HANA. Por ejemplo, consulte las siguientes notas de SAP (para el acceso se requiere una cuenta de SAP Service Marketplace):

• Nota de SAP 1793345: Sizing for SAP Suite on HANA (Ajuste de tamaño para SAP Suite en HANA)
• Nota de SAP 1872170 - Suite on HANA and S/4 HANA sizing report (Informe de ajuste de tamaño de Suite en HANA y S/4 HANA)
• Nota de SAP 2121330 - FAQ: SAP BW on HANA Sizing Report (Preguntas más frecuentes: informe de ajuste de tamaño de SAP BW en HANA)
• Nota de SAP 1736976 - Sizing Report for BW on HANA (Informe de ajuste de tamaño para BW en HANA)
• Nota de SAP 2296290 - New Sizing Report for BW on HANA (Nuevo informe de ajuste de tamaño para BW en HANA)

Disponibilidad

La redundancia de recursos es el tema general en las soluciones de infraestructura de alta disponibilidad. Trabaje con SAP, un integrador de sistemas o Microsoft para diseñar e implementar correctamente una estrategia de alta disponibilidad y recuperación ante desastres. Esta arquitectura se rige por el Acuerdo de Nivel de Servicio (SLA) para HANA en Azure (instancias grandes). Para evaluar sus requisitos de disponibilidad, tenga en cuenta los únicos puntos de error, el nivel deseado de tiempo de actividad de los servicios y estas métricas comunes:

• Objetivo de tiempo de recuperación (RTO) significa el periodo de tiempo en que el servidor de HANA (instancias grandes) no está disponible.

• Objetivo de punto de recuperación (RPO) significa el período máximo tolerable en que los datos del cliente pueden perderse debido a un error.

Para lograr alta disponibilidad, implemente más de una instancia en un par de alta disponibilidad, y use HSR en modo sincrónico para minimizar el tiempo de inactividad y la pérdida de datos. Además de una configuración local de dos nodos de alta disponibilidad, HSR admite la replicación multinivel, en la que un tercer nodo de una región de Azure independiente se registra en la réplica secundaria del par HSR con clústeres como su destino de replicación. De este modo se forma una cadena de margarita de replicación.

La conmutación por error en el nodo de recuperación ante desastres es un proceso manual sin agrupación en clústeres de Linux. Para la detección de errores y la conmutación por error automáticas, puede configurar Pacemaker para reducir aún más el tiempo de inactividad causado por errores de software o hardware. A partir de HANA 2,0 SPS 04, HSR también admite la replicación en varios destinos. En lugar de una cadena de margarita, esta forma de replicación tiene un suscriptor principal y varios suscriptores secundarios.

Al configurar HSR de HANA (instancias grandes) con conmutación por error automática, puede solicitar al equipo de administración de servicios de Microsoft que configure un dispositivo STONITH para sus servidores HANA (instancias grandes).

Recuperación ante desastres

Esta arquitectura admite la recuperación ante desastres entre HANA (instancias grandes) en diferentes regiones de Azure. Hay dos formas de admitir la recuperación ante desastres con HANA (instancias grandes):

• Replicación del almacenamiento. El contenido de almacenamiento principal se replica constantemente en los sistemas remotos de almacenamiento de recuperación ante desastres que están disponibles en el servidor de HANA (instancias grandes) de recuperación ante desastres designado. En la replicación de almacenamiento, la base de datos de HANA no se carga en memoria. Esta opción de recuperación ante desastres es más sencilla desde una perspectiva de administración. Para determinar si se trata de una estrategia adecuada, considere el tiempo de carga de la base de datos con respecto al Acuerdo de Nivel de Servicio de disponibilidad. La replicación de almacenamiento también permite realizar la recuperación en un momento dado. Si se ha configurado una recuperación ante desastres con varios fines (optimización de costo), debe adquirir almacenamiento adicional del mismo tamaño en la ubicación de recuperación ante desastres. Microsoft proporciona scripts de conmutación por error y de instantáneas de almacenamiento de autoservicio para la conmutación por error de HANA como parte de la oferta de HANA (instancias grandes).

• HSR de varios niveles o varios destinos con una tercera réplica en la región de recuperación ante desastres (donde la base de datos HANA está cargada en la memoria). Esta opción admite un tiempo de recuperación menor, pero no admite la recuperación en un momento dado. HSR requiere un sistema secundario. El tráfico de la replicación del sistema de HANA en el sitio de recuperación ante desastres se controla a través de servidores proxy, como nginx o tablas de IP. Como alternativa, se puede usar Global Reach para vincular circuitos de ExpressRoute, lo que permite a los usuarios autorizados conectarse directamente a la unidad de HANA (instancias grandes).

Optimización de costos

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.

Las SKU pueden afectar al modelo de facturación. A continuación se indican algunas otras consideraciones.

Máquinas virtuales

En esta arquitectura de referencia, las máquinas virtuales se usan para hospedar aplicaciones SAP, servicios SAP y servicios compartidos, como instancias de JumpBox de administración. Existen algunas SKU certificadas de HANA (instancias grandes). Las configuraciones dependen de la carga de trabajo, los recursos de CPU, la memoria deseada y el presupuesto.

Las SKU de HANA (instancias grandes) están disponibles como instancias reservadas de VM. Azure Reservations puede reducir el costo si puede acordar un período de uno o tres años. Las reservas de VM pueden reducir los costos hasta un 72 % en comparación con los precios de pago por uso. Dispone de una infraestructura de SAP HANA creada específicamente con proceso, almacenamiento y red. HANA (instancias grandes) se acopla con las redes y el almacenamiento NFS, y proporciona compatibilidad integrada para copias de seguridad a través de instantáneas de almacenamiento, alta disponibilidad y recuperación ante desastres, así como configuraciones de escalabilidad horizontal. Si la carga de trabajo no tiene un tiempo predecible de finalización o de consumo de recursos, considere la posibilidad de utilizar la opción de pago por uso.

Use la información general del plan de ahorro de Azure y combine con Azure Reservations. El plan de ahorro de Azure es un plan de ahorro de costes flexible que genera importantes ahorros en los precios de pago por uso. Acepte un contrato de uno o tres años y reciba descuentos en los servicios de proceso elegibles. Los ahorros se aplican a estos servicios de proceso independientemente de la región, el tamaño de instancia o el sistema operativo. Para más información, consulte documentación de planes de ahorro de Azure.

Use las VM de Azure Spot 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.

Para obtener más información, consulte la sección "SAP HANA en Azure (instancias grandes)" en Precios de HLI para máquinas virtuales SAP HANA.

Azure ExpressRoute

Para esta arquitectura, Azure ExpressRoute se usa como servicio de redes para crear conexiones privadas entre una red local y las redes virtuales de Azure. Las máquinas virtuales de Azure se conectan a HANA (instancias grandes) mediante otra conexión de ExpressRoute y una puerta de enlace de ExpressRoute. Se recomienda usar la SKU Alto rendimiento o Ultrarrendimiento.

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.

Backup

En función de sus requisitos empresariales, elija entre las distintas opciones disponibles.

Para obtener más información acerca de un enfoque de autoservicio para realizar copias de seguridad y más opciones proporcionadas con HANA (instancias grandes), consulte el artículo [Copia de seguridad y restauración][backup-restore].

Facilidad de uso

Supervise los recursos de HANA (instancias grandes) como la CPU, la memoria, el ancho de banda de red y el espacio de almacenamiento con SAP HANA Studio, SAP HANA Cockpit, SAP Solution Manager y otras herramientas nativas de Linux. Las SKU de Tipo I de HANA (instancias grandes) no se suministran con herramientas de supervisión integradas. Las SKU de Tipo II ofrecen herramientas de diagnóstico integradas previamente para el registro de la actividad del sistema y la solución de problemas.

Microsoft ofrece herramientas y recursos básicos que le ayudarán a supervisar HANA (instancias grandes) en Azure. El equipo de soporte técnico de Microsoft también puede ayudarle a solucionar problemas técnicos.

Seguridad

• Desde finales de 2018, el almacenamiento de HANA (instancias grandes) se cifran de forma predeterminada.

• Los datos en tránsito entre HANA (instancias grandes) y las VM no se cifran. Para cifrar la transferencia de datos, habilite el cifrado específico de la aplicación. Consulte la Nota de SAP 2159014 - FAQ: SAP HANA Security (Preguntas más frecuentas: seguridad de SAP HANA).

• El aislamiento proporciona seguridad entre los inquilinos en el entorno multiinquilino de HANA (instancias grandes). Los inquilinos se aíslan mediante su propia VLAN.

• Los procedimientos recomendados de seguridad de la red de Azure proporcionan una guía útil.

• Como con cualquier implementación, se recomienda la protección del sistema operativo, incluida la protección de la imagen de SUSE Linux para SAP en Azure.

• Por motivos de seguridad física, el acceso a los centros de datos de Azure está limitado solo a personal autorizado. Ningún cliente puede acceder a los servidores físicos.

Para más información, consulte el artículo SAP HANA Security: An Overview (Seguridad de SAP HANA: información general). (Para acceder se requiere una cuenta de SAP Service Marketplace).

Comunidades

Las comunidades pueden responder preguntas y ayudarle a configurar una implementación correcta. Tenga en cuenta lo siguiente.

• Blog Ejecución de aplicaciones SAP en la plataforma de Microsoft
• Stack Overflow SAP

Colaboradores

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

Autor principal:

• Ben Trinh | Arquitecto principal

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

Recursos relacionados

Puede examinar los siguientes escenarios de ejemplo de Azure que muestran soluciones específicas que usan algunas tecnologías similares:

• Ejecución de cargas de trabajo SAP de producción mediante una instancia de Oracle Database en Azure
• Entornos de desarrollo y pruebas para cargas de trabajo SAP en Azure