Guía de planificación de alta disponibilidad de SAP HANA

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 HANA con alta disponibilidad (HA) en Google Cloud.

En esta guía, se da por sentado que ya conoces las prácticas y los conceptos generales necesarios para implementar un sistema SAP HANA con 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 SAP HANA con alta disponibilidad, consulta:

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

Esta guía no reemplaza ninguna documentación proporcionada por SAP.

Opciones de alta disponibilidad para SAP HANA en Google Cloud

Puedes usar una combinación de funciones de Google Cloud y SAP en el diseño de una configuración de alta disponibilidad para SAP HANA que puede manejar fallas en los niveles de infraestructura y de software. En las siguientes tablas, se describen las funciones de SAP y Google Cloud que se usan para proporcionar alta disponibilidad.

Función Descripción
Migración en vivo de Compute Engine

Compute Engine supervisa el estado de la infraestructura subyacente y, automáticamente, migra la instancia lejos de un evento de mantenimiento de infraestructura. La intervención del usuario no es obligatoria.

Compute Engine mantiene la instancia en ejecución durante la migración, si es posible. En el caso de interrupciones importantes, puede haber una pequeña demora entre el momento en que la instancia falla y el momento en que vuelve a estar disponible.

En los sistemas de varios hosts, los volúmenes compartidos, como el volumen “/hana/shared” usado en la guía de implementación, son discos persistentes conectados a la VM que aloja el host principal y se activan por NFS en los hosts de trabajador. Durante la migración en vivo del host principal, no se puede acceder al volumen de NFS durante algunos segundos. Cuando se reinicia el host principal, el volumen de NFS vuelve a funcionar en todos los hosts y la operación normal se reanuda automáticamente.

Una instancia recuperada es idéntica a la instancia original, incluidos 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 automáticamente.

De forma predeterminada, las instancias se configuran para que se reinicien automáticamente. Te recomendamos que no cambies esta configuración.

Reinicio automático del servicio de SAP HANA

El reinicio automático del servicio de SAP HANA es una solución de recuperación ante fallas que proporciona SAP.

SAP HANA tiene muchos servicios configurados que se ejecutan todo el tiempo para varias actividades. Cuando alguno de estos servicios se inhabilita debido a un error de software o un error humano, la función controladora de reinicio automático del servicio de SAP HANA la reinicia automáticamente. Cuando se reinicia el servicio, se vuelven a cargar todos los datos necesarios en la memoria y se reanuda su funcionamiento.

Copias de seguridad de SAP HANA

Las copias de seguridad de SAP HANA crean copias de los datos de la base de datos que se pueden usar para reconstruir la base de datos en un momento determinado.

Para obtener más información sobre el uso de las copias de seguridad de SAP HANA en Google Cloud, consulta la guía de operaciones de SAP HANA.

Replicación del almacenamiento de SAP HANA

La replicación del almacenamiento de SAP HANA proporciona asistencia de recuperación ante desastres a nivel de almacenamiento a través de ciertos socios de hardware. La replicación del almacenamiento de SAP HANA no es compatible con Google Cloud. En su lugar, puedes considerar usar instantáneas de discos persistentes de Compute Engine.

A fin de obtener más información sobre el uso de instantáneas de discos persistentes para crear copias de seguridad de los sistemas SAP HANA en Google Cloud, consulta la guía de operaciones de SAP HANA.

Conmutación por error automática del host de SAP HANA

La conmutación por error automática del host de SAP HANA es una solución de recuperación ante fallas local que requiere uno o más hosts de SAP HANA en espera en un sistema de escalamiento horizontal. Si uno de los hosts principales falla, la conmutación por error automática del host activa el host en línea de reserva y reinicia el host con errores como host de reserva.

Para obtener más información, consulta los siguientes vínculos:

Replicación del sistema SAP HANA

La replicación del sistema SAP HANA te permite configurar uno o más sistemas para que reemplacen el sistema principal en situaciones de alta disponibilidad o recuperación ante desastres. Puedes ajustar la replicación para satisfacer tus necesidades en términos de rendimiento y tiempo de conmutación por error.

Clústeres con alta disponibilidad nativos del SO para SAP HANA en Google Cloud

El agrupamiento en clústeres del sistema operativo Linux proporciona conocimiento de la aplicación y del invitado para el estado de la aplicación y automatiza las acciones de recuperación en caso de que se genere una falla.

