Pandora:Documentation es:DRBD Appiliance

From Pandora FMS Wiki

Jump to: navigation, search

HA en Pandora FMS Appliance Centos

Introducción a DRBD

El Dispositivo de Bloque Replicado Distribuido, es una solución de almacenamiento replicada, que no comparte, basada en software que refeja el contenido de dispositivos de bloque (discos duros, particiones, volúmenes lógicos, etc) entre servidores.

Datos del DRBD mirror:

  • En tiempo real: la replicación ocurre continuamente, mientras las aplicaciones modifican los datos en el dispositivo.
  • De modo transparente: las aplicaciones que almacenan sus datos en el dispositivo reflejado ignoran el hecho de que los datos están en realidad almacenados en varios ordenadores.
  • Con sincronicidad o sin ella. Con reflejo sincrónico, una aplicación escrita es notificada de que ha sido completada por escrito, sólo después de que haya sido llevada a cabo en ambos sistemas del ordenador. El reflejo asíncrono implica que las aplicaciones escritas serán notificadas por escrito cuando la escritura sea completada de modo local, pero antes de que la escritura se haya propagado al sistema peer.



Drbd.png



En DRBD usted puede conseguir un cluster sobre casi todo lo que pueda replicar en del disco. En nuestro caso específico, cuando queremos "clusterizar" sólo la base de datos, pero también podemos replicar entera la configuración de Pandora FMS, incluyendo el servidor,los agentes locales, y por supuesto, la base de datos.

El DRBD es un módulo de kernel basado en RAID-1/TCP, muy sencillo de configurar y realmente rápido y sometido a pruebas de error. Puede obtener más información en su página Web:http://www.drbd.org

DRBD es OPenSource.

Entorno Inicial

Queremos tener un cluster MySQL en una configuración HA basada en un master (activo) y en un slave (pasivo). Dos servidores de Pandora FMS y la consola ,instalados sobre la appliance de Centos, utilizarán una dirección IP virtual para conectarse con el nodo que está corriendo y que contiene un servidor MySQL.

Esta es la configuración de red para los dos nodos que están corriendo el cluster MySQL:

192.168.70.10 (drbd1) -> Master
192.168.70.11 (drbd2) -> Slave
192.168.70.15 -> Virtual-ip

Cada nodo tiene dos discos duros:

/dev/sda con el sistema Linux estándar.
/dev/sdb con un disco vacío y sin formatear, listo para tener la configuración de RAID1 con DRBD.

Asumimos que usted tiene el tiempo sincronizado entre todos los nodos. Esto es extremadamente IMPORTANTE. Si no es así, por favor, sincronícelo antes de continuar, utilizando ntp or un dispositivo similar. Recuerde también habilitar el servicio ntpd en el arranque

# service ntpd start
# chkconfig ntpd on

Para el correcto funcionamiento le recomendamos que deshabilite el firewall así como Selinux de ambas máquinas.

# service iptables stop
# chkconfig iptables off
# sed -i 's/^\(SELINUX=\)enforcing/\1permissive/' /etc/selinux/config
# setenforce permissive

Otro punto a tener en cuenta es la edición del fichero /etc/hosts. En él tendremos tener indicados ambos equipos:

# vim /etc/hosts
192.168.70.10 drbd1
192.168.70.11 drbd2

Instalación paquetes y dependencias necesarias

DRBD no se encuentra en los repositorios oficiales de Centos, por lo tanto hay que añadir el repositorio en ambos equipos:

[root@drbd1 ~]# rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm
Retrieving http://elrepo.org/elrepo-release-6-4.el6.elrepo.noarch.rpm
warning: /var/tmp/rpm-tmp.dIHerV: Header V4 DSA/SHA1 Signature, key ID baadae52: NOKEY
Preparing...                ########################################### [100%]
   1:elrepo-release         ########################################### [100%]

Necesitamos instalar los siguientes paquetes (Ejemplo para Centos):

yum install drbd84-utils  kmod-drbd84 corosync pacemaker openais python-dateutil python-lxml redhat-rpm-config

En la versión de pacemaker disponible para Centos necesitamos instalar el comando crm ya que no viene por defecto. Su instalación es esta

