Existen varios algoritmos disponibles en HAProxy para repartir las conexiones entre los diferentes backends, dicho comportamiento se regula mediante balance.

El modo más común es roundrobin mediante el cual se reparte, de acuerdo con los pesos asignados las conexiones según van entrando. Este modo tiene el inconveniente que los servidores deben ser sin estado (stateless) o bien disponer de un sistema para mantenerlo coherente entre los servidores backend.

listen smtpd 0.0.0.0:25
        mode tcp
        balance roundrobin
        server qmailfront1 127.0.0.1:2525 check weight 10
        server qmailback1 192.168.10.33:25 check weight 60
        server qmailback2 192.168.10.34:25 check weight 30

Por el contrario, en el modo conocido como sticky, el balanceador reparte las conexiones entre todos los backends, también de acuerdo con los pesos asignados, pero siempre asignando el mismo backend para un determinado cliente. De esta forma los backends pueden ser con estado (statefull) sin ningún sistema para mantener la coherencia. El gran inconveniente es que desaparece el failover automático ya que si un backend tiene un problema desparecen los datos de las sesiones con él. Para modificar el comportamiento del balanceador a este modo deberemos cambiar el algoritmo a “source“: Balancear según el origen.

listen smtpd 0.0.0.0:25
        mode tcp
        balance source
        server qmailfront1 127.0.0.1:2525 check weight 10
        server qmailback1 192.168.10.33:25 check weight 60
        server qmailback2 192.168.10.34:25 check weight 30

Relacionados

• Instalar HAProxy (balanceador HTTP SMTP TCP)
• Estado de HAProxy desde socket
• Balanceador de carga con HAProxy

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

Relacionados

• WARNING: duplicate document ids found – Identificadores de 32 o 64 bits en Sphinx
• Statement is not safe to log in statement format
• ssh con daemontools
• Replicación en memcached
• Reinicio automático de memcached en la versión de Facebook

Error: Missing Dependency: libesmtp is needed by package pacemaker

Este error afecta al paquete pacemaker y no lo podremos instalar mediante yum:

# yum install -y pacemaker
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
 * base: ftp.udl.es
 * extras: ftp.udl.es
 * updates: ftp.udl.es
Excluding Packages in global exclude list
Finished
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package pacemaker.x86_64 0:1.0.10-1.4.el5 set to be updated
--> Processing Dependency: pacemaker-libs = 1.0.10-1.4.el5 for package: pacemaker
--> Processing Dependency: libesmtp for package: pacemaker
--> Processing Dependency: libpe_status.so.2()(64bit) for package: pacemaker
--> Processing Dependency: libcib.so.1()(64bit) for package: pacemaker
--> Processing Dependency: libtransitioner.so.1()(64bit) for package: pacemaker
--> Processing Dependency: libpe_rules.so.2()(64bit) for package: pacemaker
--> Processing Dependency: libcrmcommon.so.2()(64bit) for package: pacemaker
--> Processing Dependency: libcrmcluster.so.1()(64bit) for package: pacemaker
--> Processing Dependency: libstonithd.so.0()(64bit) for package: pacemaker
--> Processing Dependency: libpengine.so.3()(64bit) for package: pacemaker
--> Processing Dependency: libesmtp.so.5()(64bit) for package: pacemaker
--> Running transaction check
---> Package pacemaker.x86_64 0:1.0.10-1.4.el5 set to be updated
--> Processing Dependency: libesmtp for package: pacemaker
--> Processing Dependency: libesmtp.so.5()(64bit) for package: pacemaker
---> Package pacemaker-libs.x86_64 0:1.0.10-1.4.el5 set to be updated
--> Finished Dependency Resolution
pacemaker-1.0.10-1.4.el5.x86_64 from clusterlabs has depsolving problems
  --> Missing Dependency: libesmtp is needed by package pacemaker-1.0.10-1.4.el5.x86_64 (clusterlabs)
pacemaker-1.0.10-1.4.el5.x86_64 from clusterlabs has depsolving problems
  --> Missing Dependency: libesmtp.so.5()(64bit) is needed by package pacemaker-1.0.10-1.4.el5.x86_64 (clusterlabs)
