SUSE Linux Enterprise High Availability Extension 15 SP3

Inicio rápido de instalación y configuración #

SUSE Linux Enterprise High Availability Extension 15 SP3

Fecha de publicación: March 20, 2025

Este documento sirve como guía para la instalación de un clúster muy básico de dos nodos mediante los guiones de bootstrap proporcionados por el paquete ha-cluster-bootstrap. Esto incluye la configuración de una dirección IP virtual como recurso de clúster y el uso del SBD (del inglés Split Brain Detector, detector de inteligencia dividida) en el almacenamiento compartido como mecanismo de “fencing” de nodo.

Autores: Tanja Roth y Thomas Schraitle

Historial de revisiones: Documentación de SUSE Linux Enterprise High Availability Extension

1 Ejemplo de uso #

Los procedimientos descritos en este documento sirven para realizar una instalación mínima de un clúster de dos nodos con las siguientes propiedades:

Dos nodos: alice (IP: 192.168.1.1) y bob (IP: 192.168.1.2), conectados entre sí a través de la red.
Una dirección IP virtual flotante (192.168.2.1) que permite a los clientes conectarse al servicio independientemente del nodo físico en el que se esté ejecutando.
Un dispositivo de almacenamiento compartido, que se utiliza como mecanismo de “fencing” del SBD. Esto evita situaciones de clúster con nodos malinformados (Split Brain).
Failover (relevo de funciones multinodo) de recursos de un nodo a otro si el host activo se interrumpe (instalación activa/pasiva).

Después de instalar el clúster con los guiones de bootstrap, se supervisa con la interfaz gráfica Hawk2. Se trata de una de las herramientas de gestión de clústeres incluidas en SUSE® Linux Enterprise High Availability Extension. Como prueba básica del funcionamiento del failover de recursos, se colocará uno de los nodos en modo En espera y se comprobará si la dirección IP virtual se migra al segundo nodo.

Puede utilizar el clúster de dos nodos con fines de prueba o como configuración de clúster mínima que puede ampliar más adelante. Antes de utilizar el clúster en un entorno de producción, modifíquelo según sus necesidades.

2 Requisitos del sistema #

En esta sección se informa sobre los principales requisitos del sistema para la situación descrita en la Sección 1. Para ajustar el clúster a fin de usarlo en un entorno de producción, consulte la lista completa en el Chapter 2, System requirements and recommendations.

2.1 Requisitos de hardware #

Servidores

Dos servidores con el software especificado en la Sección 2.2, “Requisitos de software”.

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.

Canales de comunicación

Se necesitan al menos dos medios de comunicación TCP/IP por nodo del clúster. El equipo de red debe ser compatible con los medios de comunicación que desee utilizar para las comunicaciones del clúster: multidifusión o difusión unidireccional. Los medios de comunicación deben admitir una velocidad de datos de 100 Mbit/s o superior. Para que la instalación del clúster sea compatible, se requieren dos o más vías de comunicación redundantes. Esto puede realizarse de las siguientes formas:

Con un vínculo de dispositivos de red (opción preferida)
Con un segundo canal de comunicación en Corosync

“Fencing” de nodo o STONITH

Para evitar situaciones de “clústeres con nodos malinformados (Split Brain)”, los clústeres necesitan un mecanismo de “fencing” de nodo. Si se produce una situación de clústeres con nodos malinformados (Split Brain), los nodos del clúster se dividen en dos o más grupos que no tienen constancia de los demás (debido a un fallo de hardware o software o debido a que se ha cortado la conexión de red). Un mecanismo de “fencing” aísla el nodo en cuestión (normalmente restableciendo o apagando el nodo). Esto también se denomina STONITH (“Shoot the other node in the head”, disparar al otro nodo en la cabeza). Un mecanismo de “fencing” de nodo puede ser un dispositivo físico (un conmutador de alimentación) o un mecanismo como SBD (STONITH por disco), en combinación con un vigilante. Para usar el SBD se requiere un almacenamiento compartido.

2.2 Requisitos de software #

Todos los nodos que formarán parte del clúster deben tener al menos los siguientes módulos y extensiones:

Basesystem Module 15 SP3
Server Applications Module 15 SP3
SUSE Linux Enterprise High Availability Extension 15 SP3

2.3 Otros requisitos y recomendaciones #

Sincronización horaria

Los nodos del clúster deben sincronizarse con un servidor NTP externo al clúster. Desde SUSE Linux Enterprise High Availability Extension 15, la implementación por defecto de NTP es chrony. Para obtener más información, consulte la Guía de administración de SUSE Linux Enterprise Server 15 SP3.

Si los nodos no se sincronizan, puede que el clúster no funcione correctamente. Asimismo, los archivos de registro y los informes del clúster son muy difíciles de analizar sin la sincronización. Si utiliza guiones de bootstrap, el sistema le avisará si NTP no está aún configurado.

Nombre del host y dirección IP

Utilice direcciones IP estáticas.
Muestre todos los nodos del clúster en el archivo /etc/hosts con su nombre de host completo y su nombre de host abreviado. Es esencial que los miembros del clúster puedan encontrarse unos a otros por su nombre. Si los nombres no están disponibles, se producirá un error de comunicación interna del clúster.

SSH

Todos los nodos del clúster deben ser capaces de acceder a los demás mediante SSH. Herramientas como crm report (para resolver problemas) y el explorador de historial de Hawk2 requieren acceso SSH sin contraseña entre los nodos; si no se proporciona, solo podrán recopilar datos del nodo actual.

Si utiliza guiones de bootstrap para configurar el clúster, las claves SSH se crean y se copian automáticamente.

3 Descripción general de los guiones de bootstrap #

Todos los comandos del paquete ha-cluster-bootstrap ejecutan guiones de bootstrap que requieren solo un mínimo de tiempo y de intervención manual.

Con ha-cluster-init puede definir los parámetros básicos necesarios para la comunicación del clúster. Esto le deja con un clúster de un nodo en ejecución.
Con ha-cluster-join puede añadir más nodos al clúster.
Con ha-cluster-remove puede eliminar nodos del clúster.

Todos los guiones de bootstrap se registran en /var/log/ha-cluster-bootstrap.log. Consulte este archivo para obtener información sobre el proceso de bootstrap. Todas las opciones que se establecen durante el proceso de bootstrap se pueden modificar más adelante con el módulo de clúster de YaST. Consulte el Chapter 4, Using the YaST cluster module para obtener más información.

Cada guion incluye una página man donde se explican las distintas funciones y las opciones del guion y se ofrece una descripción general de los archivos que el guion puede crear y modificar.

El guion de bootstrap ha-cluster-init comprueba y configura los siguientes componentes:

NTP: Si NTP no se ha configurado para iniciarse durante el arranque, aparece un mensaje. Desde SUSE Linux Enterprise High Availability Extension 15, la implementación por defecto de NTP es chrony.
SSH: Crea claves SSH para la entrada sin contraseña entre los nodos del clúster.
Csync2: Configura Csync2 para replicar los archivos de configuración en todos los nodos de un clúster.
Corosync: Permite configurar el sistema de comunicación del clúster.
SBD/watchdog: Comprueba si existe un vigilante y se le pregunta si desea configurar el SBD como mecanismo de “fencing” de nodo.
IP virtual flotante: Le pregunta si desea configurar una dirección IP virtual para la administración del clúster con Hawk2.
Cortafuegos: Abre los puertos del cortafuegos necesarios para la comunicación del clúster.
Nombre del clúster: Permite definir un nombre para el clúster, que es, por defecto, hacluster. Este componente es opcional y resulta útil sobre todo para los clústeres geográficos. Normalmente, el nombre del clúster refleja la ubicación y permite que sea más fácil distinguir un sitio dentro de un clúster geográfico.
QDevice/QNetd: Esta configuración no se trata aquí. Si desea utilizar un servidor QNetd, puede configurarlo con el guión bootstrap como se describe en Chapter 14, QDevice and QNetd.

4 Instalación de SUSE Linux Enterprise High Availability Extension #

