Guía de planificación de alta disponibilidad y recuperación ante desastres de SAP HANA

En esta guía, se proporciona una descripción general a fin de planificar y administrar la alta disponibilidad y la recuperación ante desastres para los sistemas SAP HANA implementados en Google Cloud mediante la guía de implementación de SAP HANA en Google Cloud. Esta guía no tiene como objetivo reemplazar la documentación estándar de SAP.

Alta disponibilidad para SAP HANA en Google Cloud

Puedes obtener alta disponibilidad para SAP HANA en Google Cloud mediante una combinación de funciones de Google Cloud y SAP que manejan fallas a nivel de infraestructura o 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.

Para obtener más información sobre el reinicio automático, consulta Reinicio automático de instancias de VM en Google Cloud.

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.

Reinicio automático de las instancias de VM en Google Cloud

En el caso del reinicio de la instancia de VM debido a problemas de mantenimiento o de otro tipo, el reinicio automático de Compute Engine y el reinicio automático del servicio SAP HANA funcionan juntos para reiniciar automáticamente la instancia y la aplicación sin tu intervención. No se necesita redireccionamiento del cliente.

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.

Compatibilidad de Cloud Deployment Manager con alta disponibilidad de SAP HANA

Si la migración en vivo de Compute Engine, el reinicio automático y el alto porcentaje de tiempo de actividad mensual de las VM de Compute Engine no son suficientes para satisfacer tus requisitos de disponibilidad, Google Cloud también brinda compatibilidad con Deployment Manager para las siguientes funciones de alta disponibilidad:

  • Clúster de alta disponibilidad de SUSE Linux Enterprise Server (SLES) para SAP HANA

Para cada una de estas funciones, Google Cloud proporciona una plantilla de archivo de configuración a completar que Deployment Manager lee a fin de implementar un sistema SAP HANA totalmente compatible con SAP y que cumpla con las prácticas recomendadas de SAP y Google Cloud.

Clústeres de Linux de alta disponibilidad de Deployment Manager 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.

Deployment Manager para los sistemas de escalamiento horizontal de SAP HANA con conmutación por error automática del host de SAP HANA

Obtén más información sobre las funciones de alta disponibilidad de SAP HANA

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

Recuperación ante desastres

A fin de prepararte para los desastres, puedes usar la replicación del sistema SAP HANA en un sistema SAP HANA secundario, realizar copias de seguridad de SAP HANA a fin de habilitar la recuperación, o ambos.

Para cargas de trabajo esenciales que requieren tiempos de recuperación rápidos, usa la replicación del sistema HANA a fin de minimizar el tiempo de inactividad. El uso de copias de seguridad para recuperar un sistema cuesta menos, pero lleva más tiempo, ya que se debe crear un sistema nuevo y, luego, restablecer las copias de seguridad en el momento deseado.

En cualquier caso, debes usar el redireccionamiento basado en la red para redireccionar las aplicaciones cliente que usan el sistema SAP HANA a la dirección IP del sistema de reemplazo una vez que esté disponible. Para obtener más información, consulta la Guía de administración de SAP HANA.

A partir de SAP HANA SPS09, puedes usar la API basada en Python incluida en SAP HANA a fin de crear tu propio proveedor de alta disponibilidad/recuperación ante desastres (HA/DR) e integrarlo en el proceso de toma de control de la replicación del sistema SAP HANA para automatizar tareas como el redireccionamiento de las conexiones de cliente de la base de datos del sistema principal al secundario después de una toma de control. Para obtener más información, consulta Implementing a HA/DR Provider (Implementa un proveedor de HA/DR).

Ten en cuenta que cualquier restricción que SAP define, incluida la limitación de distancia para la replicación síncrona, también está vigente en Google Cloud.

Recuperación ante desastres mediante la replicación del sistema SAP HANA

Para maximizar el uso de los recursos de infraestructura y optimizar los costos de la solución de DR, puedes usar el sistema secundario para los casos prácticos que no sean de producción, como un sistema de control de calidad o de desarrollo. En este caso, el sistema secundario no está precargado con datos, por lo que la conmutación por error tarda más tiempo que tener el sistema secundario precargado con datos y mantenerlo sincronizado con el sistema principal.

En HANA 2 SPS00, se incluye compatibilidad con el modo de configuración Activa/Activa (lectura habilitada), que permite que la replicación del sistema SAP HANA admita el acceso de lectura en el sistema secundario. Para obtener más información, consulta Active/Active (Read Enabled) [Activa/Activa (lectura habilitada].

Se admite la replicación síncrona y asíncrona cuando se usa la replicación del sistema SAP HANA con Google Cloud.

Si es posible, recomendamos usar la replicación síncrona, en la que las transacciones de SQL no se confirman en la instancia de la base de datos principal hasta que se confirman en la instancia en espera. Esto mantiene la instancia en espera 100% sincronizada y garantiza un objetivo de punto de recuperación cero. Se puede usar la replicación síncrona para instancias que residen en cualquier zona dentro de la misma región.

SystemReplication-preload1

Si el sistema en espera está en una región diferente del sistema principal, usa la replicación asíncrona, en la que no hay que esperar a que la instancia en espera reconozca los datos antes de la confirmación en la instancia principal. En este caso, es posible que pierdas pequeñas cantidades de datos si ocurre un desastre. Una compensación es que la replicación asíncrona te brinda un objetivo de punto de recuperación mayor que cero.

SystemReplication-preload2

Para todas las situaciones de replicación, debes realizar una toma de control de forma manual en el sistema en espera a fin de iniciar la recuperación ante desastres. También debes redireccionar de forma manual las aplicaciones que usan la base de datos de SAP HANA para orientar la instancia a la que falló en el sistema en espera.

Elige la opción de replicación del sistema HANA que mejor se adapte a tus necesidades comerciales, como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). A fin de obtener más información, consulta Replication Modes for SAP HANA System Replication (Modos de replicación para la replicación del sistema SAP HANA).

