Intro

La elección de CentOS para instalar el cluster de HA tiene su origen en el largo periodo de vida de esta distribución (unos 10 años).

Sin embargo, si no actualizamos el SO periódicamente este periodo de vida resultaría inutil, puesto que no estaríamos aplicando las actuailzaciones de seguridad que ofrece la distribución.

Para estar al día de las actualizaciones hemos creado una tarea de cron que básicamente chequea los paquetes disponibles para su actualización y nos manda un correo. El script se llamará check-updates.sh y lo pondremos dentro de la carpeta crones del directorio /home/virtual, que está dentro del recurso drbd datos. El contenido del script es el siguiente:

Actualización

Una vez que el sistema nos avisa de que hay paquetes disponibles, hay que actualizar.

Para ello, actualizaremos primero un nodo y luego el otro. Emplearemos el siguiente esquema:

  1. Pasar las máquinas virtuales al nodo que no se va a actualizar
  2. Poner el nodo a actualizar en standby
  3. Actualizar los paquetes del nodo
  4. Poner el kernel personalizado para drbd por defecto en la configuración de grub2
  5. Reiniciar el nodo
  6. Ajustes finales

Pasar las máquinas virtuales al nodo que no se va a actualizar

Para evitar la interrupción del servicio en las máquinas virtuales que están corriendo en el cluster, hemos de pasarlas todas al nodo que no se va actualizar antes de comenzar con la actualización.

Puesto que nos interesa que el propio cluster gestione la localización de las máquinas virtuales en fución principalmente de la carga de los nodos, lo ideal es que lo recursos que constituyen las máquinas virtuales no tengan constricciones de localización durante el funcionamiento normal del cluster. Sin embargo, si no tenemos por costumbre ‘limpiar’ los recursos tras las migraciones, es posible que éstos contengan algún tipo de constricción de preferencia consecuencia de haber sido transferidos a ese nodo con anterioridad. Para ver si los recursos tienen restricciones de ese tipo empleamos el comando siguiente:

pcs constraint ref recurso

Donde recurso es el recurso sobre el que queremos conocer las restricciones. En el siguiente ejemplo veremos las restricciones sobre la máquina virtual oc8:

# pcs constraint ref oc8
Resource: oc8
cli-prefer-oc8
order-res_libvirtd-clone-oc8-mandatory

La línea cli-prefer-oc8 la añade el cluster cuando movemos el recurso desde otro nodo para evitar que vuelva a su nodo original automáticamente, lo que se suele producir para balancear la carga entre nodos.

Si queremos comenzar actualizando el node1, hemos de decirle a todos los recursos que prefieren el node2. De otro modo, cuando levantemos el node1 tras la actualización los recursos tratarán de migrar al node1 antes de tiempo y provocarán cuando menos una interrupción temporal de los mismos.

Pero antes hemos de asegurarnos de que los recursos que actualmente están corriendo en el nodo2 no migren al nodo1 para balancear la carga cuando pasemos los del nodo1 al nodo2. Para ello fijamos los recursos que actualmente están corriendo en el nodo 2 con un constraint de location para el recurso en el nodo2. Si tenemos el recurso ws2008 corriendo en el nodo2:

#pcs constraint location ws2008 prefers node2=INFINITY

Repetiríamos el proceso para todos los recursos asignados al nodo2 y que deberán permanecer allí aunque añadamos los recursos del nodo1.

 

Migrando los recursos al nodo2

Ahora hemos de indicar a los recursos del nodo1 que prefieren el nodo2. Supongamos que tenemos el recurso 0c8 corriendo en el nodo1. Para indicarle que prefiere el node2 haríamos:

# pcs constraint location oc8 prefers node2=INFINITY

Si listamos ahora los constraints del recurso oc8 veremos lo siguiente:

# pcs constraint ref oc8
Resource: oc8
cli-prefer-oc8
location-oc8-node2-INFINITY
order-res_libvirtd-clone-oc8-mandatory

Ahora le eliminamos la preferencia por el node1 que viene en la restricción cli-prefer-oc8 mediante el comando:

# pcs constraint delete cli-prefer-oc8

En ese momento podemos ver como el cluster migra la máquina virtual del node1 al node2 sin interrupción.

Si miramos ahora las restricciones del resource 0c8 veremos lo siguiente:

# pcs constraint ref oc8
Resource: oc8
location-oc8-node2-INFINITY
order-res_libvirtd-clone-oc8-mandatory

Haríamos lo mismo para todas las máquinas virtuales.

Cuando establecemos la preferencia de localización de un recurso al nodo2 éste se mueve a dicho nodo inmediatamente si no existían restricciones de location previas del estilo de las que hemos mencionado anteriormente.

En el improbable caso de que el cluster no mueva automáticamente los recursos al nodo2 al indicarle la preferencia de localización podríamos moverlos a mano empleando el comando ‘move’. Si por ejemplo queremos mover el recurso oc8 al nodo2 haríamos lo siguiente:

# pcs resource move oc8 node2

 

Poner el nodo a actualizar en standby

Ahora habría que poner el nodo en standby para el cluster antes de actualizar. De ese modo, pacemaker será consciente de que no ha de mantenerlo activo. Empleamos el siguiente comando:

# pcs cluster standby node1

Hemos comprobado que a veces, tras la migración de los recursos al otro nodo, cuando ponemos el nodo a actualizar en standby (en nuestro caso node1), el sistema fuerza su reinicio.

Actualizar los paquetes del nodo

Puesto que la distribución de linux elegida para los nodos de nuestro cluster es CentOS, actualizamos empleando el siguiente comando:

# yum update

El sistema detecta los paquetes a actualizar y nos pregunta si los queremos actualizar, a lo que responderemos obviamente que si. Al cabo de unos minutos y de un montón de líneas en la pantalla, el sistema nos indicará que ya está actualizado tras la lista de paquetes instalados y actualizados.

 