rpm -Uvh http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-6/i686/python-pssh-2.3.1-4.2.i686.rpm
rpm -Uvh http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-6/i686/pssh-2.3.1-4.2.i686.rpm
rpm -Uvh http://rpm.repo.onapp.com/repo/centos/6.6/i386/RPMS-4.0/crmsh-2.1-1.6.i686.rpm

Configuración DRBD

Configuración inicial de DRBD

Editar /etc/drbd.conf

global {
  usage-count no;
}

common {
 protocol C;
}

resource mysql {
   on drbd1 {
       device /dev/drbd1;
       disk /dev/sdb1;
       address 192.168.70.10:7789;
       meta-disk internal;
   }
   on drbd2 {
       device /dev/drbd1;
       disk /dev/sdb1;
       address 192.168.70.11:7789;
       meta-disk internal;
   }
   disk {
       on-io-error detach; # Desconectamos el disco en caso de error de bajo nivel.
   }
   net {
       max-buffers 2048; #Bloques de datos en memoria antes de escribir a disco.
       ko-count 4; # Maximos intentos antes de desconectar.
   }
   syncer {
       rate 10M; # Valor recomendado de sincronización para redes de 100 Mb´s..
       al-extents 257; 
   }
   startup {
       wfc-timeout 0; # drbd init script esperará ilimitadamente los recursos.
       degr-wfc-timeout 120; # 2 minuteos
   }
}

Configurar nodos DRBD

Necesitará tener un disco completamente vacío en /dev/sdb (incluso sin particionamiento).

Haga una partición en /dev/sdb1 (tipo Linux)

[root@drbd1 ~]# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content will not be recoverable.
 
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
 
Command (m for help): n
Command action
    e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-261, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-261, default 261):
Using default value 261
 
Command (m for help): w
The partition table has been altered!
 
Calling ioctl() to re-read partition table.
Syncing disks.

(Hágalo en ambos nodos).

Y cree la estructura interna en el disco para drbd con los siguientes comandos en ambos nodos:

drbdadm create-md mysql
drbdadm up mysql

(De nuevo, hágalo en ambos nodos). Si al ejecutar estos comandos aparece algún error asegúrese de que los discos están bien creados, vacíos, sin formato, etc...

Disco inicial (Nodo principal)

El último comando para configurar DRBD, y sólo en el nodo principal, es para iniciar el recurso y configurarlo como principal:

drbdadm -- --overwrite-data-of-peer primary mysql

Después de establecer este comando, la configuración completa inicial comenzará. Será capaz de monitorizar su progreso via /proc/drbd. Puede llevar algo de tiempo, dependiendo del tamaño del dispositivo.

Ahora, su dispositivo DRBD está completamente operativo, incluso cuando la sincronización inicial ha sido completada (aunque con un rendimiento ligeramente reducido).Ahora puede crear un filesystem en el dispositivo, utilízelo como si fuera un dispositivo raw block, móntelo y realize cualquier operación que desee con un dispositivo de bloque accesible.

drbd1:~# cat /proc/drbd 
version: 8.0.14 (api:86/proto:86)
GIT-hash: bb447522fc9a87d0069b7e14f0234911ebdab0f7 build by phil@fat-tyre, 2008-11-12 16:40:33

 1: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---
    ns:44032 nr:0 dw:0 dr:44032 al:0 bm:2 lo:0 pe:0 ua:0 ap:0
	[>....................] sync'ed:  2.2% (2052316/2096348)K
	finish: 0:03:04 speed: 11,008 (11,008) K/sec
	resync: used:0/61 hits:2749 misses:3 starving:0 dirty:0 changed:3
	act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Crear la partición en el nodo principal

Hágalo SÓLO en el nodo principal. Se replicará a los otros nodos automáticamente. Opere con el dispositivo de bloque DRBD y olvide utilizar el dispositivo físico.

drbd1# mkfs.ext3 /dev/drbd1

Su utilización es como la de una partición estandar desde ahora. Móntela en su disco en el NODE principal de este modo:

drbd1:~# mkdir /mysql
drbd1:~# mount /dev/drbd1 /mysql/

Lo verificamos mediante el comando

df -ah

