Guía de configuración de clústeres con escalamiento vertical de alta disponibilidad para SAP HANA en RHEL

En esta guía, se muestra cómo implementar y configurar manualmente un clúster con alta disponibilidad (HA) de Red Hat Enterprise Linux (RHEL) para un sistema de escalamiento horizontal de SAP HANA en Google Cloud que usa un balanceador de cargas de red de transferencia interno para administrar la dirección IP virtual (VIP).

En esta guía, se incluyen los siguientes pasos:

• Configurar un balanceador de cargas de red de transferencia interno para redirigir el tráfico en caso de una falla
• Configurar un clúster de Pacemaker en RHEL para administrar los sistemas SAP y otros recursos durante una conmutación por error

En esta guía, también se incluyen pasos para configurar la replicación del sistema SAP HANA, pero consulta la documentación de SAP para obtener las instrucciones definitivas.

Para implementar un sistema de SAP HANA sin un clúster de alta disponibilidad de Linux o un host de nodo en espera, usa la Guía de implementación de SAP HANA.

Esta guía está destinada a usuarios avanzados de SAP HANA que estén familiarizados con la configuración de alta disponibilidad de Linux para SAP HANA.

El sistema que se implementa en esta guía

Con esta guía, implementarás un sistema SAP HANA de alta disponibilidad de varios nodos configurado para una redundancia total de zona con una instancia adicional que actúa como un creador de mayoría, también conocida como tie-breaker nodo, que garantiza que el quórum del clúster se mantenga en caso de pérdida de una zona.

La implementación final consta de los siguientes recursos:

• Un sitio principal y secundario en el que cada instancia tiene una contraparte zonal.
• Dos sitios configurados para la replicación síncrona.
• Una sola instancia de procesamiento para que actúe como creador de mayorías.
• Un administrador de recursos de clústeres de alta disponibilidad de Pacemaker con un mecanismo de protección.
• Discos persistentes para los datos de SAP HANA y los volúmenes de registro conectados a cada instancia de SAP HANA.

En esta guía, se usan las plantillas de Terraform que proporciona Google Cloud para implementar las máquinas virtuales (VM) de Compute Engine y las instancias de SAP HANA, lo que asegura que los sistemas de base SAP HANA cumplan con los requisitos de compatibilidad de SAP y con las prácticas recomendadas actuales.

En esta guía, se usa SAP HANA Studio para probar la replicación del sistema SAP HANA. Si lo prefieres, puedes usar SAP HANA Cockpit. Para obtener información sobre la instalación de SAP HANA Studio, consulta la siguiente página:

• Instala SAP HANA Studio en una VM de Windows de Compute Engine
• SAP HANA Studio Installation and Update Guide (Guía de instalación y actualización de SAP HANA Studio)

Requisitos

Antes de crear el clúster de alta disponibilidad de SAP HANA, asegúrate de que se cumplan los siguientes requisitos:

• Leíste la Guía de planificación de SAP HANA y la Guía de planificación de alta disponibilidad de SAP HANA.
• Tú o tu organización deben tener una cuenta de Google Cloud y haber creado un proyecto para la implementación de SAP HANA. Para obtener información sobre cómo crear cuentas y proyectos de Google Cloud, consulta Configura la Cuenta de Google en la guía de implementación de SAP HANA.
• Si necesitas que tu carga de trabajo de SAP se ejecute de acuerdo con los requisitos de residencia de datos, control de acceso, personal de asistencia o reglamentario, debes crear la carpeta de cargas de trabajo de Assured Workloads requerida. Para obtener más información, consulta Cumplimiento y controles soberanos para SAP en Google Cloud.

• El medio de instalación de SAP HANA se almacena en un bucket de Cloud Storage que está disponible en tu proyecto y región de implementación. Para obtener información sobre cómo subir medios de instalación de SAP HANA a un bucket de Cloud Storage, consulta Descarga SAP HANA en la Guía de implementación de SAP HANA.

• Si el Acceso al SO está habilitado en los metadatos del proyecto, debes inhabilitar el Acceso al SO de forma temporal hasta que se complete la implementación. Para fines de implementación, este procedimiento configura las claves SSH en metadatos de instancia. Cuando el acceso al SO está habilitado, la configuración de las claves SSH basada en metadatos se inhabilita y esta implementación falla. Una vez terminada la implementación, puedes volver a habilitar el acceso al SO.

  Para obtener más información, consulte:

  • Cómo habilitar o inhabilitar el acceso al SO
  • Agrega claves SSH a las VM que usan claves SSH basadas en metadatos

• Si usas un DNS interno de VPC, el valor de la variable vmDnsSetting en los metadatos del proyecto debe ser GlobalOnly o ZonalPreferred para habilitar la resolución de los nombres del nodo entre zonas. La configuración predeterminada de vmDnsSetting es ZonalOnly. Para obtener más información, consulta:

  • Configura nombres DNS para tu proyecto o instancias
  • Consulta metadatos personalizados
  • Establece metadatos personalizados para todo el proyecto

• Debes tener una solución NFS, como la solución administrada de Filestore, para compartir los volúmenes /hana/shared y /hanabackup de SAP HANA entre los hosts en el sistema de escalamiento horizontal de SAP HANA. Para implementar servidores NFS de Filestore, consulta Crea instancias.

  • Ten en cuenta que los sitios principal y secundario deben tener acceso a sus propias rutas NFS dedicadas para evitar reemplazar datos. Para usar una sola instancia de Filestore, debes configurar la implementación para usar subdirectorios distintos como la ruta de activación.

Para evitar la exposición accidental de la instancia de VM en Internet, sigue estas recomendaciones:

• Usa una puerta de enlace NAT.
• Crea reglas de firewall que bloqueen todos los accesos externos que no necesites.
• Cuando crees tus VM, haz lo siguiente:
  • Especifica una etiqueta de red para cada VM para usarlas en las reglas de enrutamiento y firewall. Si usas el archivo de configuración de Terraform que proporciona Google Cloud, especifica una etiqueta con network_tags = "TAG".
  • Crea las VM sin una IP externa. Si usas el archivo de configuración de Terraform que proporciona Google Cloud, especifica public_ip = false.

Crea una red

Por razones de seguridad, crea una red nueva. Puedes controlar quién tiene acceso con reglas de firewall o a través de otro método de control de acceso.

Si tu proyecto tiene una red de VPC predeterminada, no la uses. En su lugar, crea tu propia red de VPC para que las únicas reglas de firewall vigentes sean aquellas que crees de forma explícita.

Durante la implementación, las instancias de VM suelen requerir acceso a Internet para descargar el agente de Google Cloud para SAP. Si usas una de las imágenes de Linux certificadas por SAP disponibles en Google Cloud, la instancia de VM también requerirá acceso a Internet para registrar la licencia y acceder a repositorios de proveedores de SO. Una configuración con una puerta de enlace NAT y con rótulos identificadores de red de VM admite este acceso, incluso si las VM de destino no tienen IP externas.

Para crear una red de VPC para tu proyecto, completa los siguientes pasos:

1. Crea una red de modo personalizado. Para obtener más información, consulta Cómo crear una red de modo personalizado.

2. Crea una subred y especifica la región y el rango de IP a través de el siguiente comando. Para obtener más información, consulta Cómo agregar subredes.

Configura una puerta de enlace NAT

Si necesitas crear una o más VM sin direcciones IP públicas, debes usar la traducción de direcciones de red (NAT) para permitir que las VM accedan a Internet. Usa Cloud NAT, un servicio administrado distribuido y definido por software por Google Cloud que permite que las VM envíen paquetes salientes a Internet y reciban cualquier paquete de respuesta entrante establecido. Como alternativa, puedes configurar una VM independiente como una puerta de enlace NAT.

Punto clave: Cuando configuras Cloud NAT, especifica al menos 160 como la cantidad mínima de puertos por VM. Ciertas actualizaciones del sistema operativo ejecutan procesos simultáneos que pueden exceder el Cloud NAT predeterminado para la cantidad de puertos, lo que puede provocar errores de activación o descarga.

Cuando crees una instancia de Cloud NAT, especifica la cantidad de puertos en el campo de Puertos mínimos por VM en Configuraciones avanzadas en la página Crea una puerta de enlace NAT en la consola de Google Cloud.

Para crear una instancia de Cloud NAT para tu proyecto, consulta Usa Cloud NAT.

Después de configurar Cloud NAT para tu proyecto, tus instancias de VM pueden acceder a Internet de forma segura sin una dirección IP pública.

Cómo agregar reglas de firewall

De forma predeterminada, una regla de firewall implícita bloquea las conexiones entrantes desde fuera de tu red de nube privada virtual (VPC). Para permitir conexiones entrantes, establece una regla de firewall para la VM. Después de establecer una conexión entrante con una VM, se permite el tráfico en ambas direcciones a través de esa conexión.

También puedes crear una regla de firewall para permitir el acceso externo a puertos especificados o restringir el acceso entre las VM en la misma red. Si se usa el tipo de red de VPC default, también se aplican algunas reglas predeterminadas adicionales, como la regla default-allow-internal, que permite la conectividad entre VM en la misma red en todos los puertos.

En función de la política de TI que se aplique a tu entorno, es posible que debas aislar o restringir la conectividad a tu host de base de datos, lo que puedes hacer a través de la creación de reglas de firewall.

Según la situación en la que te encuentres, puedes crear reglas de firewall para permitir los siguientes accesos:

• Los puertos SAP predeterminados que se enumeran en TCP/IP de todos los productos SAP.
• Conexiones desde tu computadora o tu entorno de red corporativa a tu instancia de VM de Compute Engine. Si no estás seguro de qué dirección IP usar, comunícate con el administrador de red de tu empresa.

A fin de crear las reglas de firewall para tu proyecto, consulta Crea reglas de firewall.

Implementa las VM y SAP HANA

En esta guía, se usa un archivo de configuración de Terraform proporcionado por Google Cloud para implementar los siguientes elementos:

• Dos sistemas de SAP HANA coincidentes, cada uno con dos o más instancias de VM.
• Una sola instancia de creador de mayoría, también conocida como nodo tie-breaker, que garantiza que el quórum del clúster se mantenga en caso de la pérdida de una zona.

Los sistemas de SAP HANA usan la replicación asíncrona del sistema, de modo que uno de los sistemas SAP HANA funcionan como el sistema principal activo y otras funciones como un sistema secundario en espera. Debes implementar ambos sistemas de SAP HANA dentro de la misma región, idealmente en diferentes zonas.

Si necesitas un sistema de escalamiento horizontal con hosts en espera para la conmutación por error automática de host de SAP HANA, debes consultar Terraform: guía de implementación del sistema de escalamiento horizontal de SAP HANA con conmutación por error automática de host.

Define opciones de configuración para el clúster de alta disponibilidad de SAP HANA en un archivo de configuración de Terraform.

Las siguientes instrucciones usan Cloud Shell, pero, en términos generales, se pueden aplicar a una terminal local con Terraform instalado y configurado con el Proveedor de Google.

1. Confirma que las cuotas actuales de los recursos como discos persistentes y CPU sean suficientes para los sistemas SAP HANA que estás a punto de instalar. Si tus cuotas son insuficientes, entonces tu implementación falla.

   Si quieres ver los requisitos de cuota de SAP HANA, consulta las consideraciones de precios y cuotas para SAP HANA.

   Ir a Cuotas

2. Abre Cloud Shell o la terminal local.

   Abra Cloud Shell

3. Descarga el archivo de configuración manual_sap_hana_scaleout_ha.tf en tu directorio de trabajo mediante la ejecución del siguiente comando en Cloud Shell o en tu terminal:

   $ wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana_ha/terraform/manual_sap_hana_scaleout_ha.tf

   Nota: Asegúrate de tener solo un archivo de configuración de Terraform en tu directorio de trabajo.

4. Abre el archivo manual_sap_hana_scaleout_ha.tf en el editor de código de Cloud Shell o, si usas tu terminal, abre el archivo en el editor de texto que elijas.

   Para abrir el editor de código de Cloud Shell, haz clic en el ícono de lápiz en la esquina superior derecha de la ventana de la terminal de Cloud Shell.