Error: Missing Dependency: libesmtp is needed by package pacemaker-1.0.10-1.4.el5.x86_64 (clusterlabs)
Error: Missing Dependency: libesmtp.so.5()(64bit) is needed by package pacemaker-1.0.10-1.4.el5.x86_64 (clusterlabs)
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

La explicación de este error es que el paquete libesmtp no se encuentra en el repositorio de CentOS o de RHEL sino que se encuentra en el EPEL. Por lo tanto pacemaker depende de EPEL para poder ser instalado. Simplemente deberemos instalar EPEL en la versión que nos interese, por ejemplo para RHEL/CentOS 5:

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

A continuación repitiendo el yum install veremos como se instala correctamente:

# yum install pacemaker -y
(...)
Installed:
  pacemaker.x86_64 0:1.0.10-1.4.el5                                                                                                                                                                           

Dependency Installed:
  libesmtp.x86_64 0:1.0.4-5.el5                                                                     pacemaker-libs.x86_64 0:1.0.10-1.4.el5                                                                    

Complete!

Relacionados

• Ya esta disponible RHEL 6 beta para su instalación
• runlevels en derivados de RedHat (Fedora, CentOS, RHEL) y SuSE
• rpm: file /home/jordi/ejemplo.rpm is not owned by any package
• resize2fs: Inappropriate ioctl for device While trying to add group #8321
• resize2fs: Filesystem has unsupported feature(s) while trying to open /dev/local/home

Para esta configuración vamos a suponer dos hosts:

• host1
• host2

Empezaremos instalando el repositorio de clusterlabs e instalando todos los paquetes necesarios en ambos nodos (deberemos tener instalado previamente el respositorio EPEL):

wget -O /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo
yum install heartbeat cluster-glue resource-agents pacemaker -y

A continuación deberemos modificar el fichero /etc/hosts, añadiendo los dos nodos del cluster:

172.16.2.10	host1
172.16.2.11	host2

A continuación, en uno de los dos nodos generamos el fichero /etc/ha.d/ha.cf con lo siguiente:

autojoin none
bcast eth0

warntime 5
deadtime 15
initdead 60
keepalive 2

node host1
node host2

pacemaker respawn

Los parámetros son los siguientes:

• autojoin: Indicamos que no queremos que haga autojoin, indicamos estáticamente los nodos del cluster en la configuración mediante node
• bcast: Mediante bcast indicamos por que interfaz y mediante broadcast se pasaran mensajes entre los nodos del cluster. Podemos hacerlo también por multicast (mcast) pero si tenemos una VLAN para el cluster y no hay más de un cluster en la VLAN podemos dejarlo con broadcast.
• Mediante warntime, deadtime, initdead, keepalive indicamos diferentes valores globales de timeouts.
• pacemaker respawn: En caso que el pacemaker se muera por algun motivo, se vuelve a iniciar.

A continuación deberemos generar el fichero de autenticación mediante pwgen:

yum install pwgen -y

En uno de los nodos generamos el fichero con lo siguiente:

cat <<EOF >/etc/ha.d//authkeys
auth 1
1 sha1 $(pwgen 30 | openssl sha1)
EOF
chmod 600 /etc/ha.d/authkeys

A continuación deberemos propagar los ficheros mediante ha_propagate:

# /usr/share/heartbeat/ha_propagate

A continuación levantaremos el daemon en todos los nodos:

/etc/init.d/heartbeat start

Podemos ver con ps que lo tenemos levantado:

# ps auxf | grep [h]eart
root      2220  0.0  1.0   5572  5572 ?        SLs  13:08   0:00 heartbeat: master control process
root      2223  0.0  1.0   5544  5544 ?        SL   13:08   0:00  \_ heartbeat: FIFO reader
root      2224  0.0  1.0   5540  5540 ?        SL   13:08   0:00  \_ heartbeat: write: bcast eth0
root      2225  0.0  1.0   5540  5540 ?        SL   13:08   0:00  \_ heartbeat: read: bcast eth0
102       2228  0.0  0.3   4960  1884 ?        S    13:08   0:00  \_ /usr/lib/heartbeat/ccm
102       2229  0.1  0.6   8312  3384 ?        S    13:08   0:00  \_ /usr/lib/heartbeat/cib
root      2230  0.0  0.3   5080  1644 ?        S    13:08   0:00  \_ /usr/lib/heartbeat/lrmd -r
root      2231  0.0  1.2   6260  6260 ?        SL   13:08   0:00  \_ /usr/lib/heartbeat/stonithd
102       2232  0.0  0.4   7828  2368 ?        S    13:08   0:00  \_ /usr/lib/heartbeat/attrd
102       2233  0.0  0.5   7908  2708 ?        S    13:08   0:00  \_ /usr/lib/heartbeat/crmd

Mediante crm status podemos ver el estado del cluster:

# crm status
============
Last updated: Thu Mar 17 13:12:23 2011
Stack: Heartbeat
Current DC: host2 (a49ba348-6ace-4bb3-a51f-831a72b7cdf3) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, unknown expected votes
0 Resources configured.
============

Online: [ host1 host2 ]

A continuación verificamos la configuración:

# crm_verify -L
crm_verify[2340]: 2011/03/17_13:34:14 ERROR: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
crm_verify[2340]: 2011/03/17_13:34:14 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option
crm_verify[2340]: 2011/03/17_13:34:14 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
  -V may provide more details

STONITH (cluster-glue) se encarga de reiniciar los nodos en caso que se encuentren en un estado indeterminado para permitir levantar sus servicios en otro nodo. De momento lo podemos dejar deshabilitado:

crm configure property stonith-enabled=false

También deberemos definir el número de votos con los que indicamos que el cluster tiene quorum:

2 Nodes configured, unknown expected votes

En el caso de dos nodos, tiene poco sentido, por lo que se lo dejaremos en 2:

crm configure property expected-quorum-votes="2"

Indicaremos a continuación que siga funcionando el cluster en caso que no tenga quorum (uno de los dos nodos desaparezca). En caso que no lo hiciéramos, si uno de los nodos lo apagáramos, el otro apagaría todos los servicios al perder quorum:

crm configure property no-quorum-policy=ignore

Para evitar que los servicios hagan fail-back (vuelvan al otro nodo cuando se recupere de un fallo):

crm configure rsc_defaults resource-stickiness=100

A continuación añadiremos servicios, primero de todo tenemos que obtener el listado de clases que podemos añadir:

# crm ra classes
heartbeat
lsb
ocf / heartbeat pacemaker
stonith

Mediante crm ra list podemos listar los scripts de control de una de las clases:

# crm ra list ocf heartbeat
AoEtarget           AudibleAlarm        CTDB                ClusterMon          Delay               Dummy               EvmsSCC             Evmsd               Filesystem          ICP
IPaddr              IPaddr2             IPsrcaddr           LVM                 LinuxSCSI           MailTo              ManageRAID          ManageVE            Pure-FTPd           Raid1
Route               SAPDatabase         SAPInstance         SendArp             ServeRAID           SphinxSearchDaemon  Squid               Stateful            SysInfo             VIPArip
VirtualDomain       WAS                 WAS6                WinPopup            Xen                 Xinetd              anything            apache              db2                 drbd
eDir88              iSCSILogicalUnit    iSCSITarget         ids                 iscsi               ldirectord          mysql               mysql-proxy         nfsserver           oracle
oralsnr             pgsql               pingd               portblock           postfix             proftpd             rsyncd              scsi2reservation    sfex                syslog-ng

A continuación mediante crm ra info podemos obtener los datos de funcionamiento de un script en concreto:

# crm ra info ocf:heartbeat:IPaddr2
Manages virtual IPv4 addresses (Linux specific version) (ocf:heartbeat:IPaddr2)

This Linux-specific resource manages IP alias IP addresses.
It can add an IP alias, or remove one.
In addition, it can implement Cluster Alias IP functionality
if invoked as a clone resource.

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

ip* (string): IPv4 address
    The IPv4 address to be configured in dotted quad notation, for example
    "192.168.1.1".

