Oscar Mas hoy nos deja esta obra maestra de Post para combinar Ceph y Zimbra, espero os guste y os sirva.
Desde hace ya tiempo estoy buscando un Storage asequible, para poder implementar Zimbra, reducir costes y hacer que el producto aparte de ser bueno, sea más atractivo. Ya que los Storages son bastante caros y en ocasiones además de pagar la infraestructura y los discos duros ( ej. Cabinas Dell, HP, etc….), hemos de pagar a la empresa que gestiona el software, cada GB presentado a nuestro VMWare, Zimbra, etc. ( ej. Nutanix, DataCore, etc). Incluso me he encontrado, que para usar discos duros SSD, para poder hacer de cache en una cabina, nos han hecho pagar el software que lo gestiona, a parte de los discos duros SSD.
Existen muchas soluciones alternativas, Zimbra después de la adquisición de Mezeo tiene la suya propia. Pero una de las que más me ha impresionado y después de que RedHat la comprase, realmente me he lanzado a trabajar con Ceph. Que RedHat haya comprado Ceph, quiere decir que el producto evolucionará a pasos agigantados, tal como lo hizo con GlusterFS y se irá perfeccionando a medida que pase el tiempo. Suena muy bien.
Nomenclatura de Ceph
Durante todo el post, usaré una nomenclatura que puede resultar desconocida para nuestros oídos. Os dejo el enlace donde está explicada cada uno de estos nombres:
- RBD: http://ceph.com/docs/master/man/8/rbd/
- MDS: http://ceph.com/docs/master/man/8/ceph-mds/
- OSD: http://ceph.com/docs/master/man/8/ceph-osd/
- Monitor: http://ceph.com/docs/master/man/8/ceph-mon/
- Ceph: http://ceph.com/docs/master/man/8/ceph/
Porque escoger Ceph
Os paso una pequeña lista, de porque escoger Ceph frente a otros productos. Aunque una pequeña búsqueda en google, podréis encontrar más motivos:
- Económico: Ss opensource, pero gracias a RedHat, ya no estamos solos, podremos adquirir su soporte en caso necesario
- Split-Brain: En este tipo de montajes, al poder desplegar monitors a nuestro antojo, nos olvidamos del problema conocido, el cual hace que el sistema entre en conflicto al no saber el estado del sistema ante un error inesperado.
- No failover: No hay puntos de fallo en la arquitectura Ceph, su diseño está pensado para ser resistente a fallos
- Ceph Gateway: Posibilidad de conectarnos a otras infraestructuras con Amazon, Swift, etc…..
- Administración centralizada (ceph-deploy)
- RBD Caching: Podremos usar la paginación de cache del propio sistema operativo a través del Kernel
- Cache Tiering: Podremos poner un equipo de frontend, para realizar las funcionalidades de cache y lo podremos configurar en dos modos: writeback y read-only mode
- Journaling: Posibilidad de poner discos duros SSD para el Journaling del storage
- No RAID: Es obligatorio, que los equipos no tengan RAID por hardware ni por software, ya que disminuiremos la performance
- Bloques: Posibilidad de trabajar con diferentes tamaños de bloques
- RBD: Con RBD, podremos:
- Ampliar, reducir particiones en caliente
- Gestionar snapshots
- etc…
Estos simplemente son ejemplos de lo que puede llegar a hacer Ceph, pero os aconsejo que os miréis la documentación de su Wiki oficial, la cual está muy bien estructurada.
Implementación
Este howto, no está enfocado a producción, ya que hay cosas que no son viables para dicha funcionalidad:
- No se realizan modificaciones en el fichero ceph.conf, cosa que es necesaria.
- En los nodos 2 y 3, solamente se le ha añadido un HD para la implementación, unificando storage con journaling.
- Simplemente hemos usado una red para la implementación, cosa que como mínimo necesitaríamos dos redes y podríamos llegar a tener hasta tres redes:
- Clients & Monitor
- Data Replication
- HeartBeat
- Los ficheros ( por ejemplo los logs del Ceph ) no están puestos en su correspondiente ubicación
- etc….
Lo que quiero, es enseñar y quitar el miedo a una implementación de este tipo. Los equipos virtuales que hemos creado para este despliegue son los siguientes:

El esquema que nos ha de quedar una vez finalizado el howto, sería el siguiente ( no os asustéis 😉 ):
He dividido la implementación de esta infraestructura en 3 Fases:
- Fase – 1:
- Implementación de un monitor en node1 y implementación de 2 OSD en node2 y node3
- Preparación de los espacios
- Fase – 2:
- Añadiendo el MDS al node1 y añadiendo dos OSD en node2 y node3
- Fase – 3:
- Configurar el servidor de Zimbra para que pueda ver el storage entregado por Ceph
Funcionalidad de cada servidor
Al acabar el howto, veremos que las funcionalidades que hemos aplicado, son las siguientes:
- admin-node: desde este servidor gestionaremos todo nuestro cluster de Ceph
- node1: este servidor tiene dos funcionalidades
- Monitor: sería el árbitro en caso de caída de uno de los dos hosts (con esto conseguimos elimiar el Split Brain)
- MDS: es donde está ubicada la MetaData
- node2 y node3: estos servidores tienen dos funcionalidades
- Monitor: Al tener tres monitores, en caso de caída, el sistema sabrá siempre cual es el que está operativo
- OSD: es la funcionalidad que nos permite gestionar el storage
Preparación Ceph
Partimos de la base, en la cual tenemos instalados 1 servidor con Ubuntu 14.04 LTS (que alojará nuestro servidor de Zimbra) y de 4 sistemas operativos con CentOS 6 instalados, con la opción “minimal”:
He usado CentOS 6, ya que todavía Ceph no tiene soporte para CentOS 7 ( cosa que para RedHat 7 si que lo tiene ). No es necesario añadir los repositorios EPEL ni customizar los sistemas operativos, ya que en el momento que despleguemos Ceph en los servidores, este se encargará de descargar los paquetes necesarios. Como podría ser el paquete wget, etc…. y nos añadirá diferentes repositorios para su correcto funcionamiento.
Una nota bastante importante, es que todos los servidores han de tener resolución con los demás. Para realizar esto, podemos crear punteros DNS (en nuestro servidor DNS) o añadir las entradas en el fichero hosts a mano. Yo personalmente, para agilizar las comunicaciones, he añadido en todos los servidores el mismo fichero hosts:
Toda la instalación, configuración y administración de Ceph, se hace desde un equipo centralizado. En nuestro caso, hemos usado el servidor denominado “admin-node”, por consiguiente, desde este equipo hemos de crear una clave SSH y distribuirla en todos los equipos que queramos añadir al cluster de Ceph (node1, node2, node3) y al servidor de Zimbra. Una buena prueba, es acceder desde este servidor a uno de los nodos y comprobar que no pida contraseña, para poder acceder al servidor de destino:
Acordaros de deshabilitar los firewalls y el SeLinux de los sistemas operativos CentOS.
Instalación de Ceph
Antes de empezar con la instalación, crearemos los directorios donde irán ubicados los ficheros de configuración, logs, etc… este procedimiento, lo realizaremos en los cuatro servidores que formaran parte del cluster de Ceph:
[root@admin-node ~]# ssh admin-node “mkdir -p /etc/ceph /var/lib/ceph/{tmp,mon,mds,bootstrap-osd} /var/log/ceph”
[root@admin-node ~]# ssh node1 “mkdir -p /etc/ceph /var/lib/ceph/{tmp,mon,mds,bootstrap-osd} /var/log/ceph”
[root@admin-node ~]# ssh node2 “mkdir -p /etc/ceph /var/lib/ceph/{tmp,mon,mds,bootstrap-osd} /var/log/ceph”
[root@admin-node ~]# ssh node3 “mkdir -p /etc/ceph /var/lib/ceph/{tmp,mon,mds,bootstrap-osd} /var/log/ceph”
La instalación de Ceph, la haremos única y exclusivamente en el servidor desde el cual gestionaremos toda la infraestructura de Ceph (admin-ceph). Lo primero que haremos, es añadir los repositorios de Ceph, en concreto le indicaremos que queremos instalar la última versión, llamada: “firefly”:
[root@admin-node ~]# vim /etc/yum.repos.d/ceph.repo
[ceph-noarch]
name=Ceph noarch packages
baseurl=http://ceph.com/rpm-firefly/el6/noarch
enabled=1
gpgcheck=1
type=rpm-md
gpgkey=https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc
A partir de ahora, todos los comandos que lancemos para gestionar, crear, modificar, etc… nuestro cluster de Ceph, lo haremos desde el directorio /etc/ceph ( esto es muy importante, ya que si no, nos fallaran casi todos los comandos ). Ahora solamente nos queda instalar Ceph en el servidor que usaremos para administrar el cluster, el cual es “admin-node”:
[root@admin-node ~]# cd /etc/ceph/
[root@admin-node ceph]# yum install ceph-deploy –y
FASE – 1
La configuración de Ceph, la haremos en varias fases. Instalaremos Ceph en los cuatro servidores, activaremos un monitor en el node1 y instalaremos 2 OSD en los nodos: node2 y node3. Así que nos quedará de la siguiente manera:
Configuración de Ceph
Una vez instalado, procederemos a realizar el primer paso; crear en cluster indicándole un monitor inicial:
[root@admin-node ceph]# ceph-deploy new node1
Podremos observar, que acabado de lanzar el comando, nos ha creado la estructura de ficheros:
Los ficheros son los siguientes:
- ceph.conf: fichero de configuración del cluster
- ceph.log: fichero donde irán ubicándose los logs de los comandos de Ceph
- ceph.mon.keyring: fichero clave de ceph
Editaremos en fichero de ceph.conf y bajo la sección “[global]” le indicaremos que nuestro cluster dispone de dos OSD. De no hacerlo así, al verificar el cluster nos dará errores, ya que Ceph viene por defecto preparada para un mínimo de 3 OSD:
[root@admin-node ceph]# vim ceph.conf
[global]
…
osd pool default size = 2
Ahora instalamos Ceph, en todos los servidores que gestionaran el cluster. Podremos observar que el sistema se conecta a los diferentes equipos e instala todos los paquetes y dependencias. Durante este procedimiento que es automático, podremos ver que nos instala el wget, nos añade los repositorios de EPEL, etc….. os aconsejo que le echéis un vistazo, ya que la salida por pantalla que nos muestra, es muy extensa.
[root@admin-node ceph]# ceph-deploy install admin-node node1 node2 node3
Inicializaremos el monitor desplegado anteriormente:
[root@admin-node ceph]# ceph-deploy mon create-initial
Para realizar el laboratorio, hemos añadido un disco duro de 35 GB (sdb), a los dos nodos que gestionaran el storage (node2 y node3). Para posteriormente presentárselos al servidor de Zimbra.
Desde la consola de Ceph, podremos ver el disco duro ubicado en el nodo2:
[root@admin-node ceph]# ceph-deploy disk list node2
Seguidamente, primero prepararemos los dos discos duros y posteriormente los activaremos (el orden en esta secuencia es inalterable). Por defecto Ceph, nos formatea las particiones en formato XFS, cosa que veo perfecta. Eso quiere decir que el internamente gestionará los datos en formato XFS.
[root@admin-node ceph]# ceph-deploy osd prepare node2:sdb node3:sdb
Al activar las particiones, le indicaremos que en sdb1 nos ubique los ficheros y en sdb2 nos ubique el journaling. Este configuración, es totalmente errónea para un entorno en producción, ya que el journaling tendría que estar ubicado en otro disco duro, pero para hacer este lab ya nos sirve.
[root@admin-node ceph]# ceph-deploy osd activate node2:/dev/sdb1:/dev/sdb2 node3:/dev/sdb1:/dev/sdb2
Podremos observar el resultado, en cualquiera de los dos nodos:
[root@admin-node ceph]# ceph-deploy disk list node3
Copiaremos los ficheros de configuración y las claves desde el servidor “admin-node” a todos los miembros del cluster:
[root@admin-node ceph]# ceph-deploy admin admin-node node1 node2 node3
Y ya solo nos queda verificar el estado de nuestro sistema de Ceph:
[root@admin-node ceph]# ceph health
FASE – 2
Una vez verificado que el sistema funciona correctamente, pasaremos a la segunda fase, en la cual añadiremos un MDS al node1 y un monitor a los nodos; node2 y node3. Al añadir los dos nuevos monitors al cluster, eliminamos el fatídico problema del “Split Brain”, que tantos dolores de cabeza me ha dado.
Le añadimos el MDS ( MetaData Server ) al node1. En nuestro caso, solamente hemos añadido un servicio de MDS, pero podemos añadir tantos como queramos, al igual que OSD o Monitors
[root@admin-node ceph]# ceph-deploy mds create node1
Añadimos los dos nuevos monitors, tanto al node2 como al node3:
[root@admin-node ceph]# ceph-deploy mon create node2 node3
Forzamos la sincronización de los monitors:
[root@admin-node ceph]# ceph quorum_status –format json-pretty
Una vez acabado, verificamos que todo esté correcto y observamos el espacio que nos ha quedado:
[root@admin-node ceph]# ceph health
[root@admin-node ceph]# ceph df
FASE – 3
Implementar RADOS Block Device (RBD)
Antes de empezar a trabajar con RBD, es importante tener un Kernel superior al 3.10. Esto es obligatorio, ya que los módulos están integrados en el Kernel. Al intentar trabajar con la partición en una versión de CentOS 6, la cual viene con un kernel 2.6.32, podremos ver el siguiente mensaje de error:
[root@zimbra ~]# rbd map foo –pool rbd –name client.admin -m 192.168.250.21 -k /etc/ceph/ceph.client.admin.keyringcat
ERROR: modinfo: could not find module rbd
FATAL: Module rbd not found.
rbd: modprobe rbd failed! (256)
Una vez acabado, pasaremos a la tercera fase; instalaremos el agente de RBD (Rados Block Device) en nuestro servidor de Zimbra, para poder montar la unidad que hemos creado:
[root@admin-node ceph]# ceph-deploy install zimbra
Copiaremos los ficheros de configuración y las claves desde el servidor “admin-node” a servidor de Zimbra:
[root@admin-node ceph]# ceph-deploy admin zimbra
Accederemos por SSH al servidor de Zimbra. Le crearemos una partición de 60 GB ( por consola se especifica en megabytes ) y posteriormente la montaremos en el sistema. Podemos crear la partición a nuestro antojo ( siempre con moderación ), ya que al igual que otros sistemas, Ceph nos entrega el Storage en Thin-Provissioned
root@zimbra:~# rbd create foo –size 61000 -m 192.168.250.21 -k /etc/ceph/ceph.client.admin.keyring
root@zimbra:~# rbd map foo –pool rbd –name client.admin -m 192.168.250.21 -k /etc/ceph/ceph.client.admin.keyring
Crearemos nuestro sistema de ficheros en formato EXT4, para el servidor de Zimbra:
root@zimbra:~# mkfs.ext4 -m0 /dev/rbd/rbd/foo
Y montaremos la partición en nuestro sistema de Zimbra:
root@zimbra:~# mount /dev/rbd/rbd/foo /opt
Ahora ya podemos empezar la instalación de nuestro sistema de Zimbra, con cualquiera de los magníficos post que ha creado Jorge.
Gracias a la adquisición de RedHat, se ha abierto al público una herramienta de administración web llamada Calamaris, para poder gestionar y monitorizar nuestro cluster de Ceph. Antes, esta herramienta solo se entregaba a las versiones de pago. Os dejo unas capturas:

Muchas gracias por leer el Blog. Si os ha gustado la entrada podéis preguntar más información sobre Ceph a Oscar Mas.

































Hola, tuve algunos inconvenientes al principio, pero pude avanzar bastantecon el tutorial y lograr un cluster funcional. (Health OK). Sin embargo al llegar a la fase 2, al momento de agregar los monitores adicionales, obtengo este error:
# ceph-deploy mon create node2 node3
…
[node2][DEBUG ] failed: ‘ulimit -n 32768; /usr/bin/ceph-mon -i node2 –pid-file /var/run/ceph/mon.node2.pid -c /etc/ceph/ceph.conf –cluster ceph ‘
[node2][ERROR ] RuntimeError: command returned non-zero exit status: 1
[ceph_deploy.mon][ERROR ] Failed to execute command: /usr/sbin/service ceph -c /etc/ceph/ceph.conf start mon.node2
…
[node3][DEBUG ] failed: ‘ulimit -n 32768; /usr/bin/ceph-mon -i node3 –pid-file /var/run/ceph/mon.node3.pid -c /etc/ceph/ceph.conf –cluster ceph ‘
[node3][ERROR ] RuntimeError: command returned non-zero exit status: 1
[ceph_deploy.mon][ERROR ] Failed to execute command: /usr/sbin/service ceph -c /etc/ceph/ceph.conf start mon.node3
[ceph_deploy][ERROR ] GenericError: Failed to create 2 monitors
Me llama la atención que hace alusión a los “ulimit”, sin embargo estos no se han tocado (lo he verificado).
Tendrás alguna idea de que pueda ser?, muchas gracias de antemano, excelente sitio.
Saludos!
This is one of great article I have ever read!
Regards,
Minh