5. En el archivo manual_sap_hana_scaleout_ha.tf, para sap_hana_primary y sap_hana_secondary, actualiza los valores de argumento reemplazando el contenido dentro de las comillas dobles por los valores de tu instalación. Los argumentos se describen en la siguiente tabla.

   Argument	Tipo de dato	Descripción
   source	Cadena	Especifica la ubicación y la versión del módulo de Terraform que se usará durante la implementación. El archivo de configuración manual_sap_hana_scaleout_ha.tf incluye dos instancias del argumento source: una que está activa y otra que se incluye como un comentario. El argumento source que está activo de forma predeterminada especifica latest como la versión del módulo. La segunda instancia del argumento source, que de forma predeterminada se desactiva a través de un carácter # inicial, especifica una marca de tiempo que identifica una versión del módulo. Si necesitas que todas tus implementaciones usen la misma versión del módulo, quita el carácter # inicial del argumento source que especifica la marca de tiempo de la versión y agrégala al argumento source que especifica latest.
   project_id	Cadena	Especifica el ID del proyecto de Google Cloud en el que implementarás este sistema. Por ejemplo, my-project-x.
   machine_type	String	Especifica el tipo de máquina virtual (VM) de Compute Engine en el que quieres ejecutar el sistema SAP. Si necesitas un tipo de VM personalizada, especifica un tipo de VM predefinido con una cantidad de CPU virtuales más cercana al número que necesitas sin dejar de ser más grande. Una vez completada la implementación, modifica la cantidad de CPU virtuales y la cantidad de memoria. Por ejemplo, n1-highmem-32.
   network	String	Especifica el nombre de la red en la que necesitas crear el balanceador de cargas que administra la VIP. Si usas una red de VPC compartida, debes agregar el ID del proyecto host como directorio superior del nombre de la red. Por ejemplo, HOST_PROJECT_ID/NETWORK_NAME.
   subnetwork	Cadena	Especifica el nombre de la subred que creaste en un paso anterior. Si realizas la implementación en una VPC compartida, especifica este valor como SHARED_VPC_PROJECT_ID/SUBNETWORK. Por ejemplo: myproject/network1
   linux_image	Cadena	Especifica el nombre de la imagen del sistema operativo Linux en la que deseas implementar tu sistema SAP. Por ejemplo: rhel-9-2-sap-ha o sles-15-sp5-sap. Para obtener la lista de imágenes de sistema operativo disponibles, consulta la página Imágenes en la consola de Google Cloud.
   linux_image_project	Cadena	Especifica el proyecto de Google Cloud que contiene la imagen que especificaste para el argumento linux_image. Este proyecto puede ser uno propio o un proyecto de imagen de Google Cloud. En el caso de una imagen de Compute Engine, especifica rhel-sap-cloud o suse-sap-cloud. Para encontrar el proyecto de imagen de tu sistema operativo, consulta Detalles de los sistemas operativos.
   primary_instance_name	Cadena	Especifica un nombre de la instancia de VM para el sistema SAP HANA principal. El nombre puede contener letras minúsculas, números o guiones.
   primary_zone	Cadena	Especifica una zona en la que se implemente el sistema SAP HANA principal. Las zonas principal y secundaria deben estar en la misma región. Por ejemplo, us-east1-c.
   secondary_instance_name	String	Especifica un nombre de la instancia de VM para el sistema de SAP HANA secundario. El nombre puede contener letras minúsculas, números o guiones.
   secondary_zone	Cadena	Especifica una zona en la que se implemente el sistema SAP HANA secundario. Las zonas principal y secundaria deben estar en la misma región. Por ejemplo, us-east1-b.
   sap_hana_deployment_bucket	String	Para instalar SAP HANA automáticamente en las VMs implementadas, especifica la ruta de acceso del bucket de Cloud Storage que contiene los archivos de instalación de SAP HANA. No incluyas gs:// en la ruta de acceso; solo incluye el nombre del bucket y los nombres de las carpetas. Por ejemplo, my-bucket-name/my-folder. El bucket de Cloud Storage debe existir en el proyecto de Cloud que especificas para el argumento project_id.
   sap_hana_scaleout_nodes	Integer	Especifica la cantidad de hosts de trabajador que necesitas en tu sistema de escalamiento horizontal. Para implementar un sistema de escalamiento horizontal, necesitas al menos un host de trabajador. Terraform crea los hosts de trabajador, además de la instancia principal de SAP HANA. Por ejemplo, si especificas 3, se implementarán cuatro instancias de SAP HANA en tu sistema de escalamiento horizontal.
   sap_hana_sid	Cadena	Para instalar SAP HANA automáticamente en las VMs implementadas, especifica el ID del sistema SAP HANA. Debe constar de tres caracteres alfanuméricos y comenzar con una letra. Todas las letras deben estar en mayúsculas. Por ejemplo, ED1.
   sap_hana_instance_number	Integer	Opcional. Especifica el número de instancia, de 0 a 99, del sistema SAP HANA. El valor predeterminado es 0.
   sap_hana_sidadm_password	Cadena	Para instalar SAP HANA automáticamente en las VMs implementadas, especifica una contraseña temporal SIDadm para que las secuencias de comandos de instalación se usen durante la implementación. La contraseña debe tener al menos 8 caracteres y debe incluir al menos una letra mayúscula, una letra minúscula y un número. Importante: Después de completar la instalación, asegúrate de cambiar la contraseña. En lugar de especificar la contraseña como texto sin formato, te recomendamos que utilices un Secret. Si deseas obtener más información, consulta Administración de contraseñas.
   sap_hana_sidadm_password_secret	Cadena	Opcional. Si usas Secret Manager para almacenar la contraseña SIDadm, especifica el Nombre del secreto que corresponde a esta contraseña. En Secret Manager, asegúrate de que el valor Secret, que es la contraseña, contenga al menos 8 caracteres e incluya al menos una letra mayúscula, una letra minúscula y un número. Importante: El secreto debe existir en el proyecto de Google Cloud que especificas para el argumento project_id. Si deseas obtener más información, consulta Administración de contraseñas.
   sap_hana_system_password	Cadena	Para instalar SAP HANA automáticamente en las VMs implementadas, especifica una contraseña de superusuario temporal para la secuencia de comandos de instalación que se usará durante la implementación. La contraseña debe tener al menos 8 caracteres y también incluir al menos una letra mayúscula, una letra minúscula y un número. Importante: Después de completar la instalación, asegúrate de cambiar la contraseña. En lugar de especificar la contraseña como texto sin formato, te recomendamos que utilices un Secret. Si deseas obtener más información, consulta Administración de contraseñas.
   sap_hana_system_password_secret	Cadena	Opcional. Si usas Secret Manager para almacenar la contraseña del superusuario de la base de datos, especifica el Nombre del secreto que corresponde a esta contraseña. En Secret Manager, asegúrate de que el valor Secret, que es la contraseña, contenga al menos 8 caracteres e incluya al menos una letra mayúscula, una letra minúscula y un número. Importante: El secreto debe existir en el proyecto de Google Cloud que especificas para el argumento project_id. Si deseas obtener más información, consulta Administración de contraseñas.
   sap_hana_double_volume_size	Booleano	Opcional. Para duplicar el tamaño del volumen de HANA, especifica true. Este argumento es útil cuando deseas implementar varias instancias de SAP HANA o una instancia de SAP HANA de recuperación ante desastres en la misma VM. De forma predeterminada, el tamaño del volumen se calcula automáticamente para que sea el tamaño mínimo requerido por la VM, sin dejar de cumplir con los requisitos de certificación y asistencia de SAP. El valor predeterminado es false.
   sap_hana_backup_size	Número entero	Opcional. Especifica el tamaño del volumen /hanabackup en GB. Si no especificas este argumento ni lo estableces en 0, la secuencia de comandos de instalación aprovisiona la instancia de Compute Engine con un volumen de copia de seguridad de HANA de dos veces la memoria total.
   sap_hana_sidadm_uid	Integer	Opcional. Especifica un valor para anular el valor predeterminado del ID de usuario SID_LCadm. El valor predeterminado es 900. Puedes cambiar esto a un valor diferente para mantener la coherencia dentro de tu entorno de SAP.
   sap_hana_sapsys_gid	Número entero	Opcional. Anula el ID de grupo predeterminado para sapsys. El valor predeterminado es 79.
   sap_vip	Cadena	Especifica la dirección IP que usarás para tu VIP. La dirección IP debe estar dentro del rango de direcciones IP asignadas a la subred. El archivo de configuración de Terraform reserva esta dirección IP para ti.
   primary_instance_group_name	Cadena	Opcional. Especifica el nombre del grupo de instancias no administrado para el nodo principal. El nombre predeterminado es ig-PRIMARY_INSTANCE_NAME.
   secondary_instance_group_name	Cadena	Opcional. Especifica el nombre del grupo de instancias no administrado para el nodo secundario. El nombre predeterminado es ig-SECONDARY_INSTANCE_NAME.
   loadbalancer_name	Cadena	Opcional. Especifica el nombre del balanceador de cargas de red de transferencia interno. El nombre predeterminado es lb-SAP_HANA_SID-ilb.
   network_tags	Cadena	Opcional. Especifica una o más etiquetas de red separadas por comas que desees asociar con tus instancias de VM para un firewall o enrutamiento. Si especificas public_ip = false y no especificas una etiqueta de red, asegúrate de proporcionar otro medio de acceso a Internet.
   nic_type	Cadena	Opcional. Especifica la interfaz de red que se usará con la instancia de VM. Puedes especificar el valor GVNIC o VIRTIO_NET. Para usar una NIC virtual de Google (gVNIC), debes especificar una imagen de SO que admita gVNIC como valor del argumento linux_image. Para obtener la lista de imágenes del SO, consulta Detalles de los sistemas operativos. Si no especificas un valor para este argumento, la interfaz de red se selecciona automáticamente según el tipo de máquina que especifiques para el argumento machine_type. Este argumento está disponible en el módulo sap_hana versión 202302060649 o posterior.
   disk_type	Cadena	Opcional. Especifica el tipo predeterminado de volumen de Persistent Disk o Hyperdisk que deseas implementar para los datos de SAP y los volúmenes de registros en tu implementación. Para obtener información sobre la implementación de disco predeterminada que realiza la configuración de Terraform que proporciona Google Cloud, consulta Implementación de discos mediante Terraform. Los siguientes valores son válidos para este argumento: pd-ssd, pd-balanced, hyperdisk-extreme, hyperdisk-balanced y pd-extreme. En las implementaciones de escalamiento vertical de SAP HANA, también se implementa un disco persistente balanceado independiente para el directorio /hana/shared. Puedes anular este tipo de disco predeterminado y los tamaños predeterminados del disco y las IOPS predeterminadas a través de algunos argumentos avanzados. Para obtener más información, navega al directorio de trabajo, ejecuta el comando terraform init y, luego, consulta el archivo /.terraform/modules/manual_sap_hana_scaleout_ha/variables.tf. Antes de usar estos argumentos en producción, asegúrate de probarlos en un entorno de no producción.
   use_single_shared_data_log_disk	Booleano	Opcional. El valor predeterminado es false, que le indica a Terraform que implemente un disco persistente o Hyperdisk independiente para cada uno de los siguientes volúmenes de SAP: /hana/data,/hana/log, /hana/shared y /usr/sap. Para activar estos volúmenes de SAP en el mismo disco persistente o Hyperdisk, especifica true.
   include_backup_disk	Booleano	Opcional. Este argumento se aplica a las implementaciones de escalamiento vertical de SAP HANA. El valor predeterminado es true, que le indica a Terraform implementar un disco separado para alojar el directorio /hanabackup. El tipo de disco se determina mediante el argumento backup_disk_type. El tamaño de este disco se determina a través del argumento sap_hana_backup_size. Si configuras el valor de include_backup_disk como false, no se implementa ningún disco para el directorio /hanabackup.
   public_ip	Booleano	Opcional. Determina si se agrega o no una dirección IP pública a la instancia de VM. El valor predeterminado es true. Precaución: No especifiques false, a menos que tengas una puerta de enlace NAT configurada con una etiqueta de red definida para la VM o le hayas proporcionado a VM otra ruta a Internet. Si no hay una ruta a Internet, la instalación falla.
   service_account	Cadena	Opcional. Especifica la dirección de correo electrónico de una cuenta de servicio administrada por el usuario que usarán las VM del host y los programas que se ejecutan en las VM del host. Por ejemplo: [e-mail]. Si especificas este argumento sin un valor o lo omites, la secuencia de comandos de instalación usará la cuenta de servicio predeterminada de Compute Engine. Para obtener más información, consulta la sección sobre administración de identidades y accesos para programas SAP en Google Cloud.
   sap_deployment_debug	Booleano	Opcional. Solo cuando Atención al cliente de Cloud te solicite habilitar la depuración para tu implementación, especifica true, lo que hace que la implementación genere registros de implementación con verbosidad. El valor predeterminado es false.
   primary_reservation_name	Cadena	Opcional. Especifica el nombre de la reserva para usar una reserva de VM de Compute Engine específica para aprovisionar la instancia de VM que aloja la instancia principal de SAP HANA de tu clúster de alta disponibilidad. De forma predeterminada, la secuencia de comandos de instalación selecciona cualquier reserva de Compute Engine disponible según las siguientes condiciones. Para que una reserva se pueda usar, sin importar si especificas un nombre o si la secuencia de comandos de instalación lo selecciona automáticamente, la reserva debe configurarse con lo siguiente: La opción specificReservationRequired se configura como true o, en la consola de Google Cloud, la opción Seleccionar reserva específica está seleccionada. Algunos tipos de máquinas de Compute Engine son compatibles con las plataformas de CPU que no están cubiertas por la certificación de SAP del tipo de máquina. Si la reserva de destino es para cualquiera de los siguientes tipos de máquina, la reserva debe especificar las plataformas de CPU mínimas como se indica: n1-highmem-32: Broadwell de Intel n1-highmem-64: Broadwell de Intel n1-highmem-96: Intel Skylake m1-megamem-96: Intel Skylake Las plataformas de CPU mínimas para todos los demás tipos de máquinas certificados por SAP para su uso en Google Cloud cumplen con el requisito mínimo de CPU de SAP.
   secondary_reservation_name	Cadena	Opcional. Especifica el nombre de la reserva para usar una reserva de VM de Compute Engine específica para aprovisionar la instancia de VM que aloja la instancia secundaria de SAP HANA de tu clúster de alta disponibilidad. De forma predeterminada, la secuencia de comandos de instalación selecciona cualquier reserva de Compute Engine disponible según las siguientes condiciones. Para que una reserva se pueda usar, sin importar si especificas un nombre o si la secuencia de comandos de instalación lo selecciona automáticamente, la reserva debe configurarse con lo siguiente: La opción specificReservationRequired se configura como true o, en la consola de Google Cloud, la opción Seleccionar reserva específica está seleccionada. Algunos tipos de máquinas de Compute Engine son compatibles con las plataformas de CPU que no están cubiertas por la certificación de SAP del tipo de máquina. Si la reserva de destino es para cualquiera de los siguientes tipos de máquina, la reserva debe especificar las plataformas de CPU mínimas como se indica: n1-highmem-32: Broadwell de Intel n1-highmem-64: Broadwell de Intel n1-highmem-96: Intel Skylake m1-megamem-96: Intel Skylake Las plataformas de CPU mínimas para todos los demás tipos de máquinas certificados por SAP para su uso en Google Cloud cumplen con el requisito mínimo de CPU de SAP.
   primary_static_ip	Cadena	Opcional. Especifica una dirección IP estática válida para la instancia de VM principal en tu clúster de alta disponibilidad. Si no especificas una, se generará una dirección IP automáticamente para tu instancia de VM. Por ejemplo, 128.10.10.10. Este argumento está disponible en el módulo sap_hana_ha versión 202306120959 o posterior.
   secondary_static_ip	Cadena	Opcional. Especifica una dirección IP estática válida para la instancia de VM secundaria en tu clúster de alta disponibilidad. Si no especificas una, se generará una dirección IP automáticamente para tu instancia de VM. Por ejemplo, 128.11.11.11. Este argumento está disponible en el módulo sap_hana_ha versión 202306120959 o posterior.
   primary_worker_static_ips	List(String)	Opcional. Especifica un array de direcciones IP estáticas válidas para las instancias de trabajador en la instancia principal de tu sistema de alta disponibilidad de escalamiento horizontal de SAP HANA. Si no especificas un valor para este argumento, se genera una dirección IP de forma automática para cada instancia de VM de trabajador. Por ejemplo, [ "1.0.0.1", "2.3.3.4" ]. Las direcciones IP estáticas se asignan en el orden de creación de la instancia. Por ejemplo, si eliges implementar 3 instancias de trabajador, pero especificas solo 2 direcciones IP para el argumento primary_worker_static_ips, entonces estas direcciones IP se asignan a las primeras dos instancias de VM que implementa la configuración de Terraform. Para la tercera instancia de VM de trabajador, la dirección IP se genera automáticamente. Este argumento está disponible en el módulo sap_hana_ha versión 202307270727 o posterior.
   secondary_worker_static_ips	List(String)	Opcional. Especifica un array de direcciones IP estáticas válidas para las instancias de trabajador en la instancia secundaria de tu sistema de alta disponibilidad de escalamiento horizontal de SAP HANA. Si no especificas un valor para este argumento, se genera una dirección IP de forma automática para cada instancia de VM de trabajador. Por ejemplo, [ "1.0.0.2", "2.3.3.5" ]. Las direcciones IP estáticas se asignan en el orden de creación de la instancia. Por ejemplo, si eliges implementar 3 instancias de trabajador, pero especificas solo 2 direcciones IP para el argumento secondary_worker_static_ips, entonces estas direcciones IP se asignan a las primeras dos instancias de VM que implementa la configuración de Terraform. Para la tercera instancia de VM de trabajador, la dirección IP se genera automáticamente. Este argumento está disponible en el módulo sap_hana_ha versión 202307270727 o posterior.

   En los siguientes ejemplos se muestran los archivos de configuración completados que definen un clúster de alta disponibilidad para un sistema SAP HANA de escalamiento horizontal. El clúster usa un balanceador de cargas de red de transferencia interno para administrar la VIP.

   Terraform implementa los recursos de Google Cloud que se definen en el archivo de configuración y las secuencias de comandos toman el control para configurar el sistema operativo e instalar SAP HANA.

   Nota: Las secuencias de comandos de implementación instalan SAP HANA solo si se especifican los argumentos adecuados en el archivo de configuración de Terraform. Para instalar SAP HANA de forma automática en las VM implementadas, debes especificar los siguientes argumentos:

   • sap_hana_deployment_bucket
   • sap_hana_sid
   • sap_hana_sidadm_password o sap_hana_sidadm_password_secret
   • sap_hana_system_password o sap_hana_system_password_secret

