Oscar Mas nos deleita hoy con una entrada muy interesante y demandada, Zimbra con Cluster DRBD.
Veo mucho en los foros, que los administradores de Zimbra, preguntan sobre el sistema DRBD (Distributed Replicated Block Device) para poderlo implementarlo en la plataforma de Zimbra. Yo personalmente, tengo varios clusters DRBD, pero implementados con sistemas de Postfix para dar alta disponibilidad (HA) y tolerancia a fallos (FT). Como es normal, Zimbra no da soporte a instalaciones basadas en este tipo de plataformas, ya que DRBD no está soportado. Por ese motivo para explicar este despliegue usaré Zimbra OpenSource y no la versión Network. Para el desarrollo, usaremos tres piezas fundamentales:
- Zimbra: Poco hay que hablar de este producto
- DRBD: Es el encargado de que los datos se mantengan sincronizados en los dos servidores
- OCFS2: Es el sistema de ficheros que nos permite Activo/Activo o Activo/Pasivo
¿Por qué usar OCFS2 y no otro tipo de sistema de ficheros? La respuesta es, que solo (que yo conozca) hay dos sistemas de ficheros que permitan Activo/Activo. Uno es OCFS2 (de Oracle) y el otro es GFS2, el cual pertenece a RedHat. Si no queréis usar Activo/Activo y lo que queréis es Activo/Pasivo, os aconsejo usar XFS en vez de los sistemas clásicos, como podrían ser Ext3 o Ext4, ya que XFS da mejor performance y rendimiento.
El esquema del sistema quedaría de la siguiente manera:
Montaje del sistema
Para que las dos distribuciones de Linux (en nuestro caso Ubuntu 12.04 LTS) estén a la par, actualizaremos los paquetes la ultima versión:
root@zimbra1:~# aptitude update && aptitude upgrade –y root@zimbra2:~# aptitude update && aptitude upgrade -y
También es importante que los dos sistemas tengan la misma hora, ya que sinó nos podemos volver locos con los logs:
root@zimbra1:~# aptitude install ntp ntpdate –y root@zimbra2:~# aptitude install ntp ntpdate -y
Si lo que realmente queréis es poner en producción este sistema, os aconsejo que uséis la versión 8.4.4 de DRBD, ya que viene con el “dynamically adaptive resync rate controller”, cosa que con la versión 8.4.3 (que es la que usaremos) no viene por defecto. A consecuencia es esto tendremos que ajustar correctamente el valor sync-rate en el fichero de configuración del DRBD.
Con las distribuciones Ubuntu 12.04 existe un bug, el cual la versión del modulo de DRBD es la versión 8.4.3 y la versión del userland es la 8.3.11. Es de vital importancia que tanto la versión de DRBD como la de userland sean la misma. Para que lo entendamos; el userland, son las herramientas de espacio del usuario que interactúan con el Kernel, de ahí que tengan que ser la misma versión. Para que esta capa se entienda con el Kernel, lo que haremos es instalar la versión por defecto de los repositorios de Ubuntu, posteriormente lo eliminaremos y acto seguido compilaremos la versión correspondiente para que cuadren tanto el modulo DRBD como el userland:
root@zimbra1:~# aptitude install drbd8-utils –y && aptitude remove drbd8-utils –y
Como podéis ver en la captura anterior, la versión 8.3.11 que nos ofrece la Ubuntu es muy vieja. Nos descargaremos los paquetes necesarios para poder compilar la versión 8.4.3 y de esta manera tener una versión más reciente del DRBD
root@zimbra1:~# aptitude install psmisc build-essential flex git xsltproc –y root@zimbra1:~# cd /usr/local/src/ root@zimbra1:/usr/local/src# wget http://oss.linbit.com/drbd/8.4/drbd-8.4.3.tar.gz root@zimbra1:/usr/local/src# tar xzvf drbd-8.4.3.tar.gz root@zimbra1:/usr/local/src# cd drbd-8.4.3/ root@zimbra1:/usr/local/src/drbd-8.4.3# ./configure && make && make install
Verificaremos que hemos actualizado el DRBD a la versión 8.4.3:
Crearemos la estructura de ficheros para que podamos trabajar de una manera standard, ya que al compilar el paquete no le hemos pasado ningún parámetro:
root@zimbra1:~# rm -rf /etc/drbd.conf root@zimbra1:~# rm -rf /etc/drbd.d/ root@zimbra1:~# ln -s /usr/local/etc/drbd.conf /etc/drbd.conf root@zimbra1:~# ln -s /usr/local/etc/drbd.d /etc/drbd.d
Configuraremos el DRBD:
root@zimbra1:~# vim /usr/local/etc/drbd.d/zimbra_drbd.res
resource r0 {
protocol C;
meta-disk internal;
device /dev/drbd0;
disk /dev/sdb1;
net {
allow-two-primaries;
cram-hmac-alg "sha1";
shared-secret "oscarmash_zimbra";
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
rr-conflict violently;
}
startup {
wfc-timeout 60;
become-primary-on both;
}
syncer { rate 35M; }
on zimbra1 { address 172.30.30.201:7789; }
on zimbra2 { address 172.30.30.202:7789; }
}
Una vez llegado a este punto, es importante conocer y saber bien los valores que ponemos en cada caso. Os aconsejo que os miréis la documentación de DRBD, ya que es exquisita: http://www.drbd.org/docs/about/ . La explicación de los valores más interesantes del fichero de configuración del sistema de DRBD es la siguiente:
- protocol C – Indicamos que el protocolo de comunicación va a ser síncrono. Lo que se escriba en el disco duro de uno de los nodos, no se considerará acabado hasta que ambos sistemas den el Ok de escritura. Es el protocolo más usado en instalaciones de DRBD
- meta-disk internal – indicamos al sistema que el archivo de meta data, será el mismo que donde tenemos ubicado el disco duro que estamos usando en producción. Cabe destacar que se necesitará un espacio adicional para poder almacenar los mata data
- wfc-timeout 60 – Le indicamos en segundos el tiempo que el sistema esperará a que el otro nodo del cluster esté levantado. Pasado este tiempo arrancará los servicios. Hay que ponerlo, ya que por defecto el tiempo de espera es infinito
- become-primary-on both – Le indicamos al sistema que usaremos Activo/Activo.
- syncer { rate 35M; } – Es el ancho de banda que usará DRBD para hacer la sincronización en background. Ha de ser el 30% del ancho de banda de nuestra Ethernet. Supongamos que tenemos una Ethernet de 1GB, que son 125Mb, el 30% de 125 es 37,5…… para hacer números redondos pondremos 35M en nuestro caso.
Como es de suponer, los dos discos duros que hay en cada Ubuntu, tanto en Zimbra 1 como en Zimbra 2, han de tener el mismo tamaño. Crearemos la partición del disco duro que posteriormente formatearemos con el sistema de ficheros OCFS2:
root@zimbra1:~# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xd74972ac.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-209715199, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-209715199, default 209715199):
Using default value 209715199
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Crearemos el sistema de ficheros del DRBD:
root@zimbra1:~# drbdadm create-md r0 Writing meta data... initializing activity log NOT initializing bitmap New drbd meta data block successfully created. Success
Instalamos las herramientas del sistema de ficheros OCFS2, para poder formatear la partición y que nuestro sistema pueda trabajar con OCFS2:
root@zimbra1:~# aptitude install ocfs2-tools –y Configuramos el OCFS2: root@zimbra1:~# vim /etc/ocfs2/cluster.conf cluster: node_count = 2 name = zimbra node: ip_port = 7777 ip_address = 172.30.30.201 number = 1 name = zimbra1 cluster = zimbra node: ip_port = 7777 ip_address = 172.30.30.202 number = 2 name = zimbra2 cluster = zimbra
Arrancamos los servicios de DRBD:
root@zimbra1:~# service drbd start
Al arrancarlo, podremos ver que esta esperando 60 segundos al otro cluster, tal y como le hemos indicado en el fichero de configuración (/usr/local/etc/drbd.d/zimbra_drbd.res ) del DRBD en la variable wfc-timeout 60; :
Y podremos ver que actualmente nuestro servidor esta Secondary y desconoce como está el otro sistema. Es normal que desconozca como está el otro sistema, ya que aún no lo hemos configurado:
Le indicamos que el nodo 1 (zimbra1) será primario:
root@zimbra1:~# drbdadm -- --overwrite-data-of-peer primary all
Y formateamos la partición de datos que usaremos con el DRBD. Este formateo, solamente se ha de hacer una vez. Es importante usar la variable mail cuando formateamos la partición, ya que automáticamente nos hará el sistema de bloques más pequeños, de no ser así podríamos tener un problema a la larga de INodes: el problema consiste en que si hacemos un df –h, veremos que nos queda espacio libre, pero el sistema nos dirá que no left space, y al hacer un df –i, veremos que los INodos están al 100%:
root@zimbra1:~# mkfs.ocfs2 --label ocfs2-zimbra -T mail /dev/drbd0
Le indicamos al sistema que cuando arranque nos monté la partición, pero hasta que no estén levantadas las tarjetas de red, no lo monte. Esto se hace con la opción _netdev:
root@zimbra1:~# echo "/dev/drbd0 /opt ocfs2 noauto,noatime,nodiratime,_netdev 0 0" >> /etc/fstab
Ahora hemos de realizar los mismos pasos en el segundo servidor de Zimbra, excepto estos dos pasos:
root@zimbra2:~# drbdadm -- --overwrite-data-of-peer primary all root@zimbra2:~# mkfs.ocfs2 --label ocfs2-zimbra -T mail /dev/drbd0
En el momento de levantar los servicios del DRBD del Zimbra2, ya podremos observar que las dos particiones están Primary/Primary y que los datos se replican del Zimbra 1 al Zimbra 2:
Ahora hemos de ser pacientes y esperar a que se repliquen los datos desde el Zimbra1 al Zimbra2. Cargamos los modulos a mano, para poder montar la partición en los dos servidores de Zimbra
root@zimbra1:~# service o2cb load
Y ya para acabar, necesitamos habilitar el sistema OCFS2 que arranque con el sistema operativo y de esta manera nos cargue los modulos, lo podemos hacer mediante el wizard que nos proporciona el paquete deb. Una vez lanzado, si queremos modificarlo manualmente, hay que editar el fichero: /etc/default/o2cb . Para realizar esta operación simplemente hay que lanzar el siguiente comando en los dos servidores:
root@zimbra1:~# dpkg-reconfigure ocfs2-tools
Ahora ya, solamente nos queda montar el sistema de ficheros, en los dos sistemas:
Instalamos las dependencias de Zimbra, en los dos servidores:
root@zimbra1:~# aptitude install libgmp3c2 libperl5.14 pax sysstat sqlite3 –y root@zimbra2:~# aptitude install libgmp3c2 libperl5.14 pax sysstat sqlite3 –y
Y empezamos la instalación únicamente en el primer servidor de Zimbra, ya que en el segundo servidor realizaremos una instalación Dummy:
root@zimbra1:~# cd /usr/local/src/zcs-8.0.6_GA_5922.UBUNTU12_64.20131203103702/ root@zimbra1:/usr/local/src/zcs-8.0.6_GA_5922.UBUNTU12_64.20131203103702# ./install.sh
No voy a entrar, en como se instala el sistema de Zimbra, ya que Jorge tiene un magnifico HowTo de como instalarlo: http://www.jorgedelacruz.es/2013/04/12/instalando-zimbra-8-0-3-ubuntu-12-04/. Ahora hacemos una Dummy instalación en el segundo servidor de Zimbra. Este tipo de instalación, lo que hace es instalar los servicios de Zimbra cogiendo por defecto los valores que encuentre en el directorio opt:
root@zimbra2:~# cd /usr/local/src/zcs-8.0.6_GA_5922.UBUNTU12_64.20131203103702/ root@zimbra2:/usr/local/src/zcs-8.0.6_GA_5922.UBUNTU12_64.20131203103702# ./install.sh -s
Durante la instalación el wizard de nos indicará si queremos borrar el directorio /opt/zimbra, indicarle que no. Esto es debido a que al instalarlo en el servidor de Zimbra 1, el DRBD ha replicado toda la partición /opt, contra nuestro servidor de Zimbra 2:
Como ya hemos comentado anteriormente, Zimbra no es una plataforma que soporte Activo/Activo, por ese motivo aconsejo encarecidamente, deshabilitar los servicios de arranque del segundo cluster (zimbra2) y solamente levantarlos en el momento que tengamos algún tipo de problema con el primer cluster (Zimbra 1)
root@zimbra2:/usr/local/src/zcs-8.0.6_GA_5922.UBUNTU12_64.20131203103702# update-rc.d -f zimbra remove
Un saludo y espero que os sirve de guía.
Qué guapo! 🙂 Esto me lo tendré que mirar con calma y probarlo ya que es algo que nunca he hecho.
Me servirá poco en sistemas en producción ya que no es algo soportado y suelo trabajar con la NE, pero sin dudas es algo muy útil.
En el roadmap de Zimbra hay algo de activo/activo pero de aquí a unos años no lo veremos. Primero veremos el cambio de MySQL a MariaDB y de a poco irán metiendo cosas de activo/activo. Estaría bien que lo soportaran YA sobre Gluster o el el FS de Oracle que explicas…aquí hay una ventaja clara de Exchange que hace años que trabaja muy bien con sus DAGs.
Muchas gracias por todos vuestros posts, sois unos máquinas 🙂
Sebas
Muchas gracias Sebas por tus siempre amables comentarios.
Lo que tenemos que hacer es hacer una quedada de comunidad Zimbra en España 🙂
Un abrazo
Si tienes cualquier consulta, no dudes en contarnoslo, ya que por gracia o desgracia conozco bastante bien el sistema de DRBD.
No he usado nunca drbd, y ahora que estoy intentando cuando trato de ejecutar drbdadm create-md r0 me sale el siguiente error ‘r0’ not defined in your config (for this host)
Estoy usando centos pero el archivo res lo coloque donde var por defecto.
Agradezco me ayuden con esto
Hola Jorge esta entrada esta genial sin embargo me gustaría saber si puedes ayudarme a crear un cluster con un ya zimbra funcionando
Hola Edgard.
Si quieres ayuda en relación a un sistema clusterizado con Zimbra, puedes ponerte en contacto con mi empresa o con la de Jorge para poder darte soporte.
Oscar Puedes mandarme un correo electrónico donde esrcribirte y plantearte el escenario deseado para que nos cotices la solución ?
Hola buen día Oscar, muy buena explicación, solamente me queda la duda si obligatoriamente se tienen que realizar todos los pasos antes de instalar Zimbra o hay alguna manera de poder realizar el Cluster de un Servidor ya con Zimbra instalado y operando.
Saludos y quedo al pendiente.
Hola Jesús
No hay ningún tipo de problema (aunque yo haría un laboratorio para verificarlo todo) en montarlo antes o después, ya que el DRBD es un servicio que sincroniza dos H.D., el sistema de ficheros puede ser Ext4, XFS, OCFS2, etc….. a DRBD les da igual el sistema de ficheros que uses. Aunque como indico en el post, Zimbra no es un sistema Primary/Primary, así que te aconsejo usar el mismo sistema de ficheros que tienes ahora en tu sistema, el cual supongo que debe de ser Ext4. Aunque si yo lo montase usaría XFS, el cual da unos rendimientos espectaculares.
Lo que es muy importante es que el sync-rate le pongas el valor correcto y si quieres tunear el sistema de ficheros, te aconsejo que te revises la documentación del noatime del fstab.
También es importante, que te curres los scripts ante una caída de servicio, ya que el sistema por si solo, no cambia de Primary/Secondary a Secondary/Primary…… eso sin contar que tampoco te levantaría el sistema de Zimbra.
Espero ayudar…
Muchas gracias por la atención y sugerencias, saludos y excelente Blog.
Excelente post. Tengo la siguiente interrogante, ya configure ambos nodos activo/activo lo formatee ext4.
Servidor 1:
CentOs6_Serv1 data]# service drbd status
drbd driver loaded OK; device status:
version: 8.4.4 (api:1/proto:86-101)
GIT-hash: 599f286440bd633d15d5ff985204aff4bccffadd build by phil@Build64R6, 2013-10-14 15:33:06
m:res cs ro ds p mounted fstype
0:clusterdb Connected Primary/Primary UpToDate/UpToDate C /data ext4
Servidor 2:
CentOs6_Serv2 data]# service drbd status
drbd driver loaded OK; device status:
version: 8.4.4 (api:1/proto:86-101)
GIT-hash: 599f286440bd633d15d5ff985204aff4bccffadd build by phil@Build64R6, 2013-10-14 15:33:06
m:res cs ro ds p mounted fstype
0:clusterdb Connected Primary/Primary UpToDate/UpToDate C /data ext4
He leido varios post, pero no consigo como hacer para sincronizar ambos disco, creo archivos de prueba en el servidor1 y entiendo que el deberia sincronizarse y aparece esa información replicada en el servidor2.
Hola,
Por lo que indicas, estas usando un sistema de ficheros (en tu caso EXT4), el cual no soporta Activo/Activo. Si queires Activo/Activo con EXT4, tendrás que usar GlusterFS o cambiar de sistema de ficheros a OCFS2.
Un saludo
Felicitaciones, una guía paso a paso muy bien explicada y de excelente nivel técnico como la gran parte de la información contenida en este sitio. Solo tengo una duda respecto a DRBD, si en el nodo 1 tengo un error en el HD que provoca cluster dañados, ese daño se replica en el nodo2 ?
Saludos!
Ivan
Hola Ivan,
por desgracia, los sistemas basados en Bloque, como es el caso de DRBD, en el momento que uno de los nodos tiene algún tipo de error, ese mismo error se lo pasa al otro nodo. Esto no es teoría, tengo un cluster basado en DRBD con 30.000 cuentas de correo y el año pasado, a consecuencia de un golpe en el Hardware, uno de los nodos empezó a tener problemas. Activamos el segundo nodo y los problemas se volvieron a reproducir en el segundo nodo. Al final tuvimos que hacer una parada y hicimos que el sistema chequease los discos duros. A partir de ese momento no hemos tenido más incidencias y el sistema ha estado estable durante 4 años.
Si estas pensando en algún sistema de almacenamiento fiable y estable, te aconsejo que mires Ceph, no quiere decir que DRBD sea malo, sino que es otra tecnología. Pero esto irá en función de la cantidad de servidores que quieras usar, aunque Ceph funciona correctamente con dos servidores.
Un detalle a tener en cuenta, es que OCFS2 no es el mejor sistema de ficheros, ya que cuando llega al 70% o 80%, empieza a ser inestable. Te aconsejo usar un sistema de ficheros standard como puede ser Ext4 o XFS.
Un saludo
Hola Oscar,
Tengo que instalar Zimbra en dos servidores para tener HA. Aún no me decido por cuál tecnología utilizar, DRDB me pareció interesante pero claro, existe el problema que te consultaba. Es para solucionar la vida a un amigo que tiene un pequeño ISP y “heredó” un servidor de correo inmanejable. Quizás con DRDB y algún backup periódico de las ctas de usuario sea suficiente. De todas maneras voy a mirar Ceph.
Gracias
Ivan
Hola Oscar, realize exitosamente la instalación de DRBD e instale Zimbra1, pero cuando voy a realizar la instalación Dummy de Zimbra2 y voy a inicializar los servicios me muestra lo siguiente:
zimbra@pruebazimbra2:~$ zmcontrol start
Host localhost
Connect: Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.
Starting ldap…Done.
Failed.
ldap_url and ldap_master_url cannot be the same on an ldap replica
Gracias por la ayuda brindada.
Hola Jeisson
Necesitaría más datos para poderte ayudar, pero si no has de implementar esta solución en breve, te aconsejo que te mires el proyecto Always On, ya que puede ser una gran alternativa a este tipo de proyectos.
Wow! gracias! me funciono la replicacion de datos. pero una consulta, es posible configurar 2 particiones de ocfs2 en un mismo servidor? algo asi:
Serv1 /mnt/part1 —- (ocfs2+drbd) —— /mnt/part1 en Serv2
Serv1 /mnt/part2 —- (ocfs2+drbd) —— /mnt/part2 en Serv2
drbd si me permite (como te muestro lineas abajo) pero en el cluster.conf del ocfs2 no se como poner dos instancias de replicacion… intente poniendo dis veces cada seccion (como muestro abajo) pero no funcino… disculpa que te moleste con estas cosas… si tienes algun tiempito.. estare feliz de saber por fin como se hace!! hace tiempo estoy con esto.
P.D. Preferiria no usar CMAN.. muchos problemas con el fencin….
###### /etc/ocfs2/cluster.conf #############
cluster:
node_count = 2
name = cluster1
cluster:
node_count = 2
name = cluster2
#######################
root@lap-001:~# cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
srcversion: F937DCB2E5D83C6CCE4A6C9
0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r—–
ns:71 nr:486 dw:557 dr:2061 al:2 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r—–
ns:796300 nr:76 dw:796376 dr:541102 al:128 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
Hola Rafael, lo que comentas es totalmente posible. Pero por mi experiencia, no te aconsejo OCFS2, si puedes cambiar a XFS sería una buena idea, ya que OCFS2 cuando llega al + o – 80%, se vuelve inestable.
Excelente Post!
Estimado Oscar,
¿Sabes si las versiones 8.6 de Zimbra ya soportan Activo/Activo? Porque estoy buscando una solución que evite el tiempo donde zimbra está levantando (al hacer failover) y por lo tanto inaccesible.
gracias!
Hola Daniel,
Tendremos que esperar a finales de este año o a principios del año que viene, a que Zimbra saque la versin 9, que llevar el Always-ON…… https://blog.zimbra.com/2013/09/project-always-on/
Un saludo
Excelente el sitio. Gracias!
Consulta, tengo 2 servidores con 6 discos cada uno en RAID10, afectaría en algo que yo quiera usar DRDB para que sincronize el /opt (RAID10) de ambos servidores?
Saludos a Oscar y a Jorge
Una pregunta, de acuerdo a este comentario:
“Como ya hemos comentado anteriormente, Zimbra no es una plataforma que soporte Activo/Activo, por ese motivo aconsejo encarecidamente, deshabilitar los servicios de arranque del segundo cluster (zimbra2) y solamente levantarlos en el momento que tengamos algún tipo de problema con el primer cluster (Zimbra 1)”
Este instructivo no sirve para levantar un cluster de Zimbra Activo-Activo?
Saludos cordiales
Hola, hace tiempo uso DRBD pero en conjunto con Heartbeat en vez de OCFS2, a mi me parece mejor ya que gestiona por completo el failover.
Quería consultarte como lo hacen con el problema de los Logs y estadísticas de Zimbra al tener dos servidores que “fingen” ser el mismo. Al consultar las estadísticas recibo el error:
Message: system failure: java.lang.ArrayIndexOutOfBoundsException: 10 Error code: service.FAILURE Method: [unknown] Details:soap:Receiver
Mis servidores se llaman mail-1.midominio.com y mail-2.midominio.com, tienen sus propias IP, pero con Hertbeat hago que el que está como primario levante una IP virtual que corresponde al nombre de host mail.midominio.com. Zimbra en todas partes tiene registrado que está instalado en el host mail.midominio.com, sin embargo parece que los logs y estadísticas no lo reconocen, saben que están o en mail-1.midominio.com o mail-2.midominio.com y creo que por eso da error.
Lo logro solucionar siguiendo los paso indicados acá:
http://community.zimbra.com/collaboration/f/1886/t/1133718
Sin embargo cada cierto tiempo vuelve a ocurrir, es muy desagradable no tener acceso a las estadísticas. ¿Te ha ocurrido,? ¿Podrías comentarnos algo de este tema?
¡Saludos y gracias!
Saludos Jorge, buen trabajo.
Pregunto, ya lograste el activo/activo a nivel de datos.
Ahora que usas para distribuir la carga? heartbeat-pacemaker?
Digo si como usuario voy a la web del correo, quien me distribuye la conexion sea a zimbra1 o a zimbra2? Gracias.
Hola, muy buen post.
Entiendo que la gente compara drbd como un raid 1 a traves de la red, ya que replica de manera exacta todos los datos en todos los discos.
Existe alguna forma de hacer un raid 5 por ejemplo ?
o algo menos complicado un raid 0 ( sumar todas las unidades como una sola unidad logica accesible desde todos los nodos?
He intentado buscar informacion en internet y creo que no me expreso bien y mi ingles es bastante pobre, leo mejor de lo que me expreso asi que las busquedas se me hacen muy complejas.
Un saludo y gracias de antemano
Hola don Jorge;
El servidor lo configure y trabaja de lo mas bien, lo único es que al reiniciarlo no levanta la unidad /dev/drbd0 y si la monto manual no hay problema, sera la versión de ubuntu(16.04) o la versión de drbd (8.4.5) ya he investigado y he probado varias versiones y todas me dan el mismo problema, ayer de hecho prové la versión 9 e igual.
Saludos, y gracias…
Saludos Jorge.
Primero que todo gran blog.
Tengo una duda para implementar HA en Zimbra.
Se puede desplegar HA integrando ya un Mail Zimbra Activo, me explico:
Actualmente ya un server corriendo y quiero montar otro server para brinar HA y FT para el servicio, pero la duda es que si se puede implementar sin problemas como lo describe es este post o que consideraciones debo tomar o un instructivo para realizar esto.
Muchas gracias por su ayuda.
Jorge solo una pregunta.
Digamos que no quiero usar DRBD y lo que hago es instalar zimbra1 y luego zimbra2, pero por ultimo creo un cron con rsync (diferencial) para que cada cierto tiempo lo que este en zimbra1 lo mande a zimbra2, de esta forma los 2 zimbra siempre sean idénticos en cuanto a /opt , cosa de que cuando zimbra1 falle, lo que hago es acomodar la IP en zimbra2 y levantar los servicios.
Es valido esto? Es que hace años use DRBD y fue un dolor de cabeza con las reiniciadas o apagones inesperados, no me dio confianza en esos tiempos.
Saludos Jose Alberto,
No lo he probado nunca, supongo que con eso y un backup de la DB y del LDAP estarías cubierto, dale un vistazo y me dices.
Un saludo
Muy bueno!!! necesito informacion para (postfix + dovecot HA) 5-000-000 de usuarios debian9
Saludos Jorge y Oscar, voy a probarlo pero en 02 nodo centos 7.9, ya tengo un zimbra funcionando y configurado, que se recomienda realizar para no se pierda la data y se adapte a la nueva configuración del clúster. Como es una VM en Vmware, puedo agregarlo en disco para el RDBD, pero la data de zimbra ya esta en la partición /opt de mi primer disco.
Gracias por sus recomendaciones.