Guía de configuración del clúster de HA para SAP HANA en RHEL

En esta guía, se muestra cómo implementar y configurar un clúster de alta disponibilidad (HA) de Red Hat Enterprise Linux (RHEL) para un sistema de escalamiento vertical de SAP HANA 1.0 SPS 12 o posterior en Google Cloud.

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

  • Configurar el Balanceo de cargas TCP/UDP interno para redirigir el tráfico en caso de 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 hosts en espera, usa la Guía de implementación de SAP HANA.

Si deseas configurar un clúster de HA para SAP HANA en SUSE Linux Enterprise Server (SLES), consulta la guía de configuración de clústeres de HA para 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

Al seguir las instrucciones de esta guía, podrás implementar dos instancias de SAP HANA y configurar un clúster de HA en RHEL. Implementas cada instancia de SAP HANA en una VM de Compute Engine en una zona diferente dentro de la misma región. En esta guía, no se aborda la instalación de alta disponibilidad de SAP NetWeaver.

Descripción general de un clúster de Linux de alta disponibilidad para un sistema de escalamiento vertical de SAP HANA de un solo nodo

El clúster implementado incluye las siguientes funciones y características:

  • Dos VM de host, cada una con una instancia de SAP HANA
  • Replicación síncrona del sistema SAP HANA.
  • El administrador de recursos del clúster de alta disponibilidad de Pacemaker
  • Un mecanismo de defensa STONITH
  • Reinicio automático de la instancia con errores como la instancia secundaria nueva

En esta guía, se usan las plantillas de Cloud Deployment Manager 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:

Requisitos

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

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

Crea una red

Por razones de seguridad, crea una red nueva. Puedes controlar quién tiene acceso con reglas de firewall o mediante 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 explícitamente.

Durante la implementación, las instancias de VM suelen requerir acceso a Internet para descargar el agente de supervisión de Google. 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 configurar la red, sigue estos pasos:

  1. Ve a Cloud Shell.

    Ir a Cloud Shell

  2. Para crear una red nueva en el modo de subredes personalizadas, ejecuta el siguiente comando:

    gcloud compute networks create [YOUR_NETWORK_NAME] --subnet-mode custom

    donde [YOUR_NETWORK_NAME] es el nombre de la nueva red. El nombre de la red solo puede contener caracteres en minúsculas, dígitos y el carácter de guion (-).

    Especifica --subnet-mode custom para evitar el uso del modo automático predeterminado, que crea de forma automática una subred en cada región de Compute Engine. Para obtener más información, consulta Modo de creación de subredes.

  3. Crea una subred y especifica la región y el rango de IP mediante el siguiente comando:

    gcloud compute networks subnets create [YOUR_SUBNETWORK_NAME] \
            --network [YOUR_NETWORK_NAME] --region [YOUR_REGION] --range [YOUR_RANGE]

    En el ejemplo anterior, se ilustra lo siguiente:

    • [YOUR_SUBNETWORK_NAME] es la subred nueva.
    • [YOUR_NETWORK_NAME] es el nombre de la red que creaste en el paso anterior.
    • [REGION] es la región en la que deseas que esté la subred.
    • [YOUR_RANGE] es el rango de direcciones IP especificado en formato CIDR, por ejemplo, 10.1.0.0/24. Si planeas agregar más de una subred, asigna rangos de IP de CIDR no superpuestos para cada subred de la red. Ten en cuenta que cada subred y sus rangos de IP interna se asignan a una sola región.
  4. Opcionalmente, repite el paso anterior y agrega subredes adicionales.

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

A fin de 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.

Agrega 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). A fin de 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 mediante 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.
  • Comunicación entre las VM de la subred de SAP HANA, incluida la comunicación entre los nodos en un sistema de escalamiento horizontal de SAP HANA o la comunicación entre el servidor de base de datos y los servidores de aplicaciones en una arquitectura de 3 niveles. Puedes habilitar la comunicación entre las VM si creas una regla de firewall para permitir el tráfico que se origina desde la subred.

Para crear una regla de firewall, sigue estos pasos:

Console

  1. En Cloud Console, ve a la página Reglas de firewall.

    ABRIR REGLAS DE FIREWALL

  2. En la parte superior de la página, haz clic en Crear regla de firewall.

    • En el campo Red, selecciona la red donde se ubica tu VM.
    • En el campo Destinos, especifica los recursos de Google Cloud a los que se aplica esta regla. Por ejemplo, especifica Todas las instancias de la red. O bien, para limitar la regla a instancias específicas en Google Cloud, ingresa etiquetas en Etiquetas de destino especificadas.
    • En el campo Filtro de fuente, selecciona una de las siguientes opciones:
      • Rangos de IP para permitir el tráfico entrante de direcciones IP específicas. Especifica el rango de direcciones IP en el campo Rangos de IP de origen.
      • Subredes para permitir el tráfico entrante desde una subred específica. Especifica el nombre de la subred en el siguiente campo Subredes. Puedes usar esta opción para permitir el acceso entre las VM en una configuración de escalamiento horizontal o de 3 niveles.
    • En la sección Protocolos y puertos, selecciona Protocolos y puertos especificados e ingresa tcp:[PORT_NUMBER].
  3. Haz clic en Crear para crear tu regla de firewall.

gcloud

Crea una regla de firewall mediante el siguiente comando:

$ gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags

Implementa las VM y SAP HANA

Antes de comenzar a configurar el clúster de HA, debes definir e implementar las instancias de VM y los sistemas SAP HANA que funcionarán como los nodos principales y secundarios en tu clúster de HA.

A fin de definir e implementar los sistemas, usa la misma plantilla de Cloud Deployment Manager que usas para implementar un sistema SAP HANA en la guía de implementación de SAP HANA.