6. En el mismo archivo manual_sap_hana_scaleout_ha.tf, actualiza los valores de argumento para majority_maker. Los argumentos se describen en la siguiente tabla.

   Argument	Tipo de dato	Descripción
   project	Cadena	Especifica el ID del proyecto de Google Cloud en el que implementarás este sistema.
   majority_maker_instance_name	Cadena	Especifica un nombre para la instancia de VM de Compute Engine que funcione como marca mayoritaria. Este argumento está disponible en el módulo sap_hana_ha versión 202307270727 o posterior.
   majority_maker_instance_type	Cadena	Especifica el tipo de máquina virtual (VM) de Compute Engine que deseas usar para la instancia de creador de mayoría. Por ejemplo, n1-highmem-32. Si quieres usar un tipo de VM personalizada, especifica un tipo de VM predefinido con una cantidad de CPU virtuales más cercana al número que necesitas sin dejar de ser más grande. Una vez completada la implementación, modifica la cantidad de CPU virtuales y la cantidad de memoria. Este argumento está disponible en el módulo sap_hana_ha versión 202307270727 o posterior.
   majority_maker_zone	Cadena	Especifica una zona en la que se implementará la instancia de VM de marca mayoritaria. Esta zona debe estar en la misma región que las zonas principal y secundaria. Por ejemplo, us-east1-d Google Cloud recomienda que la instancia de VM de creador de mayoría se implemente en una zona diferente a la de los sistemas SAP HANA principal y secundario. Este argumento está disponible en el módulo sap_hana_ha versión 202307270727 o posterior.
   majority_maker_linux_image	Cadena	Con los mismos valores que en el paso anterior, especifica la ruta de acceso completa de la imagen como "linux_image_project/linux_image". Por ejemplo, "rhel-sap-cloud/rhel-9-0-sap-v20230708".
   subnetwork	Cadena	Especifica el nombre de la subred que creaste en un paso anterior. Si realizas la implementación en una VPC compartida, especifica este valor como SHARED_VPC_PROJECT_ID/SUBNETWORK. Por ejemplo: myproject/network1
   service_account	Cadena	Opcional. Especifica la dirección de correo electrónico de una cuenta de servicio administrada por el usuario que usarán las VM del host y los programas que se ejecutan en las VM del host. Por ejemplo: [e-mail]. Si especificas este argumento sin un valor o lo omites, la secuencia de comandos de instalación usará la cuenta de servicio predeterminada de Compute Engine. A fin de obtener más información, consulta la sección sobre administración de identidades y accesos para programas SAP en Google Cloud.
   metadata_startup_script	Cadena	No edites este argumento. De forma predeterminada, el creador de la mayoría descargará la última secuencia de comandos de inicio para preparar la instancia para el agrupamiento en clústeres de Pacemaker.

   Para mayor claridad, se omiten los comentarios en la siguiente configuración de ejemplo.

  module "sap_hana_primary" {
    source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"

    project_id                     = "example-project-123456"
    zone                           = "us-west1-a"
    machine_type                   = "n1-highmem-32"
    subnetwork                     = "default"
    linux_image                    = "rhel-9-0-sap-v20230711"
    linux_image_project            = "rhel-sap-cloud"
    instance_name                  = "hana-ha-1"
    sap_hana_sid                   = "HA1"

    sap_hana_deployment_bucket      = "my-hana-bucket"
    sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
    sap_hana_system_password_secret = "hana_sys_pwd"
    sap_hana_scaleout_nodes         = 1
    sap_hana_shared_nfs             = "10.10.10.1:/hana_scaleout/hana_a/shared"
    sap_hana_backup_nfs             = "10.10.10.1:/hana_scaleout/hana_a/backup"

  }
  module "sap_hana_secondary" {
    source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"

    project_id                     = "example-project-123456"
    zone                           = "us-west1-b"
    machine_type                   = "n1-highmem-32"
    subnetwork                     = "default"
    linux_image                    = "rhel-9-0-sap-v20230711"
    linux_image_project            = "rhel-sap-cloud"
    instance_name                  = "hana-ha-2"
    sap_hana_sid                   = "HA1"

    sap_hana_deployment_bucket      = "my-hana-bucket"
    sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
    sap_hana_system_password_secret = "hana_sys_pwd"
    sap_hana_scaleout_nodes         = 1
    sap_hana_shared_nfs             = "10.10.10.2:/hana_scaleout/hana_b/shared"
    sap_hana_backup_nfs             = "10.10.10.2:/hana_scaleout/hana_b/backup"
  }

  resource "google_compute_instance" "majority_maker" {

    project =  "example-project-123456"

    # majority_maker_instance_name
    name         = "majority-maker"

    # majority_maker_instance_type
    machine_type = "n1-standard-8"

    # majority_maker_zone
    zone         = "us-west1-c"

    boot_disk {
      initialize_params {
        # majority_maker_linux_image
        image = "rhel-sap-cloud/rhel-9-0-sap-v20230711"
      }
    }

    network_interface {
      # network or subnetwork
      network = "default"
    }

      service_account {
      # service_account (Optional)
      # email  = [e-mail].
      scopes = ["cloud-platform"]
    }

    # Do not edit
    metadata_startup_script = "curl -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh | bash -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh"

  }

1. Inicializa tu directorio de trabajo actual y descarga los archivos del módulo y el complemento del proveedor de Terraform para Google Cloud:

   terraform init

   El comando terraform init prepara tu directorio de trabajo para otros comandos de Terraform.

   Para forzar una actualización del complemento de proveedor y los archivos de configuración en tu directorio de trabajo, especifica la marca --upgrade. Si se omite la marca --upgrade y no realizas ningún cambio en tu directorio de trabajo, Terraform usa las copias almacenadas en caché de forma local, incluso si latest se especifica en la URL source.

   terraform init --upgrade 

2. De manera opcional, crea el plan de ejecución de Terraform:

   terraform plan

   El comando terraform plan muestra los cambios que requiere tu configuración actual. Si omites este paso, el comando terraform apply crea automáticamente un plan nuevo y te solicita que lo apruebes.

3. Aplica el plan de ejecución:

   terraform apply

   Cuando se te solicite aprobar las acciones, ingresa yes.

   El comando terraform apply configura la infraestructura de Google Cloud y, luego, entrega el control a una secuencia de comandos que configura el clúster de HA y, luego, instala SAP HANA según los argumentos definidos en el archivo de configuración de Terraform.

   Mientras Terraform tiene control, los mensajes de estado se escriben en Cloud Shell. Una vez que se invocan las secuencias de comandos, los mensajes de estado se escriben en Logging y se pueden ver en la consola de Google Cloud, como se describe en Verifica los registros.

Verifica la implementación de tu sistema HANA de alta disponibilidad

Verifica los registros

1. En la consola de Google Cloud, abre Cloud Logging para supervisar el progreso de la instalación y verificar si hay errores.

   Nota: Es posible que generes costos cuando completes este paso en Cloud Logging. Para obtener más información, consulta Precios de Cloud Logging.

   Ir a Cloud Logging

2. Filtra los registros:

   Explorador de registros

   1. En la página Explorador de registros, ve al panel Consulta.

   2. En el menú desplegable Recurso, selecciona Global y, luego, haz clic en Agregar.

      Si no ves la opción Global, ingresa la siguiente consulta en el editor de consultas:

      resource.type="global"
      "Deployment"
      

   3. Haz clic en Ejecutar consulta.

   Visor de registros heredado

   • En la página Visor de registros heredado, en el menú del selector básico, selecciona Global como tu recurso de registro.

3. Analiza los registros filtrados:

   • Si se muestra "--- Finished", el proceso de implementación está completo y puedes continuar con el siguiente paso.

   • Si ves un error de cuota, sigue estos pasos:

     1. En la página Cuotas de IAM y administración, aumenta cualquiera de las cuotas que no cumplan con los requisitos de SAP HANA que se enumeran en la Guía de planificación de SAP HANA.

     2. Abra Cloud Shell.

        Ir a Cloud Shell

     3. Ve al directorio de trabajo y borra la implementación para limpiar las VM y los discos persistentes de la instalación fallida:

        terraform destroy

        Cuando se te solicite aprobar la acción, ingresa yes.

     4. Vuelve a ejecutar tu implementación.

Verifica la configuración de la VM y la instalación de SAP HANA

Nota: Las secuencias de comandos de implementación instalan SAP HANA solo si se especifican los argumentos adecuados en el archivo de configuración de Terraform. De lo contrario, puedes omitir este paso.

1. Después de que el sistema SAP HANA se implemente sin errores, conéctate a cada VM mediante una conexión SSH. En la página Instancias de VM de Compute Engine, puedes hacer clic en el botón SSH para cada instancia de VM o usar tu método SSH preferido.

   

2. Cambia al usuario raíz.

   sudo su -

3. En el símbolo del sistema, ingresa df -h. Asegúrate de ver un resultado que incluya los directorios /hana, como /hana/data.

   [root@example-ha-vm1 ~]# df -h
     Filesystem                        Size  Used Avail Use% Mounted on
     devtmpfs                          126G     0  126G   0% /dev
     tmpfs                             126G   54M  126G   1% /dev/shm
     tmpfs                             126G   25M  126G   1% /run
     tmpfs                             126G     0  126G   0% /sys/fs/cgroup
     /dev/sda2                          30G  5.4G   25G  18% /
     /dev/sda1                         200M  6.9M  193M   4% /boot/efi
     /dev/mapper/vg_hana-shared        251G   52G  200G  21% /hana/shared
     /dev/mapper/vg_hana-sap            32G  477M   32G   2% /usr/sap
     /dev/mapper/vg_hana-data          426G  9.8G  417G   3% /hana/data
     /dev/mapper/vg_hana-log           125G  7.0G  118G   6% /hana/log
     /dev/mapper/vg_hanabackup-backup  512G  9.3G  503G   2% /hanabackup
     tmpfs                              26G     0   26G   0% /run/user/900
     tmpfs                              26G     0   26G   0% /run/user/899
     tmpfs                              26G     0   26G   0% /run/user/1003

Limpia y vuelve a intentar la implementación

Si alguno de los pasos de verificación de implementación en las secciones anteriores muestra que la instalación no se realizó de forma correcta, debes deshacer la implementación y volver a intentarlo a través de los siguientes pasos:

1. Resuelve cualquier error para asegurarte de que tu implementación no vuelva a fallar por el mismo motivo. Si deseas obtener más información para verificar los registros o resolver errores relacionados con la cuota, consulta Verifica los registros.

2. Abre Cloud Shell o, si instalaste Google Cloud CLI en la estación de trabajo local, abre una terminal.

   Abra Cloud Shell

3. Ve al directorio que contiene el archivo de configuración de Terraform que usaste para esta implementación.

4. Borra todos los recursos que forman parte de la implementación a través de la ejecución del siguiente comando:

   terraform destroy

   Cuando se te solicite aprobar la acción, ingresa yes.

5. Vuelve a intentar la implementación como se indicó antes en esta guía.

Valida la instalación del Agente de Google Cloud para SAP

Después de que hayas implementado todas las instancias y que hayas instalado el sistema SAP, valida que el agente de Google Cloud para SAP funcione de forma correcta.

Verifica que el Agente de Google Cloud para SAP esté en ejecución

Para verificar que el agente esté en ejecución, sigue estos pasos:

1. Establece una conexión SSH con la instancia de VM del host.

2. Ejecuta el siguiente comando:

   systemctl status google-cloud-sap-agent

   Si el agente funciona de forma correcta, el resultado contendrá active (running). Por ejemplo:

   google-cloud-sap-agent.service - Google Cloud Agent for SAP
   Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
   Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
   Main PID: 1337673 (google-cloud-sa)
   Tasks: 9 (limit: 100427)
   Memory: 22.4 M (max: 1.0G limit: 1.0G)
   CGroup: /system.slice/google-cloud-sap-agent.service
          └─1337673 /usr/bin/google-cloud-sap-agent
   

Si el agente no está en ejecución, reinicia el agente.

Verifica que el agente de host SAP reciba métricas

Para verificar que el Agente de Google Cloud para SAP recopile las métricas de infraestructura y que se envíen de forma correcta al agente de host SAP, sigue estos pasos:

1. En el sistema SAP, ingresa la transacción ST06.

2. En el panel de descripción general, revisa la disponibilidad y el contenido de los siguientes campos para verificar la configuración completa y correcta de la infraestructura de supervisión de SAP y Google:

   • Proveedor de servicios en la nube: Google Cloud Platform
   • Acceso de supervisión mejorada: TRUE
   • Detalles de supervisión mejorada: ACTIVE

