Alta disponibilidad con clúster en Centos 7

En esta entrada vamos a ver como montar un clúster de alta disponibilidad, en sus siglas HA, de su nombre en inglés “High Availability”, en un servidor con Centos 7. De esta manera podemos ver su instalación, configuración y mantenimiento.

Hay que tener en cuenta que un clúster, en computación, está formado por dos o más nodos, que trabajan juntos para realizar cierta tarea. De esta manera si uno de los nodos falla el otro nodo seguirá suministrando el servicio.

Alta disponibilidad con clúster en Centos 7

Los clústeres pueden ser de diferentes tipos:

• De Almacenamiento: proporciona una imagen del sistema de ficheros coherente, a través de los servicios suministrados por el clúster, permitiendo que los servidores lean y escriban simultáneamente en un solo de ficheros compartido.
• Alta disponibilidad: elimina los puntos únicos de fallo y conmuta los servicios ante un error en unos de los nodos.
• Equilibrio de carga: envía solicitudes de servicio de red a varios nodos del clúster para equilibrar la carga de solicitud entre los nodos.
• Alto rendimiento: realiza un procesamiento en paralelo o simultaneo, lo que ayuda a mejorar el rendimiento de las aplicaciones.

Otra solución ampliamente utilizada para ofrecer HA es la replicación (específicamente la replicación de datos) La replicación es el proceso mediante el cual una o más bases de datos (secundarias) se pueden mantener sincronizadas con una única base de datos principal (o maestra)

Para este artículo utilizaremos dos nodos, con los nombres:

• Nodo 1: servnode1 con IP 192.168.0.150
• Nodo 2: servnode2 con IP 192.168.0.151

Crearemos un clúster activo – pasivo, con una IP virtual y un servicio de web de Apache.

Pasos previos

Para evitar posibles problemas vamos a deshabilitar SELinux, editando su fichero de configuración:

1

vi /etc/selinux/config

Y sustituir:

1

SELINUX=enforcing

Por:

1

SELINUX=disabled

Guardamos y salimos.

Para que se apliquen los cambios debemos reiniciar.

Además, deshabilitamos el cortafuegos para simplificar las cosas:

1
2

systemctl disable firewalld
systemctl stop firewalld

Configurar el DNS local

Para que las dos máquinas se puedan comunicar entre sí se debeconfigurar el DNS local, mediante la configuración del fichero “/etc/hosts”, en ambos nodos.

1

vi /etc/hosts

Y añadimos:

1
2

192.168.0.150 servnode1.localdomain servnode1
192.168.0.151 servnode2.localdomain servnode2

Guardamos y salimos con : “:wq”

Instalar el servidor Web Apache

La instalación es bien sencilla, para instalar Apache:

1

yum -y install httpd

Esto, al igual que el resto de los pasos, se tienen que hacer en ambos nodos.

Además vamos a crear un fichero de configuración que nos muestra el estado del servidor Apache:

1

vi /etc/httpd/conf.d/status.conf

Con el contenido:

1
2
3
4
5
6

<Location /server-status>
   SetHandler server-status
   Order Deny,Allow
   Deny from all
   Allow from 127.0.0.1
</Location>

Estas directivas permiten el acceso a la página de estado solamente desde localhost del nodo activo.

Instalamos y configuramos Corosync y Pacemaker

Las piezas esenciales para el funcionamiento del clúster con Corosync, que nos provee del engine del clúster; con Pacemaker obtendremos las funciones básicas para que el grupo de nodos trabajen juntos en el clúster.

Instalación de Corosync, Pacemaker y pcs

Debemos ejecutar el siguiente comando:

1

yum install corosync pacemaker pcs

Una vez instalados nos debemos asegurar que la pieza pcs este encendida y añadido al arranque:

1
2
3

systemctl enable pcsd
systemctl start pcsd
systemctl status pcsd

Creamos el clúster

Durante la instalación se crea un usuario del sistema llamado “hacluster” Así que necesitamos asignarle una contraseña necesaria para la pieza “pcs” De la siguiente manera, en ambos nodos:

1

passwd hacluster

Una vez hecho esto, desde el nodo 1, ejecutamos el siguiente comentado:

1
2
3

[root@servnode1 ]# pcs cluster auth servnode1.localdomain servnode2.localdomain -u hacluster -p contrasea --force
servnode2.localdomain: Authorized
servnode1.localdomain: Authorized

Ahora ya podemos crear el clúster, con el nombre que deseemos, aunque no puede superar los 15 caracteres.

Con el comando:

1

pcs cluster setup --name nombre-que-deseemos servnode1.localdomain servnode2.localdomain

En mi caso:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

[root@servnode1 /]# pcs cluster setup --name clusterweb servnode1.localdomain servnode2.localdomain
Destroying cluster on nodes: servnode1.localdomain, servnode2.localdomain...
servnode1.localdomain: Stopping Cluster (pacemaker)...
servnode2.localdomain: Stopping Cluster (pacemaker)...
servnode2.localdomain: Successfully destroyed cluster
servnode1.localdomain: Successfully destroyed cluster
 
Sending 'pacemaker_remote authkey' to 'servnode1.localdomain', 'servnode2.localdomain'
servnode2.localdomain: successful distribution of the file 'pacemaker_remote authkey'
servnode1.localdomain: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
servnode1.localdomain: Succeeded
servnode2.localdomain: Succeeded
 
Synchronizing pcsd certificates on nodes servnode1.localdomain, servnode2.localdomain...
servnode2.localdomain: Success
servnode1.localdomain: Success
Restarting pcsd on the nodes in order to reload the certificates...
servnode2.localdomain: Success
servnode1.localdomain: Success

Ahora ya Podemos añadir el clúster al arranque y encenderlo:

1
2

pcs cluster enable –all
pcs cluster start –all

Tal como sigue:

1
2
3
4
5
6
7
8

[root@servnode1 /]# pcs cluster start --all
servnode1.localdomain: Starting Cluster (corosync)...
servnode2.localdomain: Starting Cluster (corosync)...
servnode1.localdomain: Starting Cluster (pacemaker)...
servnode2.localdomain: Starting Cluster (pacemaker)...
[root@servnode1 /]# pcs cluster enable --all
servnode1.localdomain: Cluster Enabled
servnode2.localdomain: Cluster Enabled

Podemos comprobar su estado, de las siguientes maneras:

1
2

pcs status
crm_mon -1

Una muestra en mi caso:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

[root@servnode1 /]# sudo pcs status
Cluster name: clusterweb
 
WARNINGS:
No stonith devices and stonith-enabled is not false
 
Stack: corosync
Current DC: servnode1.localdomain (version 1.1.19-8.el7_6.2-c3c624ea3d) - partition with quorum
Last updated: Thu Dec 20 10:37:37 2018
Last change: Thu Dec 20 10:33:38 2018 by hacluster via crmd on servnode1.localdomain
 
2 nodes configured
0 resources configured
 
Online: [ servnode1.localdomain servnode2.localdomain ]
 
No resources
 
 
Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled
[root@servnode1 /]# crm_mon -1
Stack: corosync
Current DC: servnode1.localdomain (version 1.1.19-8.el7_6.2-c3c624ea3d) - partition with quorum
Last updated: Thu Dec 20 10:37:48 2018
Last change: Thu Dec 20 10:33:38 2018 by hacluster via crmd on servnode1.localdomain
 
2 nodes configured
0 resources configured
 
Online: [ servnode1.localdomain servnode2.localdomain ]
 
No active resources

De esta manera observamos que los dos nodos están conectados, sin errores y en línea. Aún así se nos muestra la siguiente advertencia “No stonith devices and stonith-enabled is not false”, esto es debido a que no hemos definido el STONITH, que se encarga de realizar “fence”, también conocido como “te pego un tiro en la cabeza”, cuando uno de los nodos no funciona correctamente. Todavía nos queda más trabajo por delante, ya que tampoco hemos definido servicios.

Configurar las opciones del clúster

Como hemos dicho la pieza del STONITH esta habilitada por defecto, pero en esta guía no lo vamos a utilizar, por lo que lo vamos a deshabilitar.

Deshabilitamos STONITH :

1

pcs property set stonith-enabled=false

Además, indicamos que vamos a ignorar la política de cuórum:

1

pcs property set no-quorum-policy=ignore

Para asegurarnos que todo esta correcto, y que tanto el STONITH como la política de cuórum están deshabilitados:

1
2
3
4
5
6
7
8

[root@servnode1 /]#  pcs property list
Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: clusterweb
 dc-version: 1.1.19-8.el7_6.2-c3c624ea3d
 have-watchdog: false
 no-quorum-policy: ignore
 stonith-enabled: false

Añadir un nuevo servicio o recurso al clúster

En este apartado veremos como agregar un nuevo recurso a nuestro clúster. Una parte importante es configurar una IP virtual, llamada VIP, que se podrá mover de manera instánea de un nodo a otro dentro de la misma red o centro de datos. Necesitamos que esta VIP la utilice el nodo que en ese momento sea el activo.

