documentation.suse.com / Instalación de un clúster de alta disponibilidad básico de dos nodos
SUSE Linux Enterprise High Availability 16.0

Instalación de un clúster de alta disponibilidad básico de dos nodos

Fecha de publicación: 03 Nov 2025
DESCRIPCIÓN

Cómo configurar un clúster de alta disponibilidad básico de dos nodos con SBD sin disco y un vigilante de software.

INTENCIÓN

Puede utilizar este clúster con fines de prueba o como configuración de clúster mínima que puede ampliar más adelante.

ESFUERZO

En configurar un clúster básico de alta disponibilidad se tardan aproximadamente 15 minutos, dependiendo de la velocidad de la conexión de red.

OBJETIVO

Empezar a usar SUSE Linux Enterprise High Availability de forma rápida y sencilla.

1 Ejemplo de uso

 

En esta guía se describe la configuración de un clúster de alta disponibilidad mínimo con las siguientes propiedades:

  • Dos nodos de clúster con acceso SSH sin contraseña entre sí.

  • Una dirección IP virtual flotante que permita a los clientes conectarse a la herramienta de gestión gráfica Hawk independientemente del nodo en el que se esté ejecutando el servicio.

  • SBD (STONITH Block Device, dispositivo de bloques STONITH) sin disco y un vigilante (watchdog) de software utilizado como mecanismo de fencing de nodos para evitar situaciones de nodos malinformados.

  • QDevice trabaja con QNetd para participar en las decisiones de quórum del clúster. Se requieren QDevice y QNetd para esta configuración, de modo que SBD sin disco pueda gestionar situaciones de nodos malinformados para el clúster de dos nodos.

  • Failover de recursos de un nodo a otro si el host activo se interrumpe (configuración activa/pasiva).

Se trata de una configuración de clúster sencilla con requisitos externos mínimos. Puede utilizar este clúster con fines de prueba o como configuración de clúster mínima que puede ampliar más adelante para un entorno de producción.

2 Descripción general de la instalación

 

Para instalar el clúster de alta disponibilidad descrito en la Sección 1, “Ejemplo de uso”, debe realizar las siguientes tareas:

  1. Revise la Sección 3, “Requisitos del sistema” para asegurarse de tener todo lo que necesita.

  2. Instale SUSE Linux Enterprise High Availability en los nodos del clúster (Sección 4, “Habilitación de la extensión de High Availability”).

  3. Instale QNetd en un servidor que no sea de clúster (Sección 5, “Configuración del servidor QNetd”).

  4. Inicialice el clúster en el primer nodo (Sección 6, “Configuración del primer nodo”).

  5. Añada más nodos al clúster (Sección 7, “Adición del segundo nodo”).

  6. Inicie sesión en la interfaz Web de Hawk para supervisar el clúster (Sección 8, “Inicio de sesión en Hawk”).

  7. Compruebe el estado de QDevice y QNetd (Sección 9, “Visualización del estado del quórum”).

  8. Realice pruebas básicas para asegurarse de que el clúster funciona según lo esperado (Sección 10, “Comprobación del clúster”).

  9. Revise la Sección 11, “Pasos siguientes” para averiguar cómo expandir el clúster para un entorno de producción.

3 Requisitos del sistema

 

En esta sección se describen los requisitos del sistema para una configuración mínima de SUSE Linux Enterprise High Availability.

3.1 Requisitos de hardware

 
Servidores

Tres servidores: dos para actuar como nodos de clúster y uno para ejecutar QNetd.

Los servidores pueden ser equipos desde cero o máquinas virtuales. No es necesario que el hardware sea idéntico (memoria, espacio de disco, etc.), pero debe tener la misma arquitectura. No se admiten clústeres de distintas plataformas.

Consulte la sección System Requirements en https://www.suse.com/download/sle-ha/ para obtener más información sobre el hardware del servidor.

Tarjetas de interfaz de red