Configura la supervisión para SAP HANA

De manera opcional, puedes supervisar tus instancias de SAP HANA con el agente para SAP de Google Cloud. Desde la versión 2.0, puedes configurar el agente para recopilar las métricas de supervisión de SAP HANA y enviarlas a Cloud Monitoring. Cloud Monitoring te permite crear paneles para visualizar estas métricas, configurar alertas basadas en límites de métricas y mucho más.

Si deseas obtener más información sobre la recopilación de métricas de supervisión de SAP HANA mediante el agente de para SAP de Google Cloud, consulta Recopilación de métricas de supervisión de SAP HANA.

Crea una lista de instancias para la automatización de secuencias de comandos (opcional)

Para automatizar parcialmente algunas de las tareas repetitivas durante la configuración del sistema SAP HANA y del clúster de Pacemaker, puedes usar secuencias de comandos de Bash. En esta guía, se usan esas secuencias de comandos de Bash para acelerar la configuración de tu sistema SAP HANA y del clúster de Pacemaker. Estas secuencias de comandos requieren una lista de todas las instancias VM implementadas y sus zonas correspondientes como entrada.

Para habilitar esta automatización, crea un archivo llamado nodes.txt y, luego, incluye los detalles de todas las instancias de VM implementadas en el siguiente formato: nombre de la zona, espacio en blanco y, luego, el nombre de la instancia de VM. El siguiente archivo de muestra se usa en esta guía:

# cat nodes.txt
  us-west1-a hana-ha-vm-1
  us-west1-a hana-ha-vm-1w1
  us-west1-a hana-ha-vm-1w2
  us-west1-b hana-majoritymaker
  us-west1-c hana-ha-vm-2
  us-west1-c hana-ha-vm-2w1
  us-west1-c hana-ha-vm-2w2
 

Configura el acceso SSH sin contraseña

Para configurar el clúster de Pacemaker y sincronizar las claves del almacén seguro (SSFS) de SAP HANA, se requiere un acceso SSH sin contraseña entre todos los nodos, incluida la instancia del creador de mayoría. Para el acceso SSH sin contraseña, debes agregar las claves públicas SSH a los metadatos de la instancia de todas las instancias implementadas.

El formato de los metadatos es USERNAME: PUBLIC-KEY-VALUE.

Para obtener más información sobre cómo agregar claves SSH a las VMs, consulta Agrega claves SSH a las VMs que usan claves SSH basadas en metadatos.

Pasos manuales

1. Para cada instancia en los sistemas principales y secundarios, así como en la instancia del creador de mayorías, recopila la clave pública para el usuario root.

   gcloud compute ssh --quiet --zone ZONE_ID INSTANCE_NAME -- sudo cat /root/.ssh/id_rsa.pub

2. Agrega la clave con la string root: y escribe la clave como una línea nueva en el archivo llamado public-ssh-keys.txt, por ejemplo:

   root:ssh-rsa AAAAB3NzaC1JfuYnOI1vutCs= root@INSTANCE_NAME

3. Después de recopilar todas las claves públicas SSH, sube las claves como metadatos a todas las instancias:

   gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone ZONE_ID INSTANCE_NAME

Pasos automatizados

Como alternativa, a fin de automatizar el proceso de configuración del acceso SSH sin contraseña para todas las instancias que se enumeran en nodes.txt, realiza los siguientes pasos desde la consola de Google Cloud:

1. Crea una lista de claves públicas de todas las instancias implementadas:

   while read -u10 ZONE HOST ;  do echo "Collecting public-key from $HOST"; { echo 'root:'; gcloud compute ssh --quiet --zone $ZONE $HOST --tunnel-through-iap -- sudo cat /root/.ssh/id_rsa.pub; } | tr -ds '\n' " " >> public-ssh-keys.txt; done 10< nodes.txt

2. Asigna las claves públicas SSH como entradas de metadatos a todas las instancias:

   while read -u10 ZONE HOST ;  do echo "Adding public keys to $HOST"; gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone $ZONE $HOST; done 10< nodes.txt 

Inhabilita el inicio automático de SAP HANA

Pasos manuales

Asegúrate de que el inicio automático de SAP HANA esté inhabilitado para cada instancia de SAP HANA en el clúster. Para las conmutaciones por error, Pacemaker administra el inicio y la detención de las instancias de SAP HANA en un clúster.

1. En cada host como SID_LCadm, detén SAP HANA:

   > HDB stop

2. En cada host, abre el perfil de SAP HANA con un editor, como "vi":

   vi /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_HOST_NAME

3. Establece la propiedad Autostart en 0:

   Autostart=0

4. Guarda el perfil.

5. En cada host como SID_LCadm, inicia SAP HANA:

   > HDB start

Pasos automatizados

Como alternativa, para inhabilitar el inicio automático de SAP HANA para todas las instancias que se enumeran en nodes.txt, ejecuta la siguiente secuencia de comandos desde la consola de Google Cloud:

while read -u10 ZONE HOST ;
 do gcloud compute ssh --verbosity=none --zone $ZONE $HOST -- "echo Setting Autostart=0 on \$HOSTNAME;
 sudo sed -i 's/Autostart=1/Autostart=0/g' /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_\$HOSTNAME";
 done 10< nodes.txt
 

Nota: Ignora el error “No existe el archivo o el directorio” que se muestra cuando la secuencia de comandos de automatización accede a la instancia de creador de mayorías. Este error se muestra porque la instancia de creador de mayorías no tiene SAP HANA instalado.

Habilita SAP HANA Fast Restart

Google Cloud recomienda enfáticamente habilitar SAP HANA Fast Restart para cada instancia de SAP HANA, en especial para instancias más grandes. SAP HANA Fast Restart reduce los tiempos de reinicio en caso de que SAP HANA finalice, pero el sistema operativo permanezca en ejecución.

Nota: Si implementas SAP HANA mediante el módulo de Terraform de Google Cloud sap_hana o sap_hana_ha, versión 202309280828 o posterior, entonces el reinicio rápido se habilita automáticamente.

Como se establece en las secuencias de comandos de automatización que proporciona Google Cloud, la configuración del kernel y el sistema operativo ya son compatibles con el reinicio rápido de SAP HANA. Debes definir el sistema de archivos tmpfs y configurar SAP HANA.

Para definir el sistema de archivos tmpfs y configurar SAP HANA, puedes seguir los pasos manuales o usar la secuencia de comandos de automatización que proporciona Google Cloud para habilitar el reinicio rápido de SAP HANA. Para obtener más información, consulta los siguientes vínculos:

• Pasos manuales: Habilita el reinicio rápido de SAP HANA
• Pasos manuales: Habilita el reinicio rápido de SAP HANA

Para obtener instrucciones autorizadas completas sobre Fast Restart SAP HANA, consulta la documentación de la opción Fast Restart SAP HANA.

Pasos manuales

Configura el sistema de archivos tmpfs

Después de que las VM del host y los sistemas base de SAP HANA se implementan de forma correcta, debes crear y activar directorios para los nodos de NUMA en el sistema de archivos tmpfs.

Muestra la topología de NUMA de tu VM

Para poder asignar el sistema de archivos tmpfs requerido, debes saber cuántos nodos de NUMA tiene tu VM. Si deseas mostrar los nodos de NUMA disponibles en una VM de Compute Engine, ingresa el siguiente comando:

lscpu | grep NUMA

Por ejemplo, un tipo de VM m2-ultramem-208 tiene cuatro nodos de NUMA, numerados del 0 al 3, como se muestra en el siguiente ejemplo:

NUMA node(s):        4
NUMA node0 CPU(s):   0-25,104-129
NUMA node1 CPU(s):   26-51,130-155
NUMA node2 CPU(s):   52-77,156-181
NUMA node3 CPU(s):   78-103,182-207

Crea los directorios de nodos de NUMA

Crea un directorio para cada nodo de NUMA en tu VM y configura los permisos.

Por ejemplo, para cuatro nodos de NUMA que están numerados del 0 al 3:

mkdir -pv /hana/tmpfs{0..3}/SID
chown -R SID_LCadm:sapsys /hana/tmpfs*/SID
chmod 777 -R /hana/tmpfs*/SID

Activa los directorios de nodos de NUMA en tmpfs

Activa los directorios del sistema de archivos tmpfs y especifica una preferencia de nodo de NUMA para cada uno con mpol=prefer:

SID especifica el SID con letras mayúsculas.

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID
mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID
mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID
mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID

Nota: si cambias los tipos de máquina y los nodos de NUMA aumentan o disminuyen, debes modificar el sistema de archivos tmpfs y la sección [persistence] del archivo INI de SAP HANA, que se muestra en la siguiente sección, para que coincida con la cantidad nueva de nodos de NUMA.

Actualizar /etc/fstab

Para asegurarte de que los puntos de activación estén disponibles después de reiniciar el sistema operativo, agrega entradas a la tabla del sistema de archivos, /etc/fstab:

tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0
tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1
tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2
tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3

Opcional: Establece límites para el uso de memoria

El sistema de archivos tmpfs puede aumentar o reducirse de forma dinámica.

A fin de limitar la memoria que usa el sistema de archivos tmpfs, puedes establecer un límite de tamaño para un volumen de nodo NUMA con la opción size. Por ejemplo:

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID

También puedes limitar el uso de memoria tmpfs general de todos los nodos de NUMA para una instancia determinada de SAP HANA y un nodo del servidor determinado si configuras el parámetro persistent_memory_global_allocation_limit en la sección [memorymanager] del archivo global.ini.

Configuración de SAP HANA para Fast Restart

A fin de configurar SAP HANA para Fast Restart, actualiza el archivo global.ini y especifica las tablas que se almacenarán en la memoria persistente.

Actualiza la sección [persistence] en el archivo global.ini

Configura la sección [persistence] en el archivo global.ini de SAP HANA para hacer referencia a las ubicaciones de tmpfs. Separa cada ubicación de tmpfs con un punto y coma:

[persistence]
basepath_datavolumes = /hana/data
basepath_logvolumes = /hana/log
basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID

En el ejemplo anterior, se especifican cuatro volúmenes de memoria para cuatro nodos de NUMA, que corresponden a m2-ultramem-208. Si ejecutas en el m2-ultramem-416, debes configurar ocho volúmenes de memoria (0..7).

Reinicia SAP HANA después de modificar el archivo global.ini.

SAP HANA ahora puede usar la ubicación de tmpfs como espacio de memoria persistente.

Especifica las tablas que se almacenarán en la memoria persistente

Especifica particiones o tablas de columnas específicas para almacenarlas en la memoria persistente.

Por ejemplo, para activar la memoria persistente en una tabla existente, ejecuta la consulta de SQL:

ALTER TABLE exampletable persistent memory ON immediate CASCADE

Para cambiar el valor predeterminado de las tablas nuevas, agrega el parámetro table_default en el archivo indexserver.ini. Por ejemplo:

[persistent_memory]
table_default = ON

Para obtener más información sobre cómo controlar las columnas, las tablas y qué vistas de supervisión proporcionan información detallada, consulta Memoria persistente de SAP HANA.

Pasos automatizados

La secuencia de comandos de automatización que proporciona Google Cloud para habilitar el reinicio rápido de SAP HANA realiza cambios en los directorios /hana/tmpfs*, el archivo /etc/fstab y la configuración de SAP HANA. Cuando ejecutas la secuencia de comandos, es posible que debas realizar pasos adicionales en función de si esta es la implementación inicial de tu sistema SAP HANA o de cambiar el tamaño de la máquina a un tamaño de NUMA diferente.

Para la implementación inicial de tu sistema SAP HANA o cambio del tamaño de la máquina a fin de aumentar la cantidad de nodos de NUMA, asegúrate de que SAP HANA se ejecute durante la ejecución de la secuencia de comandos de automatización que Google Cloud proporciona para habilitar el reinicio rápido de SAP HANA.

Cuando cambies el tamaño de tu máquina a fin de disminuir la cantidad de nodos de NUMA, asegúrate de que SAP HANA se detenga durante la ejecución de la secuencia de comandos de automatización que proporciona Google Cloud para habilitar el reinicio rápido de SAP HANA. Después de ejecutar la secuencia de comandos, debes actualizar de forma manual la configuración de SAP HANA para completar la configuración de reinicio rápido de SAP HANA. Para obtener más información, consulta Configuración de SAP HANA para un reinicio rápido.

Nota: Recomendamos que ejecutes la secuencia de comandos que proporciona Google Cloud para habilitar el reinicio rápido de SAP HANA en un entorno que no sea de producción y verificar los resultados de forma exhaustiva antes de ejecutar la secuencia de comandos en entornos de producción. Asumes la responsabilidad de habilitar de forma correcta el reinicio rápido de SAP HANA.

Para habilitar el reinicio rápido de SAP HANA, sigue estos pasos:

1. Establece una conexión SSH con la VM del host.

2. Cambiar a la raíz:

   sudo su -

3. Descarga la secuencia de comandos sap_lib_hdbfr.sh:

   wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh

4. Haz que el archivo sea ejecutable:

   chmod +x sap_lib_hdbfr.sh

5. Verifica que la configuración no tenga errores:

   vi sap_lib_hdbfr.sh
   ./sap_lib_hdbfr.sh -help

   Si el comando muestra un error, comunícate con el servicio de Atención al cliente de Cloud. Si deseas obtener más información para comunicarte con el equipo de Atención al cliente de Cloud, consulta Obtén asistencia para SAP en Google Cloud.

6. Ejecuta la secuencia de comandos después de reemplazar el ID del sistema SAP HANA (SID) y la contraseña para el usuario SYSTEM de la base de datos SAP HANA. Para proporcionar la contraseña de forma segura, te recomendamos que uses un secreto en Secret Manager.

   Ejecuta la secuencia de comandos con el nombre de un secreto en Secret Manager. Este secreto debe existir en el proyecto de Google Cloud que contiene tu instancia de VM del host.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME 

   Reemplaza lo siguiente:

   • SID: Especifica el SID con letras mayúsculas. Por ejemplo, AHA.
   • SECRET_NAME: Especifica el nombre del secreto que corresponde a la contraseña del usuario del sistema de la base de datos de SAP HANA. Este secreto debe existir en el proyecto de Google Cloud que contiene tu instancia de VM del host.

   Como alternativa, puedes ejecutar la secuencia de comandos con una contraseña de texto sin formato. Después de habilitar el reinicio rápido de SAP HANA, asegúrate de cambiar la contraseña. No se recomienda usar una contraseña con texto sin formato, ya que tu contraseña se registraría en el historial de línea de comandos de tu VM.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'

   Reemplaza lo siguiente:

   • SID: Especifica el SID con letras mayúsculas. Por ejemplo, AHA.
   • PASSWORD: Especifica la contraseña para el usuario del sistema de la base de datos de SAP HANA.