Poner el kernel personalizado para drbd por defecto en la configuración de grub2

Posiblemente entre los paquetes a actualizar se encuentre el kernel. Lo normal es que cada vez que el sistema actualiza el kernel ponga el nuevo kernel por defecto para grub2. Sin embargo, si el sistema arrancase con este nuevo kernel, no podríamos montar los recursos drbd. Por ese motivo es muy importante que configuremos grub2 para que arranque desde nuestro kernel ‘tuneado’.

Para ver el kernel que tenemos corriendo y saber así cual hemos de poner por defecto, emplearemos la instrucción

# uname -a

Nos arroja la siguiente salida

Linux node1 3.10.80 #1 SMP Tue Jun 9 11:09:56 CEST 2015 x86_64 x86_64 x86_64 GNU/Linux

Hemos de buscar en /boot/grub2/grub.cfg la entrada que corresponda a nuestro kernel 3.10.80 dentro de las etiquetas menuentry

En nuestro caso aparece:

menuentry 'CentOS Linux (3.10.80) 7 (Core)'

Ya sabemos como llama grub2 a nuestro kernel.

Lo ponemos por defecto con la siguiente instrucción:

# grub2-set-default 'CentOS Linux (3.10.80) 7 (Core)'

Es posible evitar tener que modificar el kernel por defecto cada vez. Si tenemos un kernel modificado (por ejemplo para drbd), podemos decirle a yum que no actualice el kernel incluyendo la siguiente línea en la sección [main] del archivo /etc/yum.conf: exclude=kernel*

 

IMPORTANTE: Hemos de comprobar que la actualización no nos ha vuelto el archivo /usr/lib/ocf/resource.d/heartbeat/VirtualDomain a la versión antigua, pues tiene un bug y provoca continuos stonith entre los nodos cuando se tratan de migrar las máquinas virtuales o en el mejor de los casos impide que las máquinas virtuales se puedan migrar de uno a otro nodo sin apagarse.

Reiniciar el nodo

Tras poner nuestro kernel por defecto hemos de reiniciar el nodo para asegurarnos de que se cargan correctamente los nuevos ejecutables instalados en la actualización.

# reboot

Si estamos conectados por ssh el sistema se desconectará y para ver cuando podemos tratar de conectar de nuevo empleamos el ping:

localhost$ ping node1

Cuando recibamos respuesta (lo que dependerá de lo rápido que el nodo reinicie) podremos conectar de nuevo con el nodo para terminar la actualización.

 

Ajustes finales del nodo

Lo normal es instalar drbd como un módulo del kernel puesto que el rendimiento es el mismo que si lo instalamos dentro del propio kernel y de ese modo creamos un kernel de menor tamaño. Salvo que instruyamos al sistema de otro modo, lo normal es que tras el reinicio el nodo no haya cargado el módulo drbd. Para comprobarlo tratamos de ver el estado del drbd:

# drbd-overview

Si estamos en lo cierto y el sistema no ha cargado el módulo al inicio, nos contestará lo siguiente:

drbd not loaded

Cargamos pues el módulo:

# modprobe drbd

Si hacemos de nuevo un drbd-overview, en este caso responderá:

0:datos/0  Unconfigured . . . .

Nos está indicando que hay un volumen drbd llamado datos que no está configurado, por lo que habremos de ‘levantar’ el volumen.

Antes de levantar el volumen datos hemos de activar pacemaker.

Si no tenemos dicho al sistema que arranque pacemaker al inicio, este es el momento de indicárselo. Primero lo comprobamos:

# systemctl status pacemaker

Si no está cargado, para cargarlo hacemos:

# systemctl start pacemaker

Si queremos que el sistema lo cargue al inicio tendríamos que hacer:

# systemctl enable pacemaker

Si levantamos el volumen antes de activar pacemaker, éste lo desmonta. Una vez iniciado pacemaker si que podemos levantar el volumen:

#drbdadm up datos

La salida es la siguiente (no hay que preocuparse):

/usr/local/var/run/drbd: No such file or directory
/usr/local/var/run/drbd: No such file or directory

Si hacemos de nuevo drbd-overview, el resultado es distinto:

0:datos/0  Connected Secondary/Primary UpToDate/UpToDate C r-----

De este modo nos está indicando que el volumen datos está conectado y nuestro nodo es Secundario para el mismo, aunque está actualizado en ambos nodos (UpToDate/UpToDate). Si no lo estuviese, el sistema actualiza el contenido del volumen datos del nodo donde está actualizado al otro.

Una vez cargado pacemaker hemos de sacar el nodo de su estado de standby mediante el comando:

# pcs cluster unstandby node1

Si todo va bien el pacemaker se encarga de poner el volumen datos como primario en el nodo y arrancar por orden los recursos, excepto las máquinas virtuales, que deben estar corriendo en el otro nodo.

Si en un tiempo prudente (un par de minutos como mucho) pacemaker no pone como primario el nodo que hemos sacado de standby es posible que ese nodo hubiera sufrido un stonith. En ese caso el sistema crea un constraint que evita que se ponga como primario. Una vez nos hemos asegurado de que en ambos nodos el volumen drbd está UpToDate habría que eliminar este constraint

 

Ahora es el momento de migrar todas las máquinas virtuales del node2 al node1 y comenzar con la actualización de éste.

 

Para terminar

Antes de ponernos con otra cosa hemos de asegurarnos de eliminar los constraint que hemos puesto a los recursos para pasarlos al nodo que no se va a actualizar.

Al quitar estos constraints el sistema se encarga de mover ‘en caliente’ los recursos para balancear la carga.

Ahora ya podemos ir a por esa merecida cerveza.