Al menos dos tarjetas de interfaz de red por nodo de clúster. Esto le permite configurar dos o más canales de comunicación para el clúster, utilizando uno de los siguientes métodos:

  • Combine las tarjetas de interfaz de red en una vinculación de red (método preferido). En este caso, debe configurar el dispositivo vinculado en cada nodo antes de inicializar el clúster.

  • Cree un segundo canal de comunicación en Corosync. Esto se puede configurar mediante el guion de configuración del clúster. En este caso, las dos tarjetas de interfaz de red deben estar en subredes diferentes.

STONITH (fencing de nodos)

Para que sean compatibles, todos los clústeres de SUSE Linux Enterprise High Availability deben tener al menos un dispositivo de fencing (STONITH) para evitar situaciones de nodos malinformados. Puede ser un dispositivo físico (un conmutador de alimentación) o un dispositivo SBD en combinación con un vigilante. El SBD se puede utilizar con almacenamiento compartido o en modo sin disco.

La configuración mínima descrita en esta guía utiliza un vigilante de software y un SBD sin disco, por lo que no se requiere hardware adicional. Antes de usar este clúster en un entorno de producción, sustituya el vigilante de software por un vigilante de hardware.

3.2 Requisitos de software

 
Sistema operativo

Todos los nodos y el servidor QNetd deben tener SUSE Linux Enterprise Server instalado y registrado.

Extensión de High Availability

La extensión de SUSE Linux Enterprise High Availability requiere un código de registro adicional.

Esta extensión se puede habilitar durante la instalación de SLES, o más adelante en un sistema en ejecución. En esta guía se explica cómo habilitar y registrar la extensión en un sistema en ejecución.

3.3 Requisitos de red

 
Sincronización horaria

Todos los sistemas deben sincronizarse con un servidor NTP externo al clúster. SUSE Linux Enterprise Server usa chrony para NTP. Al inicializar el clúster, se le advierte si chrony no se está ejecutando.

Incluso si los nodos están sincronizados, los archivos de registro y los informes de clúster pueden resultar difíciles de analizar si los nodos tienen diferentes zonas horarias configuradas.

Nombre del host y dirección IP

Todos los nodos del clúster deben ser capaces de encontrarse unos otros y al servidor QNetd por sus nombres. Use los siguientes métodos para resolver los nombres de forma fiable:

  • Utilice direcciones IP estáticas.

  • Muestre todos los nodos del archivo /etc/hosts con su dirección IP, el nombre de dominio completo y el nombre de host corto.

En cada tarjeta de interfaz de red solo se admite la dirección IP principal.

SSH

Todos los nodos del clúster deben ser capaces de acceder unos a otros y al servidor QNetd a través de SSH. Ciertas operaciones de clúster también requieren autenticación SSH sin contraseña. Al inicializar el clúster, el guion de configuración comprueba si hay claves SSH existentes y las genera si no existen.

Importante
Importante: acceso SSH de root en SUSE Linux Enterprise 16

En SUSE Linux Enterprise 16, el inicio de sesión SSH de root con contraseña está inhabilitado por defecto.

En cada nodo y en el servidor QNetd cree un usuario con privilegios de sudo o configure la autenticación SSH sin contraseña para el usuario root antes de inicializar el clúster.

Si inicializa el clúster con un usuario sudo, ciertos comandos de crmsh también requieren permiso de sudo sin contraseña.

Red independiente para QNetd

Se recomienda que los nodos del clúster accedan al servidor QNetd a través de una red diferente a la que usa Corosync. Idealmente, el servidor QNetd debe estar en un bastidor separado del clúster, o al menos en una fuente de alimentación distinta, y no en el mismo segmento de red que los canales de comunicación de Corosync.

4 Habilitación de la extensión de High Availability

 

En este procedimiento se explica cómo instalar SUSE Linux Enterprise High Availability en una instancia de SUSE Linux Enterprise Server existente. Puede omitir este procedimiento si ya ha instalado la extensión y los paquetes de High Availability durante la instalación de SLES con Agama.

Requisitos
 

  • SUSE Linux Enterprise Server se instala y se registra en el Centro de servicios al cliente de SUSE.

  • Debe tener un código de registro adicional para SUSE Linux Enterprise High Availability.