Para obtener una ejecución inicial exitosa, deberías ver un resultado similar al siguiente:

INFO - Script is running in standalone mode
ls: cannot access '/hana/tmpfs*': No such file or directory
INFO - Setting up HANA Fast Restart for system 'TST/00'.
INFO - Number of NUMA nodes is 2
INFO - Number of directories /hana/tmpfs* is 0
INFO - HANA version 2.57
INFO - No directories /hana/tmpfs* exist. Assuming initial setup.
INFO - Creating 2 directories /hana/tmpfs* and mounting them
INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839
INFO - Updating the HANA configuration.
INFO - Running command: select * from dummy
DUMMY
"X"
1 row selected (overall time 4124 usec; server time 130 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;'
0 rows affected (overall time 3570 usec; server time 2239 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain';
0 rows affected (overall time 4308 usec; server time 2441 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON';
0 rows affected (overall time 3422 usec; server time 2152 usec)

Pasos automatizados

Para automatizar este proceso, usa nodes.txt y las siguientes secuencias de comandos de la consola de Google Cloud:

1. Genera un archivo hosts.txt con una lista de direcciones IP y nombres de host:

   while read -u10 ZONE HOST ; do gcloud compute instances list --filter="name=( 'NAME' $HOST )" --format="csv[separator=' ',no-heading](networkInterfaces[0].networkIP,name)" >> hosts.txt; done 10< nodes.txt

2. Verifica que tu archivo hosts.txt sea similar al siguiente ejemplo:

   10.138.0.1 rhel-hana-primary
   10.138.0.2 rhel-hana-primaryw1
   10.138.0.3 rhel-hana-secondary
   10.138.0.4 rhel-hana-secondaryw1
   10.138.0.5 rhel-sap-mm
   

3. En todos los hosts del clúster, incluido el creador de la mayoría, actualiza el archivo /etc/hosts para incluir los nombres de host y las direcciones IP internas de todas las instancias en el clúster de Pacemaker.

   while read -u10 ZONE HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet $HOST --zone $ZONE -- "sudo tee -a /etc/hosts" < hosts.txt; done 10< nodes.txt

Crea una copia de seguridad de las bases de datos

Crea copias de seguridad de tus bases de datos a fin de iniciar el registro de la base de datos para la replicación del sistema SAP HANA y crear un punto de recuperación.

Si tienes varias bases de datos de usuarios en una configuración de MDC, crea una copia de seguridad de cada una de ellas.

La plantilla de Deployment Manager usa /hanabackup/data/SID como directorio de copia de seguridad predeterminado.

Sigue estos pasos para crear copias de seguridad de bases de datos nuevas de SAP HANA:

1. En el host principal, cambia a SID_LCadm. El comando puede ser diferente según la imagen de SO.

   sudo -i -u SID_LCadm

2. Crea copias de seguridad de las bases de datos:

   • Para un sistema de contenedor de base de datos único de SAP HANA, ejecuta este comando:

     > hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     En el siguiente ejemplo, se muestra una respuesta exitosa de un sistema SAP HANA nuevo:

     0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)

   • Para un sistema de contenedores de varias bases de datos (MDC) de SAP HANA, crea una copia de seguridad de la base de datos del sistema y de todas las bases de datos de usuarios:

     > hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     > hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

   En el siguiente ejemplo, se muestra una respuesta exitosa de un sistema SAP HANA nuevo:

   0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)

3. Confirma que el modo de registro esté configurado en normal:

   > hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \
     "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"

   Deberías ver lo siguiente:

   VALUE
   "normal"

Habilita la replicación del sistema SAP HANA

Como parte de la habilitación de la replicación del sistema SAP HANA, debes copiar los datos y los archivos de claves de los almacenes seguros de SAP HANA en el sistema de archivos (SSFS) del host principal al secundario. El método que usa este procedimiento para copiar los archivos es solo uno de los métodos que se pueden usar.

1. En el host principal como SID_LCadm, habilita la replicación del sistema:

   > hdbnsutil -sr_enable --name=PRIMARY_HOST_NAME

2. En el host secundario:

   1. Como SID_LCadm, detén SAP HANA:

      > sapcontrol -nr INST_NUM -function StopSystem

   2. Como raíz, archiva los datos de SSFS y los archivos de claves existentes:

      # cd /usr/sap/SID/SYS/global/security/rsecssfs/
      # mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC
      # mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARC

   3. Copia el archivo de datos del host principal:

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \
      /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT

   4. Copia el archivo de claves del host principal:

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \
      /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   5. Actualiza la propiedad de los archivos:

      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   6. Actualiza los permisos de los archivos:

      # chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   7. Como SID_LC, registra el sistema SAP HANA secundario con la replicación del sistema SAP HANA:

      > hdbnsutil -sr_register --remoteHost=PRIMARY_HOST_NAME --remoteInstance=INST_NUM \
      --replicationMode=syncmem --operationMode=logreplay --name=SECONDARY_HOST_NAME

   8. Como SID_LCadm, inicia SAP HANA:

      > sapcontrol -nr INST_NUM -function StartSystem

Valida la replicación del sistema

En el host principal como SID_LCadm, confirma que la replicación del sistema SAP HANA esté activa mediante la ejecución de la siguiente secuencia de comandos de Python:

$ python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Si la replicación está configurada de forma correcta, entre otros indicadores, se muestran los siguientes valores para los servicios xsengine, nameserver y indexserver:

• El Secondary Active Status es YES.
• El Replication Status es ACTIVE.

Además, el overall system replication status muestra ACTIVE.

Habilita los hooks del proveedor de HA/DR de SAP HANA

Red Hat recomienda que habilites el hook del proveedor de HA/DR de SAP HANA, que permite que SAP HANA envíe notificaciones para ciertos eventos y mejora la detección de fallas. Los hooks del proveedor de HA/DR de SAP HANA requieren la versión de SAP HANA 2.0 SPS 03 o una posterior.

Nota: Si deseas implementar los hooks del proveedor HA/DR en un sistema SAP HANA preexistente con un tiempo de inactividad casi nulo, consulta el Guía de operaciones de SAP HANA.

En el sitio principal y secundario, completa los siguientes pasos:

1. Como SID_LCadm, detén SAP HANA:

   > sapcontrol -nr 00 -function StopSystem

1. Como raíz o SID_LCadm, abre el archivo global.ini para editarlo:

   > vi /hana/shared/SID/global/hdb/custom/config/global.ini

2. Agrega las siguientes definiciones al archivo global.ini:

   [ha_dr_provider_SAPHanaSR]
   provider = SAPHanaSR
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 1
   
   [trace]
   ha_dr_saphanasr = info
   

3. Como raíz, crea un archivo de configuración personalizado en el directorio /etc/sudoers.d mediante la ejecución del siguiente comando. Este archivo de configuración nuevo permite que el usuario SID_LCadm acceda a los atributos del nodo del clúster cuando se llama al método de hook srConnectionChanged().

   > sudo visudo -f /etc/sudoers.d/20-saphana

4. En el archivo /etc/sudoers.d/20-saphana, agrega el siguiente texto:

   Reemplaza SID_LC por el SID en letras minúsculas.

   Cmnd_Alias SOK = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR
   SID_LCadm ALL=(ALL) NOPASSWD: SOK, SFAIL
   Defaults!SOK, SFAIL !requiretty

5. En el archivo /etc/sudoers, asegúrate de que se incluya el siguiente texto.

   #includedir /etc/sudoers.d

   Ten en cuenta que el # de este texto es parte de la sintaxis y no significa que la línea sea un comentario.

Nota: Si bien Red Hat recomienda el procedimiento de esta sección, puedes usar un enfoque alternativo. En lugar de crear un archivo de configuración directo, puedes agregar el acceso requerido directamente al archivo /etc/sudoers.

6. Como SID_LCadm, inicia SAP HANA:

   > sapcontrol -nr 00 -function StartSystem

7. En el host principal como SID_LCadm, prueba el estado que informó la secuencia de comandos del hook:

   > cdtrace
   > awk '/ha_dr_SAPHanaSR.*crm_attribute/ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

Configura la compatibilidad con la conmutación por error de Cloud Load Balancing

El servicio de balanceador de cargas de red de transferencia interno con compatibilidad con la conmutación por error enruta el tráfico al host activo en un clúster de SAP HANA basado en un servicio de verificación de estado.

Reserva una dirección IP para la IP virtual

La dirección IP virtual (VIP), que a veces se conoce como dirección IP flotante, sigue el sistema SAP HANA activo. El balanceador de cargas enruta el tráfico que se envía a la VIP hacia la VM que aloja el sistema SAP HANA activo.

1. Abre Cloud Shell:

   Ir a Cloud Shell

2. Reserva una dirección IP para la IP virtual. Esta es la dirección IP que usan las aplicaciones para acceder a SAP HANA. Si omites la marca --addresses, se elige una dirección IP en la subred especificada:

   $ gcloud compute addresses create VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses VIP_ADDRESS

   Para obtener más información sobre cómo reservar una IP estática, consulta Reserva una dirección IP interna estática.

3. Confirma la reserva de la dirección IP:

   $ gcloud compute addresses describe VIP_NAME \
     --region CLUSTER_REGION

   Deberías ver un resultado similar al siguiente:

   address: 10.0.0.19
   addressType: INTERNAL
   creationTimestamp: '2020-05-20T14:19:03.109-07:00'
   description: ''
   id: '8961491304398200872'
   kind: compute#address
   name: vip-for-hana-ha
   networkTier: PREMIUM
   purpose: GCE_ENDPOINT
   region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha
   status: RESERVED
   subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

Crea grupos de instancias para tus VM host

1. En Cloud Shell, crea dos grupos de instancias no administrados y asigna el VM host de instancia principal a uno y el VM host de instancia principal del secundario a la otra:

   $ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
     --zone=PRIMARY_ZONE
   $ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
     --zone=PRIMARY_ZONE \
     --instances=PRIMARY_HOST_NAME
   $ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
     --zone=SECONDARY_ZONE
   $ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
     --zone=SECONDARY_ZONE \
     --instances=SECONDARY_HOST_NAME
   

2. Confirma la creación de los grupos de instancias:

   $ gcloud compute instance-groups unmanaged list

   Deberías ver un resultado similar al siguiente:

   NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
   hana-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
   hana-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Crea una verificación de estado de Compute Engine

1. En Cloud Shell, crea la verificación de estado. Para el puerto que usa la verificación de estado, elige un puerto que esté en el rango privado, 49152-65535, a fin de evitar conflictos con otros servicios. Los valores de intervalo de verificación y tiempo de espera son un poco más largos que los valores predeterminados con el fin de aumentar la tolerancia a la conmutación por error durante los eventos de migración en vivo de Compute Engine. Puedes ajustar los valores si es necesario:

   $ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
     --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
     --healthy-threshold=2

2. Confirma la creación de la verificación de estado:

   $ gcloud compute health-checks describe HEALTH_CHECK_NAME

   Deberías ver un resultado similar al siguiente:

   checkIntervalSec: 10
   creationTimestamp: '2020-05-20T21:03:06.924-07:00'
   healthyThreshold: 2
   id: '4963070308818371477'
   kind: compute#healthCheck
   name: hana-health-check
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check
   tcpHealthCheck:
    port: 60000
    portSpecification: USE_FIXED_PORT
    proxyHeader: NONE
   timeoutSec: 10
   type: TCP
   unhealthyThreshold: 2

Crea una regla de firewall para las verificaciones de estado

Define una regla de firewall para un puerto en el rango privado que permita el acceso a las VM de tu host desde los rangos de IP que usan las verificaciones de estado de Compute Engine, 35.191.0.0/16 y 130.211.0.0/22. Si deseas obtener más información, consulta Crea reglas de firewall para las verificaciones de estado.

1. Si aún no tienes una, agrega una etiqueta de red a las VM del host. La regla de firewall usa esta etiqueta de red para las verificaciones de estado.

   $ gcloud compute instances add-tags PRIMARY_HOST_NAME \
     --tags NETWORK_TAGS \
     --zone PRIMARY_ZONE
   $ gcloud compute instances add-tags SECONDARY_HOST_NAME \
     --tags NETWORK_TAGS \
     --zone SECONDARY_ZONE
   

2. Si aún no tienes una, crea una regla de firewall para permitir las verificaciones de estado:

   $ gcloud compute firewall-rules create RULE_NAME \
     --network NETWORK_NAME \
     --action ALLOW \
     --direction INGRESS \
     --source-ranges 35.191.0.0/16,130.211.0.0/22 \
     --target-tags NETWORK_TAGS \
     --rules tcp:HLTH_CHK_PORT_NUM

   Por ejemplo:

   gcloud compute firewall-rules create  fw-allow-health-checks \
   --network example-network \
   --action ALLOW \
   --direction INGRESS \
   --source-ranges 35.191.0.0/16,130.211.0.0/22 \
   --target-tags cluster-ntwk-tag \
   --rules tcp:60000

Configura el balanceador de cargas y el grupo de conmutación por error

1. Crea el servicio de backend del balanceador de cargas:

   $ gcloud compute backend-services create BACKEND_SERVICE_NAME \
     --load-balancing-scheme internal \
     --health-checks HEALTH_CHECK_NAME \
     --no-connection-drain-on-failover \
     --drop-traffic-if-unhealthy \
     --failover-ratio 1.0 \
     --region CLUSTER_REGION \
     --global-health-checks

2. Agrega el grupo de instancias principal al servicio de backend:

   $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --instance-group PRIMARY_IG_NAME \
     --instance-group-zone PRIMARY_ZONE \
     --region CLUSTER_REGION

3. Agrega el grupo de instancias de conmutación por error secundario al servicio de backend:

   $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --instance-group SECONDARY_IG_NAME \
     --instance-group-zone SECONDARY_ZONE \
     --failover \
     --region CLUSTER_REGION

4. Crea una regla de reenvío. En la dirección IP, especifica la dirección IP que reservaste para la VIP. Si necesitas acceder al sistema SAP HANA desde fuera de la región que se especifica a continuación, incluye la marca --allow-global-access en la definición:

   $ gcloud compute forwarding-rules create RULE_NAME \
     --load-balancing-scheme internal \
     --address VIP_ADDRESS \
     --subnet CLUSTER_SUBNET \
     --region CLUSTER_REGION \
     --backend-service BACKEND_SERVICE_NAME \
     --ports ALL

   Para obtener más información sobre el acceso entre regiones al sistema de alta disponibilidad de SAP HANA, consulta Balanceo de cargas de TCP/UDP interno.

Nota: Tus grupos de instancias de backend no se registrarán como en buen estado hasta que completes la configuración del clúster de Pacemaker.

Prueba la configuración del balanceador de cargas

Aunque los grupos de instancias de backend no se registren como en buen estado, puedes probar la configuración del balanceador de cargas mediante la configuración de un objeto de escucha que responda a las verificaciones de estado. Después de configurar un objeto de escucha, si el balanceador de cargas está configurado de forma correcta, el estado de los grupos de instancias de backend cambia a en buen estado.

En las siguientes secciones, se presentan diferentes métodos que puedes usar para probar la configuración.

Prueba el balanceador de cargas con la utilidad socat

Puedes usar la utilidad socat para escuchar de forma temporal en el puerto de verificación de estado.

1. En las VM del host principal y secundario, instala la utilidad socat:

   $ sudo yum install -y socat

2. Inicia un proceso socat para escuchar durante 60 segundos en el puerto de verificación de estado:

   $ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork

3. En Cloud Shell, después de esperar algunos segundos para que la verificación de estado detecte el objeto de escucha, verifica el estado de tus grupos de instancias de backend:

   $ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   Debería ver un resultado similar al siguiente:

   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
      ipAddress: 10.0.0.35
      port: 80
    kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
      ipAddress: 10.0.0.34
      port: 80
    kind: compute#backendServiceGroupHealth

Prueba el balanceador de cargas mediante el puerto 22

Si el puerto 22 está abierto para conexiones SSH en las VM del host, puedes editar de manera temporal el verificador de estado a fin de usar el puerto 22, que tiene un objeto de escucha que puede responder al verificador de estado.

Para usar de forma temporal el puerto 22, sigue estos pasos:

1. Haz clic en la verificación de estado en la consola:

   Ir a la página Verificaciones de estado

2. Haz clic en Editar.

3. En el campo Puerto, cambia el número de puerto a 22.

4. Haz clic en Guardar y espera uno o dos minutos.

5. En Cloud Shell, verifica el estado de tus grupos de instancias de backend:

   $ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   Debería ver un resultado similar al siguiente:

   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
      ipAddress: 10.0.0.35
      port: 80
    kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
      ipAddress: 10.0.0.34
      port: 80
    kind: compute#backendServiceGroupHealth

6. Cuando termines, vuelve a cambiar el número de puerto de verificación de estado al número de puerto original.

Configura Pacemaker

Con el siguiente procedimiento, se configura la implementación de Red Hat de un clúster de Pacemaker en las VM de Compute Engine para SAP HANA.

El procedimiento se basa en la documentación de Red Hat para configurar clústeres de alta disponibilidad, que incluyen lo siguiente (se requiere una suscripción a Red Hat):

• Instalación y configuración de un clúster de alta disponibilidad de Red Hat Enterprise Linux 7.6 (y versiones posteriores) en Google Cloud
• Replicación automatizada del sistema SAP HANA en escalamiento vertical en clústeres de Pacemaker

Pasos manuales

Completa los siguientes pasos en todos los hosts. En la imagen de RHEL para SAP que proporciona Google, algunos paquetes ya están instalados, pero se requieren algunas modificaciones adicionales.

1. Como raíz, quita el agente de recursos de escalamiento vertical de SAP HANA que viene preinstalado en la imagen:

   # yum -y remove resource-agents-sap-hana

2. Instala Pacemaker y los agentes de recursos faltantes:

   # yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana-scaleout
   

3. Update packages to latest version:

   # yum update -y

4. Configura la contraseña para el usuario hacluster, que se creó como parte de los paquetes:

   # passwd hacluster

5. Especifica una contraseña para hacluster en los mensajes.

6. En las imágenes de RHEL para SAP que proporciona Google Cloud, el servicio de firewall del SO está activo de forma predeterminada. Configura el servicio de firewall para permitir el tráfico de alta disponibilidad:

   # firewall-cmd --permanent --add-service=high-availability

   # firewall-cmd --reload

7. Inicia el servicio pcs y configúralo para que se inicie en el momento del inicio:

   # systemctl start pcsd.service
   # systemctl enable pcsd.service

8. Comprueba el estado del servicio pcs:

   # systemctl status pcsd.service

   Debería ver un resultado similar al siguiente:

   ● pcsd.service - PCS GUI and remote configuration interface
     Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago
       Docs: man:pcsd(8)
             man:pcs(8)
   Main PID: 31627 (pcsd)
     CGroup: /system.slice/pcsd.service
             └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
   Jun 13 21:17:03 hana-ha-1 systemd[1]: Starting PCS GUI and remote configuration interface...
   Jun 13 21:17:05 hana-ha-1 systemd[1]: Started PCS GUI and remote configuration interface.

Pasos automatizados

Para automatizar este proceso, puedes usar nodes.txt y la siguiente secuencia de comandos de la consola de Google Cloud.

Cuando se te solicite, ingresa una contraseña para que use el usuario hacluster que se creó durante la instalación de los agentes de recursos de Pacemaker.

echo "Set password for hacluster user:"; read -r HA_PASSWD; while read -u10 HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "sudo yum -y remove resource-agents-sap-hana; sudo yum -y install pcs pacemaker fence-agents-gce resource-agents-sap-hana-scaleout resource-agents-gcp; sudo yum update -y; sudo firewall-cmd --permanent --add-service=high-availability; sudo firewall-cmd --reload; sudo systemctl start pcsd.service; sudo systemctl enable pcsd.service; yes $HA_PASSWD | sudo passwd hacluster"; done 10< nodes.txt

Actualiza el archivo /etc/hosts

En todos los hosts del clúster, incluido el creador de la mayoría, actualiza el archivo /etc/hosts para incluir los nombres de host y las direcciones IP internas de todas las instancias en el clúster de Pacemaker.

El resultado del archivo /etc/hosts debería ser similar al siguiente ejemplo:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1                localhost localhost.localdomain localhost6 localhost6.localdomain6
10.138.0.1 rhel-hana-primary.us-west1-a.c.project-name.internal rhel-hana-primary # Added by Google
169.254.169.254 metadata.google.internal # Added by Google
10.138.0.1 rhel-hana-primary
10.138.0.2 rhel-hana-primaryw1
10.138.0.3 rhel-hana-secondary
10.138.0.4 rhel-hana-secondaryw1
10.138.0.5 rhel-sap-mm

Para obtener más información de Red Hat sobre la configuración del archivo /etc/hosts en los nodos del clúster de RHEL, consulta https://access.redhat.com/solutions/81123.

Cree el clúster

1. Como raíz en el host principal, autoriza al usuario hacluster. Es importante incluir todos los hosts del clúster en este comando, que debería ser parte del clúster.

   RHEL 8.0 y versiones posteriores

   pcs host auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
   

   RHEL 7.6 y versiones posteriores

   pcs cluster auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
   

2. En los mensajes, ingresa el nombre de usuario hacluster y la contraseña que configuraste para el usuario hacluster en la sección anterior.

3. Configura el clúster en modo de mantenimiento.

   pcs property set maintenance-mode=true

4. Genera y sincroniza la configuración de corosync.

   RHEL 8.0 y versiones posteriores

   pcs cluster setup scale_out_hsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name

   RHEL 7.6 y versiones posteriores

   pcs cluster setup --start --name hanascaleoutsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name

Edita la configuración predeterminada de corosync.conf

1. Abre el archivo /etc/corosync/corosync.conf con el editor que prefieras.

2. Quita el parámetro consensus.

3. Modifica los parámetros restantes según las recomendaciones de Google Cloud.

   En la siguiente tabla, se muestran los parámetros totem para los que Google Cloud recomienda valores, junto con el impacto de cambiar los valores. Para conocer los valores predeterminados de estos parámetros, que pueden diferir entre distribuciones de Linux, consulta la documentación de tu distribución de Linux.

   Parámetro	Valor recomendado	Impacto del cambio de valor
   secauth	off	Inhabilita la autenticación y encriptación de todos los mensajes totem
   join	60 (ms)	Aumenta el tiempo de espera del nodo para recibir mensajes join en el protocolo de membresía.
   max_messages	20	Aumenta la cantidad máxima de mensajes que puede enviar el nodo después de recibir el token.
   token	20000 (ms)	Aumenta el tiempo de espera del nodo para obtener un token de protocolo totem antes de que el nodo declare la pérdida del token, suponga una falla de nodo y comience a tomar medidas. Aumentar el valor del parámetro token hace que el clúster sea más tolerante a los eventos momentáneos de la infraestructura, como una migración en vivo. Sin embargo, también puede hacer que el clúster tarde más tiempo en detectar las fallas de nodos y en recuperarse de ellas. El valor del parámetro token también determina el valor predeterminado del parámetro consensus, que controla cuánto tiempo espera un nodo para permitir que se logre el consenso antes de intentar restablecer la membresía de configuración.
   consensus	No disponible	Especifica en milisegundos cuánto tiempo se debe esperar para que se logre el consenso antes de comenzar una nueva ronda de configuración de membresía. Te recomendamos omitir este parámetro. Cuando no se especifica el parámetro consensus, Corosync establece su valor en 1.2 veces el valor del parámetro token. Si usas el valor recomendado 20000 del parámetro token, el parámetro consesus se establece con el valor 24000. Si especificas de forma explícita un valor para consensus, asegúrate de que el valor sea 24000 o 1.2*token, lo que sea mayor.
   token_retransmits_before_loss_const	10	Aumenta la cantidad de retransmisiones del token que intenta realizar el nodo antes de suponer que ocurrió una falla en el nodo receptor y comenzar a tomar medidas.
   transport	Para SLES: udpu Para RHEL 8 o versiones posteriores: knet Para RHEL 7: udpu	Especifica el mecanismo de transporte que usa corosync.

4. Desde el host que contiene el archivo corosync.conf editado, sincroniza la configuración de corosync en el clúster:

   RHEL 8 y versiones posteriores

   # pcs cluster sync corosync

   RHEL 7

   # pcs cluster sync

5. Configura el clúster para que se inicie de manera automática:

   # pcs cluster enable --all
   # pcs cluster start --all

6. Confirma que la nueva configuración de corosync esté activa en el clúster mediante la utilidad corosync-cmapctl:

   # corosync-cmapctl

Establece una demora para el reinicio de Corosync

Pasos manuales

1. En todos los hosts como raíz, crea un archivo directo systemd que retrase el inicio de Corosync para garantizar la secuencia adecuada de eventos después de reiniciar una VM protegida:

   systemctl edit corosync.service

2. Agrega las siguientes líneas al archivo:

   [Service]
   ExecStartPre=/bin/sleep 60

3. Guarda el archivo y sal del editor.

4. Vuelve a cargar la configuración del administrador del sistema.

   systemctl daemon-reload

5. Confirma que se creó el archivo directo:

   service corosync status

   Deberías ver una línea para el archivo directo, como se muestra en el siguiente ejemplo:

   ● corosync.service - Corosync Cluster Engine
      Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
     Drop-In: /etc/systemd/system/corosync.service.d
              └─override.conf
      Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

Pasos automatizados

Como alternativa, ejecuta el siguiente comando desde la consola de Google Cloud a fin de automatizar este proceso para todas las instancias que se enumeran en nodes.txt:

while read -u10 HOST;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST   --  "sudo mkdir -p /etc/systemd/system/corosync.service.d/; sudo echo -e '[Service]\nExecStartPre=/bin/sleep 60' | sudo tee -a /etc/systemd/system/corosync.service.d/override.conf; sudo systemctl daemon-reload"; done 10< nodes.txt

Configura la protección

Las imágenes de RHEL que proporciona Google Cloud incluyen un agente de protección llamado fence_gce, que es específico de Google Cloud. Usa fence_gce a fin de crear dispositivos de protección para cada VM del host.

Para garantizar que ocurra la secuencia correcta de eventos después de una acción de protección, debes configurar el sistema operativo para que retrase el reinicio de Corosync después de que una VM se protege. También debes ajustar el tiempo de espera de Pacemaker para los reinicios a fin de responder ante la demora.

Para ver todas las opciones disponibles con el agente de protección fence_gce, ejecuta fence_gce -h.

Nota: Si cambiaste los nombres de host para que ya no sean los mismos que los nombres de las instancias de VM, consulta Instala y configura un clúster de alta disponibilidad de Red Hat Enterprise Linux 7.6 (y versiones posteriores) en Google Compute Cloud. En los siguientes pasos, se requiere que los nombres de host sean los mismos que los de las instancias de VM.

Pasos manuales

1. En el host principal, como usuario raíz, crea los dispositivos de cerca para todos los hosts, incluido el creador de la mayoría:

   pcs stonith create STONITH-host-name fence_gce \
   port=host-name \
   zone=host-zone \
   project=project-id \
   pcmk_host_list=host-name pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
   op monitor interval="300s" timeout="120s" \
   op start interval="0" timeout="60s"

2. Establece la restricción de ubicación para los dispositivos de protección:

   pcs constraint location STONITH-host-name avoids host-name

3. Repite los dos pasos anteriores para todos los demás hosts en la instancia principal y los clústeres secundarios y el host de la marca mayoritaria, ingresando los valores apropiados para las variables host-name y host-zone.

Pasos automatizados

Para automatizar este proceso, debes usar el archivo nodes.txt y la siguiente secuencia de comandos de la consola de Google Cloud:

while read -u10 ZONE HOST; do gcloud compute ssh $HOST --tunnel-through-iap --quiet --zone $ZONE -- "sudo pcs stonith create STONITH-$HOST fence_gce project=project-id port=$HOST zone=$ZONE pcmk_host_list=$HOST pcmk_reboot_timeout=300 pcmk_monitor_retries=4 op monitor interval=300s timeout=120s op start interval=0 timeout=60s && sudo pcs constraint location STONITH-$HOST avoids $HOST"; done 10< nodes.txt

Establece la configuración predeterminada del clúster

Configura los límites de migración y permanencia para determinar la cantidad de veces que se debe intentar la conmutación por error antes de fallar y a fin de configurar el sistema con el fin de que se reinicie primero en el host actual. Esto solo se debe configurar en un nodo para aplicarlo al clúster.

1. Como raíz desde cualquier host, establece los valores predeterminados de los recursos:

   RHEL 8.0 y versiones posteriores

   # pcs resource defaults update resource-stickiness=1000
   # pcs resource defaults update migration-threshold=5000

   RHEL 7.6 y versiones posteriores

   # pcs resource defaults resource-stickiness=1000
   # pcs resource defaults migration-threshold=5000

   La propiedad resource-stickiness controla la probabilidad de que un servicio continúe ejecutándose donde está. Los valores más altos proporcionan mayor permanencia del servicio. Un valor de 1000 significa que el servicio es muy persistente.

   La propiedad migration-threshold especifica la cantidad de fallas que deben ocurrir antes de que un servicio se transfiera a otro host. Un valor de 5,000 es lo bastante alto como para evitar la conmutación por error en situaciones de error de corta duración.

   Para verificar los valores predeterminados del recurso, ingresa pcs resource defaults.

2. Establece los valores predeterminados del tiempo de espera de la operación del recurso:

   RHEL 8.0 y versiones posteriores

   # pcs resource op defaults update timeout=600s

   RHEL 7.6 y versiones posteriores

   # pcs resource op defaults timeout=600s

   Para verificar los valores predeterminados de la operación del recurso, ingresa pcs resource op defaults.

3. Establece las siguientes propiedades del clúster:

   # pcs property set stonith-enabled="true"
   # pcs property set stonith-timeout="300s"
   

   Puedes verificar la configuración de la propiedad con pcs property list.

Crea el recurso SAPHanaTopology

El recurso SAPHanaTopology obtiene el estado y la configuración de la replicación del sistema HANA en los nodos. También verifica SAP Host Agent.

1. Como raíz en cualquiera de los hosts, crea el recurso SAPHanaTopology:

   RHEL 8.0 y versiones posteriores

   # pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopology SID=SID \
   InstanceNumber=inst_num \
   op methods interval=0s timeout=5 \
   op monitor interval=10 timeout=600 \
   clone meta clone-node-max=1 interleave=true

   RHEL 7.6 y versiones posteriores

   # pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopologyScaleOut SID=SID \
   InstanceNumber=inst_num \
   op start timeout=600 \
   op stop timeout=300 \
   op monitor interval=10 timeout=600

   # pcs resource clone  rsc_SAPHanaTopology_SID_HDBinstNr meta clone-node-max=1 interleave=true

2. Después de crear el recurso, verifica la configuración. Agrega -clone al nombre del recurso para incluir la información del conjunto de clones en la respuesta:

   RHEL 8.0 y versiones posteriores

   # pcs resource config rsc_SAPHanaTopology_SID_HDBinstNr-clone

   Debería ver un resultado similar al siguiente:

   Clone: SAPHanaTopology_HA1_00-clone
   Meta Attrs: clone-node-max=1 interleave=true
   Resource: SAPHanaTopology_HA1_00 (class=ocf provider=heartbeat type=SAPHanaTopology)
   Attributes: InstanceNumber=00 SID=HA1
   Operations: methods interval=0s timeout=5 (SAPHanaTopology_HA1_00-methods-interval-0s)
          monitor interval=10 timeout=600 (SAPHanaTopology_HA1_00-monitor-interval-10)
          start interval=0s timeout=600 (SAPHanaTopology_HA1_00-start-interval-0s)
          stop interval=0s timeout=300 (SAPHanaTopology_HA1_00-stop-interval-0s)

   RHEL 7.6 y versiones posteriores

   # pcs resource show rsc_SAPHanaTopology_SID_HDBinstNr-clone

   Debería ver un resultado similar al siguiente:

   Clone: rsc_SAPHanaTopology_HA1_HDB00-clone
   Meta Attrs: clone-node-max=1 interleave=true
   Resource: rsc_SAPHanaTopology_HA1_HDB00 (class=ocf provider=heartbeat type=SAPHanaTopologyScaleOut)
   Attributes: InstanceNumber=00 SID=HA1
   Meta Attrs: clone-node-max=1 interleave=true
   Operations: methods interval=0s timeout=5 (rsc_SAPHanaTopology_HA1_HDB00-methods-interval-0s)
          monitor interval=10 timeout=600 (rsc_SAPHanaTopology_HA1_HDB00-monitor-interval-10)
          start interval=0s timeout=600 (rsc_SAPHanaTopology_HA1_HDB00-start-interval-0s)
          stop interval=0s timeout=300 (rsc_SAPHanaTopology_HA1_HDB00-stop-interval-0s)

También puedes verificar los atributos del clúster mediante el comando crm_mon -A1.

Crea el recurso SAPHanaController

El agente de recursos de SAPHana administra las bases de datos configuradas para la replicación del sistema SAP HANA.

Los siguientes parámetros en la definición de recursos de SAPHana son opcionales:

• AUTOMATED_REGISTER: Cuando se configura como true, registra de forma automática la principal anterior como secundaria cuando vence el DUPLICATE_PRIMARY_TIMEOUT después de una apropiación. El valor predeterminado es false.

  Para un clúster de SAP HANA con alta disponibilidad de varios niveles, si usas una versión anterior a SAP HANA 2.0 SP03, configura AUTOMATED_REGISTER como false. Esto evita que una instancia recuperada intente registrarse para la replicación en un sistema HANA que ya tiene un destino de replicación configurado. Para SAP HANA 2.0 SP03 o versiones posteriores, puedes establecer AUTOMATED_REGISTER como true para las configuraciones de SAP HANA que usan la replicación de sistemas de varios niveles.

• DUPLICATE_PRIMARY_TIMEOUT: Establece la diferencia de tiempo en segundos entre dos marcas de tiempo principales si se produce una situación de principales duplicadas. El valor predeterminado 7200.

• PREFER_SITE_TAKEOVER: Determina si los reinicios locales se prueban antes de iniciar la conmutación por error. El predeterminado es false.

Para obtener información adicional sobre estos parámetros, consulta Installing and Configuring a Red Hat Enterprise Linux 7.6 (and later) High-Availability Cluster on Google Cloud [Instala y configura un clúster de alta disponibilidad de Red Hat Enterprise Linux 7.6 (y versiones posteriores) en Google Cloud]. Se requiere una suscripción a Red Hat.

1. Como raíz en cualquiera de los hosts, crea el recurso SAPHanaController:

   RHEL 8.0 y versiones posteriores

   # pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op demote interval=0s timeout=320 \
   op methods interval=0s timeout=5 \
   op monitor interval=59 \
   role="Master" timeout=700 \
   op monitor interval=61 \
   role="Slave" timeout=700 \
   op promote interval=0 timeout=3600 \
   op start interval=0 timeout=3600 \
   op stop interval=0 timeout=3600e

   # pcs resource promotable rsc_SAPHana_SID_HDBinstNr meta master-max="1" clone-node-max=1 interleave=true

   RHEL 7.6 y versiones posteriores

   # pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op start interval=0 timeout=3600 \
   op stop interval=0 timeout=3600 \
   op promote interval=0 timeout=3600 \
   op monitor interval=60 \
   role="Master" timeout=700 \
   op monitor interval=61 \
   role="Slave" timeout=700

   # pcs resource master msl_rsc_SAPHana_SID_HDBinstNr rsc_SAPHana_SID_HDBinstNr master-max="1" clone-node-max=1 interleave=true

2. Verifica los atributos de los recursos resultantes:

   RHEL 8.0 y versiones posteriores

   # pcs resource config rsc_SAPHana_SID_HDBinstNr-clone

   Deberías ver un resultado similar al siguiente:

   Resource: SAPHana_HA1_00 (class=ocf provider=heartbeat type=SAPHanaController)
   Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
   Operations: demote interval=0s timeout=320 (SAPHana_HA1_00-demote-interval-0s)
         methods interval=0s timeout=5 (SAPHana_HA1_00-methods-interval-0s)
         monitor interval=59 role=Master timeout=700 (SAPHana_HA1_00-monitor-interval-59)
         promote interval=0 timeout=3600 (SAPHana_HA1_00-promote-interval-0)
         reload interval=0s timeout=5 (SAPHana_HA1_00-reload-interval-0s)
         start interval=0 timeout=3600 (SAPHana_HA1_00-start-interval-0)
         stop interval=0 timeout=3600 (SAPHana_HA1_00-stop-interval-0)
         monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_00-monitor-interval-61)

   RHEL 7.6 y versiones posteriores

   # pcs resource show msl_rsc_SAPHana_SID_HDBinstNr

   Deberías ver un resultado similar al siguiente:

   Master: msl_rsc_SAPHana_HA1_HDB00
   Meta Attrs: clone-node-max=1 interleave=true master-max=1
   Resource: rsc_SAPHana_HA1_HDB00 (class=ocf provider=heartbeat type=SAPHanaController)
   Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
   Operations: demote interval=0s timeout=320 (rsc_SAPHana_HA1_HDB00-demote-interval-0s)
          methods interval=0s timeout=5 (rsc_SAPHana_HA1_HDB00-methods-interval-0s)
          monitor interval=60 role=Master timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-60)
          monitor interval=61 role=Slave timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-61)
          promote interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-promote-interval-0)
          start interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-start-interval-0)
          stop interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-stop-interval-0)