Sin embargo, a fin de implementar dos sistemas en lugar de uno, debes agregar la definición del segundo sistema al archivo de configuración. Para ello, copia y pega la definición del primer sistema. Después de crear la segunda definición, debes cambiar los nombres de los recursos y las instancias en la segunda definición. Para evitar una falla zonal, especifica una zona diferente en la misma región. Todos los demás valores de propiedad en las dos definiciones permanecen iguales.

Una vez que los sistemas SAP HANA se implementen de forma correcta, debes definir y configurar el clúster de HA.

Las siguientes instrucciones se usan con Cloud Shell, pero se pueden aplicar al SDK de Cloud en términos generales.

  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 las cuotas no son suficientes, la implementación fallará. Si quieres ver los requisitos de cuota de SAP HANA, consulta las consideraciones de precios y cuotas para SAP HANA.

    Ir a la página Cuotas

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

    Ir a Cloud Shell

  3. Ingresa el siguiente comando en Cloud Shell o en el SDK de Cloud a fin de descargar la plantilla de archivo de configuración template.yaml para el clúster de alta disponibilidad de SAP HANA al directorio de trabajo:

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/template.yaml
  4. De manera opcional, cambia el nombre del archivo template.yaml para identificar la configuración que define.

  5. Abre el archivo template.yaml en el editor de código de Cloud Shell o, si usas el SDK de Cloud, 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.

  6. En el archivo template.yaml, completa la definición de la primera VM y el sistema SAP HANA. Reemplaza los corchetes y su contenido por los valores de la instalación a fin de especificar los siguientes valores de propiedad. Las propiedades se describen en la siguiente tabla.

    Para crear las instancias de VM sin instalar SAP HANA, borra todas las líneas que comiencen con sap_hana_ o conviértelas en comentarios.

    Propiedad Tipo de datos Descripción
    tipo String

    Especifica la ubicación, el tipo y la versión de la plantilla de Deployment Manager que se usará durante la implementación.

    El archivo YAML incluye dos especificaciones type, y una de ellas se marca como comentario. La especificación type que está activa de forma predeterminada especifica la versión de la plantilla como latest. La especificación type que se marca como comentario especifica una versión específica de la plantilla con una marca de tiempo.

    Si necesitas que todas tus implementaciones usen la misma versión de plantilla, usa la especificación type, que incluye la marca de tiempo.

    instanceName String El nombre de la instancia de VM que se define en este momento. Especifica nombres diferentes en las definiciones de la VM principal y secundaria. Los nombres se deben especificar con letras minúsculas, números o guiones.
    instanceType String El tipo de máquina virtual de Compute Engine en el que quieres ejecutar SAP HANA. 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.
    zone String La zona de Google Cloud en la que se implementará la instancia de VM que estás definiendo. Especifica diferentes zonas en la misma región para las definiciones de la VM principal y secundaria. Las zonas deben estar en la misma región que seleccionaste para tu subred.
    subnetwork String El nombre de la subred que creaste en un paso anterior. Si realizas la implementación en una VPC compartida, especifica este valor como [SHAREDVPC_PROJECT]/[SUBNETWORK]. Por ejemplo, myproject/network1.
    linuxImage String El nombre de la imagen del sistema operativo Linux o de la familia de imágenes que usas con SAP HANA. Para especificar una familia de imágenes, agrega el prefijo family/ al nombre de la familia. Por ejemplo, family/rhel-7-6-sap-ha. Para indicar una imagen específica, proporciona solo el nombre de la imagen. Para ver la lista de imágenes y familias disponibles, consulta la página Imágenes en Cloud Console.
    linuxImageProject String El proyecto de Google Cloud que contiene la imagen que usarás. Este proyecto puede ser uno propio o un proyecto de imágenes de Google Cloud, como rhel-sap-cloud. Para obtener más información sobre los proyectos de imagen de GCP, consulta la página Imágenes en la documentación de Compute Engine.
    sap_hana_deployment_bucket String El nombre del bucket de almacenamiento de GCP en el proyecto que contiene los archivos de instalación y revisión de SAP HANA que subiste en un paso anterior. Todos los archivos de revisión de actualización en el bucket se aplican a SAP HANA durante el proceso de implementación.
    sap_hana_sid String El ID del sistema SAP HANA (SID). Debe constar de tres caracteres alfanuméricos y comenzar con una letra. Todas las letras deben estar en mayúsculas.
    sap_hana_instance_number Número entero El número de instancia, de 0 a 99, del sistema SAP HANA. El valor predeterminado es 0.
    sap_hana_sidadm_password String La contraseña del administrador del sistema operativo (SO). Las contraseñas deben tener como mínimo ocho caracteres y deben incluir al menos una letra mayúscula, una letra minúscula y un número.
    sap_hana_system_password String La contraseña para el superusuario de la base de datos. Las contraseñas deben tener al menos ocho caracteres y, a su vez, incluir al menos una letra mayúscula, una letra minúscula y un número.
    sap_hana_sidadm_uid Entero El valor predeterminado para el ID de usuario sidadm es 900 a fin de evitar que los grupos creados por el usuario entren en conflicto con SAP HANA. Puedes cambiar este valor a uno diferente si es necesario.
    sap_hana_sapsys_gid Entero El ID de grupo predeterminado para sapsys es 79. Si especificas un valor superior, puedes anular este valor según tus requisitos.
    sap_hana_scaleout_nodes Entero Especifica 0. Estas instrucciones son solo para sistemas SAP HANA de escalamiento vertical.
    networkTag String Una etiqueta de red que representa tu instancia de VM para el firewall o el enrutamiento. Si especificas “publicIP: No”, pero no especificas una etiqueta de red, asegúrate de proporcionar otro medio de acceso a Internet.
    publicIP Booleano Opcional. Determina si se agrega una dirección IP pública a tu instancia de VM. El valor predeterminado es Yes.
    serviceAccount String Opcional. Especifica una cuenta de servicio que usarán las VM del host y los programas que se ejecutan en las VM del host. Especifica la cuenta de correo electrónico del miembro de la cuenta de servicio. Por ejemplo, svc-acct-name@project-id.iam.gserviceaccount.com. De forma predeterminada, se usa la cuenta de servicio predeterminada de Compute Engine. A fin de obtener más información, consulta Administración de identidades y accesos para programas SAP en Google Cloud.
  7. Crea la definición de la segunda VM y el sistema SAP HANA. Para ello, copia la definición de la primera y pégala después de la primera definición. SIgue estos pasos para consultar el ejemplo.

  8. En la definición del segundo sistema, especifica valores diferentes para las siguientes propiedades que especificaste en la primera definición:

    • name
    • instanceName
    • zone
  9. Crea las instancias:

    gcloud deployment-manager deployments create deployment-name --config template-name.yaml

    Mediante el comando anterior, se invoca a Deployment Manager, que implementa las VM, descarga el software de SAP HANA del bucket de almacenamiento e instala SAP HANA, todo según las especificaciones del archivo template.yaml.

    El procesamiento de la implementación consta de dos etapas. En la primera, Deployment Manager escribe su estado en la consola. En la segunda, las secuencias de comandos de implementación escriben su estado en Cloud Logging.

