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.

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

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

: 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 vi /etc/selinux/config

Y sustituir:

1 SELINUX =enforcing SELINUX=enforcing

Por:

1 SELINUX =disabled 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 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 vi /etc/hosts

Y añadimos:

1 2 192.168.0.150 servnode1.localdomain servnode1 192.168.0.151 servnode2.localdomain servnode2 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 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 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 > <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 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 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 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 [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 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 [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 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 [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 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 [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 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 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 [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 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 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 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 [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 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 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:

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 ) [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