Aunque por lo general los principios de los clústeres con alta disponibilidad que se aplican en entornos que no son de nube se aplican en Google Cloud, hay algunas diferencias en la forma de implementar, por ejemplo, las IP virtuales y la protección.

Puedes usar distribuciones de Linux de alta disponibilidad de Red Hat o SUSE para tu clúster con alta disponibilidad para SAP HANA en Google Cloud.

Agentes de recursos del clúster

Red Hat y SUSE proporcionan agentes de recursos para Google Cloud con sus implementaciones con alta disponibilidad del software del clúster de Pacemaker. Los agentes de recursos para Google Cloud administran la protección STONITH, las VIP que se implementan con rutas o IP de alias, y las acciones de almacenamiento.

Para entregar actualizaciones que aún no están incluidas en los agentes de recursos básicos del SO, Google Cloud proporciona de manera periódica agentes de recursos complementarios para clústeres con alta disponibilidad de SAP. Cuando se requieren estos agentes de recursos complementarios, los procedimientos de implementación de Google Cloud incluyen un paso para descargarlos.

Protección

Fencing (Protección), en el contexto del agrupamiento en clústeres del SO de Google Cloud Compute Engine, adopta el formato de STONITH, que proporciona a cada miembro de un clúster de dos nodos la capacidad de reiniciar el otro nodo.

Los agentes de recursos que proporcionan Red Hat y SUSE administran la protección STONITH en Google Cloud.

Dirección IP virtual

Los clústeres con alta disponibilidad para SAP en Google Cloud usan una dirección IP (VIP) virtual o flotante para redireccionar el tráfico de red de un host a otro en caso de que se genere una conmutación por error.

Las implementaciones que no suelen ser de nube usan una solicitud injustificada de protocolo de resolución de direcciones (ARP) para anunciar el movimiento y la reasignación de una VIP a una dirección MAC nueva.

En Google Cloud, en lugar de usar solicitudes ARP injustificadas, se usa uno de los varios métodos para mover y reasignar una VIP en un clúster con alta disponibilidad. El método recomendado es usar un balanceador de cargas de TCP/UDP interno, pero, según tus necesidades, también puedes usar una implementación VIP basada en rutas o basada en IP de alias.

Para obtener más información sobre la implementación de VIP en Google Cloud, consulta Implementación de IP virtual en Google Cloud.

Almacenamiento y replicación

Una configuración de clúster con alta disponibilidad de SAP HANA usa la replicación síncrona de su sistema para mantener sincronizadas las bases de datos principales y secundarias de SAP HANA. Los agentes de recursos estándar que proporciona el SO para SAP HANA administran la replicación del sistema durante una conmutación por error. Para hacerlo, inician y detienen la replicación, y cambian las instancias que actúan como instancias activas y las que actúan como instancias en espera durante el proceso de replicación.

Si necesitas almacenamiento de archivos compartido, los archivadores basados en NFS o SMB pueden proporcionar la funcionalidad requerida.

Para una solución de almacenamiento compartido con alta disponibilidad, puedes usar una solución 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.

Los discos persistentes regionales de Compute Engine ofrecen almacenamiento en bloque replicado de forma síncrona en distintas zonas. Aunque los discos persistentes regionales no son compatibles con el almacenamiento de la base de datos en los sistemas SAP con alta disponibilidad, puedes usarlos con los servidores de archivos NFS.

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

Configuración del tiempo de espera y del intervalo

La configuración del intervalo de verificación y del tiempo de espera para los agentes de recursos y la configuración del clúster afectan la rapidez con la que el software del clúster activa una conmutación por error. Los valores que se usan en las instrucciones y en la automatización de Google Cloud para clústeres con alta disponibilidad pueden diferir en parte de los valores predeterminados del software del clúster, pero cualquier conjunto de valores debería ser suficiente en la mayoría de los casos. Puedes ajustar los valores si es necesario. Solo asegúrate de probar los valores que usas en tu entorno antes de liberar el sistema para su uso.

Los valores del tiempo de espera y del intervalo de verificación que sugiere la cuenta de Google Cloud para los eventos de mantenimiento de la migración en vivo de Google Cloud, la duración puede variar en parte según el tipo de máquina que uses y otros factores. Para obtener más información, consulta Migración en vivo.