Ejemplo de un archivo de configuración template.yaml completo

En el siguiente ejemplo, se muestra un archivo de configuración template.yaml completo que implementa dos instancias de VM con un sistema SAP HANA instalado.

El archivo contiene las definiciones de dos recursos para implementar: sap_hana_primary y sap_hana_secondary. Cada definición de recurso contiene las definiciones de una VM y una instancia de SAP HANA.

La definición del recurso sap_hana_secondary se creó cuando se copió y se pegó la primera definición y, luego, se modificaron los valores de las propiedades name, instanceName y zone. Todos los demás valores de propiedad en las dos definiciones de recursos son iguales.

Las propiedades networkTag, serviceAccount, sap_hana_sidadm_uid y sap_hana_sapsys_gid pertenecen a la sección Opciones avanzadas de la plantilla del archivo de configuración. Las propiedades sap_hana_sidadm_uid y sap_hana_sapsys_gid se incluyen para mostrar sus valores predeterminados, que se usan porque las propiedades se convertieron en comentarios.

resources:
- name: sap_hana_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/rhel-8-1-sap-ha
    linuxImageProject: rhel-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Tempa55word
    sap_hana_system_password: Tempa55word
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_hana_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/rhel-8-1-sap-ha
    linuxImageProject: rhel-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

Crea reglas de firewall que permitan el acceso a las VM del host

Si aún no lo hiciste, crea reglas de firewall que permitan el acceso a cada VM del host desde las siguientes fuentes:

  • Para fines de configuración, tu estación de trabajo local, un host de bastión o un servidor de salto
  • Para el acceso entre los nodos del clúster, las otras VM del host en el clúster de HA

Cuando creas reglas de firewall de VPC, especificas las etiquetas de red que definiste en el archivo de configuración template.yaml para designar tus VM del host como destino de la regla.

Para verificar la implementación, define una regla que permita conexiones SSH en el puerto 22 desde un host de bastión o tu estación de trabajo local.

Para el acceso entre los nodos del clúster, agrega una regla de firewall que permita todos los tipos de conexiones en cualquier puerto de otras VM en la misma subred.

Asegúrate de que se creen las reglas de firewall para verificar la implementación y la comunicación dentro del clúster antes de continuar con la siguiente sección. Para obtener instrucciones, consulta Agrega reglas de firewall.

Verifica la implementación de las VM y SAP HANA

Antes de comenzar a configurar el clúster de HA, verifica que las VM y SAP HANA estén implementadas de forma correcta mediante la verificación de los registros, la asignación del directorio del SO y la instalación de SAP HANA.

Verifica los registros

  1. Abre Cloud Logging para verificar errores y supervisar el progreso de la instalación.

    Ir a Cloud Logging

  2. En la pestaña Recursos, selecciona Global como tu recurso de registro.

    • Si se muestra "INSTANCE DEPLOYMENT COMPLETE", el procesamiento de Deployment Manager 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. En la página Implementaciones de Deployment Manager, borra la implementación para limpiar las VM y los discos persistentes de la instalación con errores.
      3. Vuelve a ejecutar Deployment Manager.

      Pantalla de Logging

Verifica la configuración de las VM y SAP HANA

  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.

    Botón SSH de la página Instancias de VM de Compute Engine

  2. Cambia al usuario raíz.

    $ sudo su -
  3. En el símbolo del sistema, ingresa df -h. En cada VM, asegúrate de ver los directorios /hana, como /hana/data.

    Filesystem                        Size  Used Avail Use% Mounted on
    /dev/sda2                          30G  4.0G   26G  14% /
    devtmpfs                          126G     0  126G   0% /dev
    tmpfs                             126G     0  126G   0% /dev/shm
    tmpfs                             126G   17M  126G   1% /run
    tmpfs                             126G     0  126G   0% /sys/fs/cgroup
    /dev/sda1                         200M  9.7M  191M   5% /boot/efi
    /dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
    /dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
    /dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
    /dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
    /dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
    tmpfs                              26G     0   26G   0% /run/user/900
    tmpfs                              26G     0   26G   0% /run/user/899
    tmpfs                              26G     0   26G   0% /run/user/1000
  4. En el siguiente comando, reemplaza sid con el ID del sistema que especificaste en la plantilla del archivo de configuración para cambiar al usuario administrador de SAP.

    # su - sidadm
  5. Ejecuta el siguiente comando para asegurarte de que los servicios de SAP HANA, como hdbnameserver, hdbindexserver y otros, se ejecuten en la instancia:

    > HDB info

