systemadmin.es > Clustering > Cluster con DRBD y heartbeat 2 / pacemaker

Cluster con DRBD y heartbeat 2 / pacemaker

Siguiendo con la instalación y configuración de heartbeat 2 vamos a ver como instalar un servicio con datos en disco con DRBD.

Gracias a DRBD podemos simular un disco compartido entre dos equipos mediante un disco local en cada uno de ellos y DRBD sincronizando los datos por red. Vamos a ver un ejemplo de uso de DRBD con sphinx con alta disponibilidad con pacemaker/heartbeat2.

Suponiendo que ya tenemos instalado heartbeat procedemos a instalar DRBD en todos los nodos:

yum install drbd83 kmod-drbd83 -y
modprobe drbd

Empezamos a partir de la configuración de ejemplo que viene con el paquete drbd83:

'cp' /usr/share/doc/drbd*/drbd.conf /etc/drbd.conf 
sed 's/\(syncer.*$\)/\1\n\t\trate 40M;/g' -i /etc/drbd.d/global_common.conf

Y definimos nuestro primer recurso DRBD, por ejemplo un disco para el daemon sphinx (por ejemplo). En dicho fichero deberemos indicar los hosts que pertenecen al cluster y que disco local usar (que deberá ser del mismo tamaño). En dicho disco se van a almacenar los datos y se sincronizaran por red con el resto de discos que definamos. El fichero a generar debe estar entro de /etc/drbd.d/ con la extensión .res, por ejemplo, /etc/drbd.d/shpinx.res

resource sphinx
{
  device    /dev/drbd0;
  meta-disk internal;

  protocol  C;

  on host1
  {
    address   172.16.0.10:7789;
    disk      /dev/sdb;
  }
  on host2
  {
    address   172.16.0.11:7789;
    disk      /dev/sdb;
  }
}

Ahora en uno de los nodos inicializamos los metadatos del disco:

# drbdadm create-md sphinx

  --==  Thank you for participating in the global usage survey  ==--
The server's response is:

you are the 7979th user to install this version
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
success

En el caso que ya tengamos datos en el disco nos avisará de ello y nos pedirá confirmación para modificar el sistema de ficheros:

# drbdadm create-md sphinx

  --==  Thank you for participating in the global usage survey  ==--
The server's response is:

you are the 8805th user to install this version
md_offset 32212250624
al_offset 32212217856
bm_offset 32211234816

Found ext3 filesystem
    10485760 kB data area apparently used
    31456284 kB left usable by current configuration

Even though it looks like this would place the new meta data into
unused space, you still need to confirm, as this is only a guess.

Do you want to proceed?
[need to type 'yes' to confirm] yes

Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
success

Levantamos el recursos DRBD:

drbdadm up sphinx

A continuación en /proc/drbd podremos ver como se ha levantado el recurso DRBD:

[root@host1 ~]# cat /proc/drbd 
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:16
 0: cs:WFConnection ro:Secondary/Unknown ds:Inconsistent/DUnknown C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:102360

Apreciamos como nos indica que esta en un estado inconsistente, ya que los discos aún no se han sincronizado. A continuación, si tenemos datos en uno de los discos, debemos ejecutar en el nodo que tenga los datos lo siguiente:

drbdadm -- --overwrite-data-of-peer primary sphinx

De esta forma se copiaran los bloques del disco del equipo dónde lo ejecutemos al disco del equipo secundario (más adelante se va a sobrescribir ese disco)

En el caso que en ninguno de los discos de los dos equipos tengamos datos podemos simplemente marcar los discos como iguales con:

drbdadm -- --clear-bitmap new-current-uuid r0

De esta forma nos ahorramos traspasar unos bloques que realmente no contienen nada y a medida que se modifiquen se irán sincronizando realmente.

En el /proc/drbd veremos como cambia de Inconsistent a UpToDate:

[root@host1 ~]# cat /proc/drbd 
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:16
 0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:102360

Ahora en el nodo secundario procedemos a levantar también el recurso DRBD, procediendo a la sincronización de los datos con el nodo principal:

drbdadm create-md sphinx
drbdadm up sphinx

En el /proc/drbd veremos el progreso de sincronización:

[root@host2 ~]# cat /proc/drbd 
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:09
 0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r----
    ns:0 nr:3262752 dw:3262720 dr:0 al:0 bm:199 lo:2 pe:16674 ua:1 ap:0 ep:1 wo:b oos:28193564
	[=>..................] sync'ed: 10.4% (27532/30716)M queue_delay: 18.5 ms
	finish: 0:37:02 speed: 12,660 (5,456) want: 40,960 K/sec

Cuando acabe veremos como pasa de Inconsistent/UpToDate a UpToDate/UpToDate:

[root@host2 ~]# cat /proc/drbd 
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:16
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:102360 dw:102360 dr:0 al:0 bm:7 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

A continuación deberemos añdir el recurso DRBD al cluster mediante ocf:linbit:drbd:

# crm ra info ocf:linbit:drbd
This resource agent manages a DRBD resource
as a master/slave resource. DRBD is a shared-nothing replicated storage
device. (ocf:linbit:drbd)

Master/Slave OCF Resource Agent for DRBD

Parameters (* denotes required, [] the default):

drbd_resource* (string): drbd resource name
    The name of the drbd resource from the drbd.conf file.

drbdconf (string, [/etc/drbd.conf]): Path to drbd.conf
    Full path to the drbd.conf file.

Operations' defaults (advisory minimum):

    start         timeout=240
    promote       timeout=90
    demote        timeout=90
    notify        timeout=90
    stop          timeout=100
    monitor_Slave_0 interval=20 timeout=20 start-delay=1m
    monitor_Master_0 interval=10 timeout=20 start-delay=1m

Para a versión 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3 dicho script (/usr/lib/ocf/resource.d/linbit/drbd) da muchos problemas, por lo que deberemos substituirlo por el disponible en el git. Debremos ejecutar lo siguiente en los dos nodos:

wget 'http://git.drbd.org/?p=drbd-8.3.git;a=blob_plain;f=scripts/drbd.ocf' -O /usr/lib/ocf/resource.d/linbit/drbd

A continuación añadimos el recurso DRBD:

crm configure primitive drbdsphinx ocf:linbit:drbd params drbd_resource="sphinx"

A continuación deberemos indicar las limitaciones de DRBD:

  • clone-max=”2″: Sólo puede estar en dos instancias
  • clone-node-max=”1″: Una instancia por nodo
  • master-max=”1″: Máximo 1 solo master
  • master-node-max=”1″: Máximo 1 master por nodo
  • notify=”true”: Se debe notificar al recurso que ocurre al peer

Quedando el comando:

crm configure ms ms_drbdsphinx drbdsphinx \
    meta master-max="1" master-node-max="1" clone-max="2" \
    clone-node-max="1" notify="true"

A continuación limpiamos los mensajes de error que se hayan generado mientras el DRBD no pertenecía a un set master/slave con:

crm resource cleanup drbdsphinx

Podemos comprobar la alta disponibilidad del recurso DRBD con el /proc/drbd. Nos dirigimos al nodo actualmente secundario y hacemos un cat. Veremos lo siguiente:

[root@host2 ~]# cat /proc/drbd 
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:16
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Si apagamos el heartbeat del nodo primario veremos como el secundario pasa a ser el master:

[root@host2 ~]# crm status
============
Last updated: Fri Mar 18 14:45:36 2011
Stack: Heartbeat
Current DC: host2 (a49ba348-6ace-4bb3-a51f-831a72b7cdf3) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ host2 ]
OFFLINE: [ host1 ]

 Master/Slave Set: ms_drbdsphinx
     Masters: [ host2 ]
     Stopped: [ drbdsphinx:1 ]

