SUSE Linux Enterprise High Availability Extension 15 SP5

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

Fecha de publicación: 11 de diciembre de 2023

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 la shell crm. 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.

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 propietarios respectivos. Los símbolos de marcas comerciales (®, ™, 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.

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.1.10) que permite a los clientes conectarse al servicio independientemente del nodo en el que se esté ejecutando. Esta dirección IP se utiliza para conectarse a la herramienta de gestión gráfica Hawk2.
Un dispositivo de almacenamiento compartido, que se utiliza como mecanismo de “fencing” del SBD. Esto evita que haya 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).

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, consulte el Administration Guide para modificar el clúster 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

Un dispositivo de "fencing" (o delimitación) de nodos (STONITH) para evitar que se produzcan nodos malinformados. Puede ser un dispositivo físico (un conmutador de alimentación) o un mecanismo como un SBD (STONITH por disco), en combinación con un watchdog (o vigilante). El SBD se puede utilizar con almacenamiento compartido o en modo sin disco. Este documento describe el uso del SBD con almacenamiento compartido. Se deben cumplir los siguientes requisitos:

Un dispositivo de almacenamiento compartido. Para obtener información sobre la configuración del almacenamiento compartido, consulte Storage Administration Guide for SUSE Linux Enterprise Server. Si solo necesita almacenamiento compartido básico para realizar pruebas, consulte el Apéndice A, Almacenamiento iSCSI básico para el SBD.
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 más información sobre STONITH, consulte el Chapter 12, Fencing and STONITH. Para obtener más información sobre el SBD, consulte el Chapter 13, Storage protection and SBD.

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 SP5
Server Applications Module 15 SP5
SUSE Linux Enterprise High Availability Extension15 SP5

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. Si desea información adicional, consulte Administration Guide for SUSE Linux Enterprise Server 15 SP5.

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.
Solo se admite la dirección IP principal.
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 #

Los comandos siguientes ejecutan guiones de bootstrap que requieren solo un mínimo de tiempo y de intervención manual.

Con crm 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 crm cluster join puede añadir más nodos al clúster.
Con crm cluster remove puede eliminar nodos del clúster.

Todos los guiones de bootstrap se registran en /var/log/crmsh/crmsh.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.

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

NTP

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

SSH

Crea claves SSH para el inicio de sesión 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

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

SBD/watchdog

Comprueba si existe un watchdog y 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

Define 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

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

Esta configuración no se trata aquí, pero puede configurarla más adelante como se describe en el Chapter 14, QDevice and QNetd.

4 Instalación de los paquetes de Alta disponibilidad #

Los paquetes para configurar y gestionar un clúster se incluyen en el patrón de instalación High Availability. Este patrón solo está disponible después de instalar SUSE Linux Enterprise High Availability Extension.

Puede registrarse en el Centro de servicios al cliente de SUSE e instalar High Availability Extension mientras instala SUSE Linux Enterprise Server o después de la instalación. Para obtener más información, consulte Deployment Guide para SUSE Linux Enterprise Server.

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

Instale el patrón Alta disponibilidad desde la línea de comandos:
```
# 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 todos los nodos
Para realizar una instalación automática de SUSE Linux Enterprise Server 15 SP5 y el paquete High Availability Extension, utilice AutoYaST para clonar los nodos existentes. Para obtener más información, consulte el Section 3.2, “Mass installation and deployment with AutoYaST”.

5 Uso del SBD para el "fencing" de nodos #

Antes de poder configurar el SBD con el guion de bootstrap, debe habilitar un watchdog en cada nodo. SUSE Linux Enterprise Server incluye varios módulos del kernel que proporcionan controladores de watchdog específicos del hardware. High Availability Extension utiliza el daemon de SBD como componente de software que “alimenta” al watchdog.

En el procedimiento siguiente se utiliza el watchdog 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 watchdogs 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 watchdog coincide con el hardware, se puede usar softdog como módulo de watchdog del kernel.

Procedimiento 2: Habilitación del watchdog softdog para el SBD #

En cada nodo, habilite el watchdog softdog:

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

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

6 Configuración del primer nodo #

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

Procedimiento 3: configuración del primer nodo (alice) con crm cluster init #

Inicie sesión en el primer nodo del clúster como root o como usuario con privilegios de sudo.
Importante: acceso de clave SSH de usuario de sudo
El clúster utiliza el acceso SSH sin contraseña para la comunicación entre los nodos. El guion crm cluster init comprueba las claves SSH y las genera si aún no existen.
Si pretende configurar el primer nodo como un usuario con privilegios de sudo, debe asegurarse de que las claves SSH del usuario existen (o se generarán) localmente en el nodo, no en un sistema remoto.
Inicie el guion de bootstrap:
```
# crm 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 utilizar multidifusión en lugar de unidifusión (valor por defecto) para la comunicación del clúster, utilice la opción --multicast (o -U).
Los guiones comprueban la configuración de NTP y si existe un servicio de watchdog de hardware. Si fuera necesario, genera las claves SSH pública y privada usadas para el acceso SSH y la sincronización de 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. Acepte el puerto propuesto (5405) o introduzca uno diferente.
Configure el SBD como mecanismo de "fencing" de nodo:
1. Confirme con y que desea utilizar el SBD.
2. Introduzca una vía persistente para la partición del dispositivo de bloques que desea utilizar para el SBD. La vía debe ser coherente en todos los nodos del clúster.
  El guion crea una pequeña partición en el dispositivo que se utilizará para el SBD.
