Guía de planificación de alta disponibilidad para SAP NetWeaver en Google Cloud

En esta guía, se proporciona una descripción general de las opciones, las recomendaciones y los conceptos generales que debes conocer antes de implementar un sistema SAP NetWeaver de alta disponibilidad (HA) en Google Cloud.

En esta guía, se da por sentado que ya conoces las prácticas y los conceptos necesarios para implementar un sistema de SAP NetWeaver de alta disponibilidad. Por lo tanto, la guía se centra sobre todo en lo que necesitas saber para implementar este sistema en Google Cloud.

Si necesitas saber más sobre los conceptos y las prácticas generales que se requieren para implementar un sistema de SAP NetWeaver de HA, consulta lo siguiente:

Esta guía de planificación se centra solo en la alta disponibilidad para SAP NetWeaver y no abarca la misma para los sistemas de bases de datos. Si deseas obtener información sobre la alta disponibilidad para SAP HANA, consulta la guía de planificación de alta disponibilidad de SAP HANA.

Arquitectura de implementación

En el siguiente diagrama, se muestra un clúster de HA básico de Linux que usa el software de clúster de Pacemaker.

En el clúster, se incluyen dos hosts: un host principal y uno secundario. Cada host se encuentra en una zona diferente dentro de la misma región.

La instancia activa de Central Services y la instancia inactiva de Enqueue Replication Server (ERS) se encuentran en el host principal. La instancia activa de ERS y la instancia inactiva de Central Services están en el host secundario. Cada par de Central Services y ERS tiene su propia dirección IP virtual (VIP). En el diagrama, “Central Services” representa ABAP SAP Central Services o, para una pila de Java, SAP Central Services.

Una configuración básica de HA para SAP NetWeaver en Google Cloud con dos hosts, cada uno en una zona diferente

La alta disponibilidad de la infraestructura de Google Cloud

Google Cloud tiene una alta disponibilidad por su diseño, con una infraestructura redundante de centros de datos en todo el mundo que contienen zonas diseñadas para ser independientes unas de otras. Por lo general, las zonas tienen planos de control, alimentación, enfriamiento y Herramientas de redes que están aislados de otras zonas. Si ocurriera un solo evento de falla, en la mayoría de los casos, afectaría a una sola zona.

En algunos casos, es posible que cumplas con los requisitos de disponibilidad sin implementar todas las protecciones locales y tradicionales contra fallas de hardware, almacenamiento y Herramientas de redes, lo que podría ahorrarte tiempo y dinero.

Antes de diseñar y, además, implementar tu estrategia de alta disponibilidad en Google Cloud, revisa los Acuerdos de Nivel de Servicio de Google Cloud.

Para obtener información general sobre la confiabilidad, privacidad y seguridad de Google Cloud, consulta Infraestructura de confianza.

Opciones de agrupamiento en clústeres de HA para sistemas de SAP en Google Cloud

Debes definir un clúster de alta disponibilidad (HA) para SAP NetWeaver en Google Cloud mediante los mismos tipos de software de clústeres de HA de terceros que podrías usar en una instalación local. Con el software del clúster de HA, se supervisa el estado de los sistemas y se administra la conmutación por error cuando ocurren problemas.

Puedes usar varias soluciones de software de clúster de HA, como las siguientes:

  • Red Hat Enterprise Linux (RHEL) para soluciones de SAP
  • SUSE Linux Enterprise Server (SLES) para aplicaciones de SAP
  • Clústeres de conmutación por error de Windows Server

Software de agrupación en clústeres de HA de Linux

Las versiones recientes de RHEL y SLES incluyen compatibilidad integrada con HA que está habilitada en particular para Google Cloud. A fin de verificar si tu versión de Linux incluye compatibilidad con HA habilitada para Google Cloud, busca “GCP-HA” en la tabla en Compatibilidad con sistemas operativos para SAP NetWeaver en Google Cloud.

Software de agrupación en clústeres de HA de Windows

En Windows Server, debes usar el clúster de conmutación por error de Windows Server (WSFC) para crear el clúster de HA, como se describe en Ejecuta clústeres de conmutación por error de Windows Server.

En Google Cloud, Cloud Load Balancing administra el enrutamiento del tráfico entrante al nodo activo en un clúster de WSFC, que no requiere una implementación de un alias de IP o una VIP de ruta estática.

Cloud Load Balancing usa verificaciones de estado para determinar el nodo activo.

Implementaciones de HA de SAP NetWeaver, zonas y regiones de Google Cloud

Implementa los nodos de tu clúster de HA en dos o más zonas de Compute Engine dentro de la misma región. La implementación de los nodos en diferentes zonas garantiza que se encuentren en diferentes máquinas físicas y también protege contra la posibilidad poco probable de una falla zonal.

Mantener las zonas dentro de la misma región garantiza que los nodos estén lo suficientemente cerca, en términos geográficos, y así cumplir con los requisitos de latencia de SAP para los sistemas de alta disponibilidad.

Implementaciones de HA de SAP NetWeaver y máquinas virtuales de Compute Engine