nic (string, [eth0]): Network interface
    The base network interface on which the IP address will be brought
    online. 

    If left empty, the script will try and determine this from the
    routing table.

    Do NOT specify an alias interface in the form eth0:1 or anything here;
    rather, specify the base interface only.

cidr_netmask (string): CIDR netmask
    The netmask for the interface in CIDR format
    (e.g., 24 and not 255.255.255.0)

    If unspecified, the script will also try to determine this from the
    routing table.

broadcast (string): Broadcast address
    Broadcast address associated with the IP. If left empty, the script will
    determine this from the netmask.

iflabel (string): Interface label
    You can specify an additional label for your IP address here.
    This label is appended to your interface name.
    If a label is specified in nic name, this parameter has no effect.

lvs_support (boolean, [false]): Enable support for LVS DR
    Enable support for LVS Direct Routing configurations. In case a IP
    address is stopped, only move it to the loopback device to allow the
    local node to continue to service requests, but no longer advertise it
    on the network.

mac (string): Cluster IP MAC address
    Set the interface MAC address explicitly. Currently only used in case of
    the Cluster IP Alias. Leave empty to chose automatically.

clusterip_hash (string, [sourceip-sourceport]): Cluster IP hashing function
    Specify the hashing algorithm used for the Cluster IP functionality.

unique_clone_address (boolean, [false]): Create a unique address for cloned instances
    If true, add the clone ID to the supplied value of ip to create
    a unique address to manage

arp_interval (integer, [200]): ARP packet interval in ms
    Specify the interval between unsolicited ARP packets in milliseconds.

arp_count (integer, [5]): ARP packet count
    Number of unsolicited ARP packets to send.

arp_bg (string, [yes]): ARP from background
    Whether or not to send the arp packets in the background.

arp_mac (string, [ffffffffffff]): ARP MAC
    MAC address to send the ARP packets too.

    You really shouldn't be touching this.

Operations' defaults (advisory minimum):

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

Añadiremos una IP de cluster (VIP) como servicio con crm configure primitive:

crm configure primitive haip1 ocf:heartbeat:IPaddr2 params ip=172.16.2.100 cidr_netmask=32 op monitor interval=30s

Mediante crm status podemos apreciar que se ha levantado y en que nodo:

# crm status
============
Last updated: Thu Mar 17 13:36:33 2011
Stack: Heartbeat
Current DC: host2 (a49ba348-6ace-4bb3-a51f-831a72b7cdf3) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, unknown expected votes
1 Resources configured.
============

Online: [ host1 host2 ]

 haip1	(ocf::heartbeat:IPaddr2):	Started host1

En el nodo que se haya levantado podemos ver como esta presente mediante ip addr show:

# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:29:40:db:82 brd ff:ff:ff:ff:ff:ff
    inet 172.16.2.10/16 brd 172.16.255.255 scope global eth0
    inet 172.16.2.100/32 brd 172.16.6.100 scope global eth0

A continuación mediante ocf:heartbeat:anything podemos añadir cualquier daemon al cluster. Primero obtenemos los detalles con crm ra info:

# crm ra info ocf:heartbeat:anything
Manages an arbitrary service (ocf:heartbeat:anything)

This is a generic OCF RA to manage almost anything.

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

binfile* (string): Full path name of the binary to be executed
    The full name of the binary to be executed. This is expected to keep running with the same pid and not just do something and exit.

cmdline_options (string): Command line options
    Command line options to pass to the binary