Inhabilita el inicio automático de SAP HANA

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 sidadm, 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 sidadm, inicia SAP HANA:

    > HDB start

Opcional: Configura claves SSH en las VM principales y secundarias

Las claves del almacenamiento seguro (SSFS) de SAP HANA deben sincronizarse entre los hosts en el clúster de HA. En estas instrucciones, para simplificar la sincronización y permitir que se copien archivos (como las copias de seguridad) entre los hosts en el clúster de HA, se autorizan las conexiones SSH directas entre los dos hosts.

Es probable que tu organización tenga lineamientos que rijan las comunicaciones de redes internas. Si es necesario, después de completar la implementación, puedes quitar los metadatos de las VM y las claves del directorio authorized_keys.

Si configurar conexiones SSH directas no cumple con los lineamientos de tu organización, puedes sincronizar las claves SSFS y transferir archivos mediante otros métodos, como los que se mencionan a continuación:

Para habilitar las conexiones SSH entre la instancia principal y la secundaria, haz lo que se indica a continuación.

  1. En la VM host principal, sigue estos pasos:

    1. Conéctate a la VM mediante SSH.

    2. Genera una clave SSH para el usuario que necesita la conexión SSH de host a host. El usuario sueles ser tú.

      $ ssh-keygen
    3. En los mensajes, presiona Intro para aceptar los valores predeterminados.

    4. Actualiza los metadatos de la VM principal con información sobre la clave SSH para la VM secundaria.

      $ gcloud compute instances add-metadata secondary-host-name \
           --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
           --zone secondary-zone
    5. Autoriza la VM principal a sí misma

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
  2. En la VM secundaria del host, sigue estos pasos:

    1. Conéctate a la VM mediante SSH.

    2. Genera una clave SSH para el usuario que necesita la conexión SSH de host a host.

      $ ssh-keygen
    3. Actualiza los metadatos de la VM secundaria con información sobre la clave SSH para la VM principal.

      $ gcloud compute instances add-metadata primary-host-name \
            --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
            --zone primary-zone
    4. Autoriza la VM secundaria a sí misma

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    5. Para confirmar que las claves SSH estén configuradas de forma correcta, abre una conexión SSH desde el sistema secundario al principal.

      $ ssh primary-host-name
  3. En la VM principal del host, abre una conexión SSH a la VM secundaria del host para confirmar la conexión:

    $ ssh secondary-host-name

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 sidadm. El comando puede ser diferente según la imagen de SO.

    sudo -i -u sidadm
  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 sidadm, habilita la replicación del sistema:

    > hdbnsutil -sr_enable --name=primary-host-name
  2. En el host secundario como sidadm, detén SAP HANA:

    > HDB stop
  3. En el host principal, mediante la misma cuenta de usuario que usaste para configurar la conexión SSH entre las VM del host, copia los archivos de claves en el host secundario. A fin de lograr mayor comodidad, con los siguientes comandos, también se define una variable de entorno para tu ID de cuenta de usuario:

    $ sudo cp /usr/sap/SID/SYS/global/security/rsecssfs ~/rsecssfs -r
    $ myid=$(whoami)
    $ sudo chown ${myid} -R /home/"${myid}"/rsecssfs
    $ scp -r rsecssfs $(whoami)@secondary-host-name:rsecssfs
    $ rm -r /home/"${myid}"/rsecssfs
    
  4. En el host secundario, con el mismo usuario que en el paso anterior, sigue estos pasos:

    1. Reemplaza los archivos de claves existentes en los directorios rsecssfs por los archivos del host principal y establece los permisos del archivo para limitar el acceso:

      $ SAPSID=SID
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ myid=$(whoami)
      $ sudo cp /home/"${myid}"/rsecssfs/data/SSFS_"${SAPSID}".DAT \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo cp /home/"${myid}"/rsecssfs/key/SSFS_"${SAPSID}".KEY \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chmod 644 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chmod 640 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
    2. Limpia los archivos del directorio principal.

      $ rm -r /home/"${myid}"/rsecssfs
    3. Como sidadm, 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
    4. Como sidadm, inicia SAP HANA:

      > HDB start

Valida la replicación del sistema

En el host principal como sidadm, 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.

Solo en SAP HANA 1.0 SPS 12: Crea un usuario de Linux para el agente de supervisión

Debes registrar los agentes de recursos como usuarios de la base de datos de SAP HANA para que puedan ejecutar consultas en el estado de replicación del sistema. Los agentes de recursos necesitan los privilegios CATALOG READ y MONITOR ADMIN.