En en nodo secundario, pasivo, creamos el directorio de montaje:

[root@drbd2 ~]#mkdir /mysql

Obtener información sobre el estado del sistema

Ejecutado desde el nodo del master actual (drbd1):

drbd1:/# drbdadm role mysql
Primary/Secondary
drbd1:/# drbdadm dstate mysql
UpToDate/UpToDate

Y desde drbd2 (backup, disco de replicado):

drbd2:~# drbdadm role mysql
Secondary/Primary
drbd2:~# drbdadm dstate mysql
UpToDate/UpToDate

Configurando el mysql en el disco DRBD

Suponemos que tiene toda la información sobre mysql en los siguientes directorios (puede ser diferente dependiendo de su distribución Linux):

/etc/my.cnf
/var/lib/mysql/

Lo primero es detener el mysql en los nodos principal y secundario. (/etc/init.d/mysqld stop)

En el nodo principal(drbd1):

Mueva todos los datos a la partición montada en los nodos principales y borre toda la información relevante de mysql al nodo secundario:

drbd1:~# mv /etc/my.cnf /mysql/
drbd1:~# mv /var/lib/mysql /mysql/mysql

Enlace la nueva ubicación a la localización original:

drbd1:~# ln -s /mysql/mysql/ /var/lib/mysql
drbd1:~# ln -s /mysql/my.cnf /etc/my.cnf

En el nodo secundario(drbd2):

Borrar toda la información de mysql

drbd2:~# rm -Rf /var/lib/mysql
drbd2:~# rm -Rf /etc/my.cnf

Desmontar el nodo primario y convertirlo en secundario:

drbd1:~# umount /mysql/ ; drbdadm secondary mysql

Convertir el secundario en primario y hacer el montaje:

drbd2:~# drbdadm primary mysql ; mount /dev/drbd1 /mysql

Y creamos en este nodo los enlaces simbólicos de la misma forma:

drbd2:~# ln -s /mysql/my.cnf /etc/my.cnf
drbd2:~# ln -s /mysql/mysql /var/lib/mysql

Tras esto ya queda configurado mysql en ambos nodos, podemos volver a poner el nodo secundario como principal y viceversa haciendo lo indicado anteriormente pero esta vez al revés.

drbd2:~# umount /mysql/ ; drbdadm secondary mysql
drbd1:~# drbdadm primary mysql ; mount /dev/drbd1 /mysql

Recuperación manual de split brain

DRBD detecta split brain al tiempo que la conectividad resulta accesible de nuevo y los nodos peer cambian el protocolo DRBD handshake inicial. Si el DRBD detecta que ambos nodos están (o estuvieron en algún momento, cuando estaban desconectados) en el rol principal, entonces, inmediatamente romperán la conexión de replicación. La señal reveladora de esto es un mensaje como el siguiente apareciendo en el log del sistema:

Split-Brain detected, dropping connection!

Después de que el split brain haya sido detectado, un nodo tendrá siempre el recurso en el estado de conexión StandAlone. El otro puede también estar en el estado StandAlone (si ambos nodos son detectados en el split brain simultáneamente), o en WFConnection (si el peer rompe la conexión antes de que el otro nodo tenga la oportunidad de detectar split brain).

En este caso, nuestro nodo secundario (castor) está solo:

drbd1:~# cat /proc/drbd 
version: 8.0.14 (api:86/proto:86)
GIT-hash: bb447522fc9a87d0069b7e14f0234911ebdab0f7 build by phil@fat-tyre, 2008-11-12  16:40:33

  1: cs:WFConnection st:Secondary/Unknown ds:UpToDate/DUnknown C r---
     ns:0 nr:0 dw:0 dr:0 al:0 bm:7 lo:0 pe:0 ua:0 ap:0
	 resync: used:0/61 hits:0 misses:0 starving:0 dirty:0 changed:0
   	 act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0


En este punto, a menos que haya configurado DRBD para que se recupere automáticamente de split brain, debe intervenir de modo manual seleccionando un modo cuyas modificaciones serán descartadas (este nodo se llama "victima" del split brain). Esta intervención se hace con los siguientes comandos:

drbdadm secondary mysql
drbdadm -- --discard-my-data connect mysql

