IBM Cloud Docs
SAP Netweaver 7.x con SAP HANA en configuración de alta disponibilidad

SAP Netweaver 7.x con SAP HANA en configuración de alta disponibilidad

La arquitectura IBM Cloud® proporciona capacidades técnicas superiores, como un entorno definible por software, fundamental para una infraestructura de nube, interfaces programables y cientos de configuraciones de hardware y red. Está diseñado para ofrecer un mayor nivel de flexibilidad al mezclar servidores virtuales y dedicados para adaptarse a diversas cargas de trabajo, automatización de interfaces y opciones de implantación híbrida. IBM Cloud La oferta de infraestructura certificada SAP para SAP HANA y SAP NetWeaver le proporciona una selección óptima de servidores de metal desnudo y basados en virtualización en los que se ejecuta la pila de software SAP.

SAP HANA es una de las varias bases de datos que pueden instalarse en SAP NetWeaver en el sitio IBM Cloud®. SAP HANA es una base de datos en memoria instalada en un servidor de bases de datos dedicado. Las principales arquitecturas de implantación de SAP HANA son sistemas de un solo host o de múltiples hosts. IBM Cloud está certificado para ejecutar servidores de aplicaciones SAP NetWeaver ABAP, Java, y SAP productos basados en estas pilas de servidores de aplicaciones.

SAP Netweaver 7.x despliegue en configuración HA multizona

La siguiente arquitectura de referencia describe implementaciones de Alta Disponibilidad en IBM Cloud VPC, considerando SAP Netweaver Application Servers con SAP HANA Database workloads running on Virtual Server Instances.

Figura 1. SAP Despliegue de Netweaver en configuración HA multizona
SAP Despliegue de Netweaver en configuración HA multizona

El despliegue del sistema SAP en Alta Disponibilidad se basa en dos configuraciones de clúster de marcapasos:

  • un clúster protege un único punto de fallo de las aplicaciones SAP y de los servicios centrales.
  • el segundo clúster garantiza la disponibilidad de la base de datos SAP HANA.

SAP componentes técnicos

En esta configuración se despliegan los siguientes componentes técnicos de SAP:

  • SAP HANA base de datos. Dos instalaciones en 2 VSI con configuración de replicación para soporte HA.
  • SAP Instancia ASCS, instalada en uno de los nodos. Esta instancia contiene el Servidor de Mensajes y el proceso Enqueue Server. Se utiliza para gestionar bloqueos, intercambiar mensajes y equilibrar la carga de trabajo en el sistema SAP.
  • SAP Instancia de ERS, instalada en un nodo opuesto. Este servidor de replicación de colas es una instancia obligatoria en un escenario de HA, con la función de preservar una réplica de la tabla de colas en la memoria local.
  • SAP PAS, el servidor de aplicaciones primario con diálogo y procesamiento por lotes.
  • SAP AAS, un servidor de Aplicaciones Adicionales, instalado en un nodo opuesto relacionado con el PAS.
  • SAP Router (opcional), proporciona conexiones seguras al VSI y conexiones remotas para el soporte de SAP AG Remote Services.

Servicios y componentes de la VPC

IBM Cloud VPC Servicios y componentes de apoyo a la configuración de alta disponibilidad de SAP:

  • Servicios de red (VPN, Public Gateway ) que proporcionan acceso a los clientes y conectividad a Internet
  • Jumphost: se utiliza para acceder, gestionar y administrar instancias de servidor virtual SAP desde la misma ZONA del cliente directamente desde sus instalaciones.
  • Application Load Balancer, con la función de distribuir el tráfico para las instancias virtuales que forman parte de los clústeres SAP y HANA
  • DNS Services
  • FileShares proporciona almacenamiento de archivos basado en NFS, que se utiliza como almacenamiento compartido para satisfacer las necesidades de las configuraciones de sistemas de archivos SAP Netweaver.

Los clientes de la red de cara al cliente (CFN) utilizan una IP flotante para acceder a las instancias de servidor virtual dentro de IBM Cloud. Las instancias de servidor virtual se alojan en zonas de disponibilidad (centros de datos) de regiones geográficas.

Las instancias del servidor virtual SAP pueden estar en una zona de seguridad separada, pero deben estar en la misma región IBM Cloud. La conexión de cliente con el host de salto sigue las mismas reglas que la conexión directa desde el entorno local del cliente con las instancias de SAP de la instancia del servidor virtual. La conexión utiliza la IP flotante y las reglas del cortafuegos del grupo de seguridad 1 de una subred pública designada. En esta arquitectura, hay dos grupos de seguridad definidos; esta organización es el método más sencillo para separar las subredes públicas y privadas. Puede añadir más grupos de seguridad si necesita más aislamiento.

Aspectos clave de la alta disponibilidad

La redundancia de componentes críticos, los mecanismos automatizados de conmutación por error y la integración con tecnologías de clustering y replicación de sistemas como Pacemaker y SAP HANA System Replication, son aspectos importantes para la arquitectura de referencia de Alta Disponibilidad.

Para mantener el acceso y la disponibilidad del procesamiento de aplicaciones para los usuarios finales, se recomienda instalar servidores de aplicaciones redundantes en SAP. Esto puede obtenerse utilizando un Servidor de Aplicaciones Primario y un Servidor de Aplicaciones Adicional utilizando 2 VSIs.

Si se produce un fallo y falla uno de los nodos, los usuarios pierden el acceso al servidor de aplicaciones que ha fallado. Si se utilizan grupos de inicio de sesión para equilibrar la carga, los usuarios pueden volver a conectarse y se les redirige al servidor de aplicaciones que queda disponible.