Realice este procedimiento en todos los equipos que desee utilizar como nodos de clúster:

  1. Inicie sesión como usuario root o como usuario con privilegios de sudo.

  2. Compruebe si la extensión de High Availability ya está habilitada: 

    > sudo SUSEConnect --list-extensions

  3. Compruebe si los paquetes de High Availability ya están instalados: 

    > zypper search ha_sles

  4. Habilite la extensión de SUSE Linux Enterprise High Availability: 

    > sudo SUSEConnect -p sle-ha/16.0/x86_64 -r HA_REGCODE

  5. Instale los paquetes de High Availability:

    > sudo zypper install -t pattern ha_sles

5 Configuración del servidor QNetd

 

QNetd es el árbitro que proporciona un voto al daemon QDevice que se ejecuta en los nodos del clúster. El servidor QNetd se ejecuta fuera del clúster, por lo que no puede mover los recursos del clúster a este servidor. QNetd puede admitir varios clústeres si cada clúster tiene un nombre único.

Requisitos
 

  • SUSE Linux Enterprise Server se instala y se registra en el Centro de servicios al cliente de SUSE.

  • Debe tener un código de registro adicional para SUSE Linux Enterprise High Availability.

Realice este procedimiento en un servidor que no formará parte del clúster:

  1. Inicie sesión como usuario root o como usuario con privilegios de sudo.

  2. Habilite la extensión de SUSE Linux Enterprise High Availability: 

    > sudo SUSEConnect -p sle-ha/16.0/x86_64 -r HA_REGCODE

  3. Instale el paquete corosync-qnetd: 

    > sudo zypper install corosync-qnetd

    No es necesario iniciar manualmente el servicio corosync-qnetd. Se inicia automáticamente cuando se configura QDevice en el clúster.

El servidor QNetd está listo para aceptar conexiones de un cliente QDevice (corosync-qdevice). La configuración adicional se gestiona con crmsh cuando conecta clientes QDevice.

Por defecto, el servicio corosync-qnetd ejecuta el daemon como usuario coroqnetd en el grupo coroqnetd. Esto evita que el daemon se ejecute como root.

6 Configuración del primer nodo

 

SUSE Linux Enterprise High Availability incluye guiones de configuración para simplificar la instalación de un clúster. Para configurar el clúster en el primer nodo, use el guion crm cluster init.

6.1 Descripción del guion crm cluster init

 

El comando crm cluster init inicia un guion que define los parámetros básicos necesarios para la comunicación del clúster, lo que da como resultado un clúster en el que se ejecuta un nodo.

El guion comprueba y configura los siguientes componentes:

NTP

Comprueba si chrony está configurado para iniciarse en el momento del arranque. Si no es así, aparece un mensaje.

SSH

Detecta o genera claves SSH para el inicio de sesión sin contraseña entre los nodos del clúster.

Cortafuegos

Abre los puertos del cortafuegos necesarios para la comunicación del clúster.

Csync2

Configura Csync2 para replicar los archivos de configuración en todos los nodos de un clúster.

Corosync

Configura el sistema de comunicación del clúster.

SBD/vigilante (watchdog)

Comprueba si existe un vigilante y pregunta si desea configurar el SBD como mecanismo de fencing de nodos.

Administración de clúster de Hawk

Habilita el servicio Hawk y muestra la URL de la interfaz Web de Hawk.

IP virtual flotante

Pregunta si se debe configurar una dirección IP virtual para la interfaz Web de Hawk.

QDevice/QNetd

Pregunta si desea configurar QDevice/QNetd para participar en las decisiones de quórum. Se recomienda para clústeres con un número par de nodos, y especialmente para clústeres de dos nodos.

Nota
Nota: ajustes por defecto de Pacemaker

Las opciones definidas por el guion crm cluster init pueden no ser las mismas que los ajustes por defecto de Pacemaker. Puede comprobar qué ajustes ha cambiado el guion en /var/log/crmsh/crmsh.log. Todas las opciones que se establecen durante el proceso de arranque se pueden modificar más adelante con crmsh.