En el otro nodo (el split brain "superviviente"), si su estado de conexión es también StandAlone, podrás entrar:

drbdadm connect mysql
Ver el status:
 drbd2:~# cat /proc/drbd 
 version: 8.0.14 (api:86/proto:86)
 GIT-hash: bb447522fc9a87d0069b7e14f0234911ebdab0f7 build by phil@fat-tyre, 2008-11-12 16:40:33
 
  1: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---
     ns:34204 nr:0 dw:190916 dr:46649 al:12 bm:24 lo:0 pe:4 ua:20 ap:0
	 [============>.......] sync'ed: 66.7% (23268/57348)K
 	 finish: 0:00:02 speed: 11,360 (11,360) K/sec
	 resync: used:1/61 hits:2149 misses:4 starving:0 dirty:0 changed:4
   	 act_log: used:0/257 hits:118 misses:12 starving:0 dirty:0 changed:12

Switchover Manual

En el principal actual:

1. Detenga mysql

/etc/init.d/mysql stop

2. Desmonte partición

umount /dev/drbd1

3. Degrade a secundario

drbdadm secondary mysql

En el secundario actual:

4. Promueva a primario

drbdadm primary mysql

5. Monte la partición

mount /dev/drbd1 /mysql

6. Inicie MySQL

/etc/init.d/mysql start

Template warning.png

Es muy importante que antes de continuar con la instalación compruebe que todos estos pasos se han ejecutado correctamente y que el drbd funciona correctamente en ambos nodos, así como el mysql arranca en ambos nodos cuando actuan como Master.

 


Configuración Corosync / Pacemaker

Antes de la instalación debemos asegurarnos de que en el fichero /etc/hosts estén correctamente configurados ambos equipos:

192.168.70.10 	   drbd1
192.168.70.11	   drbd2

También necesitará habilitar ip_forwarding.

sysctl -w net.ipv4.ip_forward=1 

Editamos el fichero de configuración /etc/corosync/corosync.conf(nodo principal). Por defecto no esta por lo que se realiza una copia del fichero que viene como ejemplo /etc/corosync/corosync.conf.example.udpu:

#cp -p /etc/corosync/corosync.conf.example.udpu /etc/corosync/corosync.conf
totem {
        version: 2
        secauth: on
        interface {
                member {
                        memberaddr: 192.168.70.10
                }
                member {
                        memberaddr: 192.168.70.11
                }
                ringnumber: 0
                bindnetaddr: 192.168.70.10
                mcastport: 5405
                ttl: 1
        }
        transport: udpu
}
logging {
    fileline: off
    to_logfile: yes
    to_syslog: yes
    debug: on
    logfile: /var/log/cluster/corosync.log
    debug: off
    timestamp: on
    logger_subsys {
        subsys: AMF
        debug: off
    }
}


Añadimos dentro de la carpeta service.d un nuevo archivo con la siguiente configuración para el servicio pacemaker

# vi /etc/corosync/service.d/pcmk
service {
        # Load the Pacemaker Cluster Resource Manager
        name: pacemaker
        ver: 1
}


El fichero /etc/corosync/corosync.conf debe de ser idéntico en ambos nodos de manera que hay que copiar los fichero al nodo 2 a la rutas correspondientes

scp /etc/corosync/corosync.conf drbd2:/etc/corosync
scp /etc/corosync/service.d/pcmk drbd2:/etc/corosync/service.d/

Si hemos configurado secauth on deberemos crear la clave de autenticación de corosync en el nodo principal ejecutando el comando corosync-keygen :

[root@drbd1 ~]# corosync-keygen

Una vez ejecutado este comando nos pedirá que creemos entropía pulsando teclas, para hacerlo de forma más rápida lo mejor es que desde otro terminal os descarguéis un fichero de gran tamaño. O bien ejecutando el siguiente comando las veces necesarias: find / >/dev/null 2>&1 Una vez generada se crea automáticamente un fichero con la clave /etc/corosync/authkey, fichero que hay que copiar al segundo nodo en /etc/corosync/ para que las claves sean idénticas:

scp /etc/corosync/authkey root@192.168.70.11:/etc/corosync/authkey

