ha-cluster-pacemaker

Rol para configurar y expandir un clúster básico de Pacemaker en sistemas CentOS/RHEL 6/7/8/9, AlmaLinux 8/9, Rocky Linux 8/9, Fedora 31/32/33/34/35/36/37/38/39/40 y CentOS 8/9 Stream.

Este rol puede configurar los siguientes aspectos de un clúster de Pacemaker:

• habilitar los repositorios del sistema necesarios
• instalar los paquetes necesarios
• crear y configurar usuarios y grupos para ejecutar el clúster de Pacemaker
• configurar el firewall
• generar elementos en /etc/hosts
• autorizar nodos del clúster
• crear o expandir el clúster (ver allow_cluster_expansion)
  • clúster de "2 o más" nodos
  • un único heartbeat, rrp o knet con hasta 8 enlaces
  • nodos remotos
  • usar interfaces/IPs autodetectadas o seleccionadas de forma personalizada para el heartbeat
• iniciar y habilitar el clúster en el arranque
• configurar dispositivos stonith
  • por defecto, instalar y configurar dispositivos stonith fence_xvm
  • opción de configurar fence_kdump
  • opción de configurar fence_vmware (SOAP/REST) u otros dispositivos fence_* stonith
  • opción de configurar fence_aws

El rol soporta completamente el modo --check para la configuración por defecto y parcialmente para la mayoría de otras opciones.

Al reportar problemas, por favor proporciona la siguiente información (si es posible):

• versión de Ansible utilizada
• sistema operativo desde el que se ejecutó Ansible
• playbook y archivo de inventario que produjeron el error (elimina información sensible donde sea apropiado)
• mensaje de error o descripción del comportamiento no esperado que has encontrado

Requisitos

Este rol depende del rol ondrejhome.pcs-modules-2.

Ansible 2.8 o superior. (NOTA: puede ser posible usar versiones anteriores, si hay problemas intenta actualizar Ansible a 2.8 o más)

RHEL 6/7/8: Se espera que las máquinas ya estén registradas. Por defecto, el rol habilitará el acceso al canal 'Alta Disponibilidad' o 'Almacenamiento Resiliente'. Si esto no es deseado, revisa la variable enable_repos.

RHEL/CentOS 7: Este rol requiere al menos la versión 2.9 de la biblioteca python-jinja2. Si no está presente, puedes encontrar un error descrito en el Problema #6. Para obtener la versión actualizada de python-jinja2 y sus dependencias, puedes usar el siguiente repositorio RPM - https://copr.fedorainfracloud.org/coprs/ondrejhome/ansible-deps-el7/ para CentOS 7 y RHEL 7.

CentOS 8 Stream Probado con la versión 20240129, la versión mínima recomendada de Ansible es 2.11.0, que comienza a identificar el sistema como 'CentOS' en lugar de 'RedHat' (a diferencia de CentOS Linux). Las versiones más antiguas de CentOS 8 Stream 20201211 tienen como versión mínima utilizable de Ansible 2.9.16/2.10.4. La versión 2.8.18 no funcionó en el momento de la prueba. Esto está relacionado con El servicio está en estado desconocido #71528.

CentOS 9 Stream Probado con la versión 20240129, la mínima recomendada de Ansible es 2.11.0.

Debian Buster Probado con la versión 20210310 con Ansible versión 2.10 y Debian Bullseye probada con la versión 20220326 con Ansible versión 2.12. La parte de Debian de este rol no incluye la configuración de stonith ni la configuración del firewall. Nota: Este rol fue probado solo de manera limitada en Debian; no todas las características de este rol fueron probadas.

Debian Bookworm Probado con Ansible versión 2.14 y Debian Bookworm. La parte de Debian de este rol no incluye la configuración de stonith ni la configuración del firewall. Nota: Este rol fue probado solo de manera limitada en Debian; no todas las características de este rol fueron probadas.