Después de implementar el clúster, activa un evento de migración en vivo en el host principal con el comando gcloud compute instances simulate-maintenance-event del SDK de Cloud para probar la configuración.

Registros y supervisión

Los agentes de recursos pueden incluir capacidades de registro que propagan registros a Google Cloud's operations suite para el análisis. Cada agente de recursos incluye información de configuración que identifica cualquier opción de registro. En el caso de las implementaciones de Bash, la opción de registro es gcloud logging.

También puedes instalar el agente de Cloud Logging para capturar resultados de registro a partir de procesos del sistema operativo y correlacionar el uso de recursos con eventos del sistema. El agente de Logging captura los registros del sistema predeterminados, que incluyen los datos de registro de Pacemaker y los servicios de agrupamiento en clústeres. Para obtener más información, consulta Acerca del agente de Logging.

Si deseas obtener información sobre el uso de Cloud Monitoring para configurar las verificaciones de servicio que supervisan la disponibilidad de los extremos del servicio, consulta Administra las verificaciones de tiempo de actividad.

Cuentas de servicio y clústeres con alta disponibilidad

Las acciones que el software del clúster puede realizar en el entorno de Google Cloud están protegidas por los permisos otorgados a la cuenta de servicio de cada VM del host. Para entornos de alta seguridad, puedes limitar los permisos en las cuentas de servicio de las VM del host a fin de cumplir con el principio de privilegio mínimo.

Cuando limites los permisos de una cuenta de servicio, ten en cuenta que tu sistema puede interactuar con los servicios de Google Cloud, como Cloud Storage, por lo que es posible que debas incluir permisos para esas interacciones de servicio en la cuenta de servicio de la VM del host.

Para los permisos más restrictivos, crea una función personalizada con los permisos mínimos necesarios. Para obtener información sobre las funciones personalizadas, consulta Crea y administra funciones personalizadas. Puedes restringir aún más los permisos si los limitas a solo instancias específicas de un recurso, como las instancias de VM en el clúster con alta disponibilidad, si agregas condiciones en las vinculaciones de la función de la política de IAM de un recurso.

Los permisos mínimos que tus sistemas necesitan dependen de los recursos de Google Cloud a los que acceden tus sistemas y de las acciones que realizan. En consecuencia, determinar los permisos mínimos requeridos para las VM del host en el clúster con alta disponibilidad puede requerir que investigues con exactitud qué recursos acceden a los sistemas en la VM del host y las acciones que esos sistemas realizan con esos recursos.

Como punto de partida, en la siguiente lista se muestran algunos recursos del clúster con alta disponibilidad y los permisos asociados que requieren:

  • Protección STONITH
    • compute.instances.list
    • compute.instances.get
    • compute.instances.reset
    • compute.instances.stop
    • compute.instances.start
    • logging.logEntries.create
    • compute.zones.list
  • VIP implementada mediante un alias de IP
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.instances.updateNetworkInterface
    • compute.zoneOperations.get
    • logging.logEntries.create
  • VIP implementada mediante rutas estáticas
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.routes.get
    • compute.routes.create
    • compute.routes.delete
    • compute.routes.update
    • compute.routes.list
    • compute.networks.updatePolicy
    • compute.networks.get
    • compute.globalOperations.get
    • logging.logEntries.create
  • VIP implementada mediante un balanceador de cargas interno
    • No se requieren permisos específicos: el balanceador de cargas opera en las condiciones de la verificación de estado que no requieren que el clúster interactúe con recursos ni los cambie en Google Cloud.

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 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.

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.

Conmutación por error automática del host de SAP HANA en Google Cloud

Google Cloud es compatible con la conmutación por error automática del host de SAP HANA, la solución local de recuperación ante fallas que proporciona SAP HANA. La solución de conmutación por error automática del host usa uno o más hosts de reserva que se mantienen en reserva para tomar el trabajo del host principal o de trabajador en caso de que el host falle. Los hosts de reserva no contienen datos ni procesan ningún trabajo.