Tras copiarlo se le dan permisos 400

chmod 400 /etc/corosync/authkey

Realizadas estas operaciones se inicia el servicio en ambos nodos:

/etc/init.d/corosync start

Si el servicio corosync ha arrancado correctamente, iniciamos el servicio pacemaker (en ambos nodos)

/etc/init.d/pacemaker start


Una vez iniciados se puede ver el estado del cluster en el que se muestra como ambos nodos están configurados y online (tarda unos instantes en detectar ambos nodos):

crm_mon -1
[root@drbd2 ~]# crm status
Last updated: Sat Oct 18 19:44:52 2014
Last change: Sat Oct 18 19:44:23 2014 via crmd on drbd2
Stack: classic openais (with plugin)
Current DC: drbd2 - partition with quorum
Version: 1.1.10-14.el6_5.3-368c726
2 Nodes configured, 2 expected votes
0 Resources configured 
 
 

Online: [ drbd1 drbd2 ] 
[root@drbd1 ~]# crm status
Last updated: Sat Oct 18 19:45:24 2014
Last change: Sat Oct 18 19:44:23 2014 via crmd on drbd2
Stack: classic openais (with plugin)
Current DC: drbd2 - partition with quorum
Version: 1.1.10-14.el6_5.3-368c726
2 Nodes configured, 2 expected votes
0 Resources configured


Online: [ drbd1 drbd2 ]

Template warning.png

Es muy importante que antes de continuar con la instalación compruebe que todos estos pasos se han ejecutado correctamente y que los servicios corosync y pacemaker funcionan correctamente en ambos nodos.

 


Configuración recursos Pacemaker

Una vez tengamos funcionando correctamente el Pacemaker (gestor de recursos en clúster) por un lado y el Corosync (una capa de mensajería entre sus nodos) por otro debemos añadir sus recursos.

Antes de todo, debemos conocer cual va a ser el orden que van a seguir los recursos al levantarse.

1.- IP Virtual
2.- DRBD / Filesystem
3.- Apache
4.- Mysql
5.- Pandora Server
6.- Tentacle Server

Es necesario seguir este orden ya que sin el filesystem y el DRBD montado funcionando correctamente no podremos iniciar el servidor Mysql, así como sin el servicio mysql, el servidor de Pandora arranca.

Template warning.png

Es posible que dependiendo de la versión de pacemaker el comando 'crm' no funcione correctamente.

 


En caso de que al intentar ejecutar 'crm configure' aparezcan errores, podemos ejecutar lo siguiente para solucionarlo (puede variar dependiendo de la versión).

cibadmin --modify --xml-text '<cib validate-with="pacemaker-2.1"/>'

Para confirmar que ha tenido éxito puede ejecutar 'crm configure show'.

Configuración de la IPs virtual como recurso en el cluster

Lo realizamos en el nodo que esté corriendo como Master. En primer lugar se deshabilita stonith:

crm configure property stonith-enabled=false

Y se configura el cluster para que ignore las políticas del quorum, lo cual permitirá que si un nodo cae el otro ejecute el recurso sin problema:

crm configure property no-quorum-policy=ignore

Llegado este punto se puede agregar los recursos con ip virtual asignada:

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

Al monitorizar el cluster se tendrá el siguiente resultado posterior(crm_mon -1):

FAILOVER-ADDR	 (ocf::heartbeat:IPaddr2):		Started drbd1

De esta manera al hacer ping desde un host a la ip virtual nos respondería el nodo activo en ese momento, funcionando de forma transparente para el host remitente.

Creación del recurso Apache.

Quitamos el servicio Apache del arranque.

# chkconfig httpd off (en los dos)

El siguiente paso es habilitar el server-status del apache para la monitorización de Pacemaker del servicio. Entramos en el config del Apache y descomentamos estas lineas:

ExtendedStatus On
<Location /server-status>
	SetHandler server-status
	Order deny,allow
	Allow from localhost
</Location>

Copiamos el conf de un equipo a otro:

scp /etc/httpd/conf/httpd.conf drbd2:/etc/httpd/conf/httpd.conf

Reiniciamos apache y probamos que se descarga correctamente en ambos:

[root@drbd1 ~]# /etc/init.d/httpd restart
curl http://192.168.70.10/server-status
curl http://192.168.70.11/server-status
curl http://192.168.70.15/server-status

Añadimos las siguientes lineas a la configuración de Pacemaker.

#crm configure primitive apache_res ocf:heartbeat:apache params configfile=/etc/httpd/conf/httpd.conf httpd=/usr/sbin/httpd statusurl="http://localhost/server-status" op monitor interval=60s timeout=10s op start timeout=40s op stop timeout=60s

Indicamos que apache se inicie despúes del recurso de la IP

crm configure colocation apache_ip_colo INFINITY: apache_res failover_ip
crm configure order apache_after_ip mandatory: failover_ip apache_res

Tras esto si hacemos un crm configure show lo veremos así;

node drbd1 \
        attributes standby=off
node drbd2 \
        attributes standby=off
primitive apache_res apache \
        params configfile="/etc/httpd/conf/httpd.conf" httpd="/usr/sbin/httpd" statusurl="http://localhost/server-status" \
        op monitor interval=60s timeout=10s \
        op start timeout=40s interval=0 \
        op stop timeout=60s interval=0
primitive failover_ip IPaddr2 \
        params ip=192.168.70.15 cidr_netmask=32 \
        op monitor interval=30s
colocation apache_ip_colo inf: apache_res failover_ip
order apache_after_ip Mandatory: failover_ip apache_res
property cib-bootstrap-options: \
        dc-version=1.1.10-14.el6_5.3-368c726 \
        cluster-infrastructure="classic openais (with plugin)" \
        expected-quorum-votes=2 \
        stonith-enabled=false \
        no-quorum-policy=ignore 

Si ves existe algún error en el nodo dos al pasarlo de uno al otro para el servicio pacemaker en los dos y reinicia corosync, vuelve a lanzar pacemaker. Recuerda que ejecutando crm node standby / crm node online lo pasamos de uno a otro.

No continue la instalación hasta que no compruebe que el servicio apache pasa de un nodo a otro correctamente e ingresando en un navegador la IP virtual vemos el mensaje de que Apache funciona.

[root@drbd2 ~]# crm status
Last updated: Sat Oct 18 22:32:25 2014
Last change: Sat Oct 18 22:32:14 2014 via crm_attribute on drbd1
Stack: classic openais (with plugin)
Current DC: drbd1 - partition with quorum
Version: 1.1.10-14.el6_5.3-368c726
2 Nodes configured, 2 expected votes
2 Resources configured 


Node drbd1: standby
Online: [ drbd2 ] 

 failover_ip    (ocf::heartbeat:IPaddr2):       Started drbd2
 apache_res     (ocf::heartbeat:apache):        Started drbd2

[root@drbd2 ~]# crm node standby
[root@drbd1 ~]# crm status
Last updated: Sat Oct 18 22:34:53 2014
Last change: Sat Oct 18 22:34:40 2014 via crm_attribute on drbd2
Stack: classic openais (with plugin)
Current DC: drbd1 - partition with quorum
Version: 1.1.10-14.el6_5.3-368c726
2 Nodes configured, 2 expected votes
2 Resources configured

 
Node drbd2: standby
Online: [ drbd1 ]

 failover_ip    (ocf::heartbeat:IPaddr2):       Started drbd1
 apache_res     (ocf::heartbeat:apache):        Started drbd1

Creación del recurso DRBD y montaje del Filesystem

En primer lugar se agrega el recurso drbd_res en el que se especifica el recurso DRBD (drbd_resource) ,en este caso llamado mysql y los intervalos de tiempo de comprobación, arranque y parado.

drbd1:~#crm
crm(live)#cib new drbd
crm(drbd)#configure primitive drbd_res ocf:linbit:drbd params drbd_resource=mysql op monitor interval=29s role=Master op monitor interval=31s role=Slave

En segundo lugar se agregan los recursos que tienen como propósito fijar que drbd_res solo corra sobre el nodo fijado como primario:

crm(drbd)#configure ms drbd_master_slave drbd_res meta master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true

Se hace un commit del cib drbd para registrar los cambios:

crm(drbd)#cib commit drbd