En el fichero /proc/drbd del secundario apreciamos como cambia de Secondary/Primary a Primary/Unknown:

[root@host2 ~]# cat /proc/drbd 
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:16
 0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Al volver a arrancar el heartbeat en el nodo primario vemos como se mantiene en el nodo secundario:

[root@host1 ~]# crm status
============
Last updated: Fri Mar 18 15:06:49 2011
Stack: Heartbeat
Current DC: host2 (a49ba348-6ace-4bb3-a51f-831a72b7cdf3) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ host1 host2 ]

 Master/Slave Set: ms_drbdsphinx
     Masters: [ host2 ]
     Slaves: [ host1 ]

A continuación, en el caso que el disco aún no contenga datos deberemos crear el sistema de ficheros desde el nodo que sea el master:

# mkfs.ext3 /dev/drbd/by-res/sphinx

En los dos nodos deberemos crear el punto de montaje:

mkdir -p /var/sphinx

A continuación deberemos indicar al cluster que debe gestionar el montaje y desmontaje del sistema de ficheros mediante heartbeat:Filesystem:

# crm ra info heartbeat:Filesystem
heartbeat:Filesystem

Filesystem

Operations' defaults (advisory minimum):

    start         timeout=15
    stop          timeout=15
    status        timeout=15
    monitor_0     interval=15 timeout=15 start-delay=15

Vemos que el crm ra info no aporta la información necesaria, por lo que, en algunos casos, buscando con grep en el script (/usr/lib/ocf/resource.d/heartbeat/Filesystem) comentarios que contengan OCF_RESKEY podemos obtener la información necesaria para usarlo:

# grep -e "#\s*OCF_RESKEY" /usr/lib/ocf/resource.d/heartbeat/Filesystem 
#		OCF_RESKEY_device
#		OCF_RESKEY_directory
#		OCF_RESKEY_fstype
#		OCF_RESKEY_options
#		OCF_RESKEY_statusfile_prefix
#OCF_RESKEY_device    : name of block device for the filesystem. e.g. /dev/sda1, /dev/md0
#OCF_RESKEY_directory : the mount point for the filesystem
#OCF_RESKEY_fstype    : optional name of the filesystem type. e.g. ext2
#OCF_RESKEY_options   : options to be given to the mount command via -o
#OCF_RESKEY_statusfile_prefix : the prefix used for a status file for monitoring

Con estas opciones añadimos el recurso para que monte el sistema de ficheros:

crm configure primitive fssphinx ocf:heartbeat:Filesystem \
    params device="/dev/drbd/by-res/sphinx" directory="/var/sphinx/" \
    fstype="ext3"

Comprobamos que se ha añadido con crm status:

# crm status
============
Last updated: Fri Mar 18 15:35:31 2011
Stack: Heartbeat
Current DC: host2 (a49ba348-6ace-4bb3-a51f-831a72b7cdf3) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ host1 host2 ]

 Master/Slave Set: ms_drbdsphinx
     Masters: [ host2 ]
     Slaves: [ host1 ]
 fssphinx	(ocf::heartbeat:Filesystem):	Started host2

En este caso se ha levantado bien, pero podría haber generado algún error si se hubiera levantado en el otro nodo. Por lo tanto, debemos indicar explicitamente que siempre debe montar el sistema de ficheros después del master/slave set de DRBD:

crm configure order drbd-fs mandatory: ms_drbdsphinx:promote fssphinx:start

Además, siempre debe estar en el mismo nodo el montaje del sistema de ficheros y el master del recurso DRBD:

crm configure colocation fssphinx-drbdsphinx \
    INFINITY: fssphinx ms_drbdsphinx:Master

A continuación limpiamos los errores del recurso que monta el sistema de ficheros por si se ha producido algún error anteriormente:

crm resource cleanup fssphinx