La versión de Ansible 2.9.10 y 2.9.11 fallará con el error "'hostvars' is undefined" al intentar configurar nodos remotos. Esto se aplica solo cuando hay al menos un nodo con cluster_node_is_remote=True. Evita estas versiones de Ansible si planeas configurar nodos remotos con este rol.

En CentOS Linux 8 debes asegurarte de que los repositorios BaseOS y Appstream funcionen correctamente. Dado que CentOS Linux 8 está en la fase de Fin de Vida, este rol configurará el repositorio HA para apuntar a vault.centos.org si se solicita la configuración del repositorio (enable_repos: true, que es por defecto).

Las distribuciones de pcs-0.11 (AlmaLinux 9, Rocky Linux 9, RHEL 9, Fedora 36/37/38) son compatibles solo con ondrejhome.pcs-modules-2 versión 27.0.0 o superior.

Variables del rol

• usuario utilizado para autorizar nodos del clúster

  cluster_user: 'hacluster'
  

• contraseña para el usuario utilizado para autorizar nodos del clúster

  cluster_user_pass: 'testtest'
  

• grupo al que pertenece el usuario del clúster (debería ser 'haclient')

  cluster_group: 'haclient'
  

• nombre del clúster

  cluster_name: 'pacemaker'
  

• configuración del firewall para el clúster, NOTA: en RHEL/CentOS 6 esto reemplaza el archivo de configuración de iptables!

  cluster_firewall: true
  

• habilitar el clúster en el arranque en nodos normales (no pacemaker_remote)

  cluster_enable_service: true
  

• ¿Configurar el clúster con el dispositivo de fencing fence_xvm? Esto copiará /etc/cluster/fence_xvm.key a los nodos y añadirá dispositivos de fencing al clúster. NOTA: necesitas definir 'vm_name' en el inventario para cada nodo del clúster.

  cluster_configure_fence_xvm: true
  

• ¿Configurar el clúster con el dispositivo de fencing fence_vmware_soap/fence_vmware_rest? Esto instalará el agente de fencing fence_vmware_soap/fence_vmware_rest y lo configurará. Cuando esto esté habilitado, debes especificar 3 variables adicionales con información sobre cómo acceder al vCenter. NOTA: También necesitas definir 'vm_name' en el inventario para cada nodo del clúster especificando el nombre o UUID de la VM como se ve en el hipervisor o en la salida del comando fence_vmware_soap -o list/fence_vmware_rest.

  cluster_configure_fence_vmware_soap: false
  cluster_configure_fence_vmware_rest: false
  fence_vmware_ipaddr: ''
  fence_vmware_login: ''
  fence_vmware_passwd: ''
  

  Puedes cambiar opcionalmente los atributos adicionales pasados a fence_vmware_soap/fence_vmware_rest utilizando la variable fence_vmware_options. Por defecto, esta variable habilita la encriptación pero deshabilita la validación de certificados.

  fence_vmware_options: 'ssl="1" ssl_insecure="1"'
  

  NOTA: Solo uno de fence_vmware_soap/fence_vmware_rest puede ser configurado, ya que los dispositivos stonith comparten el mismo nombre.

• ¿Configurar el clúster con el dispositivo de fencing fence_kdump? Esto inicia el servicio kdump y define los dispositivos stonith fence_kdump. NOTA: si el servicio kdump no se inicia, esto no funcionará correctamente o en absoluto.

  cluster_configure_fence_kdump: false
  

• ¿Configurar el clúster con el dispositivo de fencing fence_aws? Debes proporcionar el ID de la instancia/región de AWS y el Perfil de Instancia que pueda iniciar/detener instancias para este clúster. Cuando esto esté habilitado, debes especificar la variable fence_aws_region con información sobre la región de AWS. NOTA: Si no configuras el perfil de instancia, no funcionará correctamente o en absoluto.

  cluster_configure_fence_aws: false
  fence_aws_region: ''
  

  NOTA: También necesitas definir instance_id en el inventario para cada nodo del clúster especificando el ID de la instancia como se ve en la consola web de AWS o en la salida del comando fence_aws -o list. (man fence_aws)

  Puedes cambiar opcionalmente los atributos adicionales pasados a fence_aws utilizando la variable fence_aws_options.

  fence_aws_options: ''
  