Los paquetes para configurar y gestionar un clúster con High Availability Extension se incluyen en el patrón de instalación Alta disponibilidad (denominado sles_ha en la línea de comandos). Este patrón solo está disponible si SUSE Linux Enterprise High Availability Extension se ha instalado como extensión de SUSE® Linux Enterprise Server.

Para obtener información sobre cómo instalar extensiones, consulte la Guía de distribución de SUSE Linux Enterprise Server 15 SP3.

Procedimiento 1: Instalación del patrón Alta disponibilidad #

Si el patrón aún no está instalado, haga lo siguiente:

Instálelo mediante la línea de comandos con Zypper:
```
root # zypper install -t pattern ha_sles
```
Instale el patrón Alta disponibilidad en todos los equipos que vayan a formar parte del clúster.
Nota: instalación de paquetes de software en todas las partes
Para realizar una instalación automática de SUSE Linux Enterprise Server 15 SP3 y SUSE Linux Enterprise High Availability Extension 15 SP3, utilice AutoYaST para clonar los nodos existentes. Para obtener más información, consulte el Section 3.2, “Mass installation and deployment with AutoYaST”.
Registre los equipos en el Centro de servicios al cliente de SUSE. Para obtener más información, consulte la Guía de actualización de SUSE Linux Enterprise Server 15 SP3.

5 Uso del SBD como mecanismo de “fencing” #

Si dispone de almacenamiento compartido, por ejemplo, una SAN (red de área de almacenamiento), puede utilizarla para evitar situaciones de clústeres con nodos malinformados (Split Brain). Para ello, configure SBD como mecanismo de "fencing" de nodo. El SBD utiliza la compatibilidad con el vigilante y el agente del recurso de STONITH external/sbd.

5.1 Requisitos del SBD #

Durante la instalación del primer nodo con ha-cluster-init, puede decidir si desea utilizar el SBD. Si responde afirmativamente, deberá introducir la vía al dispositivo de almacenamiento compartido. Por defecto, ha-cluster-init crea automáticamente una pequeña partición en el dispositivo que se va a usar para el SBD.

Para utilizar el SBD, deben cumplirse los siguientes requisitos:

La vía al dispositivo de almacenamiento compartido debe ser persistente y coherente en todos los nodos del clúster. Utilice nombres de dispositivo estables, como /dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345.
El dispositivo SBD no debe utilizar RAID basado en host, LVM2 ni residir en una instancia de DRBD*.

Para obtener información sobre cómo configurar el almacenamiento compartido, consulte la Guía de administración de almacenamiento de SUSE Linux Enterprise Server 15 SP3.

5.2 Habilitación del vigilante softdog para SBD #

En SUSE Linux Enterprise Server, la compatibilidad del vigilante en el núcleo está habilitada por defecto: incorpora varios módulos de núcleo que proporcionan controladores de vigilancia específicos de hardware. High Availability Extension utiliza el daemon de SBD como componente de software que “alimenta” al vigilante.

En el procedimiento siguiente se utiliza el vigilante softdog.

Importante: limitaciones de softdog

El controlador softdog presupone que sigue habiendo al menos una CPU en ejecución. Si todas las CPU están bloqueadas, el código del controlador softdog que debe rearrancar el sistema no se ejecuta nunca. Por el contrario, los vigilantes de hardware siguen en funcionamiento aunque todas las CPU estén bloqueadas.

Antes de utilizar el clúster en un entorno de producción, se recomienda encarecidamente sustituir el módulo softdog por el módulo de hardware que mejor se adapte al hardware existente.

Sin embargo, si ningún vigilante coincide con el hardware, se puede usar softdog como módulo de vigilancia del núcleo.

Cree un almacenamiento compartido persistente, como se describe en la Sección 5.1, “Requisitos del SBD”.

Habilite el vigilante softdog:

root # echo softdog > /etc/modules-load.d/watchdog.conf
root # systemctl restart systemd-modules-load

Compruebe que el módulo softdog está correctamente cargado:
```
root # lsmod | grep dog
softdog                16384  1
```

