Pandora: Documentation es: DRBD Appiliance
Volver a Indice de Documentacion Pandora FMS
Contents
- 1 HA en Pandora FMS Appliance Centos
- 1.1 Introducción a DRBD
- 1.2 Entorno Inicial
- 1.3 Instalación paquetes y dependencias necesarias
- 1.4 Configuración DRBD
- 1.4.1 Configuración inicial de DRBD
- 1.4.2 Configurar nodos DRBD
- 1.4.3 Disco inicial (Nodo principal)
- 1.4.4 Crear la partición en el nodo principal
- 1.4.5 Obtener información sobre el estado del sistema
- 1.4.6 Configurando el mysql en el disco DRBD
- 1.4.7 Recuperación manual de split brain
- 1.4.8 Switchover Manual
- 1.5 Configuración Corosync / Pacemaker
- 1.6 Configuración recursos Pacemaker
- 1.6.1 Configuración de la IPs virtual como recurso en el cluster
- 1.6.2 Creación del recurso Apache.
- 1.6.3 Creación del recurso DRBD y montaje del Filesystem
- 1.6.4 Creación del recurso Mysql o Percona
- 1.6.5 Creción del recurso Pandora
- 1.6.6 Creación del recurso Tentacle
- 1.6.7 Configuración final de Pacemaker
1 HA en Pandora FMS Appliance Centos
1.1 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.
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.
1.2 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
1.3 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:
[[email protected] ~]# 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/x86_64/python-pssh-2.3.1-4.1.x86_64.rpm rpm -Uvh http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-6/x86_64/pssh-2.3.1-4.1.x86_64.rpm rpm -Uvh http://rpm.repo.onapp.com/repo/centos/6.6/x86_64/RPMS-4.0/crmsh-2.1-1.6.x86_64.rpm
1.4 Configuración DRBD
1.4.1 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
}
}
1.4.2 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)
[[email protected] ~]# 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...
1.4.3 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 [email protected], 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
1.4.4 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:
[[email protected] ~]#mkdir /mysql
1.4.5 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
1.4.6 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
1.4.7 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 [email protected], 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 [email protected], 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
1.4.8 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
|
|
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. |
|
1.5 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 :
[[email protected] ~]# 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 [email protected]:/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
[[email protected] ~]# 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 ]
[[email protected] ~]# 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 ]
|
|
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. |
|
1.6 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.
|
|
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'.
1.6.1 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.
1.6.2 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:
[[email protected] ~]# /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.
[[email protected] ~]# 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 [[email protected] ~]# crm node standby [[email protected] ~]# 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
1.6.3 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.
1.6.4 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
1.6.5 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
1.6.6 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
1.6.7 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
