Pandora:Documentation es:DRBD

From Pandora FMS Wiki

Jump to: navigation, search

Volver al índice de documentación de Pandora FMS

HA en Pandora FMS con DRBD

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). Varios servidores de Pandora FMS y la consola 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.10.101 (castor) -> Master 192.168.10.102 (pollux) -> Slave 192.168.10.100 virtual-ip

En nuestro escenario, el único servidor de Pandora FMS esta corriendo aquí:

192.168.10.1 pandora -> mysql app

Cada nodo tiene dos discos duros:

/dev/sda con el sistema Linux estandar. /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ízelo antes de continuar, utilizando ntp or un dispositivo similar.

Instalar paquetes

Instalar los siguientes paquetes (Debian)

apt-get install heartbeat drbd8-utils drbd8-modules-2.6-686 mysql

Instalar los siguiente paquetes (Suse)

drbd heartbeat hearbeat-resources resource-agents mysql-server

DRBD setup

Configuración inicial de DRBD

Editar /etc/drbd.conf

global {
  usage-count no;
}

common {
 protocol C;
}

resource mysql {
   on castor {
       device /dev/drbd1;
       disk /dev/sdb1;
       address 192.168.10.101:7789;
       meta-disk internal;
   }
   on pollux {
       device /dev/drbd1;
       disk /dev/sdb1;
       address 192.168.10.102: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 Lynux)

fdisk /dev/sdb

Borre toda la información en él.

dd if=/dev/zero of=/dev/sdb1 bs=1M count=128

(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).

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.

castor:/etc# 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.

castor:~# 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:

castor# mkdir /drbd_mysql
castor# mount /dev/drbd1 /drbd_mysql/

No puede hacer esto (montar) en el secundario. Para hacer esto, antes necesitará promoverlo a principal, y previamente, necesita degradar el primario a secundario:

En el principal (castor):

castor# drbdadm secondary mysql 

En el secundario (pollux):

pollux# drbdadm primary mysql

Obtener información sobre el estado del sistema

Ejecutado desde el nodo del master actual (castor):

castor:/# drbdadm state mysql
Primary/Secondary
castor:/# drbdadm dstate mysql
UpToDate/UpToDate

Y desde pollux (backup, disco de replicado):

pollux:~# drbdadm state mysql
Secondary/Primary
pollux:~# 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/mysql/my.cnf
/var/lib/mysql/

Lo primero es detener el mysql en los nodos principal y secundario.

En el nodo principal:

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:

mv /etc/mysql/my.cnf /drbd_mysql/
mv /var/lib/mysql /drbd_mysql/mysql
mv /etc/mysql/debian.cnf /drbd_mysql/

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

ln -s /drbd_mysql/mysql/ /var/lib/mysql
ln -s /drbd_mysql/my.cnf /etc/mysql/my.cnf
ln -s /etc/mysql/debian.cnf /drbd_mysql/debian.cnf

Reinicie mysql.

En el nodo secundario:

rm -Rf /etc/mysql/my.cnf
rm -Rf /var/lib/mysql
ln -s /drbd_mysql/mysql/ /var/lib/mysql
ln -s /drbd_mysql/my.cnf /etc/mysql/my.cnf

Cree la base de datos de Pandora FMS

Asumimos que tiene los ficheros por defecto de SQL para crear los ficheros de la base de datos de Pandora FMS en /tmp.

mysql -u root -p
mysql> create database pandora;
mysql> use pandora;
mysql> source /tmp/pandoradb.sql;
mysql> source /tmp/pandoradb_data.sql;

Configure permisos:

mysql> grant all privileges on pandora.* to pandora@192.168.10.1 identified by 'pandora';
mysql> flush privileges;

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:

castor:~# 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:
 pollux:/# 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 /drbd_mysql

6. Inicie MySQL

/etc/init.d/mysql start

Configuración de Hearbeat

Configuración de Heartbeat

Suponemos que tiene instalados los paquetes de hearbeat en los drbd utils, lo cual incluye un fichero de recursos heartbeat en

/etc/ha.d/resource.d/drbddisk

En primer lugar, necesitará habilitar ip_forwarding.

En sistemas DEBIAN edite /etc/sysctl.conf y modifique la siguiente línea:

net.ipv4.ip_forward = 1

En los sistemas SUSE, sólo tiene que utilizar YAST y configurar el destinatario activo en la interfaz para heartbeat (en esta documentación es eth1).

configure la dirección ip /etc/hosts en ambos hosts:

192.168.10.101  castor
192.168.10.102  pollux

Fichero principal Heartbeat file: /etc/ha.d/ha.cf

Edite el fichero /etc/ha.d/ha.cf tal como sigue en ambos nodos:

# Sample file for /etc/ha.d/ha.cf
# (c) Artica ST 2010

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 30
warntime 10
initdead 120
udpport 694
bcast eth1
auto_failback on   
# auto_failback on Make the cluster go back to master when master onde gets up.
# auto_failback off Let the master node to secondary when it gets up after a failure.
ping 192.168.10.1  # Gateway de nuestra red que debe responder al ping
apiauth ipfail gid=haclient uid=hacluster #o los que corresponda
node castor
node pollux

Fichero de recursos HA

Edite /etc/ha.d/haresources en ambos hosts:

castor drbddisk Filesystem::/dev/drbd1::/drbd_mysql::ext3 mysql 192.168.10.100

Esto define el nodo "master" por defecto. En esas lineas usted define el nombre del nodo por defecto. Es el script del recurso para iniciar/detener el nodo. El filesystem y el mount point, el recurso drbd (mysql) y la direccion de la IP virtual (192.168.10.100).

Configurando la autenticación

Edite /etc/ha.d/authkeys en ambos hosts:

auth 2
2 sha1 09c16b57cf08c966768a17417d524cb681a05549

EL número "2" significa que tiene dos nodos, y el hash es un sha1 HASH.

Do a chmod of /etc/ha.d/authkeys

chmod 600 /etc/ha.d/authkeys

Desactive el startup automático del demonio mysql. Desde ahora, deberá ser gestionado por heartbeat.

rm /etc/rc2.d/S??mysql

Primer arranque de heartbeat

En primer lugar, asegúrese de que DRBD es correco y está corriendo bien, de que también MySQL está trabajando de que la base de datos ha sido creada. Inicie heartbeat en ambos sistemas, pero PRIMERO en el nodo principal:

En castor:

/etc/init.d/heartbeat start

En pollux:

/etc/init.d/heartbeat start

Los Logs en /var/log/ha-log deberían ser suficientes para saber si todo es correcto. El nodo Master (castor) debería tener la dirección de la IP virtual. Cambie los ficheros de configuración de pandora en la consola y el servidor para usar la IP virtual y reinicie el servidor de Pandora FMS:


Necesita tener un watchdog del servidor de Pandora FMS para detectar cuando la conexión está caída o utilizar la opción de reinicion en pandora_server.conf:

restart 1
restart_delay 60

Probando el HA: Prueba de fallo total

1. Inicie un navegador web y abra sesión. Ponga la vista del servidor en modo autorefresco con 5 segundos de intervalo:

2. Cierre el nodo principal:

Presione el botón poweroff.

-o-

Ejecute 'halt' en la consola root.

3. Ponga un tail -f /var/log/ha-log en el nodo secundario para vigilar cómo está trabajando el switchover.

4. El Switchover puede llevar de 3 a 5 segundos.

Volver al índice de documentación de Pandora FMS