Se recomienda encarecidamente probar que el mecanismo de "fencing" de SBD funciona correctamente para evitar situaciones de clústeres con nodos malinformados. Esta prueba se puede realizar bloqueando la comunicación del clúster con Corosync.

6 Configuración del primer nodo #

Configure el primer nodo con el guion ha-cluster-init. Esto requiere solo un mínimo de tiempo y de intervención manual.

Procedimiento 2: Configuración del primer nodo (alice) con ha-cluster-init #

Entre como usuario root en el equipo físico o en la máquina virtual que va a utilizar como nodo de clúster.
Para iniciar el guion de bootstrap, ejecute:
```
root # ha-cluster-init --name CLUSTERNAME
```
Sustituya el marcador de posición CLUSTERNAME por un nombre descriptivo, como la ubicación geográfica del clúster (por ejemplo, amsterdam). Esto resulta especialmente útil para crear un clúster geográfico más adelante, ya que simplifica la identificación de un sitio.
Si necesita unidifusión en lugar de multidifusión (valor por defecto) para la comunicación del clúster, utilice la opción -u. Después de la instalación, busque el valor udpu en el archivo /etc/corosync/corosync.conf. Si ha-cluster-init detecta un nodo en ejecución en Amazon Web Services (AWS), el guion utilizará por defecto la unidifusión para la comunicación del clúster.
Los guiones comprueban la configuración de NTP y si existe un servicio de vigilancia de hardware. Genera las claves SSH pública y privada usadas para el acceso SSH y la sincronización Csync2 e inicia los servicios respectivos.
Configure el nivel de comunicación del clúster (Corosync):
1. Introduzca la dirección de red con la que se debe enlazar. Por defecto, el guion propone la dirección de red eth0. Si lo prefiere, especifique una dirección de red distinta; por ejemplo, bond0.
2. Introduzca una dirección de multidifusión. El guion propone una dirección aleatoria que puede utilizar por defecto. Por supuesto, su red concreta debe admitir esta dirección de multidifusión.
3. Introduzca un puerto de multidifusión. El guion propone por defecto el puerto 5405.
Configure el SBD como mecanismo de “fencing” de nodo:
1. Haga clic en s para confirmar que desea utilizar el SBD.
2. Introduzca una vía persistente para la partición del dispositivo de bloques que desea utilizar para SBD, consulte la Sección 5, “Uso del SBD como mecanismo de “fencing””. La vía debe ser coherente en todos los nodos del clúster.
Configure una dirección IP virtual para la administración del clúster con Hawk2. (Esta IP virtual se usará para probar más adelante si el failover es correcto).
1. Haga clic en s para confirmar 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 Hawk2: 192.168.2.1.
  En lugar de entrar en un nodo de clúster individual con Hawk2, puede conectarse a la dirección IP virtual.

Por último, el guion inicia el servicio Pacemaker para conectar el clúster y habilitar Hawk2. La URL que se utilizará para Hawk2 se muestra en la pantalla.

Ahora dispone de un clúster de un nodo en ejecución. Para ver su estado, haga lo siguiente:

Procedimiento 3: Entrada en la interfaz Web de Hawk2 #

En cualquier equipo, inicie un navegador Web y asegúrese de que las cookies y JavaScript están habilitados.
Como URL, introduzca la dirección IP o el nombre de host de cualquier nodo del clúster en el que se ejecute el servicio Web Hawk. Si lo prefiere, introduzca la dirección IP virtual que configuró en el Paso 5 del Procedimiento 2, “Configuración del primer nodo (alice) con ha-cluster-init”:
```
https://HAWKSERVER:7630/
```
Nota: advertencia de certificado
Si aparece una advertencia de certificado cuando intenta acceder a la URL por primera vez, se debe a que se está usando un certificado autofirmado. Los certificados autofirmados no se consideran de confianza por defecto.
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.
En la pantalla de entrada de Hawk2, escriba el nombre de usuario y la contraseña del usuario que se creó durante el proceso de bootstrap (usuario hacluster y contraseña linux).
Importante: contraseña segura
Sustituya la contraseña por defecto por una segura tan pronto como sea posible:
```
root # passwd hacluster
```
Haga clic en Entrar. Después de entrar a la sesión, en la interfaz Web de Hawk2 se abre por defecto la pantalla de estado, donde se muestra el estado del clúster actual:
Figura 1: Estado del clúster de un nodo en Hawk2 #