Para registrar los agentes de recursos como un usuario de base de datos, haz lo que se describe a continuación:

  1. En el host principal, sigue estos pasos:

    1. Como sidadm, crea el usuario rhelhasync:

      > hdbsql -i inst_num -u system -p system-password \
        "create user rhelhasync password \"monitoring-user-password\""
      > hdbsql -i inst_num -u system -p system-password \
        "grant CATALOG READ to rhelhasync"
      > hdbsql -i inst_num -u system -p system-password \
        "grant MONITOR ADMIN to rhelhasync"
      > hdbsql -i inst_num -u system -p system-password \
        "ALTER USER rhelhasync DISABLE PASSWORD LIFETIME"
    2. Como raíz, almacena la credencial para que el usuario raíz pueda acceder a ella:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore \
        SET SAPHANASIDSR localhost:3inst_num15 rhelhasync \
        "monitoring-user-password"
    3. Como raíz, confirma que las credenciales se almacenaron de forma correcta:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore list

      Deberías ver un resultado similar al siguiente:

      ha1adm@hana-ha-vm-1:/usr/sap/HA1/HDB22> /usr/sap/HA1/HDB22/exe/hdbuserstore list
      DATA FILE       : /usr/sap/HA1/home/.hdb/hana-ha-vm-1/SSFS_HDB.DAT
      KEY FILE        : /usr/sap/HA1/home/.hdb/hana-ha-vm-1/SSFS_HDB.KEY
      
      KEY SAPHANAHA1SR
       ENV : localhost:32215
       USER: rhelhasync
    4. Como raíz, confirma que la raíz pueda conectarse a la base de datos mediante la clave almacenada:

      # /usr/sap/SID/HDBinst_num/exe/hdbsql -U SAPHANASIDSR -i inst_num \
        "select distinct REPLICATION_STATUS from SYS.M_SERVICE_REPLICATION"
  2. En el host secundario, sigue estos pasos:

    1. Como raíz, almacena la credencial para que el usuario raíz pueda acceder a ella:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore \
        SET SAPHANASIDSR localhost:3inst_num15 rhelhasync \
          "monitoring-user-password"
    2. Como raíz, confirma que las credenciales se almacenaron de forma correcta:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore list

      Deberías ver un resultado similar al siguiente:

      ha1adm@hana-ha-vm-2:/usr/sap/HA1/HDB22> /usr/sap/HA1/HDB22/exe/hdbuserstore list
      DATA FILE       : /usr/sap/HA1/home/.hdb/hana-ha-vm-2/SSFS_HDB.DAT
      KEY FILE        : /usr/sap/HA1/home/.hdb/hana-ha-vm-2/SSFS_HDB.KEY
      KEY SAPHANAHA1SR
       ENV : localhost:32215
       USER: rhelhasync

Si recibes mensajes de error o se te solicita cambiar la contraseña, usa el comando hdbsql o SAP HANA Studio a fin de confirmar que la contraseña del usuario del agente de recursos no esté configurada para que deba cambiarse en el primer acceso o que no esté vencida.

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

El servicio de balanceo de cargas de TCP/UDP interno compatible 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. Esto ofrece protección en una configuración Activa/Pasiva y se puede extender para admitir una configuración Activa/Activa (secundaria con lectura habilitada).

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 las VM de tu host

  1. En Cloud Shell, crea dos grupos de instancias no administrados y asigna la VM del host principal a uno y la VM del host secundaria al otro:

    $ 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
    $ gcloud compute instances add-tags  secondary-host-name \
      --tags network-tags
    
  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:

    $ 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

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 ambas VM del host, 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ías 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ías 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):

Instala los agentes del clúster en ambos nodos

Completa los siguientes pasos en ambos nodos.

  1. Como raíz, instala los componentes de Pacemaker:

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

    Si usas una imagen de RHEL para SAP proporcionada por Google, estos paquetes ya están instalados, pero es posible que se requieran algunas actualizaciones.

  2. Configura la contraseña para el usuario hacluster, que se instala como parte de los paquetes:

    # passwd hacluster
  3. Especifica una contraseña para hacluster en los mensajes.

  4. En las imágenes de RHEL 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
  5. Inicia el servicio pcs y configúralo para que se inicie en el momento del inicio:

    # systemctl start pcsd.service
    # systemctl enable pcsd.service
  6. Comprueba el estado del servicio pcs:

    # systemctl status pcsd.service

    Deberías 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-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
    Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.
  7. En el archivo /etc/hosts, agrega el nombre completo del host y las direcciones IP internas de ambos hosts en el clúster. Por ejemplo:

    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    10.0.0.40 hana-ha-vm-1.us-central1-a.c.example-project-123456.internal hana-ha-vm-1  # Added by Google
    10.0.0.41 hana-ha-vm-2.us-central1-c.c.example-project-123456.internal hana-ha-vm-2
    169.254.169.254 metadata.google.internal  # Added by Google

    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 cualquiera de los nodos, autoriza al usuario hacluster. Haz clic en la pestaña de tu versión de RHEL para ver el comando:

    RHEL 8 y versiones posteriores

    # pcs host auth primary-host-name secondary-host-name

    RHEL 7

    # pcs cluster auth primary-host-name secondary-host-name
  2. En los mensajes, ingresa el nombre de usuario hacluster y la contraseña que configuraste para el usuario hacluster.

  3. Crea el clúster:

    RHEL 8 y versiones posteriores

    # pcs cluster setup cluster-name primary-host-name secondary-host-name

    RHEL 7

    # pcs cluster setup --name cluster-name primary-host-name secondary-host-name

Edita la configuración predeterminada de corosync.conf

Edita el archivo /etc/corosync/corosync.conf en el host principal a fin de establecer un punto de partida más apropiado para probar la tolerancia a errores del clúster de HA en Google Cloud.

  1. En cualquier host, abre el archivo /etc/corosync/corosync.conf para editarlo:

    # vi /etc/corosync/corosync.conf
  2. Si /etc/corosync/corosync.conf es un archivo nuevo o vacío, puedes verificar el directorio /etc/corosync/ para ver un archivo de ejemplo que usarás como base para el archivo de Corosync.

  3. En la sección totem del archivo corosync.conf, agrega las siguientes propiedades con los valores sugeridos, como se muestra para tu versión de RHEL:

    RHEL 8 y versiones posteriores

    • transport: knet
    • token: 20000
    • token_retransmits_before_loss_const: 10
    • join: 60
    • max_messages: 20

    Por ejemplo:

    totem {
    version: 2
    cluster_name: hacluster
    secauth: off
    transport: knet
    token: 20000
    token_retransmits_before_loss_const: 10
    join: 60
    max_messages: 20
    }
    ...

    RHEL 7

    • transport: udpu
    • token: 20000
    • token_retransmits_before_loss_const: 10
    • join: 60
    • max_messages: 20

    Por ejemplo:

    totem {
    version: 2
    cluster_name: hacluster
    secauth: off
    transport: udpu
    token: 20000
    token_retransmits_before_loss_const: 10
    join: 60
    max_messages: 20
    }
    ...
  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 forma automática:

    1. # pcs cluster enable --all
    2. # 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