Crea un recurso de dirección IP virtual

Debes crear un recurso de clúster para la VIP. El recurso VIP está localizado para el sistema operativo principal y otros hosts no lo pueden enrutar. El balanceador de cargas enruta el tráfico que se envía a la VIP al host de backend según la verificación de estado.

Como raíz en cualquiera de los hosts, ejecuta el siguiente comando:

# pcs resource create rsc_ip_SAPHANA_SID_HDBinstNr \
  IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32 \
  op monitor interval=3600s timeout=60s

El valor vip-address es la misma dirección IP que reservaste antes y que especificaste en la regla de reenvío para el frontend de tu balanceador de cargas. Cambia la interfaz de red según corresponda para tu configuración.

Crea las restricciones

Crea restricciones para definir qué servicios deben iniciarse primero y qué servicios deben ejecutarse juntos en el mismo host.

1. Define la restricción del orden de inicio:

   RHEL 8.0 y versiones posteriores

   # pcs constraint order start rsc_SAPHanaTopology_SID_HDBinstNr-clone then start rsc_SAPHana_SID_HDBinstNr-clone
   

   RHEL 7.6

   # pcs constraint order rsc_SAPHanaTopology_SID_HDBinstNr-clone then rsc_SAPHana_SID_HDBinstNr-master
   