Nota
Nota: configuración del clúster para distintas plataformas

El guión crm cluster init detecta el entorno del sistema (por ejemplo, Microsoft Azure) y ajusta determinados valores de clúster en función del perfil de ese entorno. Si desea información adicional, consulte el archivo /etc/crm/profiles.yml.

6.2 Inicialización del clúster en el primer nodo

 

Configure el clúster en el primer nodo con el guion crm cluster init. El guion solicita información básica sobre el clúster y configura los ajustes y servicios necesarios. Para obtener más información, ejecute el comando crm cluster init --help.

Requisitos
 

  • SUSE Linux Enterprise High Availability debe estar instalado y actualizado.

  • Todos los nodos deben tener al menos dos interfaces de red o una vinculación de red, con direcciones IP estáticas mostradas en el archivo /etc/hosts junto con el nombre de dominio completo y el nombre de host corto de cada nodo.

  • El servidor QNetd está instalado. Si inicia sesión en el servidor QNetd como usuario root, la autenticación SSH sin contraseña debe estar habilitada.

Realice este procedimiento en un solo nodo:

  1. Inicie sesión en el primer nodo como usuario root o como usuario con privilegios de sudo.

  2. Inicie el guion crm cluster init: 

    > sudo crm cluster init

    El guion comprueba si chrony se está ejecutando, abre los puertos del firewall necesarios, configura Csync2 y comprueba si hay claves SSH. Si no hay claves SSH disponibles, el guion las genera.

  3. Configure Corosync para la comunicación del clúster:

    1. Introduzca una dirección IP para el primer canal de comunicación (ring0). Por defecto, el guion propone la dirección de la primera interfaz de red disponible. Puede ser una interfaz individual o un dispositivo vinculado. Acepte esta dirección o introduzca otra.

    2. Si el guion detecta varias interfaces de red, pregunta si desea configurar un segundo canal de comunicación (ring1). Si ha configurado el primer canal con un dispositivo vinculado, puede rechazar la acción con n. Si necesita configurar un segundo canal, confirme con y e introduzca la dirección IP de otra interfaz de red. Las dos interfaces deben estar en subredes diferentes.

    El guion configura los puertos de firewall predeterminados para la comunicación de Corosync.

  4. Seleccione si desea configurar el SBD como mecanismo de fencing de nodos:

    1. Confirme con y que desea utilizar el SBD.

    2. Cuando se le solicite una vía a un dispositivo de bloques, introduzca none para configurar el SBD sin disco.

    El guion configura el SBD, incluida la configuración de tiempo límite relevante. A diferencia del SBD basado en disco, el SBD sin disco no requiere un recurso de clúster STONITH.

    Si no hay ningún vigilante de hardware disponible, el guion configura el vigilante de software softdog.

  5. Configure una dirección IP virtual para la administración del clúster con la interfaz Web de Hawk:

    1. Confirme con y que desea configurar una dirección IP virtual.

    2. Introduzca una dirección IP no utilizada que desee usar como IP de administración para Hawk.

    En lugar de iniciar sesión en Hawk en un nodo de clúster individual, puede conectarse a la dirección IP virtual.

  6. Elija si desea configurar QDevice y Qnetd:

    1. Confirme con y que desea configurar QDevice y QNetd.

    2. Introduzca la dirección IP o el nombre de host del servidor QNetd, con o sin nombre de usuario.

      • Si incluye un nombre de usuario que no sea el root, se le pedirá la contraseña y el guion configurará la autenticación SSH sin contraseña desde el nodo al servidor QNetd.

      • Si omite un nombre de usuario, el guion usa por defecto al usuario root, por lo que la autenticación SSH sin contraseña ya debe estar configurada para que el nodo acceda al servidor QNetd.

      Para los campos restantes, acepte los valores por defecto:

    3. Acepte el puerto propuesto (5403) o introduzca uno diferente.

    4. Elija el algoritmo que determina cómo se asignan los votos. El valor por defecto es ffsplit.

    5. Elija el método que se usará cuando se requiera un desempate. El valor por defecto es lowest.

    6. Elija si desea habilitar TLS para la comprobación de certificados de cliente. El valor predeterminado es on (intente conectarse con TLS, pero conéctese sin TLS si no está disponible).

    7. (Opcional) Introduzca comandos heurísticos para afectar a la forma en que se determinan los votos. Para omitir este paso, deje el campo en blanco.

    El guion configura QDevice y QNetd, incluidas las claves SSH, los certificados de CA y de servidor, y el puerto del firewall. También habilita los servicios necesarios en los nodos del clúster y en el servidor QNetd.

