[LUG.ro] Sistemas de archivos cluster

[Martin A. Troncoso]

Buenas gente, escribo para expresar un poco las pruebas que realize sobre 
distintos sistemas de archivos para cluster y tambien para recibir sus 
opiniones sobre los mismo, a continuacion voy a hacer un listado de las 
siguientes soluciones que investigue/probe y las cosas buenas y negativas que 
encontre, me gustaria que aquellos que tengan experiencia en este tema puedan 
aportar un poco mas al respecto.

Como nota aclaro que mi evaluacion es desde el punto de vista de 2 o a lo sumo 
3 servidores.

DRDB:
DRBD no es en si un sistema de archivos, este funciona creando un dispositivo 
virtual en el sistema y realiza una copia a nivel de bloques, o sea funciona 
como un raid 1 pero en red, sobre este dispositivo se crea el sistema de 
archivos y de esta forma podemos tener el mismo en 2 equipos.

Tener un raid 1 a travez de red es algo muy copado y sumamente util en los 
casos en que se desee tener un segundo servidor como Fail Over ya que como 
dije DRBD crea solo el dispositivo con el raid 1, sobre este debemos crear el 
sistema de archivos y los sistemas de archivos tradicionales como EXT3/4 XFS, 
etc no permiten que sean montados en multiples equipos de forma simultanea (en 
realidad si lo hicieramos correriamos un gran riesgo de corromper el sistema) 

Sin embargo DRBD tiene un modo de funcionamiento que permite realizar un 
split-brain (permitir que montemos el mismo dispositivo en multiples equipos) 
pero para esto ya necesitamos un sistema de archivos de cluster como ser GFS2 
u OCFS

GFS2:  
Global File System esta pensado para ser usado en dispositivos que sean 
accedidos a travez de multiples dispositivos, una de las cosas que realiza es 
por ejemplo un journal independiente por cada cliente, garantizando de esta 
forma la integridad de los datos, ademas de necesitar un Lock Manager 
distribuido (para el bloqueo de archivos), usando DRBD y GFS2 es posible que 
los 2 equipos accedan al mismo sistema de archivos y de fondo con un RAID1 a 
nivel de bloques a travez de la red, esto es maravilloso (sin tener en cuenta 
la perdida de performance que generar DRBD) , pero asi tambien plantea sus 
problemas, los sistemas de control de cluster que necesitamos para un GFS no 
estan muy pensados para cluster de 2 equipos, sino que trabajan con un sistema 
de votos para la integracion diseñado para un minimo de 3 equipos, entonces al 
tener solo 2 podemos tener problemas ante la caida de uno de nuestros nodos.

Ejemplo: nodo1 muere, nodo2 esta dentro del cluster no pasa nada
Ejemplo2: cae el sistema electrico, nodo1 vuelve nodo2 no, si la configuracion 
no esta bien afinada para esta situacion nos encontraremos en que al no tener 
la cantidad de votos necesarios el nodo1 no puede ingresar en el cluster (que 
en ese momento estaria compuesto por el solo) y a pesar de tener todos los 
datos en el dispositivo DRBD no podriamos acceder al sistema de archivos GFS2, 
volviendo inservible la replica hasta que no se recupere el nodo2

Se pueden realizar configuraciones para evitar estos problemas, pero es darle 
un uso mas alla del pensado, en mi opinion es un sistema de archivos hermoso 
para usar en dispositivos iSCSI con replicacion interna y conectar decenas(o 
mas) de servidores que accedan a ese dispositivo.

GlusterFS:
Este es el ultimo del que les voy a hablar ya que es el ultimo que probe como 
sistema de archivos, Gluster funciona en la capa usuario con FUSE, tiene 
algunas cosas realmente interesantes, Gluster crea un dispositivo virtual 
tomando como base un directorio del sistema raiz (o sea, nosotros le decimos a 
gluster que forme su dev a partir de por ejemplo /home) en cada servidor donde 
pongamos Gluster debemos realizar la misma operacion y definir que tipo de 
replica queremos hacer, gluster soporta varios modos como ser :

Replicacion: cada archivo que se escriba en cada dispositivo se replicara 
entero en los demas
Split: cada archivo que se escriba se realizara un split guardando una porcion 
en cada servidor

bueno, no voy a decir mas ya que en mi caso me interesaba la replicacion, 
Gluster como tal no funciona a nivel bloque, sino que funciona a nivel 
archivos.
El dispotivo virtual debe ser montado con el sistema de archivos Gluster 
(fuse) y podremos operar sobre este de forma totalmente transparente, al 
escribir en este punto de montaje Gluster capturara los eventos y realizara 
las acciones correspondientes, por ejemplo en el caso de replicacion copiara 
el mismo a los otros nodos o en el caso de split realizara un split en la 
cantidad de nodos y lo repartira (como nota , el split puede ser por cantidad 
de nodos o por tamaño) pudiendo acceder a todos los archivos en todos los 
servidores, en el caso de la replicacion algo curioso y fantastico que veremos 
es que en el directorio que seteamos para gluster (/home en este caso) 
podremos ver todos los archivos que se crearon y accederlos de forma 
transparente, eso si, si realizamos algun cambio ahi este no se vera reflejado, 
y en el caso del split veremos las partes de los archivos.

Particularmente Gluster fue el que me parecio mas apto para un cluster chico, 
ya que a pesar de ser un sistema de archivos sobre FUSE es muy simple de 
configurar, no requiere control de cluster y la performance es bastante buena 
(aunque mete una carga de red mayor a la de drbd) ademas en caso de catastrofe 
los archivos son accesibles a nivel del sistema de archivos principal (EXT3/4 
XFS, etc) por lo que recuperar los mismos es simple y no tiene grandes 
complicaciones.

Bueno, si alguien tiene experiencia o quiere aportar algo bienvenido sea, un 
saludo

PD: Hadoop que seguramente se preguntaran porque no lo inclui, bueno, segun lo 
que investigue sobre este para tener una performance mas o menos aceptable se 
requieren una gran cantidad de equipos, cosa que escapa a mis requeriemientos, 
si bien es cierto que este deberia ser sumamente escalable en cantidades 
grandes de servidores y muy tolerante a fallos

PD2: tambien realize pruebas con LSYNCD pero en este caso no es un sistema de 
archivos como tal, sino que uno dispara los eventos a traves del servicio (que 
detecta a traves de imon cuando se modifica un bloque del sistema de archivos), 
por eso no lo considere para incluirlo, aunque esta muy piola y permite hacer 
muchas cosas, ejemplo de esto es una conf que puse para copiar ciertas cosas a 
un ramdisk y cambiar permisos sobre ciertos tipos de archivos

un saludo