2. Configure the majority maker to avoid taking an an active role in the cluster environment:

   RHEL 8.0 and later

   # pcs constraint location rsc_SAPHana_SID_HDBinstNr-clone avoids majority-maker-name
   
   # pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymaker

   RHEL 7.6

   # pcs constraint location msl_rsc_SAPHana_SID_HDBinstNr avoids majoritymaker
   
   # pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymaker

3. Comprueba las restricciones:

   # pcs constraint

   Debería ver un resultado similar al siguiente:

   Location Constraints:
   Resource: STONITH-hana-ha-1
     Disabled on: hana-ha-1 (score:-INFINITY)
   Resource: STONITH-hana-ha-1w1
     Disabled on: hana-ha-1w1 (score:-INFINITY)
   Resource: STONITH-hana-ha-2
     Disabled on: hana-ha-2 (score:-INFINITY)
   Resource: STONITH-hana-ha-2w1
     Disabled on: hana-ha-2w1 (score:-INFINITY)
   Resource: STONITH-majority-maker
     Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHanaTopology_HA1_HDB00-clone
     Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHana_HA1_HDB00-master
     Disabled on: majority-maker (score:-INFINITY)
   Ordering Constraints:
     start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory)

Instala objetos de escucha y crea un recurso de verificación de estado

Para configurar un recurso de verificación de estado, primero debes instalar los objetos de escucha.

Instala un objeto de escucha

El balanceador de cargas usa un objeto de escucha en el puerto de verificación de estado de cada host para determinar dónde se ejecuta la instancia principal del clúster de SAP HANA. 1. Como raíz en la instancia principal en los sistemas principal y secundario, instala un objeto de escucha de TCP. En estas instrucciones, se instala y usa HAProxy como objeto de escucha.

# yum install haproxy

1. Abre el archivo de configuración haproxy.cfg para editarlo:

   # vi /etc/haproxy/haproxy.cfg

   1. En la sección valores predeterminados de haproxy.cfg, cambia mode a tcp.

   2. Después de la sección valores predeterminados, agrega lo siguiente para crear una sección nueva:

      #---------------------------------------------------------------------
      # Health check listener port for SAP HANA HA cluster
      #---------------------------------------------------------------------
      listen healthcheck
        bind *:healthcheck-port-num

      El puerto de vinculación es el mismo que usaste cuando creaste la verificación de estado.

      Cuando termines, tus actualizaciones deberían ser similares al siguiente ejemplo:

      #---------------------------------------------------------------------
      # common defaults that all the 'listen' and 'backend' sections will
      # use if not designated in their block
      #---------------------------------------------------------------------
      defaults
        mode                    tcp
        log                     global
        option                  tcplog
        option                  dontlognull
        option http-server-close
        # option forwardfor       except 127.0.0.0/8
        option                  redispatch
        retries                 3
        timeout http-request    10s
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout http-keep-alive 10s
        timeout check           10s
        maxconn                 3000
      
      #---------------------------------------------------------------------
      # Set up health check listener for SAP HANA HA cluster
      #---------------------------------------------------------------------
      listen healthcheck
       bind *:60000

2. En cada host como raíz, inicia el servicio para confirmar que esté configurado de forma correcta:

   # systemctl start haproxy.service

3. En la página del balanceador de cargas en la consola de Google Cloud, haz clic en la entrada del balanceador de cargas:

   Página Balanceo de cargas

   En la sección Backend de la página Detalles del balanceador de cargas, si el servicio HAProxy está activo en ambos hosts, verás 1/1 en la columna En buen estado (Healthy) de cada entrada del grupo de instancias.

   

4. En cada host, detén el servicio HAProxy:

   # systemctl stop haproxy.service

   Después de detener el servicio HAProxy en cada host, se muestra 0/1 en la columna En buen estado (Healthy) de cada grupo de instancias.

   

   Más tarde, cuando se configura la verificación de estado, el clúster reinicia el objeto de escucha en el nodo principal.

Crea el recurso de verificación de estado