El guion inicia los servicios de clúster para conectar el clúster y habilitar Hawk. La URL que se utilizará para Hawk se muestra en la pantalla. También puede comprobar el estado del clúster con el comando crm status.

Importante
Importante: contraseña segura para hacluster

El guion crm cluster init crea un usuario y una contraseña de clúster por defecto. Sustituya la contraseña por defecto por una segura tan pronto como sea posible: 

> sudo passwd hacluster

7 Adición del segundo nodo

 

Añada más nodos al clúster con el guion crm cluster join. El guion solo necesita acceso a un nodo de clúster existente y finaliza automáticamente la configuración básica en el equipo actual. Para obtener más información, ejecute el comando crm cluster join --help.

Requisitos
 

  • SUSE Linux Enterprise High Availability debe estar instalado y actualizado.

  • Debe haber ya un clúster en ejecución en al menos un nodo.

  • Todos los nodos deben tener al menos dos interfaces de red o una vinculación de red, con direcciones IP estáticas mostradas en el archivo /etc/hosts junto con el nombre de dominio completo y el nombre de host corto de cada nodo.

  • Si inicia sesión como usuario sudo: el mismo usuario debe existir en todos los nodos y en el servidor QNetd. Este usuario debe tener permiso de sudo sin contraseña.

  • Si inicia sesión como el usuario root: la autenticación SSH sin contraseña debe configurarse en todos los nodos y en el servidor QNetd.

Realice este procedimiento en cada nodo adicional:

  1. Inicie sesión en este nodo como el mismo usuario con el que configuró el primer nodo.

  2. Inicie el guion crm cluster join:

    • Si configura el primer nodo como root, puede iniciar el guion sin parámetros adicionales: 

      # crm cluster join

    • Si configura el primer nodo como usuario sudo, debe especificar ese usuario con la opción -c: 

      > sudo crm cluster join -c USER@NODE1

    El guion comprueba si chrony se está ejecutando, abre los puertos del firewall necesarios y configura Csync2.

  3. Si aún no ha especificado el primer nodo con -c, se le solicita su dirección IP o el nombre de host.

  4. Si aún no ha configurado la autenticación SSH sin contraseña entre los nodos, se le pedirá la contraseña del primer nodo.

  5. Configure Corosync para la comunicación del clúster:

    1. El guion propone una dirección IP para ring0. Esta dirección IP debe estar en la misma subred que la dirección IP usada para ring0 en el primer nodo. Si no es así, introduzca la dirección IP correcta.

    2. Si el clúster tiene dos canales de comunicación Corosync configurados, el guion le solicita una dirección IP para ring1. Esta dirección IP debe estar en la misma subred que la dirección IP usada para ring1 en el primer nodo.

El guion copia la configuración del clúster del primer nodo, ajusta la configuración del tiempo límite para considerar el nuevo nodo y pone el nuevo nodo en línea.

Puede comprobar el estado del clúster con el comando crm status.

Importante
Importante: contraseña segura para hacluster

El guion crm cluster join crea un usuario y una contraseña de clúster por defecto. En cada nodo, sustituya la contraseña por defecto por una segura tan pronto como sea posible: 

> sudo passwd hacluster

8 Inicio de sesión en Hawk

 