Los volúmenes /hana/data y /hana/log se activan solo en los hosts principales y de trabajador. Cuando se produce una toma de control, la solución de conmutación por error automática del host usa la API del conector de almacenamiento de SAP HANA y el complemento gceStorageConnector de Compute Engine para administrar el cambio de estos discos del host con errores al host de reserva. Los parámetros de configuración para el complemento gceStorageConnector, que incluyen si el cercado está habilitado o inhabilitado, se almacenan en la sección de almacenamiento del archivo global.ini de SAP.

Los volúmenes /hana/shared y /hanabackup se almacenan en un servidor NFS, que el host principal administra y que se activa en todos los hosts, incluidos los hosts de reserva.

Una vez que se completa una conmutación por error, el host con errores se reinicia como un host de reserva.

SAP admite hasta tres hosts de reserva en sistemas de escalamiento horizontal en Google Cloud. Los hosts de reserva no cuentan para el máximo de 16 hosts activos que SAP admite en sistemas de escalamiento horizontal en Google Cloud.

Por el momento, Google Cloud admite la conmutación por error automática del host de SAP HANA solo en SUSE Linux Enterprise Server (SLES) para imágenes públicas de SAP disponibles en Compute Engine en las familias de imágenes sles-12-sp3-sap y sles-12-sp2-sap. Para ver las imágenes públicas disponibles en Compute Engine, consulta Imágenes.

En el siguiente diagrama, se muestra una arquitectura de varios hosts en Google Cloud que incluye compatibilidad con la conmutación por error automática del host de SAP HANA. En el diagrama, el host de trabajador 2 falla y el host de reserva toma el control. El complemento gceStorageClient funciona con la API del conector de almacenamiento de SAP (no mostrado) para desconectar los discos que contienen los volúmenes /hana/data y /hana/logs del trabajador con errores y volver a activarlos en el host de reserva que, luego, se convierte en el host trabajador 2 mientras que el host con errores se convierte en el host de reserva.

Diagrama en el que se muestra la arquitectura de un sistema de escalamiento horizontal de SAP HANA que incluye compatibilidad con la conmutación por error automática del host.

Opciones de implementación para configuraciones con alta disponibilidad de SAP HANA

Google Cloud proporciona plantillas de Deployment Manager que puedes usar para automatizar la implementación de sistemas SAP HANA con alta disponibilidad o puedes implementar y configurar tus sistemas de SAP HANA con alta disponibilidad de forma manual.

Las plantillas de Deployment Manager que proporciona Google Cloud incluyen un archivo de configuración template.yaml que debes completar. Deployment Manager lee el archivo de configuración y, luego, implementa un sistema de SAP HANA que es completamente compatible con SAP y que cumple las prácticas recomendadas de SAP y Google Cloud.

Implementación automatizada de los clústeres con alta disponibilidad de Linux para SAP HANA

Para SAP HANA, Deployment Manager 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
  • Replicación síncrona
  • Carga previa de la memoria
  • El administrador de recursos del clúster de alta disponibilidad de Pacemaker
  • Un mecanismo de protección de Google Cloud
  • Una VM con los discos persistentes necesarios para cada instancia de SAP HANA
  • Una instancia de SAP HANA en cada VM

Para obtener más información, consulta la Guía de implementación del clúster de alta disponibilidad de SAP HANA.

Implementación automatizada de sistemas de escalamiento horizontal de SAP HANA con conmutación por error automática del host de SAP HANA

Implementación manual de clústeres de SAP HANA con alta disponibilidad

Cuando configuras un clúster con alta disponibilidad de forma manual, para asegurarte de que los sistemas de SAP HANA cumplan los requisitos de compatibilidad y las prácticas recomendadas de SAP, primero implementa las VM y las instancias de SAP HANA mediante la plantilla de Deployment Manager que proporciona Google Cloud.

A fin de obtener instrucciones para implementar y configurar de forma manual un clúster con alta disponibilidad en Google Cloud para SAP HANA, consulta:

Próximos pasos

Google Cloud y SAP proporcionan más información sobre la alta disponibilidad.

Más información de Google Cloud sobre la alta disponibilidad

Para obtener más información sobre la alta disponibilidad de SAP HANA en Google Cloud, consulta:

Para obtener información general sobre la protección de sistemas en Google Cloud contra diversas situaciones de falla, consulta Diseña sistemas sólidos.

Más información de SAP sobre sus funciones de alta disponibilidad

Para obtener más información de SAP acerca de las funciones de alta disponibilidad de SAP HANA, consulta: