Almacenamiento compartido con GlusterFS en Proxmox VE

Saludos nuevamente.

Primero que todo, el contenido de este post está basado en mi manual Configuración de un Clúster de Alta Disponibilidad con dos nodos Proxmox VE 3.2. Un manual de auto-consulta que he hecho, el cual lo he ido enriqueciendo a medida que he hecho cosas, lo nuevo que hago lo voy añadiendo como anexos (no será la organización más adecuada del contenido de un libro, pero pienso modificarla más adelante cuando tenga un poco más de tiempo y recursos). El tema que a continuación mostraré pertenece al Anexo 4: Almacenamiento compartido con GlusterFS en Proxmox VE, el cual estuve haciendo por allá por mayo de 2014 en mi casa.

Sin más preámbulo, aquí les va.

Anexo 4 – Almacenamiento compartido con GlusterFS en Proxmox VE

Como se dijo anteriormente en la página 22, el tipo de almacenamiento compartido que se debe utilizar en un Clúster HA Proxmox de dos nodos es el DRBD (no dicho por mi, eso está en la Wiki de Proxmox VE). No obstante, en este anexo se describe cómo utilizar un almacenamiento compartido utilizando un clúster GlusterFS conformado por dos equipos con GNU/Linux.

Primero que todo, hay que saber qué cosa es GlusterFS (Tomado de Wikipedia).

—————————————–

¿Qué es GlusterFS?

El Sistema de Archivos Gluster, Gluster File System o GlusterFS, es un multiescalable sistema de archivos para NAS desarrollado inicialmente por Gluster Inc. Este permite agregar varios servidores de archivos sobre Ethernet o interconexiones Infiniband RDMA en un gran entorno de archivos de red en paralelo. El diseño del GlusterFS se basa en la utilización del espacio de usuario y de esta manera no compromete el rendimiento. Se pueden encontrar siendo utilizado en una gran variedad de entornos y aplicaciones como computación en nube, ciencias biomédicas y almacenamiento de archivos. El GlusterFS está licenciado bajo la licencia GNU General Public License versión 3.

Gluster Inc fue el principal patrocinador comercial del GlusterFS, el cual ofrece tanto productos comerciales como apoyo para desarrollo de soluciones libres basadas en el GlusterFS. En Octubre de 2011, fue anunciada la adquisición de Gluster Inc por Red Hat Inc.

Diseño de GlusterFS

El GlusterFS se basa en la interacción de componentes cliente y servidor. Los servidores normalmente se implementan como almacenamiento en bloques, en cada servidor el proceso daemon glusterfsd exporta un sistema de archivos local como un volumen. El proceso cliente glusterfs, se conecta a los servidores a través de algún protocolo TCP/IP, InfiniBand o SDP, compone volúmenes compuestos virtuales a partir de los múltiples servidores remotos, mediante el uso de traductores. Por defecto, los archivos son almacenados enteros, pero también puede configurarse que se fragmente en múltiples porciones en cada servidor. Los volúmenes pueden ser montados en los equipos cliente mediante el modulo FUSE o acceder a través de la librería cliente libglusterfs sin incurrir en problemas con el sistema de archivos FUSE.

La mayor parte de las funcionalidades del GlusterFS se implementa como traductores, incluyendo:

• Espejado y la replicación de archivos.
• Fragmentación de los archivos o Data striping.
• Balanceo de carga para la lectura y escritura de archivos.
• Volúmenes con tolerancia a fallos.
• Planificación de E/S y almacenamiento en caché de disco.
• Las cuotas de almacenamiento

El servidor GlusterFS se mantiene mínimamente simple: exporta un sistema de archivos existente como está, dejando en manos de los traductores del lado del cliente a la estructura del almacenamiento. Los propios clientes se manejan independientemente, no se comunican directamente entre sí, y los traductores administran la consistencia de los datos entre ellos.

El GlusterFS se basa en un algoritmo de hash elástico en vez de utilizar un modelo de metadatos centralizados o distribuidos. Desde la versión 3.1, los volúmenes pueden ser agregados, eliminados o migrados en forma dinámica, esto ayuda a prever problemas de consistencia, y permite que el GlusterFS pueda ser escalado a varios petabytes sobre hardware de bajo coste, evitando así los cuellos de botella que normalmente afectan a muchos sistemas de archivos distribuidos con múltiple concurrencia.

—————————————–

Distribución que se utilizará para el Clúster GlusterFS

Existen varias distribuciones en la comunidad Open-Source que pueden servir como Sistema Operativo base para el clúster con GlusterFS, pero las que más se utilizan para este menester son:

• Red Hat y derivados (CentOS)
• Debian y algunos de sus derivados

En este apartado se ejemplificará, por el momento, con la distribución  GNU/Linux Debian 7.0. La infraestructura de red que se utilizará es la siguiente:

• Red de Gestión de los hipervisores y servidor(es) SAN/NAS: 192.168.137.0/24
• Subred para el Almacenamiento en Red (Red SAN/GlusterFS): 10.0.1.0/24

O sea, cada hipervisor tendrá una o varias conexiones diferentes al área de almacenamiento o clúster GlusterFS.

Configuración del Clúster con GlusterFS

A continuación se mostrará la configuración de los equipos para la creación del clúster GlusterFS. Todo el proceso se realizará mediante la interfaz de línea de comandos (CLI).

Para ello se necesitan dos o más servidores o estaciones de trabajo adaptadas como tal (PCs con más recursos que lo normal). Se recomienda que los mismos tengan una cantidad de memoria RAM, microprocesadores rápidos y una buena cantidad de discos duros para lograr tener una buena capacidad de almacenamiento. En este caso se utilizaron dos equipos con 512 MB de RAM, un microprocesador de un solo núcleo y dos discos duros de 80 GB tecnología IDE.

Cada servidor posee dos tarjetas de red GbE, una conectada a la red de gestión y la otra a la red de datos o del GlusterFS. En fin, una imagen vale más que mil palabras, aquí está el diagrama de la infraestructura para la prueba:

En este punto, se recomienda detenerse a leer el apartado “Cabina SAN/NAS: Discos duros e Infraestructura de Red, algo importante a tener en cuenta” ubicado previamente en la página 97 para tener una idea clara de la infraestructura de red que hay que utilizar para el área de almacenamiento.

Bueno, entrando en materia, configurar un clúster GlusterFS en GNU/Linux Debian es una de las cosas más sencillas de realizar. Lo primero que hay que hacer es configurar las interfaces de red y la visibilidad entre el los equipos integrantes del clúster y los demás activos, ya sea por nombres FQDN, aliases de los mismos, o por direcciones IP (en otras palabras, teniendo o un servidor DNS bien configurado o el archivo /etc/hosts de cada elemento de la granja de servidores con los datos básicos bien establecidos).

Las interfaces de red se configuran de la siguiente manera:

Nodo GFS-1.RED.CODESA.CO.CU

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet static

      address 192.168.137.20

      netmask 255.255.255.0

      network 192.168.137.0

      broadcast 192.168.137.255

      gateway 192.168.137.1

auto eth1

iface eth1 inet static

      address 10.0.1.1

      netmask 255.255.255.0

      network 10.0.1.0

      broadcast 10.0.1.255

Nodo GFS-2.RED.CODESA.CO.CU

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet static

      address 192.168.137.21

      netmask 255.255.255.0

      network 192.168.137.0

      broadcast 192.168.137.255

      gateway 192.168.137.1

auto eth1

iface eth1 inet static

      address 10.0.1.2

      netmask 255.255.255.0

      network 10.0.1.0

      broadcast 10.0.1.255

En el caso de usar el archivo /etc/hosts para la resolución básica de nombres FQDN, aliases y direcciones IP, el contenido sería el siguiente (las direcciones que aparecen aquí pueden ser adaptadas al escenario que se tenga):

127.0.0.1         localhost.localdomain        localhost

192.168.137.20    gfs-1.red.codesa.co.cu       gfs-1

192.168.137.21    gfs-2.red.codesa.co.cu       gfs-2

192.168.137.10    prx-c0-1.red.codesa.co.cu    prx-c0-1

192.168.137.11    prx-c0-2.red.codesa.co.cu    prx-c0-2

10.0.1.1          gfs-1.red.codesa.co.cu       gfs-1

10.0.1.2          gfs-2.red.codesa.co.cu       gfs-2

10.0.1.10         prx-c0-1.red.codesa.co.cu    prx-c0-1

10.0.1.11         prx-c0-2.red.codesa.co.cu    prx-c0-2

# The following lines are desirable for IPv6 capable hosts

::1     localhost ip6-localhost ip6-loopback

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

Luego de probar la conectividad y visibilidad en red (haciendo ping a los nombres de los servidores), se pasa al plato fuerte: configurar el Clúster GlusterFS.

Preparación del sistema de archivos base del GlusterFS

En toda la literatura consultada sobre implementación de clústeres con GlsuterFS hay un punto de convergencia, y es que el sistema de archivos base que se utiliza es el XFS.

¿Qué es XFS? (Tomado de Wikipedia)

XFS es un sistema de archivos de 64 bits con journaling de alto rendimiento creado por SGI (antiguamente Silicon Graphics Inc.) para su implementación de UNIX llamada IRIX. En mayo de 2000, SGI liberó XFS bajo una licencia de código abierto.

XFS se incorporó a Linux a partir de la versión 2.4.25, cuando Marcelo Tosatti (responsable de la rama 2.4) lo consideró lo suficientemente estable para incorporarlo en la rama principal de desarrollo del kernel. Los programas de instalación de las distribuciones de SuSE, Gentoo, Mandriva, Slackware, Fedora Core, Ubuntu y Debian ofrecen XFS como un sistema de archivos más. En FreeBSD el soporte para solo-lectura de XFS se añadió a partir de diciembre de 2005 y en junio de 2006 un soporte experimental de escritura fue incorporado a FreeBSD-7.0-CURRENT y luego lamentablemente eliminado en FreeBSD 10.0

XFS es el más antiguo de los sistemas de archivos con journaling disponible para la plataforma UNIX, tiene un código maduro, estable y bien depurado. Su desarrollo lo comenzó en 1993 la compañía Silicon Graphics Inc., y apareció por primera vez en el IRIX 5.3 en 1994. El sistema de archivos fue liberado bajo la GNU General Public License en mayo de 2000 y posteriormente portado a GNU/Linux, apareciendo por primera vez en una distribución entre el 2001 y el 2002.

Características del sistema de archivos XFS

Capacidad

XFS soporta un sistema de archivos de hasta 8 exabytes, aunque esto puede variar dependiendo de los límites impuestos por el sistema operativo. En sistemas GNU/Linux de 32 bits, el límite es 16 terabytes.

Registro de bitácora (journaling)

XFS provee soporte para llevar un registro (journaling), donde los cambios al sistema de archivos primero son escritos a un diario o journal antes de que se actualicen los datos del disco. El journal es un buffer circular de bloques del disco que no son parte del sistema de archivos. En XFS el registro (journal) contiene entradas ‘lógicas’ que describen a un alto nivel las operaciones que se están realizando, al contrario de otros sistemas de archivo con un registro (journal) ‘físico’, que guardan una copia de los bloques modificados durante cada transacción. Las actualizaciones del registro (journal) se realizan asincrónicamente para evitar una baja en el rendimiento.

En el caso de una caída repentina del sistema, las operaciones inmediatamente anteriores a la caída pueden ser terminadas, garantizando así la consistencia del sistema. La recuperación se realiza automáticamente a la hora del montaje del sistema de archivos y la velocidad de recuperación es independiente del tamaño del sistema de archivos. Incluso si alguna información que fuese modificada inmediatamente antes de la caída del sistema no fuese escrita al disco, XFS se encarga de borrar todos los bloques de datos sin escribir, eliminando así cualquier compromiso de seguridad.

Grupos de asignación

Los sistemas de archivos XFS están particionados internamente en grupos de asignación, que son regiones lineares de igual tamaño dentro del sistema de archivos. Los archivos y los directorios pueden crear grupos de asignación. Cada grupo gestiona sus inodos y su espacio libre de forma independiente, proporcionando escalabilidad y paralelismo — múltiples hilos pueden realizar operaciones de E/S simultáneamente en el mismo sistema de archivos.

LVM

Es posible aumentar la capacidad de sistemas de ficheros XFS: xfsgrowfs es ideal para particiones LVM.

Actualidad

La distribución comercial de linux Red Hat Enterprise Linux incorporo XFS en su versión 7.0  como su sistema de archivos por defecto, destacando su capacidad de manejar una partición de hasta 500 terabytes.

Creación y montaje del sistema de archivos base para el volumen GlusterFS a exportar

Ya comprendidos los conceptos, se pasa a preparar las particiones. En este caso, y como se dijo anteriormente, se dispone de dos discos duros de 80 GB de tamaño. Para utilizar todo el espacio de disco (160 GB), se utilizará volúmenes LVM. Los pasos son los siguientes:

NOTA: Se asume que los discos en el sistema operativo tienen los apuntadores /dev/sdb y /dev/sdc.

1.- Particionar /dev/sdb con una sola partición que abarque todo el disco y definir su tipo como Linux LVM.
2.- Particionar /dev/sdc con una sola partición que abarque todo el disco y definir su tipo como Linux LVM.
3.- Instalar el paquete lvm2 para la gestión de volúmenes LVM:

# aptitude install lvm2

4.- Instalar el paquete xfsprogs para la gestión de particiones XFS

# aptitude install xfsprogs

5.- Crear volumen físico con las dos particiones previamente creadas:

# pvcreate /dev/sdb /dev/sdc

6.- Crear grupo de volúmenes

# vgcreate VGDATAGFS /dev/sdb /dev/sdc

7.- Crear el volumen lógico que servirá de base a la partición XFS (se utilizará el valor de la cantidad total de extents y no el valor del tamaño total):

# lvcreate -l 40958 –name LVGFS0 VGDATAGFS

8.- Formatear el volumen lógico

# mkfs.xfs /dev/VGDATAGFS/LVGFS0

Al terminar el formato, la partición se ve así:

9.- Crear el punto de montaje para la nueva partición XFS que será el directorio base para la replicación del GlusterFS

# mkdir -p /srv/storages/glusterfs/gfs0

10.- Añadir punto de montaje en el archivo /etc/fstab para que cargue automáticamente durante el arranque del sistema. Esto se hace añadiendo la siguiente línea en el archivo antes mencionado:

/dev/VGDATAGFS/LVGFS0  /srv/storages/glusterfs/gfs0 xfs      rw,noatime,nodiratime,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota      0     0

11.- Montar el volumen

# mount /srv/storages/glusterfs/gfs0

o Reiniciar el servidor.

Configuración del Clúster GlusterFS

Ahora toca el turno a la configuración del clúster. Para ello se deben completar los siguientes pasos:

• Instalar el paquete del GlusterFS

En este punto cabe destacar que los paquetes del GlusterFS que viene en el repo principal de Debian 7 son de la versión 3.2. Y los que está en el repo PVE-Test de Proxmox VE son de la versión 3.5 o superior. A la hora de configurar el almacenamiento cliente en el segundo a través de la GUI da un error de montaje del volumen GlusterFS. Según el log del sistema, aparecía en las líneas del error esta parte:

Invalid argument

Después de un buen rato rompiéndome la cabeza, se me ocurrió instalar los paquetes que vienen en el repo PVE-Test de Proxmox en Debian 7 (como no contaba con la rama backports de Debian 7 en ese momento tuve que improvisar), de todas maneras este es el sistema operativo base del mismo.

Para ello añadí la línea que está dentro del archivo /etc/apt/sources.list.d/pve-enterprise en uno de los Proxmoxes al archivo /etc/apt/sources.list de los equipos con Debian 7 que fungen como Servidores de Volúmenes GlusterFS:

deb file:///media/flash/proxmox-repo/pve-test-repository wheezy pvetest

Y luego actualicé la lista de paquetes mediante el comando «aptitude update».

OJO: Bajo ninguna circunstancia ejecutar el comando «aptitude upgrade», dado que puede provocar que se instalen paquetes innecesarios. Este cambio se hace solamente para instalar o actualizar los paquetes del GlusterFS.

# aptitude install glusterfs-server

Esto instalará primeramente las dependencias de los paquetes del GlusterFS de la versión 3.5 y luego actualizará los existentes, los cuales inicialmente tienen la versión 3.2. Así ya no habrán conflictos en las versiones entre el servidor y el cliente GlusterFS, dado que serán de la misma versión: la 3.5.

• Iniciar el clúster GlusterFS ejecutando en el nodo gfs-1.red.codesa.co.cu el comando:

# gluster peer probe 10.0.1.2

• Chequear el status del clúster ejecutando el comando:

# gluster peer status

Como se ve en la siguiente imagen:

• Crear el volumen GlusterFS (Datastore) ejecutando en el nodo gfs-1.red.codesa.co.cu el comando:

# gluster volume create gfs0 replica 2 transport tcp 10.0.1.1:/srv/storages/glusterfs/gfs0 10.0.1.2:/srv/storages/glusterfs/gfs0

Como se ve en la siguiente imagen:

• Iniciar el volúmen ejecutando en el nodo gfs-1.red.codesa.co.cu el comando:

# gluster volume start gfs0

Como se ve en la siguiente imagen:

• Para saber si el demonio del GlusterFS está ejecutándose, ejecutar el siguiente comando:

# ps aux | grep gluster

# netstat -tap | grep glusterfsd

 Como se ve en la imagen siguiente:

• Finalmente, para chequear si el volumen está disponible, ejecutar el siguiente comando en los dos servidores:

# gluster volume info

Si el resultado es satisfactorio, como se ve en las imágenes siguientes, se dispone de un volumen GlusterFS, el cual mantiene una replicación entre los dos nodos del clúster y está listo para ser usado:

Integración del volumen GlusterFS recién creado al Clúster Proxmox VE

Una vez creado y listo el volumen GlusterFS, lo que queda es usarlo, ¿dónde?, pues, en otro clúster previamente creado: el de dos nodos con Proxmox VE 3.3; el cual utilizará dicho volumen como almacenamiento compartido para guardar las imágenes de discos duros de las máquinas virtuales (KVM) o contenedores (OpenVZ), aunque también se pueden almacenar otro elementos como plantillas pre-creadas de contenedores OpenVZ, imágenes de CD/DVD de instalación de otros sistemas operativos, respaldos de máquinas virtuales, etc.

NOTA: En este punto cabe destacar que el trabajo con los discos duros de los contenedores es mucho más tedioso, debido a que se usa mucho la activación y desactivación de las cuotas de disco (y una plantilla trae una gran cantidad de archivos y subdirectorios). En mi caso, tuve que esperar varios minutos para completar la creación de un contenedor o la migración en vivo de un nodo a otro; y en cuanto a la migración en vivo, en el caso de OpenVZ, se apaga primeramente el contenedor para luego migrarlo, y una vez migrado restablecer la cuota de disco.

Bueno, entrando ya en materia, lo primero que hay que hacer es añadir un nuevo almacenamiento compartido en el clúster Proxmox de la siguiente manera:

Gestor de Proxmox —> Datacenter —> Storage —> Add —> GlusterFS

Donde sale una nueva ventana…

A la cual se le deben especificar valores a los siguientes parámetros:

ID: <ID del bloque>

Server: < Nombre FQDN o dirección IP de uno de los nodos réplica del clúster GlusterFS>

Second Server: < Nombre FQDN o dirección IP de otro de los nodos réplica del clúster GlusterFS, que servirá como respaldo por si se cae el principal>

Volume nane: <Nombre del volumen GlusterFS que exporta el clúster del mismo tipo>

Content: <Contenido que albergará el nuevo almacenamiento compartido>

Nodes: <Se deja tal y como está>

Enable: Sí (Activado)

Max Backups: 1

Una vez establecidos los valores a los parámetros, sólo queda añadir el nuevo almacenamiento. O sea, presionar el botón “Add” en la ventana:

Así se mostrará en los dos nodos del clúster:

Pinchando con el mouse el ícono del nuevo almacenamiento compartido creado en el árbol de los elementos (a la izquierda en la GUI de Proxmox) podemos ver su estado:

Aquí se puede ver que su espacio libre total es de aproximadamente 160 GB y se ha usado 32 MB para el funcionamiento de GlusterFS.

Una  vez  completados  estos  pasos,  ya  se  pueden  crear  nuevas  máquinas  virtuales  en  el nuevo almacenamiento compartido siguiendo el mismo procedimiento descrito en el epígrafe “Máquinas virtuales sobre el almacenamiento compartido” de la página 30 (o sea, la selección del almacenamiento donde se guardará el disco duro de la máquina virtual, la acotación en este punto se refiere a que utilizo un almacenamiento compartido que basado en una partición LVM sobre iSCSI), pero en este caso, la apariencia cambia un poquito en la pestaña “Hard Disk”:

Terminada la creación de una máquina virtual KVM sobre un almacenamiento compartido basado en GlusterFS, su hardware virtual es como se muestra en la siguiente figura:

NOTA: La gran ventaja de usar GlusterFS como almacenamiento compartido radica en que permite guardar todos los elementos que soporta Proxmox: imágenes de discos de máquinas virtuales KVM, imágenes de CD/DVD de instalación de sistemas operativos, plantillas de contenedores OpenVZ, archivos de respaldo de máquinas virtuales (VZDumps) y estructuras completas de contenedores OpenVZ. Los otros tipos de almacenamiento compartido vistos hasta el momento solamente soportan imágenes de discos duros KVM si se usan directamente, aunque se si se montan en directorios locales como caminos de montaje, se le pueden hacer truquitos ara que permitan guardar cualquier cosa, ya que para Proxmox es un directorio local.

Creación de contenedores OpenVZ en el almacenamiento compartido GlusterFS

La creación de contenedores OpenVZ es similar a la de máquinas virtuales KVM. Tiene pequeñas diferencias.

Opciones generales…

Selección de la plantilla pre-creada base de donde el contenedor se creará…

El futuro contenedor tendrá un sistema operativo GNU/Linux Debian 6.0 (Squeeze)…

Recursos o requerimientos que tendrá el contenedor

Tipo de tarjeta de red virtual a utilizar…

Parámetros a utilizar para el cliente DNS del contenedor…

Chequear y confirmar los datos proporcionados para crear el contenedor definitivamente…

Luego se ve como el nuevo contenedor se va creando. Aquí hay que tener muuuuucha paciencia si el hipervisor no está muy dotado en recursos, dado que este proceso tarda (son muchísimos archivos pequeños)…

Hasta que termina finalmente…

Una vez creado el contenedor, se puede ver en el gestor de Proxmox:

Los datos directamente en el volumen GlusterFS se ven de la siguiente manera:

Servidor GFS-1.RED.CODESA.CO.CU:

Máquina virtual KVM

Contenedor OpenVZ

Servidor GFS-2.RED.CODESA.CO.CU:

Máquina virtual KVM

Contenedor OpenVZ

Se puede ver, además, las conexiones establecidas entre los nodos del clúster con Proxmox y los nodos del clúster con GlusterFS:

Servidor GFS-1.RED.CODESA.CO.CU:

Servidor GFS-2.RED.CODESA.CO.CU:

Migración de las máquinas virtuales y/o contenedores entre los nodos del clúster Proxmox

Antes de dejar el clúster Proxmox correctamente configurado, es altamente recomendable probar la migración de las máquinas virtuales y/o contenedores entre los nodos que conforman el mismo.

El proceso de migración de una máquina virtual KVM es el mismo de siempre. Por ejemplo, migrar una máquina del primer nodo al segundo:

Y todo funciona perfecto al final del proceso:

Pero migrar un contenedor es otra historia bien distinta, se tarda baaaaaaaaaastante. Poe ejemplo, migración del primer nodo al segundo:

Se ve bien, ¿eh? Esperando…

Como se ve en la segunda imagen, se tardó 7 minutos en inicializar la cuota remota del disco duro en el segundo nodo.

Ahora bien, en la siguiente imagen las dos máquinas virtuales migraron al segundo nodo:

Ajustes posteriores al archivo de configuración del clúster Proxmox

Ahora toca el turno a la configuración avanzada del clúster Proxmox. Hasta el momento solamente se ha hecho una configuración básica del mismo, pero no es suficiente.

A continuación se muestra el contenido final del archivo de configuración ubicado en /etc/pve/cluster.conf:

<?xml version=»1.0″?>

<cluster config_version=»50″ name=»codesa-pveclr»>

<fence_daemon clean_start=»0″ post_fail_delay=»60″ post_join_delay=»30″/>

<cman expected_votes=»1″ keyfile=»/var/lib/pve-cluster/corosync.authkey»

two_node=»1″/>

<fencedevices>

<fencedevice agent=»fence_customized» name=»fence_customized»/>

</fencedevices>

<clusternodes>

<clusternode name=»prx-c0-1″ nodeid=»1″ votes=»1″>

<fence>

<method name=»1″>

<device name=»fence_customized» nodename=»prx-c0-1″/>

</method>

</fence>

</clusternode>

<clusternode name=»prx-c0-2″ nodeid=»2″ votes=»1″>

<fence>

<method name=»1″>

<device name=»fence_customized» nodename=»prx-c0-2″/>

</method>

</fence>

</clusternode>

</clusternodes>

<rm>

<failoverdomains>

<failoverdomain name=»failover_codesa-pveclr» nofailback=»1″ ordered=»1″>

<failoverdomainnode name=»prx-c0-1″ priority=»1″/>

<failoverdomainnode name=»prx-c0-2″ priority=»1″/>

</failoverdomain>

</failoverdomains>

<pvevm autostart=»1″ vmid=»100″/>

</rm>

</cluster>

Llegar a ella no fue tarea fácil, porque se tuvo que probar poco  a poco las partes del archivo. Cuando se añadió la parte de los métodos de fencing en los nodos, el Proxmox (o el Corosync) daba el siguiente error:

¿La solución? Bueno… Después de varios días tratando de activar la configuración del HA en el clúster Proxmox, finalmente lo logré de la manera menos esperada: simplemente se sustituyó el archivo /etc/pve/cluster.conf original por uno funcional (claro, con sus correspondientes cambios) y luego reinicié los dos nodos. Claro está que soltó el error siguiente:

Fri Oct 10 00:48:19 2014:    Starting cman… tempfile:12: element device: Relax-NG validity error : Invalid attribute nodename for element device

Fri Oct 10 00:48:29 2014: Relax-NG validity error : Extra element fence in interleave

Fri Oct 10 00:48:29 2014: tempfile:8: element clusternodes: Relax-NG validity error : Element clusternode failed to validate content

Fri Oct 10 00:48:29 2014: tempfile:9: element clusternode: Relax-NG validity error : Element clusternodes has extra content: clusternode

Fri Oct 10 00:48:29 2014: Configuration fails to validate

Fri Oct 10 00:48:29 2014: [  OK  ]

No obstante, estoy conciente de que fue una solución burda y a la fuerza, lo cual hace que analice más adelante el por qué de este problema.

Claro, entre otras líneas del log del arranque del sistema operativo, o sea, en el archivo /var/log/boot, como se ve en la siguiente imagen:

Pues, lo ignoré y seguí adelante. Vi que no dio errores de parsing del archivo de configuración del clúster, pero aún persistiendo el error anterior. No obstante, se  siguió con las pruebas más agresivas como, por ejemplo, apagar normal o súbitamente uno de los nodos o los dos nodos del clúster. El log nos informa del proceso:

Oct 11 08:43:08 prx-c0-2 corosync[2335]:   [TOTEM ] A processor failed, forming new configuration.

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] CLM CONFIGURATION CHANGE

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] New Configuration:

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] #011r(0) ip(192.168.137.11)

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] Members Left:

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] #011r(0) ip(192.168.137.10)

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] Members Joined:

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [QUORUM] Members[1]: 2

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] CLM CONFIGURATION CHANGE

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] New Configuration:

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] #011r(0) ip(192.168.137.11)

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] Members Left:

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CLM   ] Members Joined:

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [TOTEM ] A processor joined or left the membership and a new membership was formed.

Oct 11 08:43:10 prx-c0-2 kernel: dlm: closing connection to node 1

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [CPG   ] chosen downlist: sender r(0) ip(192.168.137.11) ; members(old:2 left:1)

Oct 11 08:43:10 prx-c0-2 pmxcfs[2179]: [dcdb] notice: members: 2/2179

Oct 11 08:43:10 prx-c0-2 pmxcfs[2179]: [dcdb] notice: members: 2/2179

Oct 11 08:43:10 prx-c0-2 corosync[2335]:   [MAIN  ] Completed service synchronization, ready to provide service.

Oct 11 08:43:10 prx-c0-2 rgmanager[2729]: State change: prx-c0-1 DOWN

Oct 11 08:43:12 prx-c0-2 ntpd_intres[3605]: host name not found: 1.debian.pool.ntp.org

Oct 11 08:43:22 prx-c0-2 ntpd_intres[3605]: host name not found: 2.debian.pool.ntp.org

Oct 11 08:43:32 prx-c0-2 ntpd_intres[3605]: host name not found: 3.debian.pool.ntp.org

Oct 11 08:44:10 prx-c0-2 fenced[2392]: fencing node prx-c0-1

Oct 11 08:44:10 prx-c0-2 fenced[2392]: fence prx-c0-1 success

Oct 11 08:44:11 prx-c0-2 rgmanager[2729]: Starting stopped service pvevm:100

Oct 11 08:44:12 prx-c0-2 rgmanager[3910]: [pvevm] Move config for VM 100 to local node

Oct 11 08:44:12 prx-c0-2 pvevm: <root@pam> starting task UPID:prx-c0-2:00000F5A:000088F8:5439261C:qmstart:100:root@pam:

Oct 11 08:44:12 prx-c0-2 task UPID:prx-c0-2:00000F5A:000088F8:5439261C:qmstart:100:root@pam:: start VM 100: UPID:prx-c0-2:00000F5A:000088F8:5439261C:qmstart:100:root@pam:

Oct 11 08:44:13 prx-c0-2 rgmanager[3933]: [pvevm] Task still active, waiting

Oct 11 08:44:14 prx-c0-2 rgmanager[3953]: [pvevm] Task still active, waiting

Oct 11 08:44:15 prx-c0-2 rgmanager[3980]: [pvevm] Task still active, waiting

Oct 11 08:44:17 prx-c0-2 rgmanager[4000]: [pvevm] Task still active, waiting

Oct 11 08:44:18 prx-c0-2 rgmanager[4020]: [pvevm] Task still active, waiting

