Configuración de Pacemaker en Red Hat Enterprise Linux en Azure

  • Artículo

En este artículo se describe cómo configurar un clúster básico de Pacemaker en Red Hat Enterprise Server (RHEL). Las instrucciones cubren RHEL 7, RHEL 8 y RHEL 9.

Requisitos previos

Lea primero las notas y los documentos de SAP siguientes:

Instalación del clúster

Diagram that shows an overview of Pacemaker on RHEL.

Nota:

Red Hat no admite un guardián emulado por software. Red Hat no es compatible con SBD en plataformas en la nube. Para obtener más información, consulte Directivas de soporte técnico para clústeres de alta disponibilidad de RHEL: sbd y fence_sbd.

El único mecanismo de barrera admitido para los clústeres de RHEL de Pacemaker en Azure es un agente de barrera de Azure.

Los siguientes elementos llevan delante:

  • [A] : Aplicable a todos los nodos
  • [1]: solo aplicable al nodo 1
  • [2]: solo aplicable al nodo 2

Las diferencias en los comandos o la configuración entre RHEL 7 y RHEL 8/RHEL 9 se marcan en el documento.

  1. [A] Registro. Este paso es opcional. Si usa imágenes habilitadas para alta disponibilidad de SAP de RHEL, este paso no es necesario.

    Por ejemplo, si va a implementar en RHEL 7, registre la máquina virtual y conéctela a un grupo que contenga repositorios para RHEL 7.

    sudo subscription-manager register
# List the available pools
sudo subscription-manager list --available --matches '*SAP*'
sudo subscription-manager attach --pool=<pool id>

    Al adjuntar un grupo a una imagen de RHEL de pago por uso de Azure Marketplace, se le factura de forma eficaz el uso de RHEL. Se le factura una vez por la imagen de pago por uso y una vez por el derecho de RHEL en el grupo que adjunte. Para mitigar esta situación, Azure ahora proporciona imágenes de RHEL bring-your-own-subscription. Para más información, consulte Imágenes Gold de tipo "Bring-your-own-subscription" (BYOS) de Red Hat Enterprise Linux en Azure.

  2. [A] Habilitación de RHEL para los repositorios SAP. Este paso es opcional. Si usa imágenes habilitadas para alta disponibilidad de SAP de RHEL, este paso no es necesario.

    Para instalar los paquetes necesarios en RHEL 7, habilite los repositorios siguientes:

    sudo subscription-manager repos --disable "*"
sudo subscription-manager repos --enable=rhel-7-server-rpms
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
sudo subscription-manager repos --enable=rhel-sap-for-rhel-7-server-rpms
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-eus-rpms

  3. [A] Instale el complemento de alta disponibilidad de RHEL.

     sudo yum install -y pcs pacemaker fence-agents-azure-arm nmap-ncat

    Importante

    Se recomiendan las siguientes versiones del agente de barrera de Azure (o posterior) para que los clientes se beneficien de un tiempo de conmutación por error más rápido, si se produce un error en una detención de recursos o los nodos del clúster ya no se pueden comunicar entre sí:

    RHEL 7.7 o superior usan la versión más reciente disponible del paquete de agentes de barrera.

    RHEL 7.6: fence-agents-4.2.1-11.el7_6.8

    RHEL 7.5: fence-agents-4.0.11-86.el7_5.8

    RHEL 7.4: fence-agents-4.0.11-66.el7_4.12

    Para más información, consulte La máquina virtual de Azure que se ejecuta como miembro del clúster de alta disponibilidad de RHEL tarda mucho tiempo en estar cercada o se produce un error o se agota el tiempo de espera antes de que se cierre la máquina virtual.

    Importante

    Se recomiendan las siguientes versiones del agente de barrera de Azure (o posterior) para los clientes que quieran usar identidades administradas para recursos de Azure en lugar de nombres de entidad de seguridad de servicio para el agente de barrera:

    RHEL 8.4: fence-agents-4.2.1-54.el8.

    RHEL 8.2: fence-agents-4.2.1-41.el8_2.4

    RHEL 8.1: fence-agents-4.2.1-30.el8_1.4

    RHEL 7.9: fence-agents-4.2.1-41.el7_9.4.

    Importante

    En RHEL 9, se recomiendan las siguientes versiones de paquete (o posteriores) para evitar problemas con el agente de barrera de Azure:

    fence-agents-4.10.0-20.el9_0.7

    fence-agents-common-4.10.0-20.el9_0.6

    ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm

    Compruebe la versión del agente de delimitación de Azure. Si es necesario, actualícelo a la versión mínima necesaria o posterior.

    # Check the version of the Azure Fence Agent
 sudo yum info fence-agents-azure-arm

    Importante

    Si necesita actualizar el agente de barrera de Azure y, si usa un rol personalizado, asegúrese de actualizar el rol personalizado para incluir la acción powerOff. Para obtener más información, consulte Creación de un rol personalizado para el agente de barrera.

  4. Si va a implementar en RHEL 9, instale también los agentes de recursos para la implementación en la nube.

    sudo yum install -y resource-agents-cloud

  5. [A] Configure la resolución de nombres de host.

    Puede usar un servidor DNS o modificar el archivo /etc/hosts en todos los nodos. En este ejemplo se muestra cómo utilizar el archivo /etc/hosts. Reemplace la dirección IP y el nombre de host en los siguientes comandos.

    Importante

    Si usa nombres de host en la configuración del clúster, es fundamental tener una resolución confiable de nombres de host. Se produce un error en la comunicación del clúster si los nombres no están disponibles, lo que puede provocar retrasos en la conmutación por error del clúster.

    La ventaja de usar /etc/hosts es que el clúster se convierte en independiente de DNS, lo que podría ser también un único punto de errores.

    sudo vi /etc/hosts

    Inserte las líneas siguientes en /etc/hosts. Cambie la dirección IP y el nombre de host para que coincidan con su entorno.

    # IP address of the first cluster node
10.0.0.6 prod-cl1-0
# IP address of the second cluster node
10.0.0.7 prod-cl1-1

  6. [A] Cambie la hacluster contraseña a la misma contraseña.

    sudo passwd hacluster

  7. [A] Agregue reglas de firewall para Pacemaker.

    Agregue las siguientes reglas de firewall para todas las comunicaciones entre los nodos del clúster.

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

  8. [A] Habilite los servicios de clúster básicos.

    Ejecute los comandos siguientes para habilitar el servicio de Pacemaker e inícielo.

    sudo systemctl start pcsd.service
sudo systemctl enable pcsd.service

  9. [1] Cree un clúster de Pacemaker.

    Ejecute los comandos siguientes para autenticar los nodos y crear el clúster. Establezca el token en 30000 para permitir el mantenimiento de conservación de memoria. Para más información, consulte este artículo para Linux.

    Si va a compilar un clúster en RHEL 7.x, use los siguientes comandos:

    sudo pcs cluster auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup --name nw1-azr prod-cl1-0 prod-cl1-1 --token 30000
sudo pcs cluster start --all

    Si va a compilar un clúster en RHEL 8.x/RHEL 9.x, use los siguientes comandos:

    sudo pcs host auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup nw1-azr prod-cl1-0 prod-cl1-1 totem token=30000
sudo pcs cluster start --all

    Para comprobar el estado del clúster, ejecute el comando siguiente:

    # Run the following command until the status of both nodes is online
sudo pcs status

# Cluster name: nw1-azr
# WARNING: no stonith devices and stonith-enabled is not false
# Stack: corosync
# Current DC: prod-cl1-1 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
# Last updated: Fri Aug 17 09:18:24 2018
# Last change: Fri Aug 17 09:17:46 2018 by hacluster via crmd on prod-cl1-1
#
# 2 nodes configured
# 0 resources configured
#
# Online: [ prod-cl1-0 prod-cl1-1 ]
#
# No resources
#
# Daemon Status:
#   corosync: active/disabled
#   pacemaker: active/disabled
#   pcsd: active/enabled

  10. [A] Establezca los votos esperados.

    # Check the quorum votes 
pcs quorum status

# If the quorum votes are not set to 2, execute the next command
sudo pcs quorum expected-votes 2

    Sugerencia

    Si va a crear un clúster de varios nodos, es decir, un clúster con más de dos nodos, no establezca los votos en 2.

  11. [1] Permitir acciones simultáneas de barrera.

    sudo pcs property set concurrent-fencing=true

Creación de un dispositivo de barrera

El dispositivo de barrera usa una identidad administrada para un recurso de Azure o una entidad de servicio para autorizarla en Azure.

