Bueno, desde hace algún tiempo estoy trabajando en desplegar un servidor de correo Zimbra con redundancia; que cuando explote el servidor en un datacenter el servicio de correo se mude a otro servidor en otra locación física y que dicha falla sea trasparente para los usuarios. La cosa esta en que Zimbra soporta solo algunos OS Linux entre esos OS no esta Debian GNU/Linux así que nos toco usar SLES11, pueden usar Ubuntu si lo prefieren, aquí esta la lista de los OS soportados .
Entonces SLES 11, vamos a detallar puntos claves para poder hacer esto bien, necesitas:
- 2 PCs
- Red
- Los discos de SLES11 SP3 y sus extensiones H-A
Una vez tengas eso, sigues a lo siguiente que seria:
- Crear el esquema de particiones
- Instalar el SO y los paquetes de H-A
El esquema de particionado puede ser cualquiera que se ajuste a la demanda del servidor pero recuerda que debes dejar en ambos nodos el punto de montaje /opt en una particion diferente a la raíz es decir; el punto raiz ( / ) en /dev/sda1 y (/opt) en otro que puede ser /dev/sda3; las particiones no tienen que ser idénticas en tamaño pero si es recomendable que estén cerca de ser idénticas.
Ok una vez echo eso, digamos que ya instalamos el sistema operativo, seguimos con la instalación de los paquetes de H-A. Es simple, como root llamamos a YAST2, configuramos los fuentes que serian los CDs de H-A de SUSE, instalamos lo siguiente:
- DRBD
- CRM
- COROSYNC
- AGENTES HEARTBEAT
Ahora que ya tenemos eso listo vamos a comenzar a configurar lo primero es el DRBD:
global { usage-count no; }
resource repdata {
protocol C;
startup { wfc-timeout 0; degr-wfc-timeout 120; }
disk { on-io-error detach; }
net { cram-hmac-alg "sha1"; shared-secret "BLOG.rersc.com-RULES"; }
syncer { rate 10M; }
on drbd1 {
device /dev/drbd0;
disk /dev/sda3;
address 172.17.2.149:7788;
meta-disk internal;
}
on linux-szuz {
device /dev/drbd0;
disk /dev/sda2;
address 172.17.2.140:7788;
meta-disk internal;
}
}
Eso seria un ejemplo, por lo general recomiendan que el archivo de DRBD sea idéntico en los nodos replica , eso es cierto en otros casos, no este por que aquí vamos a levantar un servidor de correo que también tiene un frontend web y por eso el tema del DNS viene mas adelante. Ok lo cierto es que al final debes de copiar el archivo a la ruta (/etc/drbd.conf). Existen muchas guías en la Internet de esto así que no voy a profundizar en esta parte. Por cierto una buena guía para el montaje inicial del DRBD es esta del wiki de CENTOS al final debes de obtener un resultado como este:
[root@node1 etc]# watch -n 1 cat /proc/drbd version: 8.0.4 (api:86/proto:86) SVN Revision: 2947 build by buildsvn@c5-i386-build, 2007-07-31 19:17:18
. 0: cs:SyncTarget st:Primary/Secondary ds:Inconsistent/Inconsistent C r---
. ns:0 nr:68608 dw:68608 dr:0 al:0 bm:4 lo:0 pe:0 ua:0 ap:0
. [>...................] sync'ed: 0.9% (8124/8191)M finish: 0:12:05 speed: 11,432 (11,432) K/sec
La primera sincronización tarda dependiendo del espacio de las unidades que almacenan el directorio /opt, pero al final, vas quedar con un super-bloque que marca UP-TO-DATE y un nodo primario y uno secundario. Eso es bueno, ya tienes el primer montaje de todo el Cluster. Ahora sigue copiar la data de Zimbra, particularmente me toco migrar servidores Zimbra que ya estaban en producción pero si a ti te toca una FRESH-INSTALL estas de suerte y llevas las de ganar, pero si te toca migrar servicios que ya estaban produccion es un poco mas complicado, vas a hacer lo siguiente:
- Baja el aplicativo completo aplica un (kill -9 -1) desde el user Zimbra para asegurar.
- SCP a la carpeta (/opt/zimbra) hacia el nodo donde estas construyendo el cluster, puedes copiarla con RSYNC sobre SSH, solo asegurate que no se te quede ningún proceso pegado por que si no la copia nunca terminara.
Una vez que hayas copiado toda la data en el dispositivo primario de DRBD; es decir en el punto de montaje /opt que es utilizado por el dispositivo /dev/drbd0 que es en realidad el super-bloque del cluster, debes asegurarte que el aplicativo levante en el nodo. Para ello copia el archivo /etc/hosts del Zimbra en produccion al nodo replica.
Imaginemos que ya superaste esa etapa donde aplicativo ya levanto en el NODO-1, ahora intenta lo mismo en el NODO 2; cambia el super-bloque al NODO-2 e intenta levantar el mismo aplicativo. Digamos que si levanto y el aplicativo te levanta en el NODO-1 y NODO-2 sin problemas. El siguiente paso es hacer que todo ese proceso: bajar el aplicativo – cambiar el super-bloque de un nodo a otro, levantar el aplicativo se haga de manera automática a la hora de un desastre, allí es donde entran COROSYNC y CRM ( The PACEMAKER Interactive shell) a solucionar eso.
Bueno vamos a resumir por que esta es la parte dura, lo primero es que si no sabes nada sobre CRM o COROSYNC echate un ojo a la pagina del manual de la versión que estas usando, segundo es comprender que una vez que implementas los recursos al cluster debes de gestionarlos por el cluster si no se vuelve un pastel todo. Los recursos del cluster son las piezas que se mueven de un nodo a otro a la hora que explote el servidor primario. Entendido eso, vamos a continuar definiendo los recursos que necesitamos para que esto camine:
- La IP VIRTUAL que coordina el servicio en cluster
- EL Sistema de disco MAESTRO Y ESCLAVO.
- El MONITOR del FS
- El script LSB de arranque de Zimbra.
Vamos primero con la IP virtual:
primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 params ip="192.168.2.100" nic="eth0" op monitor interval="10s" meta is-managed="true"
Ahora vamos con el arreglo de discos:
ha-node-2:~# crm
crm(live)# cib new drbd
INFO: drbd shadow CIB created
crm(drbd)# configure primitive drbd ocf:linbit:drbd params drbd_resource="RECURSO" op monitor interval="60s"
crm(drbd)# configure ms drbd_ms drbd meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
crm(drbd)# configure primitive drbd_fs ocf:heartbeat:Filesystem params device="/dev/drbd1" directory="/media/drbd1" fstype="ext3"
crm(drbd)# configure colocation fs_on_drbd inf: drbd_fs drbd_ms:Master
crm(drbd)# configure order fs_after_drbd inf: drbd_ms:promote drbd_fs:start
crm(drbd)# cib commit drbd
crm(drbd)# cib use live
crm(live)# cib delete drbd
crm(live)# exit
bye
ha-node-2:~#
Claro que tienes que ajustar el código a tu ambiente de trabajo. Y por ultimo pero no menos importante el recurso de gestión del aplicativo.
primitive initzimbra lsb:zimbra \ op monitor interval="120s" timeout="360s" \ op start interval="0" timeout="360s" \ op stop interval="0" timeout="360s"
Con esto tenemos listo los recursos, pero no hemos terminado, si queremos que esto funcione, tenemos que asegurarnos de que todos los recursos se muevan de un lado al otro sin que se quede ninguno, para ello creamos un grupo de recursos, continuamos desde el CRM esta vez desde la sección configuración (configure).
group zimbra-grupo VIP1 drbd_fs initzimbra
Ya con esto tendríamos todo listo para hacer las pruebas, al ejecutar “crm_mon -1” debería de devolverles algo como esto:
2 Nodes configured, 2 expected votes
5 Resources configured.
Online: [ linux-szuz ]- [ tennessee ]
Master/Slave Set: drbd_ms [drbd]
Masters: [ linux-szuz ]
Slave: [ tennessee ]
Resource Group: zimbra-grupo
VIP1 (ocf::heartbeat:IPaddr2): Started linux-szuz
drbd_fs (ocf::heartbeat:Filesystem): Started linux-szuz
initzimbra (lsb:zimbra): Started linux-szuz
Y eso es todo, pueden efectuar la famosa prueba de “Vamos a sacarle el cable” y si todo sale bien verán que el servicio de correo levanta en el otro nodo de forma efectiva, el FAIL-OVER con la carga del aplicativo tarda en levantar entre un minuto a dos minutos y se puede ver el servicio del lado de los clientes desde la IP del Cluster que seria en este caso la 172.17.2.150. Bueno espero les ayude este post, deje bastante sin cubrir pero si necesitan mas INFO me avisan vía comentario. Feliz dia. Nos vemos.