Configura la protección

Las imágenes de RHEL que proporciona Google Cloud incluyen un agente de protección 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 ver todas las opciones disponibles con el agente de protección fence_gce, emite fence_gce -h.

  1. En el host principal como raíz, ejecuta el siguiente comando:

    1. Crea un dispositivo de protección para cada VM del host:

      # pcs stonith create primary-fence-name fence_gce \
        port=primary-host-name \
        zone=primary-host-zone \
        project=project-id
      # pcs stonith create secondary-fence-name fence_gce \
        port=secondary-host-name \
        zone=secondary-host-zone \
        project=project-id
    2. Restringe cada dispositivo de protección a la otra VM del host:

      # pcs constraint location primary-fence-name avoids primary-host-name
      # pcs constraint location secondary-fence-name avoids secondary-host-name
  2. En el host principal como raíz, prueba el dispositivo de protección secundario:

    1. Apaga la VM del host secundaria:

      # fence_gce -o off -n secondary-host-name --zone=secondary-host-zone

      Si el comando se ejecuta de forma correcta, perderás conectividad con la VM del host secundaria y aparecerá detenida en la página Instancias de VM en Cloud Console. Es posible que debas actualizar la página.

    2. Reinicia la VM del host secundaria:

      # fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
  3. En el host secundario como raíz, repite los pasos anteriores mediante los valores del host principal en los comandos para probar la protección principal.

  4. En cualquiera de los hosts como raíz, verifica el estado del clúster:

    # pcs status

    Los recursos de protección aparecen en la sección de recursos del estado del clúster, de manera similar al siguiente ejemplo:

    [root@hana-ha-vm-2 ~]# pcs status
    Cluster name: hana-ha-cluster
    Stack: corosync
    Current DC: hana-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
    Last updated: Mon Jun 15 17:19:07 2020
    Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on hana-ha-vm-1
    
    2 nodes configured
    2 resources configured
    
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
    
    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
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

SAP HANA 2.0 SPS 03 y versiones posteriores: habilita el hook de proveedor de HA/DR de SAP HANA

Si usas RHEL 7.6 o posterior con SAP HANA 2.0 SPS 03 o posterior, Red Hat recomienda enfáticamente que uses el hook de proveedor de HA/DR de SAP HANA.

El hook del proveedor de HA/DR de SAP HANA permite que SAP HANA envíe notificaciones para ciertos eventos y mejora la detección de fallas.

Si tu versión de RHEL es anterior a 7.6 o tu versión de SAP HANA anterior a 2.0 SPS 03, el hook no es compatible con RHEL.

Mediante los siguientes pasos, se habilita el hook del proveedor de HA/DR de SAP HANA.

  1. Como raíz en cualquiera de los hosts, detén el clúster:

    # pcs cluster stop --all
  2. En ambos hosts, sigue estos pasos:

    1. Como sidadm, detén SAP HANA:

      > HDB stop
    2. Como raíz, instala la secuencia de comandos de SAP HANA proporcionada:

      # mkdir -p /hana/shared/myHooks
      # cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks
      # chown -R sidadm:sapsys /hana/shared/myHooks
    3. Como raíz, abre el archivo global.ini para editarlo:

      # vi /hana/shared/SID/global/hdb/custom/config/global.ini
    4. Agrega las siguientes definiciones al archivo global.ini:

      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /hana/shared/myHooks
      execution_order = 1
      
      [trace]
      ha_dr_saphanasr = info
    5. Como raíz, crea un archivo de configuración sudo para permitir que la secuencia de comandos del hook actualice los atributos del nodo cuando se llame al hook srConnectionChanged():

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

      1 Cmnd_Alias SOK   = /usr/sbin/crm_attribute -n hana_SID_glob_srHook -v SOK -t crm_config -s SAPHanaSR
      2 Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_SID_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR
      3 sidadm ALL=(ALL) NOPASSWD: SOK, SFAIL
    7. Como sidadm, inicia SAP HANA:

      > HDB start
    8. Como sidadm, 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_*

Establece los valores predeterminados 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 en cualquiera de los hosts, inicia el clúster:

    # pcs cluster start --all #start the cluster
  2. Establece los valores predeterminados del recurso:

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

  3. Si las propiedades startup-fencing y stonith-enabled aún no están configuradas como true, configúralas como true ahora:

    # pcs property set startup-fencing="true"
    # pcs property set stonith-enabled="true"

    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:

    # pcs resource create topology_resource_name SAPHanaTopology SID=SID \
       InstanceNumber=inst_num \
       op start timeout=600 \
       op stop timeout=300 \
       op monitor interval=10 timeout=600 \
       clone clone-max=2 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 y versiones posteriores

    # pcs resource config topology_resource_name-clone

    RHEL 7

    # pcs resource show topology_resource_name-clone

    Debería ver un resultado similar al siguiente:

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

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