Oct 11 08:44:19 prx-c0-2 rgmanager[4042]: [pvevm] Task still active, waiting

Oct 11 08:44:20 prx-c0-2 rgmanager[4062]: [pvevm] Task still active, waiting

Oct 11 08:44:21 prx-c0-2 rgmanager[4082]: [pvevm] Task still active, waiting

Oct 11 08:44:22 prx-c0-2 rgmanager[4102]: [pvevm] Task still active, waiting

Oct 11 08:44:23 prx-c0-2 rgmanager[4122]: [pvevm] Task still active, waiting

Oct 11 08:44:24 prx-c0-2 rgmanager[4154]: [pvevm] Task still active, waiting

Oct 11 08:44:24 prx-c0-2 kernel: device tap100i0 entered promiscuous mode

Oct 11 08:44:24 prx-c0-2 kernel: vmbr0: port 2(tap100i0) entering forwarding state

Oct 11 08:44:25 prx-c0-2 rgmanager[4191]: [pvevm] Task still active, waiting

Oct 11 08:44:26 prx-c0-2 pvevm: <root@pam> end task UPID:prx-c0-2:00000F5A:000088F8:5439261C:qmstart:100:root@pam: OK

Oct 11 08:44:27 prx-c0-2 rgmanager[4214]: [pvevm] Task still active, waiting

Oct 11 08:44:28 prx-c0-2 rgmanager[2729]: Service pvevm:100 started

Oct 11 08:44:28 prx-c0-2 ntpd[2092]: Listen normally on 10 tap100i0 fe80::dcbb:3dff:fe27:8139 UDP 123

Oct 11 08:44:28 prx-c0-2 ntpd[2092]: peers refreshed

Oct 11 08:44:32 prx-c0-2 pvedaemon[2660]: <root@pam> starting task UPID:prx-c0-2:0000108E:000090E1:54392630:vncproxy:100:root@pam:

Oct 11 08:44:32 prx-c0-2 pvedaemon[4238]: starting vnc proxy UPID:prx-c0-2:0000108E:000090E1:54392630:vncproxy:100:root@pam:

Oct 11 08:44:35 prx-c0-2 kernel: tap100i0: no IPv6 routers present

Oct 11 08:44:40 prx-c0-2 ntpd_intres[3605]: host name not found: 0.debian.pool.ntp.org

Oct 11 08:44:50 prx-c0-2 ntpd_intres[3605]: host name not found: 1.debian.pool.ntp.org

Oct 11 08:45:00 prx-c0-2 ntpd_intres[3605]: host name not found: 2.debian.pool.ntp.org

Oct 11 08:45:06 prx-c0-2 rgmanager[4287]: [pvevm] VM 100 is running

Oct 11 08:45:09 prx-c0-2 pvedaemon[2660]: <root@pam> end task UPID:prx-c0-2:0000108E:000090E1:54392630:vncproxy:100:root@pam: OK

Oct 11 08:45:10 prx-c0-2 ntpd_intres[3605]: host name not found: 3.debian.pool.ntp.org

Oct 11 08:45:36 prx-c0-2 rgmanager[4338]: [pvevm] VM 100 is running

Oct 11 08:45:46 prx-c0-2 rgmanager[4376]: [pvevm] VM 100 is running

Oct 11 08:46:26 prx-c0-2 rgmanager[4438]: [pvevm] VM 100 is running

Oct 11 08:46:47 prx-c0-2 rgmanager[4486]: [pvevm] VM 100 is running

Oct 11 08:47:06 prx-c0-2 rgmanager[4527]: [pvevm] VM 100 is running

Oct 11 08:47:46 prx-c0-2 rgmanager[4595]: [pvevm] VM 100 is running

Oct 11 08:47:56 prx-c0-2 rgmanager[4626]: [pvevm] VM 100 is running

Oct 11 08:48:26 prx-c0-2 rgmanager[4677]: [pvevm] VM 100 is running

Oct 11 08:49:06 prx-c0-2 rgmanager[4745]: [pvevm] VM 100 is running

Oct 11 08:49:16 prx-c0-2 rgmanager[4776]: [pvevm] VM 100 is running

Oct 11 08:49:56 prx-c0-2 rgmanager[4844]: [pvevm] VM 100 is running

Oct 11 08:50:16 prx-c0-2 rgmanager[4885]: [pvevm] VM 100 is running

Oct 11 08:50:36 prx-c0-2 rgmanager[4926]: [pvevm] VM 100 is running

Y la máquina virtual 100 está en el segundo nodo finalmente (el contenedor se borró porque se tarde mucho [:)] ):

Y el clúster está preparado para ser usado sin problemas.

Acerca del error de parsing del archivo de configuración cuando se añaden los métodos del fencing en la configuración del nodo

Bueno, volviendo al problema anterior, teníamos este error:

Fri Oct 10 00:48:19 2014:    Starting cman… tempfile:12: element device: Relax-NG validity error : Invalid attribute nodename for element device

Fri Oct 10 00:48:29 2014: Relax-NG validity error : Extra element fence in interleave

Fri Oct 10 00:48:29 2014: tempfile:8: element clusternodes: Relax-NG validity error : Element clusternode failed to validate content

Fri Oct 10 00:48:29 2014: tempfile:9: element clusternode: Relax-NG validity error : Element clusternodes has extra content: clusternode

Fri Oct 10 00:48:29 2014: Configuration fails to validate

Fri Oct 10 00:48:29 2014: [  OK  ]

Googleando un poco y viendo el post “HA Issues”, ubicado en la URL http://forum.proxmox.com/threads/8720-HA-Issues y donde al usuario se le presentó el mismo problema, vi que el Proxmox ejecuta a bajo nivel el comando siguiente:

ccs_config_validate -l /etc/pve/cluster.conf

Esto provoca el error descrito anteriomente, pero no da resultados que puedan hacerse uno una idea de lo que realmente pasa, o sea, de por qué da un error de parseo del archivo de configuración del clúster.

A modo de prueba, se ejecutó este mismo comando, añadiéndole también la opción -v para poder obtener un registro de eventos mucho más verboso (o sea, más detallado), en uno de los nodos de un clúster de Proxmox virgen (o sea, un clúster recién creado). El resultado fue el siguiente:

root@prx-c0-1:~# ccs_config_validate -v -l /etc/pve/cluster.conf

Creating temporary file: /tmp/tmp.K3ZcF0ApOn

Config interface set to: xmlconfig:cmanpreconfig

Configuration stored in temporary file

Updating relaxng schema

Validating..

Configuration validates

Validation completed

Como se ve, la validación terminó sin problemas.

Se ejecutó en uno de los nodos otra vez y dio el mismo error con las mismas líneas. Entonces seguí buscando en Inet algo que arrojara alguna luz para la solución del problema.

Leyendo e interpretando con más calma este error, me llamaron la atención las líneas siguientes:

Fri Oct 10 00:48:29 2014: Relax-NG validity error : Extra element fence in interleave

(…)

Fri Oct 10 00:48:29 2014: tempfile:9: element clusternode: Relax-NG validity error : Element clusternodes has extra content: clusternode

(…)

La validación del archivo de configuración está notificando que hay elementos de más en la declaración. Ahí fue que me percaté que en muchos ejemplos de fencing hacen referencia solamente al nombre del dispositivo de fencing en el método fence dentro del clusternode. Todo parece indicar que ha cambiado algo en la nueva versión de Proxmox, la 3.3, dado que en la 3.2 no me daba ningún tipo de error.

Entonces lo que hice fue modificar nuevamente el archivo de configuración del clúster y dejarlo de la siguiente manera:

<?xml version=»1.0″?>

<cluster config_version=»52″ name=»codesa-pveclr»>

<fence_daemon clean_start=»0″ post_fail_delay=»60″ post_join_delay=»30″/>

<cman expected_votes=»1″ keyfile=»/var/lib/pve-cluster/corosync.authkey»

two_node=»1″/>

<fencedevices>

<fencedevice agent=»fence_customized» name=»fence_customized»/>

</fencedevices>

<clusternodes>

<clusternode name=»prx-c0-1″ nodeid=»1″ votes=»1″>

<fence>

<method name=»1″>

<device name=»fence_customized»/>

</method>

</fence>

</clusternode>

<clusternode name=»prx-c0-2″ nodeid=»2″ votes=»1″>

<fence>

<method name=»1″>

<device name=»fence_customized»/>

</method>

</fence>

</clusternode>

</clusternodes>

<rm>

<failoverdomains>

<failoverdomain name=»failover_codesa-pveclr» nofailback=»1″ ordered=»1″>

<failoverdomainnode name=»prx-c0-1″ priority=»1″/>

<failoverdomainnode name=»prx-c0-2″ priority=»1″/>

</failoverdomain>

</failoverdomains>

<pvevm autostart=»1″ vmid=»100″/>

</rm>

</cluster>

Reinicié los dos nodos del clúster y probé agresivamente el funcionamiento del fencing (apagué el nodo que tenía las máquinas virtuales). ¡¡¡Sorpresa!!! ¡¡¡Vivaaaaaa!!! Todo funcionó sin problemas. 🙂 Era que tenía que eliminar el elemento extra que no hacía falta: el parámetro nodename en la declaración del método de fencing para el nodo en cuestión. 🙂

Bueno, este es el contenido del Anexo 4 de mi manual. Espero les sirva.

😀

Información adicional

Cuando hice esta parte del manual, meses antes había salido en Amazon el libro «Proxmox High Availability (2014)». En ese momento no pude obtenerlo ni por los torrents. Muuuuuuuchos meses después me enteré por un amigo de una URL donde estaba ya el PDF. Lo descargué y vi que mi manual casi se acerca al capítulo del libro donde hablan de la integración de GlusterFS y Proxmox. No obstante, como documentación en español considero que puede serle útil a muchos administradores que utilizan Proxmox como platafroma de virtualización.

También quiero añadir que en esta URL (para los que tienen acceso a Internet) Ivan Ilves -conocido en este mundo de Proxmox y Vyatta/VyOS con el nick Cartman- creó un soberbio manual donde explica este proceso, pero utilizando a los mismos nodos Proxmox como servidores GlusterFS. Verán que tanto el contenido del post como los comentarios están muy interesantes.

Y ya, ahora sí. Fin.

😀