7 Adición del segundo nodo #

Si tiene un clúster de un nodo en ejecución, añada el segundo nodo de clúster con el guion de bootstrap ha-cluster-join, como se describe en el Procedimiento 4. El guion solo necesita acceso a un nodo de clúster existente y finalizará automáticamente la configuración básica en el equipo actual. Para obtener más detalles, consulte la página man ha-cluster-join.

Los guiones de bootstrap se encargan de cambiar la configuración específica a un clúster de dos nodos; por ejemplo, SBD y Corosync.

Procedimiento 4: Adición del segundo nodo (bob) con ha-cluster-join #

Entre como usuario root en el equipo físico o virtual que se supone que debe unirse al clúster.
Para iniciar el guion de bootstrap, ejecute:
```
root # ha-cluster-join
```
Si NTP no se ha configurado para iniciarse durante el arranque, aparece un mensaje. El guion también comprueba si hay un dispositivo de vigilancia de hardware (lo que es importante en caso de que desee configurar el SBD). Recibirá una advertencia si no hay ninguno presente.
Si decide continuar de todas formas, se le pedirá la dirección IP de un nodo existente. Introduzca la dirección IP del primer nodo (alice, 192.168.1.1).
Si aún no ha configurado el acceso SSH sin contraseña entre ambos equipos, se le pedirá la contraseña del usuario root del nodo existente.
Después de entrar en el nodo especificado, el guion copia la configuración de Corosync, configura SSH y Csync2 y convierte el equipo actual en nodo de clúster nuevo. Además, inicia el servicio necesario para Hawk2.

Compruebe el estado del clúster en Hawk2. En Estado › Nodos deberían aparecer dos nodos con estado verde (consulte la Figura 2, “Estado del clúster de dos nodos”).

Figura 2: Estado del clúster de dos nodos #

8 Comprobación del clúster #

La Sección 8.1, “Prueba de failover de recursos” es una sencilla prueba para comprobar si el clúster mueve la dirección IP virtual al otro nodo en caso de que el nodo que está ejecutando actualmente el recurso pase a modo En espera.

Sin embargo, una prueba realista implica casos de uso y situaciones específicos, incluida la prueba del mecanismo de “fencing”para evitar una situación de clúster con nodos malinformados (Split Brain). Si no ha configurado el mecanismo de “fencing” correctamente, es posible que el clúster no funcione de forma adecuada.

Antes de utilizar el clúster en un entorno de producción, pruébelo exhaustivamente en sus casos de uso o con ayuda del guion ha-cluster-preflight-check.

8.1 Prueba de failover de recursos #

Como prueba rápida, el siguiente procedimiento comprueba el failover de los recursos:

Procedimiento 5: Prueba de failover de recursos #

Abra un terminal y ejecute un ping a 192.168.2.1, la dirección IP virtual:
```
root # ping 192.168.2.1
```
Entre en el clúster, como se describe en el Procedimiento 3, “Entrada en la interfaz Web de Hawk2”.
En la opción Estado › Recursos de Hawk2, marque el nodo en el que se está ejecutando la dirección IP virtual (recurso admin_addr). Se presupone que el recurso se ejecuta en alice.
Ponga alice en modo En espera (consulte la Figura 3, “Nodo alice en modo En espera”).
Figura 3: Nodo alice en modo En espera #
Haga clic en Estado › Recursos. El recurso admin_addr se ha migrado a bob.

Durante la migración, 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. Cancele el comando ping con Control– C.

8.2 Pruebas con el comando ha-cluster-preflight-check #

El comando ha-cluster-preflight-check ejecuta pruebas estandarizadas para un clúster. Desencadena los fallos del clúster y verifica la configuración para buscar problemas. Antes de utilizar el clúster en el entorno de producción, se recomienda utilizar este comando para asegurarse de que todo funciona correctamente.

El comando admite las siguientes comprobaciones:

Comprobación del entorno -e/--env-check. Comprueba lo siguiente:
- ¿Se pueden resolver los nombres de host?
- ¿Se ha habilitado e iniciado el servicio de horario?
- ¿Tiene el nodo actual un vigilante configurado?
- ¿Se ha iniciado el servicio firewalld y están los puertos relacionados con el clúster abiertos?
Comprobación del estado del clúster -c/--cluster-check. Comprueba los distintos estados y servicios del clúster. Comprueba lo siguiente:
- ¿Están habilitados y en ejecución los servicios del clúster (Pacemaker/Corosync)?
- ¿Está habilitado STONITH? Comprueba también si los recursos relacionados con STONITH están configurados e iniciados. Si ha configurado SBD, ¿se ha iniciado el servicio SBD?
- ¿Dispone el clúster de quórum? Muestra los nodos de DC actuales y los nodos que están en línea, sin conexión y sin limpiar.
- ¿Se han iniciado o detenido los recursos o se ha producido un fallo?
Comprobación de clústeres con nodos malinformados (Split Brain) --split-brain-iptables. Simula una situación de clústeres con nodos malinformados (Split Brain) mediante el bloqueo del puerto de Corosync. Comprueba si un nodo se puede aislar en la medida de lo esperado.
Detiene los daemons para SBD, Corosync y Pacemaker -kill-sbd/-kill-corosync/-kill-pacemakerd. Después de ejecutar esta prueba, encontrará un informe en /var/lib/ha-cluster-preflight-check. En el informe se incluye la descripción del caso de prueba, se registran las acciones y se explican los posibles resultados.
Comprobación del nodo de aislamiento --fence-node. Aísla el nodo concreto que se ha pasado desde la línea de comandos.

Por ejemplo, para probar el entorno, ejecute:

root # crm_mon -1
Stack: corosync
Current DC: alice (version ...) - partition with quorum
Last updated: Fri Mar 03 14:40:21 2020
Last change: Fri Mar 03 14:35:07 2020 by root via cibadmin on alice

2 nodes configured
1 resource configured

Online: [ alice bob ]
Active resources:

 stonith-sbd    (stonith:external/sbd): Started alice

root # ha-cluster-preflight-check -e
[2020/03/20 14:40:45]INFO: Checking hostname resolvable [Pass]
[2020/03/20 14:40:45]INFO: Checking time service [Fail]
 INFO: chronyd.service is available
 WARNING: chronyd.service is disabled
 WARNING: chronyd.service is not active
[2020/03/20 14:40:45]INFO: Checking watchdog [Pass]
[2020/03/20 14:40:45]INFO: Checking firewall [Fail]
 INFO: firewalld.service is available
 WARNING: firewalld.service is not active

Puede inspeccionar el resultado en /var/log/ha-cluster-preflight-check.log.

9 Para más información #

Hay disponible más documentación sobre este producto en https://documentation.suse.com/sle-ha/. Para consultar otras tareas de configuración y administración, consulte la completa Guía de administración.

10 Información legal #

Está permitido copiar, distribuir y modificar este documento según los términos de la licencia de documentación gratuita GNU, versión 1.2 o (según su criterio) versión 1.3. Este aviso de copyright y licencia deberán permanecer inalterados. En la sección titulada “GNU Free Documentation License” (Licencia de documentación gratuita GNU) se incluye una copia de la versión 1.2 de la licencia.

Para obtener información sobre las marcas comerciales de SUSE, consulte http://www.suse.com/company/legal/. Todas las marcas comerciales de otros fabricantes son propiedad de sus respectivas empresas. Los símbolos de marca comercial (®,™ etc.) indican marcas comerciales de SUSE y sus afiliados. Los asteriscos (*) indican marcas comerciales de otros fabricantes.

Toda la información recogida en esta publicación se ha compilado prestando toda la atención posible al más mínimo detalle. Sin embargo, esto no garantiza una precisión total. Ni SUSE LLC, ni sus filiales, ni los autores o traductores serán responsables de los posibles errores o las consecuencias que de ellos pudieran derivarse.