• ¿Cómo mapear dispositivos de fencing a nodos del clúster? Por defecto, para cada nodo del clúster se crea un dispositivo stonith separado ('uno-dispositivo-por-nodo'). Algunos agentes de fencing pueden emplear múltiples nodos utilizando el mismo dispositivo stonith ('uno-dispositivo-por-clúster') y pueden tener problemas al usar múltiples dispositivos debido a los límites de cuenta de usuario iguales.

  Opciones disponibles:

  • one-device-per-node - (por defecto) - se crea un dispositivo stonith por nodo del clúster
  • one-device-per-cluster - (en agentes de fencing soportados) - solo se crea un dispositivo stonith para todo el clúster, agentes de fencing soportados: fence_vmware_rest, fence_vmware_soap, fence_xvm, fence_kdump

  cluster_configure_stonith_style: 'one-device-per-node'
  

• (RHEL/CentOS/AlmaLinux/Rocky) habilitar los repositorios que contienen los paquetes necesarios

  enable_repos: true
  

• (Solo RHEL) habilitar los repositorios de actualización extendida (EUS) que contienen los paquetes necesarios

  enable_eus_repos: false
  

• (Solo RHEL) habilitar los repositorios de servicio de actualización de SAP Solutions (E4S) que contienen los paquetes necesarios

  enable_e4s_repos: false
  

• (Solo RHEL) habilitar los repositorios Beta que contienen los paquetes necesarios

  enable_beta_repos: false
  

• (Solo RHEL) tipo de repositorios habilitados, ten en cuenta que los repos E4S solo tienen disponible el tipo 'ha'

  • ha - Alta Disponibilidad
  • rs - Almacenamiento Resiliente

  repos_type: 'ha'
  

• (Solo RHEL) custom_repository permite habilitar un repositorio con un nombre arbitrario. Nombres de repositorios de RHEL8 se pueden encontrar en http://downloads.redhat.com/redhat/rhel/rhel-8-beta/rhel-8-beta.repo

  custom_repository: ''
  

• (Solo CentOS) instalar los paquetes necesarios desde el CD-ROM disponible en /dev/cdrom

  use_local_media: false
  

• Habilitar o deshabilitar la interfaz gráfica web de PCSD. Por defecto, el rol mantiene la instalación predeterminada, lo que significa que la interfaz gráfica web de PCSD está deshabilitada en CentOS/RHEL 6.X y habilitada en CentOS/RHEL 7.X. Se puede pasar true o false a esta variable para asegurarse de que la interfaz gráfica web de PCSD esté habilitada o deshabilitada.

  enable_pcsd_gui: 'nochange'
  

• Protocolo de transporte del clúster. Por defecto, este rol utilizará lo que sea predeterminado para el sistema operativo correspondiente. Para CentOS/RHEL 6.X esto significa 'udp' (multicast UDP) y para CentOS/RHEL 7.X esto significa 'udpu' (unicast UDP). Esta variable acepta las siguientes opciones: default, udp y udpu.

  cluster_transport: 'default'
  

• Permitir añadir nodos a un clúster existente cuando se utiliza con ondrejhome.pcs-modules-2 v16 o superior.

  allow_cluster_expansion: false
  

• Interfaz de red del clúster. Si se especifica, el rol mapeará hosts a la dirección IPv4 principal de esta interfaz. Por defecto se utiliza la dirección IPv4 de ansible_default_ipv4 o la primera IPv4 de ansible_all_ipv4_addresses. Por ejemplo, para usar la dirección IPv4 principal de la interfaz ens8, se usa cluster_net_iface: 'ens8'. La interfaz debe existir en todos los nodos del clúster.

  cluster_net_iface: ''
  

