Guía de configuración del clúster de alta disponibilidad para SAP MaxDB en RHEL

En esta guía, se muestra cómo implementar un sistema SAP MaxDB en un clúster de alta disponibilidad de Red Hat Enterprise Linux (RHEL) en Google Cloud, con configuración de clúster activo/pasivo.

Para implementar un sistema SAP MaxDB de un solo nodo en Linux, usa la Guía de implementación de SAP MaxDB.

Esta guía está destinada a usuarios avanzados de SAP MaxDB que estén familiarizados con las configuraciones de alta disponibilidad de Linux para sistemas SAP.

El sistema que se implementa en esta guía

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

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

  • Dos VMs de Compute Engine en diferentes zonas que puedan ejecutar una instancia de SAP MaxDB
  • Un disco persistente regional para la instalación de SAP MaxDB
  • El administrador de recursos del clúster de alta disponibilidad de Pacemaker
  • Un mecanismo de defensa STONITH

En esta guía, no se aborda la instalación de alta disponibilidad de SAP NetWeaver.

Requisitos previos

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

  • Leíste la Guía de planificación de SAP MaxDB.
  • Tienes una suscripción a Red Hat.
  • Tú o tu organización deben tener una cuenta de Google Cloud y haber creado un proyecto para la implementación de SAP MaxDB.

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

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

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 explícitamente.

Durante la implementación, las instancias de VM suelen requerir acceso a Internet para descargar el agente de Google Cloudpara SAP. Si usas una de las imágenes de Linux certificadas por SAP disponibles en Google Cloud, la instancia de VM también requiere 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:

Console

  1. En la consola de Google Cloud , ve a la página Redes de VPC.

    Ir a las redes de VPC

  2. Haz clic en Crear red de VPC.
  3. Ingresa un Nombre para la red.

    El nombre debe cumplir con la convención de nombres. Las redes de VPC usan la convención de nombres de Compute Engine.

  4. En Modo de creación de subredes, selecciona Custom.
  5. En la sección Subred nueva, especifica los siguientes parámetros de configuración para una subred:
    1. Ingresa un Nombre para la subred.
    2. En Región, selecciona la región de Compute Engine en la que deseas crear la subred.
    3. En Tipo de pila IP, selecciona IPv4 (pila única) y, luego, ingresa un rango de direcciones IP en el formato CIDR. , como 10.1.0.0/24.

      Este es el rango de IPv4 principal de la subred. 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. Haz clic en Listo.
  6. Para agregar más subredes, haz clic en Agregar subred y repite los pasos anteriores. Puedes agregar más subredes a la red después de haberla creado.
  7. Haz clic en Crear.

gcloud

  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 NETWORK_NAME --subnet-mode custom

    Reemplaza NETWORK_NAME por el nombre de la red nueva. El nombre debe cumplir con la convención de nombres. Las redes de VPC usan la convención de nombres de Compute Engine.

    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 a través del siguiente comando: 
    gcloud compute networks subnets create SUBNETWORK_NAME \
    --network NETWORK_NAME --region REGION --range RANGE

    Reemplaza lo siguiente:

    • SUBNETWORK_NAME: el nombre de la subred nueva
    • NETWORK_NAME: el nombre de la zona que creaste en el paso anterior
    • REGION: la región en la que deseas que esté la subred
    • RANGE: el rango de direcciones IP especificado en formato CIDR, como 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. Si quieres, puedes repetir el paso anterior y agregar más 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 VMs 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.

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.

Para crear una regla de firewall, sigue estos pasos:

Console

  1. En la consola de Google Cloud , ve a la página Firewall de Compute Engine.

    Ir a Firewall

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

    • En el campo Red, selecciona la red en la que se ubica tu VM.
    • En el campo Destinos, especifica los recursos de Google Clouda 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 y luego 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 VMs y, luego, instala MaxDB

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

Crea una VM para la implementación de MaxDB

Como parte de la implementación de HA, se deberán crear dos VMs de Compute Engine de Google Cloud . Puedes consultar la guía Crea e inicia una instancia de Compute Engine.

Ten en cuenta que el disco persistente regional solo admite el uso de los tipos de máquina E2, N1, N2 y N2D. Consulta más detalles en la guía de Persistent Disk regional.

Consulta la Nota de SAP 2456432 - Aplicaciones de SAP en Google Cloud: Productos compatibles y Google Cloud tipos de máquinas para seleccionar el tipo de máquina correcto según tu tamaño.