Hawk le permite supervisar y administrar un clúster de alta disponibilidad mediante un navegador Web gráfico. También puede configurar una dirección IP virtual que permita a los clientes conectarse a Hawk independientemente del nodo en el que se esté ejecutando.

Requisitos
 

  • El equipo cliente debe poder conectarse a los nodos del clúster.

  • El equipo cliente debe tener un navegador Web gráfico con JavaScript y cookies habilitados.

Puede realizar este procedimiento en cualquier equipo que pueda conectarse a los nodos del clúster:

  1. Inicie un navegador Web e introduzca la URL siguiente: 

    https://HAWKSERVER:7630/

    Sustituya HAWKSERVER con la dirección IP o el nombre de host de un nodo de clúster, o la dirección IP virtual de Hawk si está configurada.

    Nota
    Nota: advertencia de certificado

    Si aparece una advertencia de certificado cuando accede a la URL por primera vez, se debe a que se está usando un certificado autofirmado. Consulte a su operador de clúster los detalles del certificado para verificarlo. Si desea continuar de todas formas, puede añadir una excepción en el navegador para omitir la advertencia.

  2. En la pantalla de inicio de sesión de Hawk, introduzca el Nombre de usuario y la Contraseña del usuario hacluster.

  3. Haga clic en Iniciar sesión. La interfaz Web de Hawk muestra por defecto la pantalla Estado:

La pantalla Estado muestra un recurso configurado: la dirección IP virtual admin-ip, que se ejecuta en un nodo llamado alice.
Figura 1: La pantalla Estado de Hawk
 

9 Visualización del estado del quórum

 

Puede comprobar el estado de QDevice y QNetd desde cualquier nodo del clúster. Estos ejemplos muestran un clúster con dos nodos, alice y bob.

Ejemplo 1: Visualización del estado de QDevice
 
> sudo crm corosync status quorum
1 alice member
2 bob member

Quorum information
------------------
Date:             [...]
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          2
Ring ID:          1.e
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate Qdevice

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    A,V,NMW alice
         2          1    A,V,NMW bob (local)
         0          1            Qdevice

La sección Membership information muestra los siguientes códigos de estado:

A (activo) o NA (no activo)

Muestra el estado de conectividad entre QDevice y Corosync.

V (con voto) o NV (sin voto)

Muestra si el nodo tiene un voto. V significa que ambos nodos pueden comunicarse entre sí. En una situación de nodos malinformados, un nodo se definiría como V y el otro nodo como NV.

MW (el maestro gana) o NMW (no gana el maestro)

Muestra si el indicador master_wins está definido. Por defecto, el indicador no está definido, por lo que el estado es NMW.

NR (no registrado)

Muestra que el clúster no está usando un dispositivo de quórum.

Ejemplo 2: Visualización del estado de QNetd
 
> sudo crm corosync status qnetd
1 alice member
2 bob member

Cluster "hacluster":
    Algorithm:          Fifty-Fifty split (KAP Tie-breaker)
    Tie-breaker:        Node with lowest node ID
    Node ID 1:
        Client address:         ::ffff:192.168.122.185:45676
        HB interval:            8000ms
        Configured node list:   1, 2
        Ring ID:                1.e
        Membership node list:   1, 2
        Heuristics:             Undefined (membership: Undefined, regular: Undefined)
        TLS active:             Yes (client certificate verified)
        Vote:                   ACK (ACK)
    Node ID 2:
        Client address:         ::ffff:192.168.100.168:55034
        HB interval:            8000ms
        Configured node list:   1, 2
        Ring ID:                1.e
        Membership node list:   1, 2
        Heuristics:             Undefined (membership: Undefined, regular: Undefined)
        TLS active:             Yes (client certificate verified)
        Vote:                   No change (ACK)

10 Comprobación del clúster

 

Las siguientes pruebas pueden ayudarle a identificar problemas con la configuración del clúster. Sin embargo, una prueba realista implica casos de uso y situaciones específicos. Antes de utilizar el clúster en un entorno de producción, pruébelo exhaustivamente en consonancia con sus casos de uso.