Replicación del sistema SAP HANA con carga previa

En esta situación, el sistema SAP HANA se replica en un sistema en espera dedicado. La base de datos de SAP HANA se replica en una VM de Compute Engine que tiene un nombre de host único y sus propios discos persistentes adjuntos. Todos los datos de SAP HANA se cargan en la memoria del sistema en espera. Si tienes que realizar una conmutación por error, el tiempo de conmutación por error solo será de unos 90 segundos porque todos los datos están precargados.

Para obtener más información sobre la replicación del sistema SAP HANA con carga previa, consulta la sección System Replication (Replicación del sistema) en SAP HANA – High Availability (SAP HANA: Alta disponibilidad).

Replicación del sistema SAP HANA sin carga previa

En esta situación, el sistema SAP HANA se replica en un sistema en espera dedicado. La base de datos de SAP HANA se replica en una VM de Compute Engine que tiene un nombre de host único y sus propios discos persistentes adjuntos. Los datos de SAP HANA no se cargan en la memoria del sistema en espera. Si tienes que realizar una conmutación por error, el tiempo puede ser de minutos a horas, según el tamaño del conjunto de datos.

Cuando no cargas los datos de forma previa, los requisitos de memoria para la VM de Compute Engine que aloja la base de datos de SAP HANA son mucho más pequeños. La VM solo necesita 64 GB de memoria o la cantidad de memoria que consume el almacén de filas en el host de destino, lo que sea mayor. Para obtener información sobre el alcance de memoria del almacén de filas, ejecuta la siguiente consulta:

SELECT round (sum(USED_FIXED_PART_SIZE + USED_VARIABLE_PART_SIZE)/1024/1024) AS "Row Tables MB" FROM M_RS_TABLES;

El requisito de memoria reducida te brinda opciones para ahorrar costos cuando eliges un tipo de máquina de Compute Engine.

  • Puedes usar un tipo de máquina que tenga especificaciones de memoria bajas para alojar la base de datos de SAP HANA en el sistema en espera a fin de reducir el costo de ejecución. Una VM con poca memoria no es compatible con SAP HANA en un sistema de producción, pero podrías usar esta VM de menor costo a fin de realizar una toma de control en una situación de recuperación ante desastres y, luego, modificarla para cambiar el tipo de máquina a uno con una cantidad de memoria admitida. Para hacer esto, debes detener la VM a fin de realizar la actualización, por lo que tendrás tiempo de inactividad adicional antes de que el sistema SAP HANA esté disponible.

  • Puedes usar un tipo de máquina con alta capacidad de memoria para alojar la base de datos de SAP HANA en el sistema en espera y compartirla con sistemas de desarrollo o prueba a fin de mejorar el retorno de la inversión. Puedes establecer el límite de asignación global para la base de datos de SAP HANA en 64 GB si sigues las instrucciones en Change the Global Memory Allocation Limit (Cambia el límite de asignación global de memoria), lo que deja el resto de la memoria disponible para que la usen otros sistemas. Cuando se necesita el sistema en espera, cierra las operaciones de desarrollo y prueba, realiza una toma de control y, luego, quita el límite de asignación global.

Puedes usar la replicación síncrona y asíncrona sin carga previa. Sin embargo, la replicación síncrona requiere que las instancias de origen y destino estén en la misma región de Google Cloud.

Puedes usar un proveedor de HA/DR para abordar problemas como el cierre de los sistemas de desarrollo o prueba en el host secundario.

Activa una toma de control

Para invocar la recuperación ante desastres, activa el procedimiento de toma de control de replicación del sistema SAP HANA en el sistema en espera. En SAP Note 2063657 (Nota de SAP 2063657), se proporcionan lineamientos para ayudarte a decidir si la toma de control es la mejor opción.

Para activar la toma de control, sigue el proceso de toma de control estándar de SAP HANA. A fin de obtener más información sobre este procedimiento, consulta How To Perform System Replication for SAP HANA 1.0 (Cómo realizar la replicación del sistema para SAP HANA 1.0) o How To Perform System Replication for SAP HANA 2.0 (Cómo realizar la replicación del sistema para SAP HANA 2.0).

En casos de problemas de datos o fallas de software, es posible que no haya notificaciones automáticas para que puedas realizar la toma de control. Considera crear una solución personalizada para enviar alertas mediante Cloud Monitoring o las herramientas de supervisión de HANA.

Recuperación ante desastres mediante copias de seguridad de SAP HANA

En los casos en los que un objetivo de tiempo de recuperación más largo es aceptable y tu objetivo de punto de recuperación es superior a 15 minutos, puedes recuperarte de un error si restableces la copia de seguridad. Para garantizar una recuperación exitosa cuando usas copias de seguridad, realiza copias frecuentes de los archivos de copia de seguridad, en especial de los registros, en un depósito de Cloud Storage o en otra ubicación de almacenamiento a largo plazo fuera de la región en la que se ejecuta el sistema SAP HANA. Recomendamos documentar la infraestructura del sistema principal y crear secuencias de comandos que te permitan crear un sistema de reemplazo con rapidez a fin de restablecer las copias de seguridad.

Para obtener más información, consulta la guía de operaciones de SAP HANA

Próximos pasos