• Interfaz de red redundante. Si se especifica, el rol configurará un anillo redundante de corosync utilizando la IPv4 predeterminada de esta interfaz. La interfaz debe existir en todos los nodos del clúster.

    rrp_interface: ''
  

  NOTA: puedes definir esta variable ya sea en defaults/main.yml, en este caso se usa el mismo nombre de rrp_interface para todos los hosts en el archivo de hosts. O bien puedes especificar una interfaz para cada host presente en el archivo de hosts: esto permite usar un nombre de interfaz específico para cada host (en el caso de que no tengan el mismo nombre de interfaz). También ten en cuenta que en lugar de definir rrp_interface para un host, puedes definir rrp_ip: en este caso se usa esta IP alternativa para configurar RRP de corosync (esta IP debe ser diferente a la dirección IPv4 predeterminada del host). Esto permite usar una IP alternativa que pertenezca a la misma interfaz principal.

• Si agregar hosts a /etc/hosts. Por defecto se añade una entrada para el nombre de host dado por cluster_hostname_fact en cada host a /etc/hosts. Esto se puede deshabilitar estableciendo cluster_etc_hosts en false.

  cluster_etc_hosts: true
  

• Qué hecho de Ansible utilizar como nombre de host de los nodos del clúster. Por defecto, este rol utiliza el hecho ansible_hostname como el nombre de host de cada host. En algunos entornos puede ser útil usar el Nombre de Dominio Calificado (FQDN) ansible_fqdn o el nombre del nodo ansible_nodename.

  cluster_hostname_fact: "ansible_hostname"
  

• Si el nodo debe configurarse como un nodo remoto de Pacemaker. Por defecto, esto es false, y el nodo será un miembro completo del clúster de Pacemaker. Los nodos remotos de Pacemaker no son miembros completos del clúster y permiten exceder el tamaño máximo del clúster de 32 miembros completos. Ten en cuenta que los nodos remotos son soportados por este rol solo en EL7 y EL8.

  cluster_node_is_remote: false
  

• Lista ordenada de variables para detectar la IP principal del clúster (ring0). La primera IPv4 encontrada se usa y las demás IPv4 detectadas se ignoran. En la mayoría de los casos esto no requerirá cambios, en algunos casos especiales, como cuando no hay GW predeterminado o se debe usar una IPv4 no principal de la interfaz dada, esto se puede ajustar.

  ring0_ip_ordered_detection_list:
    - "{{ hostvars[inventory_hostname]['ansible_'+cluster_net_iface].ipv4.address|default('') }}"
    - "{{ ansible_default_ipv4.address|default('') }}"
    - "{{ ansible_all_ipv4_addresses[0]|default('') }}"
  

• Configurar propiedades del clúster (No es obligatorio)

  cluster_property:
    - name: required
      node: optional
      value: optional
  

• Configurar valores predeterminados de recursos del clúster (No es obligatorio)

  cluster_resource_defaults:
    - name: required
      defaults_type: optional
      value: optional
  

• Configurar recursos del clúster (No es obligatorio)

  cluster_resource:
    - name: required
      resource_class: optional
      resource_type: optional
      options: optional
      force_resource_update: optional
      ignored_meta_attributes: optional
      child_name: optional
  

• Configurar restricciones de orden del clúster (No es obligatorio)

  cluster_constraint_order:
    - resource1: required
      resource1_action: optional
      resource2: required
      resource2_action: optional
      kind: optional
      symmetrical: optional
  

• Configurar restricciones de colocación del clúster (No es obligatorio)

  cluster_constraint_colocation:
    - resource1: required
      resource1_role: optional
      resource2: required
      resource2_role: optional
      score: optional
      influence: optional
  

• Configurar restricciones de ubicación del clúster (No es obligatorio)

  basado en nodo

  cluster_constraint_location:
    - resource: required
      node_name: required
      score: optional
  

  basado en regla (necesita ondrejhome.pcs-modules-2 versión 30.0.0 o superior)

  cluster_constraint_location:
    - resource: required
      constraint_id: required
      rule: required
      score: optional
  

Consideraciones de seguridad

Por favor, considera actualizar el valor predeterminado de cluster_user_pass.