10.1 Prueba de failover de recursos

 

Compruebe si el clúster mueve recursos a otro nodo si el nodo actual tiene el estado standby. Este procedimiento usa nodos de ejemplo llamados alice y bob, y un recurso de IP virtual llamado admin-ip con la dirección IP de ejemplo 192.168.1.10.

  1. Abra dos terminales.

  2. En el primero, haga ping a la dirección IP virtual: 

    > ping 192.168.1.10

  3. En el segundo terminal, inicie sesión en uno de los nodos del clúster.

  4. Compruebe en qué nodo se ejecuta la dirección IP virtual: 

    > sudo crm status
[..]
Node List:
  * Online: [ alice bob ]

Full List of Resources:
  * admin-ip  (ocf:heartbeat:IPaddr2):    Started alice

  5. Ponga alice en modo En espera: 

    > sudo crm node standby alice

  6. Compruebe de nuevo el estado del clúster. El recurso admin-ip debería haber migrado a bob: 

    > sudo crm status
[...]
Node List:
  * Node alice: standby
  * Online: [ bob ]

Full List of Resources:
  * admin-ip  (ocf:heartbeat:IPaddr2):    Started bob

  7. Durante la migración, en el primer terminal, se mostrará un flujo ininterrumpido de pings a la dirección IP virtual. Esto muestra que la configuración del clúster y la dirección IP flotante funcionan correctamente.

  8. Cancele el comando ping con Control–C.

  9. En el segundo terminal, vuelva a poner alice en línea: 

    > sudo crm node online alice

10.2 Prueba de errores del clúster

 

El comando crm cluster crash_test simula fallos de clúster e informa de los resultados.

El comando admite las siguientes comprobaciones:

--split-brain-iptables

Simula una situación de nodos malinformados bloqueando el puerto Corosync y comprueba si se puede aplicar fencing a un nodo como se esperaba. Debe instalar iptables antes de poder ejecutar esta prueba.

--kill-sbd/--kill-corosync/ --kill-pacemakerd

Interrumpe los daemons de SBD, Corosync o Pacemaker. Después de ejecutar una de estas pruebas, encontrará un informe en el directorio /var/lib/crmsh/crash_test/. El informe incluye una descripción del caso de prueba, un registro de acciones y una explicación de los posibles resultados.

--fence-node NODE

Delimita el nodo concreto que se ha pasado desde la línea de comandos.

Para obtener más información, ejecute el comando crm cluster crash_test --help.

En el ejemplo siguiente se usan nodos llamados alice y bob, y se prueba el fencing de bob. Para observar cómo cambia de estado de bob durante la prueba, inicie sesión en Hawk y diríjase a Estado › Nodos.

Ejemplo 3: prueba del clúster: "fencing" de nodo
 
> sudo crm status
[...]
Node List:
  * Online: [ alice bob ]

Active Resources:
  * admin-ip     (ocf:heartbeat:IPaddr2):    Started alice

> sudo crm cluster crash_test --fence-node bob

==============================================
Testcase:          Fence node bob
Fence action:      reboot
Fence timeout:     95

!!! WARNING WARNING WARNING !!!
THIS CASE MAY LEAD TO NODE BE FENCED.
TYPE Yes TO CONTINUE, OTHER INPUTS WILL CANCEL THIS CASE [Yes/No](No): Yes
INFO: Trying to fence node "bob"
INFO: Waiting 71s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

11 Pasos siguientes

 

En esta guía se describe un clúster básico de alta disponibilidad que se puede usar con fines de prueba. Para expandir este clúster para su uso en entornos de producción, se recomiendan más pasos:

Adición de más nodos

Añada más nodos al clúster con el guion crm cluster join.

Habilitación de un vigilante de hardware

Antes de usar este clúster en un entorno de producción, sustituya el softdog con un vigilante de hardware.

Adición de más dispositivos STONITH

Para cargas de trabajo críticas, se recomienda encarecidamente tener dos o tres dispositivos STONITH, y usar dispositivos STONITH físicos o SBD basados en disco.