Ver el código de «Ubuntu Cluster con Pacemaker»

Apuntes sobre como he instalado un cluster en ubuntu, para distribuir recursos en HA entre dos máquinas. 

En este caso lo que buscaba era tener solamente unas IP's balanceando entre las dos máquinas, para que si una de ellas se caia fuera la otra la que asumiera el rol de esa VIP.

Las pruebas son con Ubuntu 14.04

En primero lugar he instalado el paquete pacemaker de Ubuntu, el cual me ha instalado otros tantos, entre ellos corosync y cluster-glue

<pre>
apt-get install pacemaker
The following NEW packages will be installed:
  cluster-glue corosync crmsh libcfg6 libcib3 libcmap4 libcorosync-common4
  libcpg4 libcrmcluster4 libcrmcommon3 libcrmservice1 libesmtp6 libheartbeat2
  libibverbs1 liblrm2 liblrmd1 libnet1 libnspr4 libnss3 libnss3-nssdb
  libopenhpi2 libopenipmi0 libpe-rules2 libpe-status4 libpengine4 libperl5.18
  libpils2 libplumb2 libplumbgpl2 libqb0 libquorum5 librdmacm1 libsam4
  libsnmp-base libsnmp30 libstonith1 libstonithd2 libtotem-pg5
  libtransitioner2 libvotequorum6 libxslt1.1 openhpid pacemaker
  pacemaker-cli-utils python-lxml resource-agents
</pre>

Una vez instalados los paquetes necesarios parece que hace falta que se vean entre las dos máquinas através del servicio corosync, para lo cual hay que generar unas claves ssh que hay pasar de una a otra máquina.

Desde una de las máqiunas, en este caso la llamada secmon1, he creado la clave con:
<pre>
root# corosync-keygen
</pre>

hay que generar entropia pulsando muchas vece sel teclado. Una vez finalizado ya tenemos nuestro nuevo fichero con la clave, en /etc/corosync/authkey

Este fichero tendremos que copiarlo de alugna forma a los otros nodos, en mi caso al secmon2, en la misma ruta.

Después editamos el fichero de configuracion de /etc/corosync/corosync.conf, para editar la parte en el que especificamos la interface por la que se va a sincronizar:

<pre>
        interface {
                # The following values need to be set based on your environment
                ringnumber: 0
                '''bindnetaddr: 10.15.74.0'''
                mcastaddr: 226.94.1.1
                mcastport: 5405
        }
</pre>

Y tambien para que el servicio se pueda arrancar tenemos que editar en ambas máqiunas el fichero /etc/default/corosync:

<pre>
# start corosync at boot [yes|no]
START=yes
</pre>

Ahora ya podemos arrancar el servicio corosync y de pacemaker

<pre>
# service corosync start
# service pacemaker start
</pre>


=== DRBD ===

Para configurar el disco compartido entre las dos máqiunas con DRBD, tendremos que instalar en primer lugar el paquete necesario

<pre>
root# apt-get install drbd8-utils
</pre>

También tendremos que cargar el módulo de kernel

<pre>
modprobe drbd
</pre>

y tendremos que añadir el módulo en el /etc/modules

Para este ejemplo vamos a usar un disco lógico de LVM para hacer la replicación de los discos

El disco con el que voy a trabajar se llama:

/dev/mapper/tde--pro--secmon1--vg-quorum

Sobre este disco vamos a hacer una partición primaria que será la que vamos a replicar a l otro nodo:

<pre>
disk /dev/mapper/tde--pro--secmon1--vg-quorum: 524 MB, 524288000 bytes
189 heads, 61 sectors/track, 88 cylinders, total 1024000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x7488a29d

                                   Device Boot      Start         End      Blocks   Id  System
/dev/mapper/tde--pro--secmon1--vg-quorum1            2048     1023999      510976   83  Linux
</pre>


Tenemos que realizar la misma operación en el otro nodo, ya que las particiones han de ser idénticas. Podemos hacer uso de sfdisk -d para hacer volcado de la configuración del primero de los servers para después aplicarlo en los sucesivos


Una vez tengamos las particiones creadas y preparadas en las máquinas podemos definir la configuracion de nuestro cluster DRDM. Editamos el fichero de configuracion: /etc/drbd.d/quorum.res

<pre>
resource vote{
        device /dev/drbd0;
        disk /dev/mapper/vg_cluster-vote;
        meta-disk internal;
        protocol C;
        on datanode1 {
                address 192.168.33.46:7788;
        }
        on datanode2 {
                address 192.168.33.47:7788;
        }
        syncer {
                rate 10M;
        }
}
</pre>

Esta configuración va en cada uno de los servidores con drbd, teniendo en cuenta el nombre de disco en cada caso (en mi caso era diferente para un servidor y para otro, porque el vg de lvm se llamaba diferente en cada servidor)

En cada uno de los servidores creamos el sistema de bloques de drbd

<pre>
drbdadm create-md quorum
</pre>

y levantamos el disco

<pre>
drbdadm up quorum
</pre>

Podemos ver el estado de este disco con:

<pre>
drbd-overview
</pre>


Ahora tenemos que inicializar la sincronización de los discos, para lo cual:

<pre>
drbdadm -- --overwrite-data-of-peer primary quorum
</pre>

y con esto tendremos que ver que ya están sincronizados, en ambos lados:

<pre>
oot@tde-pro-secmon2:/etc/drbd.d# drbd-overview
  0:quorum/0  Connected Secondary/Primary UpToDate/UpToDate C r-----
</pre>

Ahora, podemos darle formato al disco, asegurándonos que en nodo en el que lo vamos a hacer tiene el rol de primario

<pre>
# drbdadm primary quorum
# mkfs.ext4 /dev/drbd0
</pre>


Si el nodo actual es el primario veremos mensajes como el siguiente

<pre>
Wed Mar 25 15:54:28 UTC 2015
  0:vote/0  Connected Primary/Secondary UpToDate/UpToDate C r-----
</pre>

Pone lo de Primary por delante, si este fuera el nodo secundario sería al revés. Si el nodo no estuvieria conectado, y por lo tanto sincronizando, en vez de connected veríamos un "StandAlone". Otra posibilidad es que veamos un WFConnecting, lo que quiere decir que no es capaz de conectar contra el otro nodo.

Antes de empezar a configurar el cluster en sí, tendremos que parar el servicio DRBD, y hacer que no se arranque el servicio de forma automática, ya que será pacemaker el encargado de levantarlo.

<pre>
# service drbd stop
# update-rc.d drbd remove 
</pre>

=== Configurando el cluster ===

==== Como se configura el cluster ====
Con el comando "crm" se maneja todo lo referente a la configuracion de recursos, propiedades, y demas cosas relacionadas con un cluster

Por ejemplo, para manejar los recrusos se utiliza "crm resource" y para cambiar las configuraciones se usa "crm configure"

Si solo ponemos esos comandos entramos en una shell de configuración, pero si añadimos alguno comando a continuación no entramos en ese modo shell:

<pre>
# crm configure property stonith-enabled=false
</pre>

==== La problemática del quorum en un cluster de 2 nodos ====
Antes de nada, es una lectura muy recomendable la de este [http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html/Clusters_from_Scratch/_perform_a_failover.html#_quorum_and_two_node_clusters enlace], que comenta la problématica cuando tenemos un cluster de solo dos nodos. Es importante porque con solo dos nodos es dificil determinar con exactitud si uno de los nodos se ha caido. Se dice que un cluster tiene quorum cunado más de la mitad de los nodos están activos, así que solo es válido a partir de 3 nodos

<pre>
total_nodes < 2 * active_nodes
</pre>

Si solo tenemos dos nodos, y uno de ellos se cae, no se cumple esta regla, y por lo tanto perdemos el quroum. Por defecto, pacemaker tiene la configuracion por defecto para que cuando se pierda el quorum se paren los recursos, pero esta política se puede sobreescribir con este parámetro:

<pre>
crm configure property no-quorum-policy="ignore"
</pre>

De esta forma, cuando se pierde el quorum, no realiza ninguna acción.

==== Stonith ====
Traducido como Shoot the Other Node In The Head. Es otra cosa que es dificil de gestionar cuando tenemos un cluster de solo dos nodos. Siempre se puede dar la casuistica en la que los dos nodos se dejan de ver e intentantan eliminarse mutuamente. Se puede leer este [http://ourobengr.com/ha/ articulo] muy interesante sobre el tema.

Por resumir, tendremos que añadir la siguiente configuración al cluster

<pre>
# crm configure property stonith-enabled=false
</pre>


==== Configuration de DRBD ====

Ahora que ya tenemos la base de nuestro cluster podemos empezar a configurar los recursos. Uno de ellos son discos replicados con DRBD. Un ejemplo de configuración sencilla según el disco DRBD sincronizado que hemos configurado antes sería:

<pre>
primitive drbd0 ocf:linbit:drbd \
	params drbd_resource="vote" \
	op monitor interval="20s" role="Slave" timeout="20s" \
	op monitor interval="15s" role="Master" timeout="20s"
ms ms-drbd0 drbd0 \
	meta clone-max="2" notify="true"
</pre>


En estas líneas configuramos dos cosas
* un recruso de disco DRBD
* un servicio en Master/Slave

Con la cláusula '''primitive''' definimos el recurso drbd al que llamamos drbd0, y le indicamos que es el disco DRBD "vote" que hemos definido en nuestra conf de DRBD más arriba

Con '''ms''' configuramos ese recurso en Maestro/esclavo. Indcamos que a este servicio ms lo llamamos "ms-drbd0" y que vamos a usar el recurso "drbd0", que como mucho va a haber dos instancias de este servicio. Se pueden especificar muchas más opciones sobre esto.


Podemos definir cuando un servicio está en MS, cuales son los posibles nodos en los que puede estar el servicio:

<pre>
location ms-drbd0-placement ms-drbd0 \
rule -inf: \#uname ne datanode1 and \#uname ne datanode2
</pre>

Es un poco rebuscado, pero con esas líneas le estamos diciendo al cluster que recurso MS "ms-drbd0" NO va a estar en ningún nodo salvo en "datanode1" o en "datanode". Supongo que esto tiene sentido en cluster con muchos nodos y solo queremos que el servicio esté en dos de ellos.

También podemos definir que un recurso en MS tenga un nodo preferido:

<pre>
location ms-drbd0-master-on-datanode1 ms-drbd0 \
rule role="master" 100: \#uname eq datanode1
</pre>