Crea el recurso SAPHana

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 varios niveles de SAP HANA con alta disponibilidad, si usas una versión anterior a SAP HANA 2.0 SP03, configura AUTOMATED_REGISTER como false. Esto evita que una instancia recuperada intente realizar el registro automático de la replicación en un sistema de HANA que ya tiene un destino de replicación configurado. Para SAP HANA 2.0 SP03 o posterior, puedes establecer AUTOMATED_REGISTER en true para las configuraciones de SAP HANA que usan 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 SAP HANA:

    RHEL 8 y versiones posteriores

    # pcs resource create sap_hana_resource_name SAPHana SID=SID \
    InstanceNumber=inst_num \
    PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
    op start timeout=3600 \
    op stop timeout=3600 \
    op monitor interval=61 role="Slave" timeout=700 \
    op monitor interval=59 role="Master" timeout=700 \
    op promote timeout=3600 \
    op demote timeout=3600 \
    promotable meta notify=true clone-max=2 clone-node-max=1 interleave=true

    RHEL 7

    # pcs resource create sap_hana_resource_name SAPHana SID=SID \
    InstanceNumber=inst_num \
    PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
    op start timeout=3600 \
    op stop timeout=3600 \
    op monitor interval=61 role="Slave" timeout=700 \
    op monitor interval=59 role="Master" timeout=700 \
    op promote timeout=3600 \
    op demote timeout=3600 \
    master meta notify=true clone-max=2 clone-node-max=1 interleave=true
  2. Verifica los atributos de recursos resultantes:

    RHEL 8 y versiones posteriores

    # pcs resource config sap_hana_resource_name

    RHEL 7

    # pcs resource show sap_hana_resource_name

    Deberías ver un resultado similar al siguiente:

     Resource: SAPHana_HA1_22 (class=ocf provider=heartbeat type=SAPHana)
      Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=22 PREFER_SITE_TAKEOVER=true SID=HA1
      Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
      Operations: demote interval=0s timeout=3600 (SAPHana_HA1_22-demote-interval-0s)
                  methods interval=0s timeout=5 (SAPHana_HA1_22-methods-interval-0s)
                  monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_22-monitor-interval-61)
                  monitor interval=59 role=Master timeout=700 (SAPHana_HA1_22-monitor-interval-59)
                  promote interval=0s timeout=3600 (SAPHana_HA1_22-promote-interval-0s)
                  reload interval=0s timeout=5 (SAPHana_HA1_22-reload-interval-0s)
                  start interval=0s timeout=3600 (SAPHana_HA1_22-start-interval-0s)
                  stop interval=0s timeout=3600 (SAPHana_HA1_22-stop-interval-0s)
  3. 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ías ver un resultado similar al siguiente:

    Stack: corosync
    Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
    Last updated: Tue Jun 16 20:07:51 2020
    Last change: Tue Jun 16 20:07:26 2020 by root via crm_attribute on hana-ha-vm-1
    
    2 nodes configured
    6 resources configured
    
    Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
    
    Active 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
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    
    Node Attributes:
    * Node hana-ha-vm-1:
       + hana_ha1_clone_state              : PROMOTED
       + hana_ha1_op_mode                  : logreplay
       + hana_ha1_remoteHost               : hana-ha-vm-2
       + hana_ha1_roles                    : 4:P:master1:master:worker:master
       + hana_ha1_site                     : hana-ha-vm-1
       + hana_ha1_srmode                   : syncmem
       + hana_ha1_sync_state               : PRIM
       + hana_ha1_version                  : 1.00.122.27.1568902538
       + hana_ha1_vhost                    : hana-ha-vm-1
       + lpa_ha1_lpt                       : 1592338046
       + master-SAPHana_HA1_22             : 150
    * Node hana-ha-vm-2:
       + hana_ha1_clone_state              : DEMOTED
       + hana_ha1_op_mode                  : logreplay
       + hana_ha1_remoteHost               : hana-ha-vm-1
       + hana_ha1_roles                    : 4:S:master1:master:worker:master
       + hana_ha1_site                     : hana-ha-vm-2
       + hana_ha1_srmode                   : syncmem
       + hana_ha1_sync_state               : SOK
       + hana_ha1_version                  : 1.00.122.27.1568902538
       + hana_ha1_vhost                    : hana-ha-vm-2
       + lpa_ha1_lpt                       : 30
       + master-SAPHana_HA1_22             : 100

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 resource_name \
  IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32

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. Por ejemplo, la dirección IP debe estar en el mismo host que la instancia principal de HANA.

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

    RHEL 8 y versiones posteriores

    # pcs constraint order topology_resource_name-clone \
    then sap_hana_resource_name-clone symmetrical=false

    RHEL 7

    # pcs constraint order topology_resource_name-clone \
    then sap_hana_resource_name-master symmetrical=false

    La especificación de symmetrical=false significa que la restricción se aplica solo al inicio y no al apagado.

    Sin embargo, debido a que configuraste interleave=true para estos recursos en un paso anterior, los procesos pueden comenzar en paralelo. En otras palabras, puedes iniciar SAPHana en cualquier nodo tan pronto como se ejecute SAPHanaTopology.

  2. Comprueba las restricciones:

    # pcs constraint

    Deberías ver un resultado similar al siguiente:

    Location Constraints:
     Resource: STONITH-hana-ha-vm-1
       Disabled on:
         Node: hana-ha-vm-1 (score:-INFINITY)
     Resource: STONITH-hana-ha-vm-2
       Disabled on:
         Node: hana-ha-vm-2 (score:-INFINITY)
    Ordering Constraints:
     start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
    Colocation Constraints:
    Ticket Constraints:

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 el lugar en el que se ejecuta la instancia principal del clúster de SAP HANA.

  1. En cada host como raíz, instala un objeto de escucha de TCP simple. En estas instrucciones, se instala y usa HAProxy como objeto de escucha.

    # yum install haproxy
  2. 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
  3. En cada host como raíz, inicia el servicio para confirmar que esté configurado de forma correcta:

    # systemctl start haproxy.service
  4. En la página del balanceador de cargas en Cloud Console, 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.

    Captura de pantalla que muestra “1/1” en la columna En buen estado de ambos grupos de instancias, lo que indica que ambos están en buen estado.

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

    La captura de pantalla muestra “0/1” en la columna En buen estado de cada grupo de instancias, lo que indica que no hay un objeto de escucha activo.

    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. En cualquier host como raíz, crea un recurso de verificación de estado para el servicio HAProxy:

    # pcs resource create healthcheck_resource_name service:haproxy
  2. Confirma que el servicio de verificación de estado esté activo en el mismo host que tu instancia principal de SAP HANA y el recurso VIP:

    # pcs status

    Si el recurso de verificación de estado no está en el host principal, muévelo con el siguiente comando:

    # pcs resource move healthcheck_resource_name target_host_name
    # pcs resource clear healthcheck_resource_name

    El comando pcs resource clear deja el recurso en su ubicación nueva, pero quita la restricción de ubicación no deseada que creó el comando pcs resource move.

    En el estado, la sección de recursos debería ser similar al siguiente ejemplo:

    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
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
    rsc_healthcheck_HA1    (service:haproxy):      Started hana-ha-vm-2
  3. Agrupa los recursos de la VIP y la verificación de estado:

    # pcs resource group add rsc-group-name healthcheck_resource_name vip_resource_name

    En el estado del clúster, la sección de recursos debería ser similar al siguiente ejemplo:

    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
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    Resource Group: g-primary
        rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-1
        rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
  4. Crea una restricción que ubica el grupo nuevo en el mismo nodo que la instancia principal de SAP HANA.

    RHEL 8 y versiones posteriores

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

    RHEL 7

    # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-master 4000

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

    # pcs constraint
    Location Constraints:
     Resource: STONITH-hana-ha-vm-1
       Disabled on:
         Node: hana-ha-vm-1 (score:-INFINITY)
     Resource: STONITH-hana-ha-vm-2
       Disabled on:
         Node: hana-ha-vm-2 (score:-INFINITY)
    Ordering Constraints:
     start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
    Colocation Constraints:
     g-primary with SAPHana_HA1_22-master (score:4000) (rsc-role:Started) (with-rsc-role:Master)
    Ticket Constraints:

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
  • shutdown -r (en el nodo activo)
  • ip link set eth0 down
  • echo c > /proc/sysrq-trigger