pidfile (string, [/var/run//anything_undef.pid]): File to write STDOUT to
    File to read/write the PID from/to.

logfile (string):
    File to write STDOUT to

errlogfile (string):
    File to write STDERR to

user (string, [root]):
    User to run the command as

monitor_hook (string):
    Command to run in monitor operation

stop_timeout (string): Seconds to wait after having sent SIGTERM before sending SIGKILL in stop operation
    In the stop operation: Seconds to wait for kill -TERM to succeed
    before sending kill -SIGKILL. Defaults to 2/3 of the stop operation timeout.

Operations' defaults (advisory minimum):

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

Por ejemplo, añadimos el daemon de memcached al cluster con el siguiente comando:

crm configure primitive memcache ocf:heartbeat:anything params binfile="/usr/bin/memcached" cmdline_options="-u\ memcached\ -p\ 11311\ -c\ 1024\ -m\ 32" monitor_hook="/usr/bin/nc\ -z\ localhost\ 11311" op monitor interval="10" timeout="20s" depth="0"

Mediante crm status podemos apreciar como se ha añadido:

# crm status
============
Last updated: Thu Mar 17 15:19:51 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 ]

 haip1	(ocf::heartbeat:IPaddr2):	Started host1
 memcache	(ocf::heartbeat:anything):	Started host2

A continuación podemos indicar dos recursos con que puntuación deben mantenerse juntos:

# crm configure colocation
usage: colocation <id> <score>: [:] [:]

Mediante crm configure colocation indicamos que la VIP y el servicio de memcache estén en el mismo nodo:

crm configure colocation memcached-ip1 INFINITY: haip1 memcache

Revisamos con crm status como se han agrupado:

# crm status
============
Last updated: Thu Mar 17 15:25:09 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 ]

 haip1	(ocf::heartbeat:IPaddr2):	Started host1
 memcache	(ocf::heartbeat:anything):	Started host1

A continuación mediante order indicamos el orden en que se deben arrancar los servicios:

# crm configure order
usage: order <id> score-type: <first-rsc>[:<action>] <then-rsc>[:<action<]
        [symmetrical=<bool>]

Por lo tanto, indicamos que primero se levante la IP y a continuación el memcached:

crm configure order ip-memcache mandatory: haip1 memcache

Relacionados

• Statement is not safe to log in statement format
• ssh con daemontools
• Replicación en memcached
• Reinicio automático de memcached en la versión de Facebook
• Posiciones del fichero de configuración de MySQL

Primero de todo lo descargamos y lo compilamos:

cd /usr/local/src/
wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.8.tar.gz
tar xzf haproxy-1.4.8.tar.gz
cd haproxy-1.4.8
make TARGET=linux26
make install

A continuación preparamos el entorno para usarlo con chroot y daemontools:

mkdir /usr/local/supervise/haproxy -p
mkdir -p /usr/local/chroot/haproxy/
useradd haproxy
cat <<EOF > /usr/local/supervise/haproxy/run
#!/bin/bash
exec /usr/local/sbin/haproxy -f /usr/local/etc/haproxy.cfg
EOF
chmod +x /usr/local/supervise/haproxy/run
ln -s /usr/local/supervise/haproxy/ /service/

Para indicar a que id debe cambiar el proceso hacemos un id al usuario haproxy que acabamos de crear y nos quedamos con el valor numérico:

# id haproxy
uid=508(haproxy) gid=508(haproxy) groups=508(haproxy)

Vamos a ver a continuación como configurarlo (mediante el fichero /usr/local/etc/haproxy.cfg) para repartir conexiones entre tres servidores de correo con una distribución de: 40%, 25% y 35%:

global
	uid 		508
	gid 		508
	chroot 		/usr/local/chroot/haproxy
	log 		127.0.0.1	local0
	log 		127.0.0.1	local1 notice
	maxconn 	32000

defaults
	log		global
	mode		tcp
	option		dontlognull
	retries		3
	option		redispatch
	option		smtpchk
	maxconn		2000
	contimeout	5000
	clitimeout	50000
	srvtimeout	50000

listen push 0.0.0.0:25
	mode tcp
	balance roundrobin
	server spamer1 10.10.1.1:25 check weight 40
	server spamer2 10.10.1.2:25 check weight 25
	server spamer3 10.10.1.3:25 check weight 35

Las directivas siguientes son las mas relevantes:

• chroot /usr/local/chroot/haproxy: Indica a HAProxy que haga un chroot en el path que se le indica
• option smtpchk: Realiza un inicio de sesión SMTP para comprobar el estado del servidor. También se pueden hacer una petición HTTP mediante httpchk
• balance roundrobin: Define el modo en que reparte las peticiones, en este caso puramente roundrobin, pero también puede ser por el servidor con menos conexiones (leastconn) o incluso inspeccionando el protocolo HTTP
• server spamer1 10.10.1.1:25 check weight 40: Define los backends a los que repartir las conexiones, en este caso indica que se le deben repartir un 40% de las peticiones