Para proteger los valores sensibles en variables pasadas a este rol, puedes usar ansible-vault para encriptarlos. El enfoque recomendado es crear un archivo separado con las variables y sus valores deseados, encriptar todo el archivo con ansible-vault encrypt y luego incluir este archivo en la sección pre_tasks: para que se cargue antes de ejecutar el rol. El ejemplo a continuación ilustra todo este proceso.

Creando un archivo encrypted_vars.yaml

• 1. Crea un archivo de texto plano encrypted_vars.yaml con tus valores secretos deseados

  # cat encrypted_vars.yaml
  ---
  cluster_user_pass: 'cluster-user-pass'
  fence_vmware_login: 'vcenter-user'
  fence_vmware_passwd: 'vcenter-pass'
  

• 2. Encripta el archivo usando ansible-vault

  # ansible-vault encrypt encrypted_vars.yaml
  

• 3. Verifica el nuevo contenido de encrypted_vars.yaml

  # cat encrypted_vars.yaml
  $ANSIBLE_VAULT;1.1;AES256
  31306461386430...
  

Ejemplo de playbook que utiliza valores de encrypted_vars.yaml

- hosts: cluster
   pre_tasks:
     - include_vars: encrypted_vars.yaml
   roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster' }

NOTA: Encriptar solo el valor de la variable y ponerlo en vars: no se recomienda, ya que podría resultar en errores como argumento 1 debe ser str, no AnsibleVaultEncryptedUnicode. El enfoque que encripta todo el archivo parece no estar afectado por este problema.

Valores predeterminados de módulo de Ansible

Si bien este rol no expone todas las opciones de configuración a través de variables, se puede usar module_defaults para cambiar los valores predeterminados de los parámetros que este rol no usa. A continuación se muestra una lista no exhaustiva de ejemplos donde esto puede resultar útil.

Ejemplo module_default A para establecer el tiempo de token de totem en 15 segundos

- hosts: cluster
  modules_defaults:
    pcs_cluster:
      token: 15000               # el valor predeterminado es 'null' - depende del valor predeterminado del sistema operativo

Ejemplo module_default B para deshabilitar la instalación de dependencias débiles en sistemas EL8+/Fedora

- hosts: cluster
  modules_defaults:
    yum:
      install_weak_deps: false   # el valor predeterminado es 'true'

Ejemplo module_default C para deshabilitar la instalación de recomendaciones de paquetes en sistemas Debian

- hosts: cluster
  modules_defaults:
    apt:
      install_recommends: false  # el valor predeterminado es 'null' - depende de la configuración del sistema operativo

NOTA: Los module_defaults solo se aplican a opciones que no están especificadas en la tarea; no puedes sobrescribir un valor que está establecido por tarea en este rol, solo se puede cambiar el valor de opciones que no se están utilizando.

Ejemplo de Playbook

Ejemplo de playbook A para crear un clúster llamado 'test-cluster' habilitado en el arranque, con fence_xvm y configuraciones de firewall. NOTA: cluster_name es opcional y predeterminado a pacemaker.

- hosts: cluster
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster' }

Ejemplo de playbook B para crear un clúster llamado 'test-cluster' sin configurar el firewall y sin fence_xvm. Para que el clúster sea autorizado correctamente, se espera que el firewall ya esté configurado o deshabilitado.

- hosts: cluster
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster', cluster_firewall: false, cluster_configure_fence_xvm: false }

Ejemplo de playbook C para crear un clúster llamado vmware-cluster con el dispositivo de fencing fence_vmware_soap.

- hosts: cluster
  vars:
    fence_vmware_ipaddr: 'vcenter-hostname-o-ip'
    fence_vmware_login: 'vcenter-username'
    fence_vmware_passwd: 'vcenter-password-for-username'
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'vmware-cluster', cluster_configure_fence_xvm: false, cluster_configure_fence_vmware_soap: true }

Ejemplo de playbook D para crear un clúster llamado test-cluster donde /etc/hosts no se modifica:

- hosts: cluster
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'test-cluster', cluster_etc_hosts: false }