A continuación podemos instalar en todos los nodos el daemon que sea, en este caso, un sphinx y proceder a añadirlo al cluster. Primero de todo deberemos añadir la IP que usaremos para el daemon mediante ocf:heartbeat:IPaddr2:

crm configure primitive sphinxip1 ocf:heartbeat:IPaddr2 \
    params ip=172.16.2.101 cidr_netmask=32 op monitor interval=30s

Deberemos añadir continuación las reglas para que esten la IP y el fs en el mismo nodo:

crm configure colocation sphinxip_fssphinx INFINITY: sphinxip1 fssphinx

Y de orden:

crm configure order ip-fs-sphinx mandatory: fssphinx sphinxip1

Para añadir el sphinx podemos usar ocf::heartbeat:SphinxSearchDaemon:

# crm ra info ocf:heartbeat:SphinxSearchDaemon
Manages the Sphinx search daemon. (ocf:heartbeat:SphinxSearchDaemon)

This is a searchd Resource Agent. It manages the Sphinx Search Daemon.

Parameters (* denotes required, [] the default):

config (string, [/etc/sphinx/sphinx.conf]): Configuration file
    searchd configuration file

searchd (string, [/usr/local/bin/searchd]): 
    searchd binary

search (string, [/usr/local/bin/search]): search binary
    Search binary for functional testing in the monitor action.

testQuery (string, [Heartbeat_Monitor_Query_Match_string]): test query
    Test query for functional testing in the monitor action.
    The query does not need to match any documents in the index.
    The purpose is merely to test whether the search daemon is
    is able to query its indices and respond properly.

Operations' defaults (advisory minimum):

    start         timeout=20s
    stop          timeout=20s
    monitor_0     interval=10 timeout=20

Con lo que suponiendo el sphinx instalado dentro de /usr/local/sphinx y con el fichero de configuración en /var/hasphinx/conf/sphinx.conf quedaría:

crm configure primitive sphinx ocf:heartbeat:SphinxSearchDaemon \
    params config="/var/hasphinx/conf/sphinx.conf" \
    searchd="/usr/local/sphinx/bin/searchd" \
    search="/usr/local/sphinx/bin/search" \
    op start timeout="30s" \
    op stop timeout="30s" \
    op monitor interval="20" timeout="30s"

Finalmente deberemos configurar también que IP y daemon estén en el mismo nodo:

crm configure colocation sphinxip-sphinx INFINITY: sphinxip1 sphinx

Y el orden:

crm configure order sphinxip1-sphinx mandatory: sphinxip1 sphinx

Mediante crm status podemos apreciar como ha quedado:

# crm status
============
Last updated: Mon Apr 18 15:33:23 2011
Stack: Heartbeat
Current DC: host2 (37ebb34b-8d67-4f2f-b971-5b572a90f916) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, 2 expected votes
4 Resources configured.
============

Online: [ host1 host2 ]

 Master/Slave Set: ms_drbdsphinx
     Masters: [ host2 ]
     Slaves: [ host1 ]
 fssphinx	(ocf::heartbeat:Filesystem):	Started host2
 sphinxip1	(ocf::heartbeat:IPaddr2):	Started host2
 sphinx	(ocf::heartbeat:SphinxSearchDaemon):	Started host2

2 comments to “Cluster con DRBD y heartbeat 2 / pacemaker”

  1. Estimado…

    Muy bueno el tutorial…

    Esto me sirve si ya tengo un servidor asterisk en producción???

    Si el maestro se cayera y el esclavo pasa algunos días trabajando y creando extensiones… estas se grabarán En el servidor maestro cuando comience a operar nuevamente????
    Gracias por tu tiempo….

  2. Hola,
    Te sirve siempre que los datos (las extensiones i demás) se guarden en el disco compartido (DRBD) y los daemons de aterisk se gestionen con el cluster

    saludos,

Deja un comentario:

XHTML - Tags permitidos:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>