En la documentación de HAProxy se pueden encontrar todas las directivas detalladas.

Relacionados

• HAProxy en modo sticky o en modo roundrobin
• Estado de HAProxy desde socket
• Balanceador de carga con HAProxy

Podemos hablar de varias configuraciones de cluster, pero en general nos podemos quedar con dos de básicas:

• Activo-Activo: Todos los nodos dels cluster reciben una parte de la misma carga.
• Activo-Pasivo: La carga la asume uno de los nodos y en caso de caída se traspasa a otro nodo

Muchas veces se abusa de estas definiciones quizá demasiado amplias para vender la moto. Suponemos un cluster así:

Cluster MySQL PostgreSQL

Este cluster evidentemente están los dos haciendo cosas, por lo que en cualquier presentación hecha por un comercial tendría muchos números de escuchar que es un “activo-activo“.

Entiendo que quieran decir que no hay un nodo desaprovechado, pero desde el punto de vista más estricto el servicio esta activo siempre en solo uno de los dos, por lo que el servicio es activo-pasivo.

Para hablar de uno activo-activo deberíamos hablar de al menos dos equipos con el mismo servicio que los clientes puedan conectar a ellos indistintamente. Un ejemplo muy claro sería un conjunto de frontales que sirven el mismo contenido indistintamente:

Cluster de Apaches activo-activo

Relacionados

• Statement is not safe to log in statement format
• ssh con daemontools
• Replicación en memcached
• Reinicio automático de memcached en la versión de Facebook
• Posiciones del fichero de configuración de MySQL

• mode=1 (activo-pasivo)

  Con este modo solo tenemos activo un slave en concreto. En el caso que este falle se pasa a usar el otro. El modo de funcionamiento nos ofrece solo tolerancia a fallos.

• mode=2 (balance-xor)

  Para transmitir una trama lo hace basado en el siguiente calculo: (MAC de origen XOR MAC destino)%numero de interfaces slaves. De esta manera para cada MAC de destino se selecciona una interfaz en concreto. Este modo nos ofrece balanceo de carga y tolerancia a fallos. En el caso que tengamos un bonding en este modo que principalmente hable con otras maquinas de otras VLANs tenemos que tener en cuenta que solo usaremos una interfaz, ya que todas las conexiones a otras VLAN deben pasar por el gateway el cual se trata de otra MAC más.

• mode=3 (broadcast)

  Transmite todas las tramas por todas las interfaces slave. Este modo nos ofrece tolerancia a fallos.

• mode=4 (802.3ad)

  Se trata del estandard IEEE 802.3ad (Dynamic link aggregation) también llamado “port trunking“. Permite la definición de agregados ofreciendo alta disponibilidad y un aumento de la velocidad. Para poder configurar este modo necesitamos:

  • Soporte de ethtool para obtener la velocidad y el modo del interfaz.
  • El switch debe soportar el modo. Por ejemplo los CISCO lo soportan con el nombre port trunking.
• mode=5 (balance-tlb)

  Este modo transmite balanceando la carga entre los slave en función de la carga de cada slave. En el caso que uno falle la MAC salta a otro slave. Para calcular la carga de cada interfaz es necesario disponer de ethtool.

  A diferencia de 802.3ad no se necesario soporte del switch para esta configuración.

  Tenemos que tener en cuenta que puede producirse que los paquetes lleguen desordenados, por lo que puede ser peor el remedio que la enfermedad, especialmente en entornos de red complejos.

• mode=6 (balance-alb)

  Balanceo de carga tanto en el envío como en la recepción. Para el balanceo de carga en la recepción lo que se hace es manipulando los replies ARP para indicar una MAC en concreto de una de las interfaces slave.

  Deberemos tener en cuenta que cualquier sistema de seguridad basado en las tablas ARP puede quejarse o simplemente tirar el puerto de la interfaz dejando el servidor sin conectividad.