En estas instrucciones, se usa ip link set eth0 down para desconectar la interfaz de red, ya que valida la conmutación por error y la protección.

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

    # ip link set eth0 down
  2. Sigue el progreso de la conmutación por error en Logging:

    Ir a Logging

    En el siguiente ejemplo, se muestran las entradas de registro de una conmutación por error exitosa:

    Captura de pantalla de los registros de Logging de una conmutación por error

  3. Vuelve a conectarte a cualquier host mediante SSH y cambia al usuario raíz.

  4. 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 ]
    
    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
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-2 ]
        Slaves: [ hana-ha-vm-1 ]
    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

Puedes encontrar los registros en las siguientes ubicaciones:

RHEL 8 y versiones posteriores

  • /var/log/pacemaker/pacemaker.log
  • /var/log/cluster/corosync.log

RHEL 7

  • /var/log/pacemaker.log
  • /var/log/cluster/corosync.log

Si no puedes encontrar los archivos de registro en estas ubicaciones, verifica la configuración de registros en /etc/sysconfig/pacemaker.

Estado válido del clúster:

# pcs status
Cluster name: hana-ha-cluster
Stack: corosync
Current DC: hana-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Wed Jun 17 00:34:16 2020
Last change: Wed Jun 17 00:34:09 2020 by root via crm_attribute on hana-ha-vm-1

2 nodes configured
8 resources configured

Online: [ hana-ha-vm-1 hana-ha-vm-2 ]

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
 Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
     Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
 Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
     Masters: [ hana-ha-vm-1 ]
     Slaves: [ hana-ha-vm-2 ]
 Resource Group: g-primary
     rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-1
     rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Si tienes problemas con tu clúster de alta disponibilidad de RHEL, recopila la siguiente información de los nodos del clúster y con la asistencia de contacto:

  • Enumera los procesos en ejecución en Pacemaker:

    ps axf | grep pacemaker

  • Instala la herramienta sos y genera un sosreport. Para obtener más información, consulta ¿Qué es un sosreport y cómo crear uno en Red Hat Enterprise Linux?:

    • Instala la herramienta sos
      yum install -y sos
    • Ejecuta la herramienta de sos en todos los nodos:
      sosreport -o logs, corosync, pacemaker -k pacemaker.crm_from="yyyy-mm-dd hh:mm:ss"
  • Si no puedes instalar la herramienta sos, proporciona una copia de /etc/corosync/corosync.conf, el archivo de configuración de Corosync, de todos los sistemas.

  • Proporciona la versión de Pacemaker:

    crmadmin --version

  • Proporciona el resultado de crm_report:

    crm_report -f "yyyy/mm/dd hh:mm"

  • Ejecuta journalctl y especifica las horas de inicio y finalización que corresponden a la hora en que se produjo el problema:

    journalctl -a --utc --no-pager -S "yyyy-mm-dd hh:mm:ss UTC" -U "yyyy-mm-dd hh:mm:ss UTC"

  • Proporciona un recuento de fallas de todos los recursos en cada nodo de Pacemaker:

    crm config show | grep primitive | awk '{print $2}' | xargs -L 1 -I "{}" crm resource failcount {} show node-name

Asistencia

Si tienes problemas con la infraestructura o los servicios de Google Cloud, comunícate con el equipo de asistencia de Google Cloud. Puedes encontrar la información de contacto en la página Descripción general de la asistencia en Google Cloud Console. Si la asistencia de Google Cloud determina que existe un problema en tus sistemas de SAP, te referiremos a la 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, transfiere el ticket al componente BC-OP-LNX-GOOGLE o BC-OP-NT-GOOGLE de Google Cloud.

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.

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

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.

Realiza tareas posteriores a la implementación

Antes de usar la instancia de SAP HANA, te recomendamos que configures y hagas una copia de seguridad de tu base de datos de SAP HANA nueva.

Para obtener más información, sigue estas sugerencias:

Próximos pasos

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