Configure una dirección IP virtual para la administración del clúster con Hawk2:
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 Hawk2: 192.168.1.10.
  En lugar de iniciar sesión en un nodo de clúster individual con Hawk2, puede conectarse a la dirección IP virtual.
Elija si desea configurar QDevice y QNetd. Si desea optar por la instalación mínima descrita en este documento, rechace su configuración por ahora con n. Puede configurar QDevice y QNetd más adelante, como se describe en el Chapter 14, QDevice and QNetd.

Por último, el guion inicia los servicios del clúster 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 4: inicio de sesión 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 virtual que ha configurado con el guion de bootstrap:
```
https://192.168.1.10: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 inicio de sesión de Hawk2, escriba los valores de Nombre de usuario y Contraseña del usuario que creó el guion 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:
```
# passwd hacluster
```
Haga clic en Iniciar sesión. La interfaz Web de Hawk2 muestra por defecto la pantalla Estado:
Figura 1: estado del clúster de un nodo en Hawk2 #

7 Adición del segundo nodo #

Añada un segundo nodo al clúster con el guion de bootstrap crm cluster join. 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 información, consulte la página man de crm cluster join.

Procedimiento 5: adición del segundo nodo (bob) con crm cluster join #

Inicie sesión en el segundo nodo del clúster como root o como usuario con privilegios de sudo.
Inicie el guion de bootstrap:
Si configura el primer nodo como root, puede ejecutar este comando sin parámetros adicionales:
```
# crm cluster join
```
Si configura el primer nodo como usuario de sudo, debe especificar ese usuario con la opción -c:
```
> sudo crm cluster join -c USER@alice
```
Si NTP no se ha configurado para iniciarse durante el arranque, aparece un mensaje. El guion también comprueba si hay un dispositivo de watchdog de hardware. Recibirá una advertencia si no hay ninguno presente.
Si aún no ha especificado alice con -c, se le solicitará la dirección IP del primer nodo.
Si aún no ha configurado el acceso SSH sin contraseña entre ambos equipos, se le pedirá la contraseña del primer nodo.
Después de iniciar sesión en el nodo especificado, el guion copia la configuración de Corosync, configura SSH y Csync2, conecta el equipo actual como un nuevo nodo de clúster e 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:

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

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 escenarios específicos. Antes de utilizar el clúster en un entorno de producción, pruébelo exhaustivamente en consonancia con sus casos de uso.

El comando sbd -d DEVICE_NAME list muestra todos los nodos que son visibles para el SBD. Para la configuración descrita en este documento, el resultado debe mostrar alice y bob.
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 standby.
La Sección 8.2, “Pruebas con el comando crm cluster crash_test” simula fallos de clúster e informa de los resultados.

8.1 Prueba de failover de recursos #

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

Procedimiento 6: prueba de failover de recursos #

Abra un terminal y ejecute un ping a 192.168.1.10, la dirección IP virtual:
```
# ping 192.168.1.10
```
Inicie sesión en Hawk2.
En la opción Estado › Recursos, marque el nodo en el que se está ejecutando la dirección IP virtual (recurso admin_addr). Este procedimiento interpreta que el recurso se está ejecutando en alice.
Ponga 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 `crm cluster crash_test` #

El comando crm cluster crash_test activa los errores del clúster para buscar posibles 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:

--split-brain-iptables: Simula una situación de clústeres con nodos malinformados mediante el bloqueo del puerto de Corosync. Comprueba si un nodo se puede aislar en la medida de lo esperado.
--kill-sbd/--kill-corosync/ --kill-pacemakerd: Detiene los daemons para el SBD, Corosync y 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 las 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, consulte el crm cluster crash_test --help.

Ejemplo 1: prueba del clúster: "fencing" de nodo #

# 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

# crm cluster crash_test --fence-node bob

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

!!! 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 60s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

Para observar el cambio de estado de bob durante la prueba, inicie sesión en Hawk2 y acceda a Estado › Nodos.

9 Pasos siguientes #

Los guiones de bootstrap proporcionan una forma rápida de configurar un clúster de Alta disponibilidad básico que puede utilizarse con fines de prueba. Sin embargo, para expandir este clúster a un clúster de Alta disponibilidad en funcionamiento que se pueda usar en entornos de producción, se recomiendan más pasos.

Pasos recomendados para completar la configuración del clúster de Alta disponibilidad #

Adición de más nodos

Añada más nodos al clúster mediante uno de los siguientes métodos:

Para los nodos individuales, utilice el guion crm cluster join como se describe en la Sección 7, “Adición del segundo nodo”.
Para la instalación masiva de varios nodos, utilice AutoYaST como se describe en el Section 3.2, “Mass installation and deployment with AutoYaST”.

Un clúster normal puede contener hasta 32 nodos. Con el servicio pacemaker_remote, los clústeres de Alta disponibilidad se pueden ampliar para incluir nodos adicionales más allá de este límite. Consulte el Pacemaker Remote Quick Start para obtener más información.

Configuración de QDevice

Si el clúster tiene un número par de nodos, configure QDevice y QNetd para participar en las decisiones de quórum. QDevice proporciona un número configurable de votos, lo que permite que un clúster mantenga más fallos de nodo de los que permiten las reglas de quórum estándar. Para obtener información, consulte el Chapter 14, QDevice and QNetd.

Habilitación de un watchdog de hardware

Antes de utilizar el clúster en un entorno de producción, sustituya el módulo softdog por el módulo de hardware que mejor se adapte al hardware existente. Para obtener información, consulte el Section 13.6, “Setting up the watchdog”.

10 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 Administration Guide.