Crea las dos VMs en zonas separadas para lograr la resiliencia zonal, con los siguientes requisitos mínimos:

  1. Detalles de la VM:

    • Instance Name
    • Zone: Tu zona preferida
    • Machine Type: Según el tamaño
    • Subnet: Es el nombre de la subred creada para esta región.

  2. Cuenta de servicio con, al menos, permiso de acceso a las siguientes APIs:

    • https://www.googleapis.com/auth/compute
    • https://www.googleapis.com/auth/servicecontrol
    • https://www.googleapis.com/auth/service.management.readonly
    • https://www.googleapis.com/auth/logging.write
    • https://www.googleapis.com/auth/monitoring.write
    • https://www.googleapis.com/auth/trace.append
    • https://www.googleapis.com/auth/devstorage.read_write

  3. Disco adicional en cada VM con un mínimo de 20 GB para usar en /usr/sap

Crea un solo disco regional para SAP MaxDB

Para esta implementación, se usará un disco regional para contener los archivos de MaxDB dentro del directorio /sapdb.

Crea el disco y asegúrate de que las zonas de replicación del disco regional coincidan con las zonas en las que creaste las dos VMs.

Conecta el disco regional a una de las VMs en las que realizarás la instalación de MaxDB y las tareas de configuración.

Prepara el SO RHEL para la instalación de SAP

El producto de SAP requiere que se instalen parámetros de configuración y paquetes específicos del sistema operativo. Sigue los lineamientos de la Nota de SAP: 2772999 - Red Hat Enterprise Linux 8.x: Instalación y configuración .

Esta tarea se debe realizar en ambos nodos.

Crea sistemas de archivos

  1. Conéctate a ambas instancias con SSH y crea los puntos de activación /usr/sap/SID y /sapdb.

    # sudo mkdir -p /usr/sap/SID
# sudo mkdir -p /sapdb

  2. Crea los sistemas de archivos en los dos discos adicionales conectados a las VMs con mkfs.

    Ten en cuenta que, en este momento, el disco regional solo se conectará en una de las VMs, por lo que la creación del sistema de archivos /sapdb solo se realizará una vez.

  3. Edita el archivo /etc/fstab para activar siempre /usr/sap/SID durante el reinicio en ambos nodos.

  4. Activa manualmente el sistema de archivos /sapdb en el nodo en el que realizarás la instalación de MaxDB.

    Para obtener más información sobre cómo crear y activar los sistemas de archivos, consulta la guía Formatea y activa un disco que no sea de arranque en una VM de Linux.

Modifica la configuración de LVM

Debes modificar la configuración de la administración de volúmenes lógicos (LVM) para que el grupo de volúmenes compartidos (VG) siempre esté conectado y solo pueda acceder a él un nodo.

Para ello, sigue estos pasos en ambos nodos:

  1. Como root, edita el archivo /etc/lvm/lvm.conf y modifica el valor system_id_source a uname desde none.

  2. Verifica los resultados:

    # grep -i system_id_source /etc/lvm/lvm.conf

    Deberías ver un resultado similar al siguiente:

    # Configuration option global/system_id_source.
        system_id_source = "uname"

  3. Además, para evitar que las VMs activen los VG administrados por el clúster cuando se reinicie un nodo, mantén el siguiente parámetro en el archivo de configuración /etc/lvm/lvm.conf con los nombres completos de los VG separados por comas que no administra el clúster.

    Por ejemplo, cuando usrsap es un nombre de VG que no administra el clúster:

    auto_activation_volume_list = [ usrsap ]

    Cuando no hay VG que no sean administrados por el clúster, por ejemplo, este parámetro se debe agregar con valores vacíos:

    auto_activation_volume_list = [  ]

Instala la base de datos y el agente de host de SAP

Ahora que tu sistema operativo está configurado, puedes instalar la base de datos SAP MaxDB y SAP Host Agent. Por lo general, MaxDB se instala con el producto SAP con el que está integrado.

Ten en cuenta que la instalación solo se realizará una vez, en la que hayas conectado el disco persistente regional.

Para instalar SAP MaxDB en tu VM, sigue estos pasos:

  1. Establece una conexión SSH a tu VM basada en Linux.
  2. Descarga SAP Software Provisioning Manager (SWPM), los medios de instalación del producto SAP y los medios de instalación de MaxDB de acuerdo con las guías de instalación de SAP.
  3. Instala tu producto SAP y la base de datos SAP MaxDB de acuerdo con las guías de instalación de SAP para tu producto. Para obtener más información, consulta la documentación de SAP MaxDB.