Otros puntos de fallo son la instancia ASCS y la base de datos SAP HANA:

  • La instancia ASCS debe desplegarse en un clúster de alta disponibilidad. De esta forma, se protegen los bloqueos de la tabla de enqueue gestionados por el Servidor de Enqueue. Para conseguirlo, se despliega una instancia de ERS en otra VSI y se crea una copia replicada de la tabla de bloqueo en su memoria de instancia. Si el ASCS falla, la tabla de bloqueos puede reconstruirse a partir de la copia replicada en la instancia ERS.

El Sistema SAP Netweaver 7.x está ejecutando por defecto una configuración ENSA1, lo que significa que en un cluster de 2 nodos, ASCS falla sobre el mismo nodo donde se está ejecutando ERS para poder adjuntar una copia de la Tabla de Bloqueo ENQ desde la instancia ERS usando mecanismos de memoria compartida.

  • SAP HANA el sistema de base de datos también se protege instalando las instancias de base de datos en un clúster de alta disponibilidad Pacemaker. El entorno se construye como un clúster estándar de alta disponibilidad de dos nodos, en el que uno está activo y el otro funciona como segundo nodo con sincronización continua de datos. La base de datos SAP HANA está configurada utilizando HANA System Replication (HSR) nativo en modo síncrono (mode=sync con log-replay activado), lo que garantiza que todos los datos comprometidos se repliquen desde el nodo primario al secundario prácticamente en tiempo real. La replicación se establece entre dos instancias SAP HANA de tamaño idéntico. Aunque SAP HANA admite arquitecturas de escalado vertical y horizontal para gestionar grandes cargas de trabajo, esta implantación se centra en el modelo de escalado vertical.

Estructura de montaje simple (SUSE Linux )

En las configuraciones de HA tradicionales, el clúster gestiona el montaje y desmontaje de los sistemas de archivos SAP durante las operaciones de conmutación por error. La arquitectura de montaje simple asume que estos sistemas de archivos no necesitan ser conmutados ni controlados por el clúster pacemaker. Esta estructura se basa en una red externa de archivos compartidos.

En lugar de un número de sistemas de archivos necesarios por sistema SAP más un número de sistemas de archivos por instancia SAP, la configuración de montaje simple sólo necesita una disposición de 2 sistemas de archivos simples: " [/sapmnt/SID] " y " [/usr/sap/SID] ".

Tanto los recursos compartidos de NFS como los directorios de instancia pueden montarse estáticamente en todos los nodos en el momento del arranque, utilizando mecanismos estándar del sistema operativo como systemd o fstab. Además, el archivo " /usr/sap/sapservices” reside localmente en cada nodo del clúster. Para mantener cierta compatibilidad con configuraciones de HA anteriores, esta arquitectura de referencia sigue utilizando la disposición "antigua" del sistema de archivos, pero la mayoría de los archivos compartidos se montan en ambos nodos para implementar el enfoque de montaje simple.

Figura 2. Arquitectura de montaje simple en SUSE Linux
Arquitectura de montaje simple en SUSE Linux

SAP HANA ampliación de la replicación del sistema (escenarios de alta disponibilidad)

SAP HANA La replicación de sistemas en una configuración de alta disponibilidad a escala admite varias configuraciones de implantación, cada una de ellas alineada con distintos requisitos empresariales y operativos, como la optimización del rendimiento, el control de costes y la continuidad del servicio (RTO).

  • Rendimiento optimizado de HANA: la instalación de SAP HANA en el primer nodo se sincroniza (sincronización con modo de funcionamiento log-replay) con la base de datos SAP HANA instalada en el segundo nodo. El tiempo de recuperación es muy corto, ya que la base de datos del segundo nodo está configurada para precargar las tablas en memoria.
  • Rendimiento optimizado de HANA, sitio secundario habilitado para lectura: un escenario de rendimiento optimizado pero con la posibilidad de permitir el acceso de lectura en el sitio secundario de la base de datos. También se denomina configuración activo-activo.
  • Optimización de costes de HANA: en este escenario, la base de datos de reserva o secundaria de HANA se coloca con un sistema de base de datos no productivo, por ejemplo, un sistema de pruebas o desarrollo. Cuando se produce una adquisición, el sistema no productivo debe detenerse para liberar los recursos de hardware necesarios para ejecutar la instancia productiva de HANA promovida. En este caso, la precarga de la mesa está desactivada y el tiempo de recepción es mayor.

Alta disponibilidad en entornos MultiZone (MZ) y SingleZone (SZ)

El despliegue de recursos en varias zonas dentro de una región permite una alta disponibilidad y el aislamiento de fallos, ya que las cargas de trabajo pueden seguir funcionando incluso si una zona experimenta un fallo. Más información sobre las zonas en IBM Cloud aquí. Sin embargo, también es posible desplegar los recursos en una configuración de HA utilizando una única zona dentro de una región. El siguiente esquema de referencia ilustra este enfoque.

  • Sólo hay una subred privada desplegada
  • SAP HANA es un clúster de 2 nodos en el mismo segmento de red
  • SAP Las instancias de servicios ASCS/ERS forman parte del mismo segmento de red y están ubicadas con los servidores de aplicaciones SAP, en 2 nodos VSI.
  • Los nombres de host virtuales son direccionados por los clientes y las aplicaciones también a través de un Application Load Balancer con la ayuda del servicio DNS.

Un grupo de colocación de energía junto con una estrategia de colocación proporciona protección adicional para las máquinas virtuales en una única zona y garantiza que cada instancia se coloca en hosts informáticos con fuentes de alimentación y dispositivos de red independientes. Consulte la información de IBM Cloud relativa a los grupos de colocación.

Figura 3. SAP NetWeaver 7.x Despliegue de HANA en configuración HA zona única
SAP NetWeaver 7.x Despliegue de HANA en configuración HA zona única