Por lo que vamos a añadir dos recursos, uno será la VIP y el otro será el webserver con Apache.

Añadimos la siguiente la 192.168.0.160 como VIP, ejecutando la siguiente orden:

1

pcs resource create vip ocf:heartbeat:IPaddr2 ip=192.168.0.160 cidr_netmask=24 op monitor interval=60s

Analicemos las partes del comando:

• vip: Es el nombre del recurso
• “ocf:heartbeat:IPaddr2”: Le indicamos a pacemaker que script debe utilizar, IPaddr2 en este caso. Además definimos en que espacio de nombre se encuentra (pacemaker) y que estandar utiliza, que ese «ocf»
• “op monitor interval=60s”: Indica a pacemaker que verifique la salud del servicio cada minutos, esto es, 60 segundos.

Ahora que ya tenemos la IP de la VIP definida, pasamos a añadir el servicio web.

1
2

pcs resource create servicio_http ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf \
statusurl="http://127.0.0.1/server-status" op monitor interval=20s

Una vez añadidos ambos servicios. Los comprobamos:

1

pcs status resources

En mi caso:

1
2
3

[root@servnode1 conf]# pcs status resources
 vip    (ocf::heartbeat:IPaddr2):       Started servnode1.localdomain
 servicio_http  (ocf::heartbeat:apache):        Starting servnode2.localdomain

En cuanto a la salida del comando, se han enumerado los dos recursos agregados: «vip» y «servicio_http». Cada uno de los servicios están, en mi caso, en nodos diferentes.

A mi me interesa que tanto la VIP como al servicio de Apache estén en el mismo nodo.

Configuración de parámetros de INFINITY

Casi todas las decisiones en un grupo de pacemaker, como elegir dónde se debe ejecutar un recurso, se realizan comparando una serie de puntuaciones. Las puntuaciones se calculan por recurso, y el administrador de recursos de clúster elige el nodo con la puntuación más alta para un recurso en particular. (Si un nodo tiene una puntuación negativa para un recurso, el recurso no se puede ejecutar en ese nodo).

Podemos manipular las decisiones del clúster con restricciones. Las restricciones tienen una puntuación. Si una restricción tiene una puntuación inferior a INFINITY, es solo una recomendación. Una puntuación de INFINITY significa que es una necesidad.

Queremos asegurarnos de que ambos recursos se ejecuten en el mismo host, por lo que definiremos una restricción de colocación con una puntuación de INFINITY.

1

pcs constraint colocation add servicio_http vip INFINITY

De esta manena ya tenemos ambos recursos en el mismo host:

1
2
3
4

Full list of resources:
 
 vip    (ocf::heartbeat:IPaddr2):       Started servnode2.localdomain
 servicio_http  (ocf::heartbeat:apache):        Started servnode2.localdomain

Pruebas de funcionamiento del clúster

Vale, todo esto está muy bien, ¿pero funciona? Desde la consola de comandos, mediante el prograna «Lynx«, consultaremos el estado:

Consulta de estado utilizando Lynx

Hay que anotar que el servicio web de Apache ahora está gestionado directamente por el clúster. Podemos comprobar que esto es así, en el nodo activo:

1
2
3
4
5
6
7
8

[root@servnode2 conf.d]# lsof -i :80
COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
httpd   5871   root    4u  IPv6  32431      0t0  TCP *:http (LISTEN)
httpd   5872 apache    4u  IPv6  32431      0t0  TCP *:http (LISTEN)
httpd   5873 apache    4u  IPv6  32431      0t0  TCP *:http (LISTEN)
httpd   5874 apache    4u  IPv6  32431      0t0  TCP *:http (LISTEN)
httpd   5875 apache    4u  IPv6  32431      0t0  TCP *:http (LISTEN)
httpd   5876 apache    4u  IPv6  32431      0t0  TCP *:http (LISTEN)

NOTA: Es muy importante que no intentemos gestionar el servicio de httpd directamente, ya que todas las gestiones se tienen que realizar a través del propio clúster.

Y esto es todo por hoy. Espero que os haya parecido interesante. ¿Tenéis experiencia con la gestión de clústers? Podéis dejar vuestras opiniones en los comentarios.

Nos vamos leyendo.

Fuentes consultadas:

Tecmint – Setup High Availability clustering in Centos and Ubuntu
DigitalOcean – How to set up an Apache active passive cluster using pacemaker on Centos 7