El segundo recurso (fs_res) se encarga de montar los dispositivos drbd en el punto de montaje. En este caso /dev/drbd1 en /mysql/ Para agregar este recurso se realiza el siguiente proceso: Se entra en el crm y se crea un nuevo cib llamado fs:

# crm
crm(live)# cib new fs

Y se ejecuta el comando para añadir el recurso

crm(fs)#configure primitive fs_res ocf:heartbeat:Filesystem params device=/dev/drbd1 directory=/mysql fstype=ext3

Se indica al dispositivo que los recursos deberá estar activos siempre en el nodo considerado como master(colocation) y seguidamente el orden en el que se ejecutará (después de que el nodo primario sea promovido):

crm(fs)# configure colocation fs_drbd_colo INFINITY: fs_res drbd_master_slave:Master
crm(fs)# configure order fs_after_drbd mandatory: drbd_master_slave:promote fs_res:start
crm(fs)# configure colocation apache_fs_colo inf: apache_res fs_res
crm(fs)# configure order apache_after_fs inf: fs_res apache_res
crm(fs)# cib commit fs

Tras esto deberá quedar así:

Last updated: Sat Oct 18 23:07:52 2014
Last change: Sat Oct 18 23:06:08 2014 via crm_attribute on drbd1
Stack: classic openais (with plugin)
Current DC: drbd1 - partition with quorum
Version: 1.1.10-14.el6_5.3-368c726
2 Nodes configured, 2 expected votes
5 Resources configured


Online: [ drbd1 drbd2 ]

failover_ip     (ocf::heartbeat:IPaddr2):       Started drbd1
apache_res      (ocf::heartbeat:apache):        Started drbd1
 Master/Slave Set: drbd_master_slave [drbd_res]
     Masters: [ drbd1 ]
     Slaves: [ drbd2 ]
fs_res  (ocf::heartbeat:Filesystem):    Started drbd1

Probamos en este punto que tras pasar de un nodo en otro, el directorio /mysql contiene los ficheros de mysql en el nodo Master.

Creación del recurso Mysql o Percona

Quitamos el servicio mysql/mysqld del arranque (en ambos nodos).

# chkconfig mysql off

La creación de este recurso difiere ligeramente en función de si utilizamos una base de datos MySQL estándar o Percona. En caso de haber utilizado nuestro Appliance, tendremos Percona, así que explicaremos este en primer lugar.

Se indica el recurso que se encarga del demonio de Percona

crm configure primitive mysql_res lsb:mysql op start timeout="120s" op stop timeout="120s" op monitor interval="10s" timeout="30s" meta target-role="Started"

Se indica al dispositivo que el recurso deberá estar activo siempre que el nodo en el que se encuentre montado el filesystem y seguidamente que se arrancará después de que se haya montado el filesystem

crm configure colocation mysql_drbd_colo inf: mysql_res drbd_master_slave:Master
crm configure order mysql_after_apache inf: apache_res mysql_res

Por último ejecutaremos una limpieza del registro para eliminar posibles errores que hayan aparecido al crear el recurso por primera vez

crm resource cleanup mysql_res



Para MySQL el procedimiento es prácticamente igual, variando el primer comando, utilizaremos el siguiente

crm configure primitive mysql_res ocf:heartbeat:mysql params additional_parameters="--socket=/var/run/mysqld/mysqld.sock" op start interval="0" timeout="120" op stop interval="0" timeout="120" op monitor interval="10" timeout="30" depth="0"

Después los comandos para indicar el estado en el que deben estar los recursos

crm configure colocation mysql_drbd_colo inf: mysql_res drbd_master_slave:Master
crm configure order mysql_after_apache inf: apache_res mysql_res

Y la limpieza de errores en caso de que haya alguno en el registro

crm resource cleanup mysql_res

Creción del recurso Pandora

Quitamos el servicio pandora_server del arranque (en ambos nodos).

# chkconfig pandora_server off

Se agrega el recurso de pandora que controla el servicio del servidor de Pandora colocándolo después del recurso mysql

crm configure primitive pandora_res lsb:pandora_server meta is-managed="true" target-role="Started" op monitor on-fail="standby" interval="10s"
crm configure colocation pandora_drbd_colo inf: pandora_res drbd_master_slave:Master
crm configure order pandora_after_mysql inf: mysql_res pandora_res