Para permitir una alta disponibilidad, las VM de Compute Engine están respaldadas por la migración en vivo y el reinicio automático.

Migración en vivo de Compute Engine

Compute Engine supervisa el estado de la infraestructura subyacente. Cuando ocurre un evento de mantenimiento de infraestructura, Compute Engine migra la instancia de forma automática y, si es posible, la mantiene en ejecución durante la migración. La intervención del usuario no es obligatoria.

En el caso de interrupciones importantes, es posible que haya una pequeña demora entre el momento en que la instancia falla y el momento en que vuelve a estar disponible.

En la mayoría de los casos, los eventos de migración en vivo ocurren sin afectar el clúster de HA. Sin embargo, simula una migración en vivo del host activo para probar tu clúster de HA después de que se haya configurado y los sistemas estén en ejecución, en especial si tu supervisión del clúster de HA está configurada con un umbral de conmutación por error bajo. Para obtener más información sobre cómo simular un evento de migración en vivo, consulta Prueba las políticas de disponibilidad.

Una instancia migrada es idéntica a la instancia original, incluido el ID de la instancia, la dirección IP privada y todos los metadatos y el almacenamiento de la instancia.

De forma predeterminada, las instancias estándar están configuradas para migrar en vivo. Te recomendamos que no cambies esta configuración.

Para obtener más información, consulta Migración en vivo.

Reinicio automático de Compute Engine

Si la instancia está configurada para finalizar cuando hay un evento de mantenimiento o si falla debido a un problema del hardware subyacente, puedes configurar Compute Engine a fin de reiniciar la instancia de forma automática. De forma predeterminada, las instancias se configuran para que se reinicien de forma automática. Te recomendamos que no cambies esta configuración.

Para obtener más información sobre el reinicio automático, consulta Reinicio automático.

Opciones de almacenamiento para sistemas de SAP de HA en Google Cloud

El sistema de archivos global de SAP NetWeaver es un punto único de fallo que debe estar disponible para todas las instancias de SAP NetWeaver en tu sistema de HA. Para garantizar la disponibilidad del sistema de archivos global en Google Cloud, puedes usar almacenamiento compartido con alta disponibilidad o discos persistentes zonales replicados.

Para una solución de almacenamiento compartido con alta disponibilidad, puedes usar soluciones de archivos compartidos de terceros, como NetApp Cloud Volumes. Google Cloud proporciona Filestore, una solución de servidor de archivos NFS, pero por el momento, no proporciona un servidor de archivos con alta disponibilidad entre zonas.

Si quieres replicar discos persistentes zonales para sistemas Linux, puedes usar un dispositivo de bloques replicados distribuidos (DRBD) a fin de replicar los discos persistentes que contengan el sistema de archivos global de SAP entre los nodos del clúster con alta disponibilidad.

Aunque los discos persistentes regionales de Compute Engine ofrecen almacenamiento en bloque replicado de forma síncrona en todas las zonas, por el momento, no son compatibles con los sistemas de SAP NetWeaver con alta disponibilidad.

Para obtener más información sobre las opciones de almacenamiento en Google Cloud, consulta lo siguiente:

Opciones de Herramientas de redes para sistemas de SAP de HA

Cuando configuras la red para el clúster de HA, además de completar los pasos en Crea una red, debes completar las siguientes tareas específicas de HA:

  • Elige tu implementación VIP para sistemas Linux, como se describe en la siguiente sección. Los sistemas Windows usan un balanceador de cargas interno, que no requiere las mismas soluciones VIP que los sistemas Linux.
  • Define la ruta de acceso de comunicación entre la instancia de SAP Central Services y la instancia de Enqueue Replication Server.
  • Define reglas de firewall para admitir las rutas de acceso de comunicación definidas.

Implementación de IP virtual en Google Cloud

Un clúster con alta disponibilidad usa una dirección IP (VIP) virtual o flotante para mover su carga de trabajo de un nodo del clúster a otro en caso de que se genere una falla inesperada o si se realiza mantenimiento programado. La dirección IP de la VIP no cambia, por lo que las aplicaciones cliente no saben que el trabajo se entrega mediante un nodo diferente.

Las VIP también se conocen como direcciones IP flotantes.

En Google Cloud, las VIP se implementan de una manera un poco diferente que en las instalaciones locales, ya que cuando se produce una conmutación por error, no se pueden usar las solicitudes ARP injustificadas para anunciar el cambio. En cambio, puedes implementar una dirección VIP para un clúster de SAP con alta disponibilidad mediante uno de los siguientes métodos:

Implementaciones de VIP del balanceo de cargas de TCP/UDP interno

Por lo general, un balanceador de cargas distribuye el tráfico del usuario entre varias instancias de las aplicaciones a fin de distribuir la carga de trabajo entre varios sistemas activos y ofrecer protección frente a una demora en el procesamiento o una falla en cualquier instancia.

El servicio de balanceo de cargas de TCP/UDP interno también proporciona asistencia de conmutación por error que puedes usar con las verificaciones de estado de Compute Engine para detectar fallas, activar la conmutación por error y redirigir el tráfico a un nuevo sistema SAP principal en un clúster con alta disponibilidad nativo del SO.