Ejemplo de playbook E para crear un clúster llamado vmware-cluster con un único dispositivo de fencing fence_vmware_rest para todos los nodos del clúster.

- hosts: cluster
  vars:
    fence_vmware_ipaddr: 'vcenter-hostname-o-ip'
    fence_vmware_login: 'vcenter-username'
    fence_vmware_passwd: 'vcenter-password-for-username'
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'vmware-cluster', cluster_configure_fence_xvm: false, cluster_configure_fence_vmware_rest: true, cluster_configure_stonith_style: 'one-device-per-cluster' }

Ejemplo de playbook F para crear un clúster llamado aws-cluster con un único dispositivo fence_aws para todos los nodos del clúster.

- hosts: cluster
  roles:
    - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'aws-cluster', cluster_configure_fence_xvm: false, cluster_configure_fence_aws: true, cluster_configure_stonith_style: 'one-device-per-cluster', enable_repos: false, fence_aws_region: 'aws-region' }

Ejemplo de configuración de recursos en playbook .

- hosts: cluster
  vars:
    cluster_property:
      - name: 'maintenance-mode'
        value: 'true'
    cluster_resource:
      - name: 'apache2'
        resource_type: 'systemd:apache2'
        options: 'meta migration-threshold=2 op monitor interval=20s timeout=10s'
      - name: 'cluster_vip'
        resource_type: 'ocf:heartbeat:IPaddr2'
        options: 'ip=192.168.1.150 cidr_netmask=24 meta migration-threshold=2 op monitor interval=20'
    cluster_constraint_colocation:
      - resource1: 'cluster_vip'
        resource2: 'apache2'
        score: 'INFINITY'
    cluster_resource_defaults:
      - name: 'failure-timeout'
        value: '30'
  roles:
     - { role: 'ondrejhome.ha-cluster-pacemaker', cluster_name: 'apache-cluster'}

Ejemplo de archivo de inventario para sistemas CentOS/RHEL/Fedora creando clústeres básicos.

[cluster-centos7]
192.168.22.21 vm_name=fastvm-centos-7.8-21
192.168.22.22 vm_name=fastvm-centos-7.8-22
[cluster-fedora32]
192.168.22.23 vm_name=fastvm-fedora32-23
192.168.22.24 vm_name=fastvm-fedora32-24
[cluster-rhel8]
192.168.22.25 vm_name=fastvm-rhel-8.0-25
192.168.22.26 vm_name=fastvm-rhel-8.0-26

Ejemplo de archivo de inventario para clúster usando interconexión RRP en interfaz personalizada y/o usando IP personalizada para RRP

[cluster-centos7-rrp]
192.168.22.27 vm_name=fastvm-centos-7.6-21 rrp_interface=ens6
192.168.22.28 vm_name=fastvm-centos-7.6-22 rrp_ip=192.168.22.29

Ejemplo de archivo de inventario con dos miembros completos y dos nodos remotos:

[cluster]
192.168.22.21 vm_name=fastvm-centos-7.6-21
192.168.22.22 vm_name=fastvm-centos-7.6-22
192.168.22.23 vm_name=fastvm-centos-7.6-23 cluster_node_is_remote=True
192.168.22.24 vm_name=fastvm-centos-7.6-24 cluster_node_is_remote=True

Ejemplo de archivo de inventario con fence_aws:

[cluster]
172.31.0.1	instance_id="i-acbdefg1234567890"
172.31.0.2	instance_id="i-acbdefg0987654321"

Videos antiguos de ejemplos de ejecución del rol con valores predeterminados para:

• CentOS 7.6 instalando un clúster de dos nodos CentOS 7.6: https://asciinema.org/a/226466
• Fedora 29 instalando un clúster de dos nodos Fedora 29: https://asciinema.org/a/226467

Licencia

GPLv3

Información del autor

Para ponerte en contacto con el autor, puedes usar el correo electrónico ondrej-xa2iel8u@famera.cz o crear un problema en GitHub al solicitar alguna característica.