Creación del recurso Tentacle

Quitamos el servicio tentacle_serverd del arranque (en ambos nodos).

# chkconfig tentacle_serverd off

Se agrega el recurso de Tentacle que controla el servicio del servidor de Tentacle colocándolo después del recurso Pandora

crm configure primitive tentacle_res lsb:tentacle_serverd meta is-managed="true" target-role="Started" op monitor on-fail="standby" interval="10s"
crm configure colocation tentacle_drbd_colo inf: tentacle_res drbd_master_slave:Master
crm configure order tentacle_after_pandora inf: pandora_res tentacle_res

Configuración final de Pacemaker

Finalmente no debemos olvidar configurar corosync y pacemaker para inciarse con el arranque del sistema.

# chkconfig corosync on
# chkconfig pacemaker on

La configuración final deberá tener este aspecto.

#crm configure show
node drbd \
        attributes standby="off"
node drbd2 \
        attributes standby="off"
primitive apache_res ocf:heartbeat:apache \
        params configfile="/etc/apache2/apache2.conf" httpd="/usr/sbin/apache2" \
        op monitor interval="60s" timeout="10s" \
        op start interval="0" timeout="40s" \
        op stop interval="0" timeout="60s"
primitive drbd_res ocf:linbit:drbd \
        params drbd_resource="mysql" \
        op monitor interval="29s" role="Master" \
        op monitor interval="31s" role="Slave"
primitive failover_ip ocf:heartbeat:IPaddr2 \
        params ip="192.168.70.202" cidr_netmask="32" \
        op monitor interval="30s"
primitive fs_res ocf:heartbeat:Filesystem \
        params device="/dev/drbd0" directory="/mysql" fstype="ext4"
primitive mysql_res ocf:heartbeat:mysql \
        params additional_parameters="--socket=/var/run/mysqld/mysqld.sock" \
        op start interval="0" timeout="120" \
        op stop interval="0" timeout="120" \
        op monitor interval="10" timeout="30" depth="0" \
        meta target-role="Started"
primitive pandora_res lsb:pandora_server \
        meta is-managed="true" target-role="Started" \
        op monitor on-fail="standby" interval="10s"
ms drbd_master_slave drbd_res \
        meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
colocation apache_fs_colo inf: apache_res fs_res
colocation apache_ip_colo inf: apache_res failover_ip
colocation fs_drbd_colo inf: fs_res drbd_master_slave:Master
colocation mysql_drbd_colo inf: mysql_res drbd_master_slave:Master
colocation pandora_drbd_colo inf: pandora_res drbd_master_slave:Master
order apache_after_fs inf: fs_res apache_res
order apache_after_ip inf: failover_ip apache_res
order fs_after_drbd inf: drbd_master_slave:promote fs_res:start
order mysql_after_apache inf: apache_res mysql_res
order pandora_after_mysql inf: mysql_res pandora_res
property $id="cib-bootstrap-options" \
        dc-version="1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff" \
        cluster-infrastructure="openais" \
        expected-quorum-votes="3" \
        stonith-enabled="false" \
        no-quorum-policy="ignore" 
#crm status
============
Last updated: Tue Oct 21 17:05:35 2014
Last change: Tue Oct 21 17:05:17 2014 via crm_attribute on drbd
Stack: openais
Current DC: drbd - partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 3 expected votes
8 Resources configured.
============

Node drbd: standby
Online: [ drbd2 ] 

failover_ip     (ocf::heartbeat:IPaddr2):       Started drbd2
apache_res      (ocf::heartbeat:apache):        Started drbd2
 Master/Slave Set: drbd_master_slave [drbd_res]
     Masters: [ drbd2 ]
     Stopped: [ drbd_res:1 ]
fs_res  (ocf::heartbeat:Filesystem):    Started drbd2
mysql_res       (ocf::heartbeat:mysql): Started drbd2
pandora_res     (lsb:pandora_server):   Started drbd2
tentacle_res    (lsb:tentacle_serverd): Started drbd2


Volver al índice de documentación de Pandora FMS