SAP proporciona información adicional sobre la instalación en la Nota 1020175 de SAP: Preguntas frecuentes: Instalación, actualización o aplicación de un parche en SAP MaxDB.

Una vez completada la instalación, ejecuta las siguientes validaciones:

  1. Como usuario de sidadm, verifica el estado de MaxDB.

    # dbmcli -d  SID -u control,password db_state

    Deberías ver un resultado similar al siguiente:

    >dbmcli -d  MDB -u control, my_p4$$w0rd db_state
OK
State
ONLINE

  2. Verifica también el estado de x_server:

    # x_server

    Deberías ver un resultado similar al siguiente:

    >x_server
2024-10-23 19:01:43 11968 19744 INF  12916          Found running XServer on port 7200
2024-10-23 19:01:43 11968 19744 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'
2024-10-23 19:01:43 11968 19744 INF  13010            installation MDB  - path: /sapdb/MDB/db
2024-10-23 19:01:45 11971 13344 INF  12916          Found running sdbgloballistener on port 7210
2024-10-23 19:01:45 11971 13344 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'

  3. Verifica si se está ejecutando el agente de host de SAP:

    # ps -ef | grep -i hostctrl

    Deberías ver un resultado similar al siguiente:

    >ps -ef | grep -i hostctrl
root      1543     1  0 Oct18 ?        00:00:15 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile
sapadm    1550     1  0 Oct18 ?        00:03:00 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
root      1618     1  0 Oct18 ?        00:03:48 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile
mdbadm   12751 11261  0 19:03 pts/0    00:00:00 grep --color=auto -i hostctrl

  4. Una vez que se verifique la instalación, detén la instancia de MaxDB y x_server.

    # dbmcli -d SID -u control, and password db_offline
# x_server stop

Realiza tareas posteriores a la instalación

Antes de usar tu instancia de SAP MaxDB te recomendamos que realices los siguientes pasos posteriores a la implementación:

  1. Actualiza el software SAP MaxDB con los parches más recientes, si están disponibles.
  2. Instala cualquier componente adicional.
  3. Configura y haz una copia de seguridad de la nueva base de datos de SAP MaxDB.

Para obtener más información, consulta Administración de la base de datos de SAP MaxDB.

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

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 MaxDB 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 MaxDB activo. El balanceador de cargas enruta el tráfico que se envía a la VIP a la VM que aloja el sistema SAP MaxDB 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 MaxDB. 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: '2024-10-23T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-maxdb-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-maxdb-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
maxdb-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
maxdb-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: '2023-10-23T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: maxdb-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/maxdb-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 MaxDB 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 MaxDB, consulta Balanceo de cargas de TCP/UDP interno.

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ía ver un resultado similar al siguiente:

    ---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-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/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-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/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-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/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-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

El siguiente procedimiento configura la implementación de Red Hat de un clúster de Pacemaker en las VMs de Compute Engine para SAP MaxDB.

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

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í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 2023-10-23 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
Oct 23 21:17:03 maxdb-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
Oct 23 21:17:05 maxdb-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

  7. Asegúrate de que todos los servicios de HA necesarios estén habilitados y en funcionamiento en ambos nodos.

    # systemctl enable pcsd.service pacemaker.service corosync.service

  8. 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 maxdb-ha-vm-1.us-central1-a.c.example-project-123456.internal maxdb-ha-vm-1  # Added by Google
10.0.0.41 maxdb-ha-vm-2.us-central1-c.c.example-project-123456.internal maxdb-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 para establecer un punto de partida más apropiado para probar la tolerancia a errores de tu clúster de HA en Google Cloud.

  1. En cualquier host, usa tu editor de texto preferido a fin de abrir el archivo /etc/corosync/corosync.conf para editarlo:

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

Configura la protección

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

A fin de garantizar 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 se protege una VM. 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, emite fence_gce -h.

Crea los recursos del dispositivo de protección

  1. En el host principal como raíz:

    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 \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"
# pcs stonith create secondary-fence-name fence_gce \
  port=secondary-host-name \
  zone=secondary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"

    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 secundaria del host y aparecerá detenida en la página Instancias de VM en la consola de Google Cloud . 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@maxdb-ha-vm-2 ~]# pcs status
Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-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 maxdb-ha-vm-1

2 nodes configured
2 resources configured

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

Full list of resources:

 STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
 STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

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

Establece una demora para el reinicio de Corosync

  1. En ambos 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

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

  1. Como raíz en ambos hosts, instala un objeto de escucha de TCP. 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 tcplog.

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

      #---------------------------------------------------------------------