1. Desde cualquier host como raíz, crea un recurso de verificación de estado para el servicio HAProxy:

   # pcs resource create hc_SID_HDBinstNr service:haproxy op monitor interval=10s timeout=20s

2. Agrupa los recursos de la VIP y la verificación de estado:

   # pcs resource group add rsc-group-name hc_SID_HDBinstNr rsc_ip_SAPHANA_SID_HDBinstNr

3. Crea una restricción que coloque el grupo en el mismo nodo que la instancia principal de SAP HANA.

   RHEL 8.0 y versiones posteriores

   # pcs constraint colocation add rsc-group-name with master rsc_SAPHana_SID_HDBinstNr-clone

   RHEL 7.6 y versiones posteriores

   # pcs constraint colocation add rsc-group-name with master msl_rsc_SAPHana_SID_HDBinstNr

4. Crea una restricción de pedido para iniciar el grupo solo después de que se promueva HANA:

   # pcs constraint order promote rsc_SAPHana_SID_HDBinstNr-clone then start rsc-group-name

   Las restricciones finales deberían ser similares al siguiente ejemplo:

   # pcs constraint
   
   Location Constraints:
   Resource: STONITH-hana-ha-1
    Disabled on: hana-ha-1 (score:-INFINITY)
   Resource: STONITH-hana-ha-1w1
    Disabled on: hana-ha-1w1 (score:-INFINITY)
   Resource: STONITH-hana-ha-2
    Disabled on: hana-ha-2 (score:-INFINITY)
   Resource: STONITH-hana-ha-2w1
    Disabled on: hana-ha-2w1 (score:-INFINITY)
   Resource: STONITH-majority-maker
    Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHanaTopology_HA1_HDB00-clone
    Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHana_HA1_HDB00-master
    Disabled on: majority-maker (score:-INFINITY)
   Ordering Constraints:
    start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory)
    promote rsc_SAPHana_HA1_HDB00-clone then start g-primary (kind:Mandatory) (id:order-rsc_SAPHana_HA1_HDB00-clone-g-primary-mandatory)
   Colocation Constraints:
    g-primary with rsc_SAPHana_HA1_HDB00-master (score:INFINITY) (rsc-role:Started) (with-rsc-role:Master)
   Ticket Constraints:

Finaliza la configuración

1. Quita el clúster del modo de mantenimiento.

   pcs property set maintenance-mode=false

2. Después de iniciar el recurso, verifica los atributos del nodo para ver el estado actual de las bases de datos de SAP HANA en los nodos:

   # crm_mon -A1

   Debería ver un resultado similar al siguiente:

   RHEL 8.0 y versiones posteriores

   Cluster Summary:
   Stack: corosync
   Current DC: hana-ha-2w1 (version 2.0.5-9.el8_4.7-ba59be7122) - partition with quorum
   Last updated: Wed Oct 11 17:59:51 2023
   Last change:  Wed Oct 11 17:59:48 2023 by hacluster via crmd on hana-ha-2
   5 nodes configured
   17 resource instances configured
   
   Node List:
   Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 dru-somm ]
   
   Active Resources:
   STONITH-hana-ha-1     (stonith:fence_gce):     Started hana-ha-2
   STONITH-hana-ha-1w1   (stonith:fence_gce):     Started hana-ha-1
   STONITH-hana-ha-2     (stonith:fence_gce):     Started hana-ha-2w1
   STONITH-hana-ha-2w1   (stonith:fence_gce):     Started dru-somm
   STONITH-dru-somm    (stonith:fence_gce):     Started hana-ha-1
   Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]:
    Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Clone Set: SAPHana_HA1_00-clone [SAPHana_HA1_00]-(promotable):
    Slaves: [ hana-ha-1w1 hana-ha-2w1 ]
   Resource Group: g-primary:
    healthcheck_HA1   (service:haproxy):       Started hana-ha-1
    ip_SAPHANA_HA1_00 (ocf::heartbeat:IPaddr2):        Started hana-ha-1
   
   Node Attributes:
   Node: hana-ha-1:
    hana_ha1_clone_state              : PROMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_roles                    : master1:master:worker:master
    hana_ha1_site                     : hana-ha-1
    hana_ha1_sra                      : -
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-1
    master-SAPHana_HA1_00             : 5
   Node: hana-ha-1w1:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_roles                    : slave:slave:worker:slave
    hana_ha1_site                     : hana-ha-1
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-1w1
    master-SAPHana_HA1_00             : -INFINITY
   Node: hana-ha-2:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-1w1
    hana_ha1_roles                    : master1:master:worker:master
    hana_ha1_site                     : hana-ha-2
    hana_ha1_sra                      : -
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-2
    master-SAPHana_HA1_00             : 100
   Node: hana-ha-2w1:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-1w1
    hana_ha1_roles                    : slave:slave:worker:slave
    hana_ha1_site                     : hana-ha-2
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-2w1
    master-SAPHana_HA1_00             : -12200
   Node: dru-somm:
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_srmode                   : syncmem

   RHEL 7.6 y versiones posteriores

   Stack: corosync
   Current DC: majority-maker (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
   Last updated: Wed Oct 11 17:58:07 2023
   Last change: Wed Oct 11 17:57:57 2023 by hacluster via crmd on hana-ha-2w1
   
   5 nodes configured
   17 resource instances configured
   
   Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 majority-maker ]
   
   Active resources:
   
   STONITH-hana-ha-1 (stonith:fence_gce):    Started hana-ha-1w1
   STONITH-hana-ha-1w1       (stonith:fence_gce):    Started hana-ha-2
   STONITH-hana-ha-2 (stonith:fence_gce):    Started hana-ha-1
   STONITH-hana-ha-2w1       (stonith:fence_gce):    Started majority-maker
   STONITH-majority-maker (stonith:fence_gce):    Started hana-ha-1w1
   Master/Slave Set: msl_rsc_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00]
    rsc_SAPHana_HA1_HDB00      (ocf::heartbeat:SAPHanaController):     Master hana-ha-1 (Monitoring)
    Slaves: [ hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Clone Set: rsc_SAPHanaTopology_HA1_HDB00-clone [rsc_SAPHanaTopology_HA1_HDB00]
    Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Resource Group: g-primary
    hc_HA1_HDB00       (service:haproxy):      Started hana-ha-1
    rsc_ip_SAPHANA_HA1_HDB00   (ocf::heartbeat:IPaddr2):       Started hana-ha-1
   
   Node Attributes:
   Node hana-ha-1:
     hana_ha1_clone_state              : PROMOTED
     hana_ha1_remoteHost               : hana-ha-2
     hana_ha1_roles                    : master1:master:worker:master
     hana_ha1_site                     : hana-ha-1
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-1
     master-rsc_SAPHana_HA1_HDB00      : 150
   Node hana-ha-1w1:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-2w1
     hana_ha1_roles                    : slave:slave:worker:slave
     hana_ha1_site                     : hana-ha-1
     hana_ha1_srmode                   : syncmem
     hana_ha1_version                  : 2.00.052.00.1599235305
     hana_ha1_vhost                    : hana-ha-1w1
     master-rsc_SAPHana_HA1_HDB00      : -10000
   Node hana-ha-2:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-2w1
     hana_ha1_roles                    : master1:master:worker:master
     hana_ha1_site                     : hana-ha-2
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-2
     master-rsc_SAPHana_HA1_HDB00      : 100
   Node hana-ha-2w1:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-1
     hana_ha1_roles                    : slave:slave:worker:slave
     hana_ha1_site                     : hana-ha-2
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-2w1
     master-rsc_SAPHana_HA1_HDB00      : -12200
   Node majority-maker:
     hana_ha1_srmode                   : syncmem

3. Si hay recursos de clúster con errores, es posible que debas ejecutar el siguiente comando:

   pcs resource cleanup

Prueba la conmutación por error

Simula una falla en el host principal para probar el clúster. Usa un sistema de prueba o ejecuta la prueba en tu sistema de producción antes de lanzar el sistema para su uso.

Realiza una copia de seguridad del sistema antes de la prueba.

Puedes simular una falla de varias maneras, incluidas las siguientes:

• HDB stop
• HDB kill
• reboot (en el nodo activo)
• ip link set eth0 down para instancias con una sola interfaz de red
• iptables ... DROP para instancias con varias interfaces de red
• echo c > /proc/sysrq-trigger

En estas instrucciones, se usa ip link set eth0 down o iptables para simular una interrupción de red entre los dos hosts en el clúster. Usa el comando ip link en una instancia con una sola interfaz de red y el comando iptables en instancias con una o más interfaces de red. La prueba valida tanto la conmutación por error como la protección. En el caso de que tus instancias tengan varias interfaces de red definidas, usa el comando iptables en el host secundario para descartar el tráfico entrante y saliente en función de la IP que usa el host principal para la comunicación del clúster, lo que simula una pérdida de conexión de red a la instancia principal.

1. En el host activo, como raíz, desconecta la interfaz de red:

   # ip link set eth0 down

   O bien, si varias interfaces de red están activas, usa iptables en el host secundario:

   # iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROP

2. Vuelve a conectarte a cualquier host a través de SSH y cambia al usuario raíz.

3. Ingresa pcs status para confirmar que el host principal ahora está activo en la VM que contenía el host secundario. El reinicio automático está habilitado en el clúster, por lo que el host detenido se reiniciará y asumirá la función de host secundario, como se muestra en el siguiente ejemplo.

   Cluster name: hana-ha-cluster
   Stack: corosync
   Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
   Last updated: Wed Jun 17 01:04:36 2020
   Last change: Wed Jun 17 01:03:58 2020 by root via crm_attribute on hana-ha-vm-2
   
   2 nodes configured
   8 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1]
   
   Full list of resources:
   
   STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
   STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-2w1
   STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-mm
   STONITH-hana-ha-vm-mm   (stonith:fence_gce):    Started hana-ha-vm-1w1
   Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ] ]
   Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
       Masters: [ hana-ha-vm-2 ]
       Slaves: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ] ]
   Resource Group: g-primary
       rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-2
       rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
   
   Daemon Status:
    corosync: active/enabled
    pacemaker: active/enabled
    pcsd: active/enabled

Soluciona problemas

A fin de solucionar problemas de configuraciones de alta disponibilidad para SAP HANA en RHEL, consulta Solución de problemas de configuraciones de alta disponibilidad para SAP.

Obtén asistencia para SAP HANA en RHEL

Si necesitas ayuda para resolver un problema con los clústeres con alta disponibilidad para SAP HANA en RHEL, recopila la información de diagnóstico requerida y comunícate con el servicio de atención al cliente de Cloud. Para obtener más información, consulta Clústeres de alta disponibilidad en la información de diagnóstico de RHEL.

Asistencia

Si tienes problemas con la infraestructura o los servicios de Google Cloud, comunícate con el servicio de Atención al cliente. Puedes encontrar la información de contacto en la página Descripción general de la asistencia en la consola de Google Cloud. Si el servicio de Atención al cliente determina que existe un problema en tus sistemas de SAP, te referiremos al servicio de asistencia de SAP.

Por problemas relacionados con el producto SAP, registra una solicitud de asistencia en Asistencia de SAP. SAP evalúa el ticket de asistencia y, si parece ser un problema de infraestructura de Google Cloud, SAP transfiere ese ticket al componente de Google Cloud adecuado en su sistema: BC-OP-LNX-GOOGLE o BC-OP-NT-GOOGLE.

Requisitos de asistencia

Antes de recibir asistencia para los sistemas SAP y la infraestructura y los servicios de Google Cloud que usan, debes cumplir con los requisitos mínimos del plan de asistencia.

Para obtener más información sobre los requisitos mínimos de asistencia para SAP en Google Cloud, consulta lo siguiente:

• Obtén asistencia para SAP en Google Cloud
• Nota de SAP 2456406: SAP en Google Cloud Platform: requisitos previos de compatibilidad (se requiere una cuenta de usuario de SAP)

Conéctate a SAP HANA

Si las VM del host no tienen una dirección IP externa para SAP HANA, solo puedes conectarte a las instancias de SAP HANA a través de la instancia de bastión mediante SSH o a través del servidor de Windows de SAP HANA Studio.

• Para conectarte a SAP HANA a través de la instancia de bastión, conéctate al host de bastión y, luego, a las instancias de SAP HANA mediante el cliente SSH que prefieras.

• Para conectarte a la base de datos de SAP HANA a través de SAP HANA Studio, usa un cliente de escritorio remoto para conectarte a la instancia de Windows Server. Después de la conexión, instala SAP HANA Studio de forma manual y accede a la base de datos de SAP HANA.

Tareas posteriores a la implementación

Después de completar la implementación, finaliza los siguientes pasos:

1. Cambia las contraseñas temporales para el administrador del sistema de SAP HANA y el superusuario de la base de datos. Por ejemplo:

   sudo passwd SID_LCadm

   Para obtener información de SAP sobre cómo cambiar la contraseña, consulta Restablece la contraseña del usuario del sistema de la base de datos del sistema.

2. Antes de usar la instancia de SAP HANA, configura la base de datos de SAP HANA nueva y crea una copia de seguridad.

3. Si tu sistema SAP HANA se implementa en una interfaz de red de VirtIO, te recomendamos que te asegures de que el valor del parámetro de TCP /proc/sys/net/ipv4/tcp_limit_output_bytes esté configurado como 1048576. Esta modificación ayuda a mejorar la capacidad de procesamiento general de la red en la interfaz de red de VirtIO sin afectar la latencia de la red.

Para obtener más información, consulte:

• Guía de operaciones de SAP HANA.
• SAP HANA Installation and Update Guide (Guía de instalación y actualización de SAP HANA).

Próximos pasos

Consulta los siguientes recursos para obtener más información:

• Installing and Configuring a Red Hat Enterprise Linux 7.6 (and later) High-Availability Cluster on Google Compute Cloud [Instala y configura un clúster de alta disponibilidad de Red Hat Enterprise Linux 7.6 (y versiones posteriores) en Google Compute Cloud]
• Automated SAP HANA System Replication in Scale-Up in pacemaker cluster (Replicación automatizada del sistema SAP HANA en escalamiento vertical en clústeres de Pacemaker)
• Support Policies for RHEL High Availability Clusters - General Requirements for Fencing/STONITH (Políticas de compatibilidad para clústeres de alta disponibilidad de RHEL: Requisitos generales para protección/STONITH)
• Guía de planificación de alta disponibilidad de SAP HANA
• Guía de planificación de recuperación ante desastres de SAP HANA
• Para obtener más información sobre la administración y la supervisión de VM, consulta la Guía de operaciones de SAP HANA.