Para configurar estos modos lo debemos hacer en el fichero /etc/modprobe.conf. Por ejemplo para configurar un bonding en modo activo-pasivo usaremos la siguiente configuración:

alias bond0 bonding
options bond0 miimon=100 mode=1

A continuación en las interfaces físicas (/etc/sysconfig/network-scripts/ifcfg-eth0) debemos definirlas como slaves. Por ejemplo, para la eth0 la definimos como slave de bond0 :

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
MASTER=bond0
SLAVE=yes
ETHTOOL_OPTS="autoneg off speed 100 duplex full"

Y a continuación deberemos definir el bonding en el fichero /etc/sysconfig/network-scripts/ifcfg-bond0:

DEVICE=bond0
ONBOOT=yes
BOOTPROTO=none
IPADDR=10.1.1.8
NETMASK=255.255.255.0
GATEWAY=10.1.1.254

Relacionados

• Statement is not safe to log in statement format
• ssh con daemontools
• Replicación en memcached
• Rendimiento ext3: Creación del journal en otro dispositivo
• Reinicio automático de memcached en la versión de Facebook

listen smtpd 0.0.0.0:25
        mode tcp
        balance roundrobin
        server qmailfront1 127.0.0.1:2525 check
        server qmailback1 192.168.10.33:25 check
        server qmailback1 192.168.10.33:25 check
        server qmailback1 192.168.10.33:25 check
        server qmailback1 192.168.10.33:25 check
        server qmailback1 192.168.10.33:25 check
        server qmailback1 192.168.10.33:25 check
        server qmailback2 192.168.10.34:25 check
        server qmailback2 192.168.10.34:25 check
        server qmailback2 192.168.10.34:25 check

El operador que configuró este servidor intentaba definir un 10% de las peticiones que llegasen las quedara el mismo, repartiendo en dos servidores internos un 30% el uno y un 60% el otro.

Funciona correctamente, pero en caso de mas servidores con números menos redondos sería muy complicado de definir.

En realidad usando pesos (weight) para cada servidor podemos hacer lo mismo mucho mas sencillo:

listen smtpd 0.0.0.0:25
        mode tcp
        balance roundrobin
        server qmailfront1 127.0.0.1:2525 check weight 10
        server qmailback1 192.168.10.33:25 check weight 60
        server qmailback2 192.168.10.34:25 check weight 30

Podemos consultar la documentación de HAProxy para muchas otras opciones.

Relacionados

• Statement is not safe to log in statement format
• ssh con daemontools
• Replicación en memcached
• Reinicio automático de memcached en la versión de Facebook
• Posiciones del fichero de configuración de MySQL

Este error ocurre porque el identificador que usa NFS (file handle) es la combinación de:

• Major del dispositivo que contiene el sistema de ficheros
• Minor del dispositivo que contiene el sistema de ficheros
• inode del sistema de ficheros

El problema ocurre cuando el major, el minor o los dos són diferentes en los nodos del clúster: Esto provoca el stale.

Para evitar esto se debe usar el fsid, el cual se usa en lugar del major y el minor del dispositivo:

/usr/local     *(async,rw,fsid=3)

Relacionados

• Usuarios en export NFS aparecen como nobody en CentOS 6
• Uso de los threads de NFS
• Statement is not safe to log in statement format
• ssh con daemontools
• Replicación en memcached

Ejemplo de cluster usando LVM

• Quitamos los procesos del nodo
• Deshabilitamos los volumenes logicos mediante lvchange:

  # lvchange -an /dev/group/volume

  Estos comandos realmente no son necesarios si no se usan los volumenes logicos, pero en el caso que no sea así nos indicará cual de ellos esta usandose y por lo tanto bloqueando el grupo entero

• Deshabilitamos el grupo mediante vgchange:

  # vgchange -an group

Una vez realizados los cambios (añadir un disco, extender un volumen…) se pueden rehabilitar cambiando la opción -an (avaliable: no) por -ay (avaliable: yes)

Relacionados

• Statement is not safe to log in statement format
• ssh con daemontools
• Replicación en memcached
• Reinicio automático de memcached en la versión de Facebook
• Recuperación parcial de una base de datos InnoDB desde snapshot