# Health check listener port for SAP MaxDB 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 MaxDB 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 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.

  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.

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

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 op monitor interval=10s timeout=20s —-group SAPMaxDB_Group

  2. Confirma que el servicio de verificación de estado esté activo en el mismo host que tu instancia de SAP MaxDB:

    # pcs status

    Si el recurso de verificación de estado no está en el mismo host que MaxDB, 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-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
  rsc_healthcheck_MDB    (service:haproxy):      Started maxdb-ha-vm-1

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 en cualquiera de los hosts, establece los valores predeterminados de los recursos:

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

    # 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 tu propiedad con pcs property list.

Crea recursos de MaxDB en el clúster

Antes de realizar estos pasos, asegúrate de que MaxDB y x_server estén detenidos y de que el sistema de archivos /sapdb esté desconectado.

Crea el recurso gcp-pd-move

El recurso gcp-pd-move es un agente de recursos que se usa para mover el disco persistente de un nodo a otro durante una conmutación por error de clúster.

  1. Crea el recurso con el siguiente comando como raíz en cualquiera de los nodos:

    # pcs resource create pd_move_resource_name gcp-pd-move \
  disk_name=regional_pd_name mode="READ_WRITE" disk_scope=regional \
  op monitor interval=10s timeout=15s \
  op start interval=0s timeout=300s \
  op stop interval=0s timeout=15s \
  --group SAPMaxDB_Group

Crea un recurso de LVM

Se usa un agente de recursos activado por LVM para activar el LVM después de que el disco se mueva al otro nodo.

  1. Crea el recurso LVM con el siguiente comando como raíz en cualquiera de los nodos:

    # pcs resource create lvm_resource_name LVM-activate \
  vgname=vgname_for_maxdb \
  vg_access_mode=system_id activation_mode=exclusive \
  --group SAPMaxDB_Group

    Por ejemplo:

    # pcs resource create sapdb_lvm LVM-activate \
  vgname=sapdb vg_access_mode=system_id \
  activation_mode=exclusive \
  --group SAPMaxDB_Group

Crea el recurso del sistema de archivos

El recurso del sistema de archivos se usa en el clúster para desmontar /sapdb y montarlo en otro nodo durante la operación de conmutación por error.

  1. Crea el recurso del sistema de archivos con el siguiente comando como raíz en cualquiera de los nodos:

    # pcs resource create fs_resource_name Filesystem \
  device=filesystem directory=/sapdb fstype=fs_type \
  --group SAPMaxDB_Group

    Por ejemplo:

    # pcs resource create sapdb_FS Filesystem \
  device=/dev/mapper/sapdb-sapdblv directory=/sapdb fstype=ext4 \
  --group SAPMaxDB_Group

Preparación para el grupo de recursos de MaxDB

Para habilitar el grupo de recursos de MaxDB, debes seguir estos pasos.

  1. Sincroniza los usuarios y los grupos del nodo en el que realizaste la instalación de MaxDB con el otro nodo.

    1. Los usuarios de SAP MaxDB deben sincronizarse entre los nodos copiando las entradas en /etc/passwd, por ejemplo:

       sdb:x:1002:1003:MaxDB User:/home/sdb:/bin/false
 madbadm:x:1003:1005:SAP System Administrator:/home/mdbadm:/bin/csh

    2. Del mismo modo, los grupos de SAP también deben sincronizarse copiando las entradas de /etc/group de un nodo al otro, por ejemplo:

       dba:x:1003:mdbadm
 sapsys:x:1005:

  2. Sincroniza los archivos específicos de MaxDB que se almacenan en los directorios del sistema operativo. Como usuario raíz, ejecuta los siguientes comandos:

    # rsync -av /etc/services target_host:/etc/services
# rsync -av /home/* target_host:/home
# rsync -av --exclude=sapservices /usr/sap/* target_host:/usr/sap
# rsync -av --ignore-existing /usr/sap/sapservicestarget_host:/usr/sap/sapservices
# rsync -av /etc/init.d/sapinittarget_host:/etc/init.d/
     
    # MaxDB specific files
# rsync -av /etc/opttarget_host:/etc
# rsync -av /var/lib/sdbtarget_host:/var/lib

  3. Para los usuarios del SO SAP en el segundo nodo, cambia el nombre de los siguientes archivos de entorno para usar su respectivo nombre de host en sus directorios principales, por ejemplo:

    mv .sapenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .sapenv_maxdb-ha-vm-1.csh .sapenv_maxdb-ha-vm-2.csh
