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

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

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

Cómo configurar un clúster de alta disponibilidad básico de tres 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:

  • Tres nodos de clúster con acceso SSH sin contraseña entre sí. Se requieren tres nodos para esta configuración, de modo que SBD sin disco pueda manejar escenarios de nodos malinformados (split-brain) sin la ayuda de QDevice.

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

  • 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. Inicialice el clúster en el primer nodo (Sección 5, “Configuración del primer nodo”).

  4. Añada más nodos al clúster (Sección 6, “Adición del segundo y el tercer nodo”).

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

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

  7. Revise la Sección 9, “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 que actúen como nodos de clúster.

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 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 encontrar a los demás por su nombre. 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 a los demás mediante 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, 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.

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

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

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.

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

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:

    Para la instalación mínima descrita en este documento, rechace la acción con n.

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

6 Adición del segundo y el tercer 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. 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.

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 solicitarán las contraseñas de cada uno de los nodos existentes.

  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

7 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
 

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

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

8.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 1: 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"

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

Configuración de QDevice

QDevice y QNetd participan en las decisiones de quórum. Con la ayuda del arbitro QNetd, QDevice proporciona un número configurable de votos. Esto permite que los clústeres soporten más errores de nodo de los que permiten las reglas de quórum estándar. Se recomienda desplegar QDevice y QNetd en clústeres con un número par de nodos, y especialmente en clústeres de dos nodos.