Para crear una identidad administrada (MSI), cree una identidad administrada asignada por el sistema para cada máquina virtual del clúster. Si ya existe una identidad administrada asignada por el sistema, se usa. No use identidades administradas asignadas por el usuario con Pacemaker en este momento. Un dispositivo de barrera, basado en la identidad administrada, se admite en RHEL 7.9 y RHEL 8.x/RHEL 9.x.

[1] Creación de un rol personalizado para el agente de barrera

La identidad administrada y la entidad de servicio no tienen permisos para acceder a los recursos de Azure de forma predeterminada. Debe conceder a la identidad administrada o a la entidad de servicio permisos para iniciar y detener (apagar) todas las máquinas virtuales del clúster. Si aún no ha creado el rol personalizado, puede crearlo mediante PowerShell o la CLI de Azure.

Utilice el siguiente contenido para el archivo de entrada. Debe adaptar el contenido a las suscripciones, es decir, reemplazar y yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy por xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx los identificadores de la suscripción. Si solo tiene una suscripción, quite la segunda entrada en AssignableScopes.

{
      "Name": "Linux Fence Agent Role",
      "description": "Allows to power-off and start virtual machines",
      "assignableScopes": [
              "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
              "/subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
      ],
      "actions": [
              "Microsoft.Compute/*/read",
              "Microsoft.Compute/virtualMachines/powerOff/action",
              "Microsoft.Compute/virtualMachines/start/action"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
}

[A] Asignación del rol personalizado

Use la identidad administrada o la entidad de servicio.

Asigne el rol Linux Fence Agent Role personalizado que se creó en la última sección a cada identidad administrada de las máquinas virtuales del clúster. Cada identidad administrada asignada por el sistema de la máquina virtual necesita el rol asignado para cada recurso de máquina virtual del clúster. Para más información, consulte Asignación de acceso de una identidad administrada a un recurso mediante Azure Portal. Compruebe que la asignación de roles de identidad administrada de cada máquina virtual contiene todas las máquinas virtuales del clúster.

Importante

Tenga en cuenta que la asignación y eliminación de la autorización con identidades administradas se puede retrasar hasta que sea efectiva.

[1] Creación de los dispositivos de barrera

Después de editar los permisos de las máquinas virtuales, puede configurar los dispositivos de barrera en el clúster.

sudo pcs property set stonith-timeout=900

Nota:

La opción pcmk_host_map solo es necesaria en el comando si los nombres de host de RHEL y los nombres de máquina virtual de Azure no son idénticos. Especifique la asignación en el formato hostname:nombre-VM. Consulte la sección en negrita en el comando. Para obtener más información, consulte ¿Qué formato debo usar para especificar asignaciones de nodos a dispositivos de barrera en pcmk_host_map?.

Para configurar el dispositivo de barrera en RHEL 7.X, use el comando siguiente:

sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \ 
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

Para RHEL 8.x/9.x, use el siguiente comando para configurar el dispositivo de barrera:

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
op monitor interval=3600

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

Si usa un dispositivo de barrera basado en la configuración de la entidad de servicio, lea Cambio de SPN a MSI para clústeres de Pacemaker mediante el uso de barreras de Azure y aprenda a convertir a la configuración de identidad administrada.

Sugerencia

  • Para evitar carreras de barrera dentro de un clúster de pacemaker de dos nodos, puede configurar la priority-fencing-delay propiedad del clúster. Esta propiedad introduce un retraso adicional en la limitación de un nodo que tiene una prioridad de recurso total mayor cuando se produce un escenario de cerebro dividido. Para más información, consulte ¿Puede Pacemaker cercar el nodo de clúster con los recursos en ejecución más pequeños?.
  • La propiedad priority-fencing-delay es aplicable a Pacemaker versión 2.0.4-6.el8 o posterior y en un clúster de dos nodos. Si configura la priority-fencing-delay propiedad de clúster, no es necesario establecer la pcmk_delay_max propiedad . Pero si la versión de Pacemaker es menor que 2.0.4-6.el8, debe establecer la pcmk_delay_max propiedad .
  • Para obtener instrucciones sobre cómo establecer la priority-fencing-delay propiedad del clúster, consulte los documentos de alta disponibilidad de escalado vertical de SAP ASCS/ERS y SAP HANA correspondientes.

Las operaciones de supervisión y barrera se deserializan. Como resultado, si hay una operación de supervisión de ejecución más larga y un evento de barrera simultánea, no hay ningún retraso en la conmutación por error del clúster porque la operación de supervisión ya se está ejecutando.

[1] Habilite el uso de un dispositivo de barrera

sudo pcs property set stonith-enabled=true

Sugerencia

El agente de barrera de Azure requiere conectividad saliente a puntos de conexión públicos. Para más información junto con las posibles soluciones, consulte Conectividad de punto de conexión público para máquinas virtuales que usan ILB estándar.

Configuración de Pacemaker para eventos programados de Azure

Azure ofrece eventos programados. Los eventos programados se envían a través del servicio de metadatos y permiten que la aplicación se prepare para dichos eventos.

El agente azure-events-az de recursos de Pacemaker supervisa los eventos programados de Azure. Si se detectan eventos y el agente de recursos determina que hay otro nodo de clúster disponible, establece un atributo de mantenimiento del clúster.

Cuando se establece el atributo de mantenimiento del clúster para un nodo, la restricción de ubicación se desencadena y todos los recursos con nombres que no empiezan por health- se migran del nodo con el evento programado. Después de que el nodo de clúster afectado esté libre de ejecutar recursos de clúster, el evento programado se confirma y puede ejecutar su acción, como un reinicio.

  1. [A] Asegúrese de que el paquete del azure-events-az agente ya está instalado y actualizado.

    RHEL 8.x: sudo dnf info resource-agents
RHEL 9.x: sudo dnf info resource-agents-cloud

    Requisitos mínimos de versión:

    • RHEL 8.4: resource-agents-4.1.1-90.13
    • RHEL 8.6: resource-agents-4.9.0-16.9
    • RHEL 8.8: resource-agents-4.9.0-40.1
    • RHEL 9.0: resource-agents-cloud-4.10.0-9.6
    • RHEL 9.2 y versiones posteriores: resource-agents-cloud-4.10.0-34.1

  2. [1] Configure los recursos en Pacemaker.

    #Place the cluster in maintenance mode
sudo pcs property set maintenance-mode=true

  3. [1] Establezca la estrategia y la restricción del nodo de mantenimiento del clúster de Pacemaker.

    sudo pcs property set node-health-strategy=custom
sudo pcs constraint location 'regexp%!health-.*' \
rule score-attribute='#health-azure' \
defined '#uname'

    Importante

    No defina ningún otro recurso del clúster a health- partir de los recursos descritos en los pasos siguientes.

  4. [1] Establezca el valor inicial de los atributos del clúster. Ejecute para cada nodo de clúster y para entornos de escalado horizontal, incluida la máquina virtual creadora de mayoría.

    sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0
sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0

  5. [1] Configure los recursos en Pacemaker. Asegúrese de que los recursos comienzan por health-azure.

    sudo pcs resource create health-azure-events \
ocf:heartbeat:azure-events-az op monitor interval=10s
sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true

  6. Sacar el clúster de Pacemaker fuera del modo de mantenimiento.

    sudo pcs property set maintenance-mode=false

  7. Borre los errores durante la habilitación y compruebe que los health-azure-events recursos se han iniciado correctamente en todos los nodos del clúster.

    sudo pcs resource cleanup

    La primera vez que la ejecución de consultas para eventos programados puede tardar hasta dos minutos. Las pruebas de Pacemaker con eventos programados pueden usar acciones de reinicio o reimplementación para las máquinas virtuales del clúster. Para obtener más información, consulte Eventos programados.

Configuración de barreras opcionales

Sugerencia

Esta sección solo es aplicable si desea configurar el dispositivo fence_kdumpde barrera especial .

Si necesita recopilar información de diagnóstico dentro de la máquina virtual, puede resultar útil configurar otro dispositivo de barrera en función del agente fence_kdumpde barrera. El fence_kdump agente puede detectar que un nodo entró en la recuperación de bloqueos de kdump y puede permitir que se complete el servicio de recuperación de bloqueos antes de que se invoquen otros métodos de barrera. Tenga en cuenta que fence_kdump no es un reemplazo de los mecanismos de barrera tradicionales, como el agente de barrera de Azure, cuando se usan máquinas virtuales de Azure.

Importante

Tenga en cuenta que cuando fence_kdump se configura como un dispositivo de barrera de primer nivel, presenta retrasos en las operaciones de barrera y, respectivamente, retrasos en la conmutación por error de los recursos de la aplicación.

Si se detecta correctamente un volcado de memoria, la barrera se retrasa hasta que se completa el servicio de recuperación de bloqueos. Si el nodo con error no es accesible o si no responde, la barrera se retrasa por tiempo determinado, el número configurado de iteraciones y el fence_kdump tiempo de espera. Para más información, consulte Cómo configuración de fence_kdump en un clúster de Red Hat Pacemaker.

Es posible que sea necesario adaptar el tiempo de espera propuesto fence_kdump al entorno específico.

Se recomienda configurar fence_kdump la barrera solo cuando sea necesario para recopilar diagnósticos dentro de la máquina virtual y siempre en combinación con métodos de barrera tradicionales, como el agente de barrera de Azure.

Los siguientes artículos de Kb de Red Hat contienen información importante sobre la configuración de fence_kdump barreras:

Ejecute los siguientes pasos opcionales para agregar fence_kdump como una configuración de barrera de primer nivel, además de la configuración del agente de barrera de Azure.

  1. [A] Compruebe que kdump está activo y configurado.

    systemctl is-active kdump
# Expected result
# active

  2. [A] Instale el agente de barrera fence_kdump.

    yum install fence-agents-kdump

  3. [1] Cree un fence_kdump dispositivo de barrera en el clúster.

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30

  4. [1] Configure los niveles de barrera para que el fence_kdump mecanismo de barrera se active primero.

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1"
pcs stonith level add 1 prod-cl1-0 rsc_st_kdump
pcs stonith level add 1 prod-cl1-1 rsc_st_kdump
pcs stonith level add 2 prod-cl1-0 rsc_st_azure
pcs stonith level add 2 prod-cl1-1 rsc_st_azure

# Check the fencing level configuration 
pcs stonith level
# Example output
# Target: prod-cl1-0
# Level 1 - rsc_st_kdump
# Level 2 - rsc_st_azure
# Target: prod-cl1-1
# Level 1 - rsc_st_kdump
# Level 2 - rsc_st_azure

  5. [A] Permita los puertos necesarios para fence_kdump a través del firewall.

    firewall-cmd --add-port=7410/udp
firewall-cmd --add-port=7410/udp --permanent

  6. [A] Asegúrese de que el initramfs archivo de imagen contiene los fence_kdump archivos y hosts . Para más información, consulte Cómo configuración de fence_kdump en un clúster de Red Hat Pacemaker.

    lsinitrd /boot/initramfs-$(uname -r)kdump.img | egrep "fence|hosts"
# Example output 
# -rw-r--r--   1 root     root          208 Jun  7 21:42 etc/hosts
# -rwxr-xr-x   1 root     root        15560 Jun 17 14:59 usr/libexec/fence_kdump_send

  7. [A] Realice la fence_kdump_nodes configuración en /etc/kdump.conf para evitar que fence_kdump se produzca un error con un tiempo de espera para algunas kexec-tools versiones. Para obtener más información, consulte fence_kdump tiempos de espera cuando no se especifica fence_kdump_nodes con kexec-tools versión 2.0.15 o posterior y fence_kdump produce un error en "tiempo de espera después de X segundos" en un clúster de alta disponibilidad de RHEL 6 o 7 con versiones anteriores a 2.0.14. Aquí se presenta la configuración de ejemplo de un clúster de dos nodos. Después de realizar un cambio en /etc/kdump.conf, la imagen kdump debe volver a generarse. Para volver a generarlo, reinicie el kdump servicio.

    vi /etc/kdump.conf
# On node prod-cl1-0 make sure the following line is added
fence_kdump_nodes  prod-cl1-1
# On node prod-cl1-1 make sure the following line is added
fence_kdump_nodes  prod-cl1-0

# Restart the service on each node
systemctl restart kdump

  8. Pruebe la configuración bloqueando un nodo. Para más información, consulte Cómo configuración de fence_kdump en un clúster de Red Hat Pacemaker.

    Importante

    Si el clúster ya está en uso productivo, planee la prueba en consecuencia porque bloquear un nodo tiene un impacto en la aplicación.

    echo c > /proc/sysrq-trigger

Pasos siguientes