mv .sapsrc_maxdb-ha-vm-1.sh  .sapsrc_maxdb-ha-vm-2.sh
mv .sapsrc_maxdb-ha-vm-1.csh  .sapsrc_maxdb-ha-vm-2.csh
mv .dbenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .dbenv_maxdb-ha-vm-1.csh .dbenv_maxdb-ha-vm-2.csh

El agente de recursos SAPDatabase no usa ningún comando específico de la base de datos para detenerla o iniciarla, sino que se basa en los comandos saphostctrl para hacer lo mismo. SAP Host Agent requiere que se creen entradas xuser para supervisar y controlar correctamente MAXDB con saphostctrl. Consulta la Nota de SAP 2435938: SAP Host Agent SAP MaxDB: DBCredentials for DB connect para obtener más información.

  1. Como root, ejecuta el siguiente comando para SetDatabaseProperty en el nodo activo:

    /usr/sap/hostctrl/exe/saphostctrl -host primary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

    Prueba las entradas con el siguiente comando, incluso si la base de datos está detenida. El comando debería poder restablecer el estado:

    /usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -dbname SID \
  -dbtype ada -function GetDatabaseStatus

El comando del agente saphostctrl usa el programa xuser de la instalación de MaxDB y, por lo tanto, para preparar el segundo nodo ahora, moverás el SAPMaxDB_group a maxdb-node-b.

  1. En cualquier nodo, ejecuta el siguiente comando como root:

    pcs resource move SAPMaxDB_group

Observa que los cuatro recursos creados, la verificación de estado, gcp-pd-move, LVM y el sistema de archivos, ahora se migraron y se iniciaron correctamente en el segundo nodo.

  1. Puedes usar el siguiente comando en cualquier nodo para observar las acciones que se realizan:

    watch pcs status

Una vez que se inicien correctamente los cuatro recursos en el segundo nodo, ejecuta el comando saphostctrl.

  1. Como root, ejecuta el siguiente comando para SetDatabaseProperty en el nodo ahora activo:

    /usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

  2. En el nodo b, inicia MaxDB y x_server de forma manual para verificar si se pueden iniciar correctamente:

    # dbmcli -d SID -u control, and password db_online
# x_server start

Continúa con el siguiente paso para crear un recurso para la base de datos de SAP. Si se observan errores en este punto, no crees el recurso de base de datos.

Crea un recurso para SAP MaxDB

RHEL Pacemaker usa el agente de recursos de la base de datos de SAP para supervisar y controlar la base de datos de SAP.

  1. Crea el recurso de base de datos en el nodo en el que SAPMaxDB_group está activo con el siguiente comando:

    # pcs resource create SAPDatabase_resource_name SAPDatabase \
  DBTYPE="ADA" SID="SID" STRICT_MONITORING="TRUE" \
  MONITOR_SERVICES="Database|x_server" AUTOMATIC_RECOVER="TRUE"
  --group SAPMaxDB_Group

    Los recursos del clúster final se pueden ver con pcs status, y el resultado esperado es el siguiente:

    # pcs status
  Cluster name: maxdb-cluster
  Stack: corosync
  Current DC: maxdb-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Oct 23 02:04:32 2024
  Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmd on maxdb-ha-vm-1

  2 nodes configured
  7 resource instances configured

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

  Full list of resources:

  STONITH-maxdb-ha-vm-1  (stonith:fence_gce):    Started maxdb-ha-vm-2
  STONITH-maxdb-ha-vm-2  (stonith:fence_gce):    Started maxdb-ha-vm-1
  Resource Group: SAPMaxDB_Group
     healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-1
     sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-1
     lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-1
     sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-1
     MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-1

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

Prueba la conmutación por error

Simula una falla en el host activo 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:

  • Detén MaxDB o x_server de forma manual
  • Cómo finalizar el proceso de MaxDB o x_server
  • 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

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

  3. Ingresa pcs status para confirmar que el host que antes era pasivo ahora tiene el disco persistente regional conectado y ejecuta los servicios de MaxDB. 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 pasivo, como se muestra en el siguiente ejemplo:

    Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-2 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
Last updated: Wed Oct 23 02:01:45 2024
Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmdon maxdb-ha-vm-2

2 nodes configured
7 resources configured

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

Full list of resources:

STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
 healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-2
 sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-2
 lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-2
 sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-2
 MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-2

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

Solucionar problemas

Para solucionar problemas de configuraciones de alta disponibilidad para sistemas SAP 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.