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:
- El documento de prácticas recomendadas de SAP Building High Availability for SAP NetWeaver and SAP HANA on Linux (Compila alta disponibilidad para SAP NetWeaver y SAP HANA en Linux)
- Documentación de SAP NetWeaver
Esta guía de planificación se centra solo en HA para SAP NetWeaver y no abarca HA 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.
El clúster usa el SAP Standalone Enqueue Server 2 (ENSA2). Para obtener una descripción de un clúster que usa la versión anterior del Standalone Enqueue Server (ENSA1), consulta Arquitectura del Standalone Enqueue Server (ENSA1).
La instancia activa de Central Services está en el host principal. La instancia activa de Enqueue Replication Server 2 (ERS) se encuentra en el host secundario. Los servicios centrales y ERS tienen 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.
Para obtener más información sobre Standalone Enqueue Server 2 en las opciones de configuración de HA, consulta la Nota de SAP 2711036: Uso de Standalone Enqueue Server 2 en un entorno de alta disponibilidad.
Arquitectura del Standalone Enqueue Server (ENSA1)
En el siguiente diagrama, la instancia activa de Central Services, que contiene la administración de bloqueo, o el servicio Enqueue, y la instancia inactiva del 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.
En el caso de una falla, el software de agrupamiento en clústeres de HA debe reubicar el Standalone Enqueue Server en el nodo en el que se ejecuta Enqueue Replication Server para conservar la información de bloqueo. Considera actualizar tu sistema para usar Standalone Enqueue Server 2, si tu versión de software lo admite. Para obtener más información, consulta la Nota de SAP 2630416: Compatibilidad con Standalone Enqueue Server 2.
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 Confiabilidad.
Opciones de agrupamiento en clústeres de HA para sistemas 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 compartido para sistemas SAP de alta disponibilidad 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 de alta disponibilidad o discos persistentes zonales replicados.
Para una solución de almacenamiento compartido y con alta disponibilidad, puede usar Google Cloud Filestore o soluciones de archivos compartidos de terceros, como NetApp Cloud Volumes Service para Google Cloud.o NetApp Cloud Volumes ONTAP.
El nivel empresarial de Filestore se puede usar para implementaciones de alta disponibilidad multizona y el nivel Básico de Filestore se puede usar para implementaciones de zona única.
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:
- Soluciones de uso compartido de archivos para SAP en Google Cloud
- Servidores de archivos en Compute Engine
- Opciones de almacenamiento de Compute Engine
Opciones de Herramientas de redes para sistemas 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:
- Compatibilidad con la conmutación por error del Balanceador de cargas de red de transferencia interno (recomendado)
- Rutas estáticas de Google Cloud
- Direcciones IP de alias de Google Cloud
Implementaciones de VIP del balanceador de cargas de red de transferencia 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 balanceador de cargas de red de transferencia 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 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.
Para obtener más información sobre la compatibilidad con la conmutación por error, consulta Configura la conmutación por error para balanceadores de cargas de red de transferencia internos.
Para implementar un clúster con alta disponibilidad mediante la implementación de la VIP del balanceador de cargas, consulta:
- Terraform: Guía de configuración de clústeres de alta disponibilidad de SAP HANA
- Guía de configuración del clúster de HA para SAP HANA en RHEL
- Guía de configuración de clústeres de alta disponibilidad para SAP HANA en SLES
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 balanceador de cargas de red de transferencia 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 balanceador de cargas de red de transferencia interno sin cambiar tu dirección VIP. Los alias de direcciones IP y los balanceadores de cargas de red de transferencia 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.
Configura clústeres de alta disponibilidad para SAP NetWeaver en Google Cloud
Google Cloud proporciona un archivo de configuración de Terraform que puedes usar para automatizar la implementación de sistemas SAP NetWeaver con alta disponibilidad o puedes implementar y configurar tus sistemas de SAP NetWeaver con alta disponibilidad de forma manual.
Para automatizar la implementación de los sistemas de SAP NetWeaver con alta disponibilidad, completa el archivo de configuración de Terraform y usa los comandos estándar de Terraform para aplicar las configuraciones. Para obtener instrucciones de implementación, consulta los siguientes vínculos:
- Terraform: Guía de configuración de clústeres de alta disponibilidad para SAP NetWeaver en SLES
- Terraform: Guía de configuración de clústeres de alta disponibilidad para SAP NetWeaver en RHEL
El método de implementación automatizada implementa la infraestructura de Google Cloud para un sistema SAP NetWeaver que es completamente compatible con SAP y que cumple las prácticas recomendadas de SAP y Google Cloud.
Para SAP NetWeaver, el método de implementación automatizada implementa un clúster de Linux de alta disponibilidad optimizado para el rendimiento que incluye las siguientes funciones:
- Conmutación por error automática
- Reinicio automático
- Una reserva de la dirección IP virtual (VIP) que especificas
- Compatibilidad con la conmutación por error proporcionada por el balanceo de cargas TCP/UDP interno, que administra el enrutamiento desde la dirección IP virtual (VIP) a los nodos del clúster de alta disponibilidad
- Una regla de firewall que permita que las verificaciones de estado de Compute Engine supervisen las instancias de VM del clúster
- El administrador de recursos del clúster de alta disponibilidad de Pacemaker
- Un mecanismo de protección de Google Cloud, el agente de protección
fence_gce - Una VM con los discos persistentes necesarios para cada instancia de SAP NetWeaver.
A fin de obtener instrucciones para implementar y configurar de forma manual un clúster con alta disponibilidad en Google Cloud para SAP NetWeaver, consulta:
- Guía de configuración manual de clústeres de alta disponibilidad para SAP NetWeaver en SLES
- Guía de configuración de clústeres de alta disponibilidad para SAP NetWeaver en RHEL