La asistencia de conmutación por error del balanceo de cargas de TCP/UDP interno es la implementación de VIP recomendada por diversos motivos, incluidos los siguientes:

  • El balanceo de cargas en Compute Engine ofrece un ANS del 99.99% de disponibilidad.
  • El balanceo de cargas admite clústeres con alta disponibilidad en varias zonas, que protegen contra fallas de la zona con tiempos de conmutación por error entre zonas predecibles.
  • El uso del balanceo de cargas reduce el tiempo necesario para detectar y activar una conmutación por error, que suele ser unos segundos después de la falla. Los tiempos de la conmutación por error promedio dependen de los tiempos de la conmutación por error de cada componente del sistema con alta disponibilidad, que puede incluir hosts, sistemas de base de datos, sistemas de aplicaciones y más.
  • Usar el balanceo de cargas simplifica la configuración del clúster y reduce las dependencias.
  • A diferencia de una implementación de VIP en la que se usan rutas, con los balanceos de cargas, puedes usar rangos de IP de tu propia red de VPC, lo que te permite reservarlos y configurarlos según sea necesario.
  • El balanceo de cargas se puede usar con facilidad para redirigir el tráfico a un sistema secundario en caso de que se generen interrupciones por mantenimiento planificadas.

Cuando creas una verificación de estado para una implementación del balanceador de cargas de una VIP, debes especificar el puerto del host que la verificación de estado prueba para determinar el estado del host. Para un clúster de SAP con alta disponibilidad, especifica un puerto de host de destino que esté en el rango privado 49152-65535 para evitar conflictos con otros servicios. En la VM del host, configura el puerto de destino con un servicio de asistencia secundario, como la utilidad socat o HAProxy.

Para los clústeres de bases de datos en los que el sistema en espera secundario permanece en línea, la verificación de estado y el servicio de asistencia permiten que el balanceo de cargas dirija el tráfico al sistema en línea que en ese momento funciona como sistema principal en el clúster.

Mediante el servicio de asistencia y la redirección de puertos, puedes activar una conmutación por error para el mantenimiento de software planificado en tus sistemas SAP.

Puedes cambiar el comportamiento de enrutamiento predeterminado para los nodos del clúster con alta disponibilidad si quitas la VIP de las tablas de enrutamiento del SO Linux local en cada nodo del clúster. Cuando se quita la entrada, los mensajes enviados desde un nodo de clúster hacia la VIP se dirigen primero a la puerta de enlace predeterminada y, luego, a la VIP. Luego, el balanceador de cargas trata los mensajes como cualquier otro tráfico de frontend y los reenvía al nodo que por el momento se aloja como sistema principal activo.

A fin de obtener más información sobre la compatibilidad de la conmutación por error del balanceo de cargas de TCP/UDP interno, consulta Configura la conmutación por error para el balanceo de cargas de TCP/UDP interno.

Para implementar un clúster con alta disponibilidad mediante la implementación de la VIP del balanceador de cargas, consulta:

Implementaciones de VIP de la ruta estática

La implementación de la ruta estática también proporciona protección contra fallas zonales, pero requiere que uses una VIP por fuera de los rangos de IP de tus subredes de VPC existentes en las que residen las VM. Por lo tanto, también debes asegurarte de que la VIP no entre en conflicto con ninguna dirección IP externa en tu red ampliada.

Las implementaciones de rutas estáticas también pueden generar cierta complejidad cuando se usan con configuraciones de VPC compartidas, que están destinadas a segregar la configuración de red a un proyecto host.

Si usas una implementación de ruta estática para la VIP, consulta con tu administrador de red a fin de definir una dirección IP adecuada para una implementación de ruta estática.

Implementaciones de VIP de IP de alias

Estas no se recomiendan para implementaciones con alta disponibilidad multizonal porque, si una zona falla, la reasignación de la IP de alias para un nodo en una zona diferente se puede demorar. En cambio, puedes implementar la VIP con un balanceo de cargas de TCP/UDP interno compatible con la conmutación por error.

Si implementas todos los nodos del clúster con alta disponibilidad de SAP en la misma zona, puedes usar una IP de alias a fin de implementar una VIP para el clúster con alta disponibilidad.

Si tienes clústeres de SAP con alta disponibilidad de múltiples zonas existentes que usan una implementación de IP de alias para la VIP, puedes migrar a una implementación de balanceo de cargas de TCP/UDP interno sin cambiar tu dirección VIP. La IP de alias y el balanceo de cargas de TCP/UDP interno usan rangos de IP de tu red de VPC.

Si bien las direcciones IP de alias no se recomiendan para implementaciones VIP en clústeres con alta disponibilidad multizonales, tienen otros casos de uso en implementaciones de SAP. Por ejemplo, se pueden usar a fin de proporcionar un nombre de host lógico y asignaciones de IP para implementaciones flexibles de SAP, como las que administra SAP Landscape Management.

Prácticas recomendadas generales para las VIP en Google Cloud

A fin de obtener más información sobre las VIP en Google Cloud, consulta Prácticas recomendadas para las direcciones IP flotantes.