LinuxParty

Tenemos este tutorial más extenso... Almacenamiento distribuido a través de 4 nodos con Gluster FS en Linux CentOS (1 de 2)

“Quiero que funcione el 100% del tiempo”. Esta es una frase que quizá hayas oído de tu jefe. Pedir 100% del tiempo garantizado es algo imposible, tan imposible como pedir que alguien no muera o que se acabe la corrupción. Pero se puede lograr algo muy cercano, que es una confiabilidad de 99.999% del tiempo, esto es 1 minuto de falla no programada al año. A esto se le llama Alta Disponibilidad (HA). La alta disponibilidad es a todos los niveles, desde doble servidor con doble fuente de poder, doble disco duro, doble tarjeta de red, aplicación capaz de correr en varios servidores al mismo tiempo con bases de datos redundantes, servidores de aplicación redundantes, sistema de archivo redundante hasta también enlaces redundantes, proveedores de Internet distribuidos geográficamente, etc.
 

En realidad es muy importante saber que tanto necesitas tener HA en tu servidor. Tener HA a todos los niveles sale muy caro, y es solo para sitios que de verdad no pueden tolerar unas horas fuera de línea al año, como quizá Google, Facebook y otros sitios globales. Pero para la mayoría de los sitios tener HA a nivel de software y quizá en dos servidores físicos es más que suficiente.
 
En ésta serie de artículos vamos a ver como lograr HA con GNU/Linux a todos los niveles, incluso con algunos tips para cuando desarrolles tus aplicaciones, y como lograrlo con sistemas de manejo de contenidos y blogs como Joomla! y Wordpress.
 
El sistema de HA por software involucra también balanceo de carga, aunque no de manera directa. Puedes tener HA sin balanceo, simplemente tienes un servidor primario y uno secundario, cuando el primario falla, el secundario toma su lugar, y regresa a funcionar el primario en cuanto se recupera. Personalmente pienso que esta solución es mas sencilla pero menos ideal, por que estas desperdiciando poder de procesamiento la mayor parte del tiempo, y entonces desperdicias dinero y contaminas sin sentido. Por eso prefiero HA con Balanceo de carga.
 
El balanceo de carga es simplemente el “delegar” actividades a varios equipos al mismo tiempo. Es como en una empresa tener a dos empleados de mostrador en vez de a uno solo. Dos va a hacer mas trabajo con menos presión, y en caso de que uno se enferme o se ausente, el otro puede mas o menos suplir el trabajo del otro, aunque por tiempo limitado y no con la misma eficiencia, pero no deja sin operar al negocio.
 
En un sistema Web en HA, donde toda la parte de software va a estar con balanceo o en el peor de los casos con redundancia, lo primero que hay que pensar es en el sistema de archivos. Ese va a ser tu cuello de botella, el dolor de cabeza. Existen varias formas de lograrlo. La primera ya está escrita en este sitio, en los artículos que plantean como construir un cluster de dos equipos, usando DRBD y OCFS2, por lo que no trataremos esta solución. Hay

1
2
3
4
5

gluster peer probe 192.168.100.1
Probe successful
 
gluster peer probe 192.168.100.2
Probe successful

  
Revisamos que es lo que pasó, para ver si se formo el arreglo correctamente:
 

1
2
3
4
5
6
7
8
9

gluster peer status
Hostname: 192.168.100.1
Uuid: 8658ea58-b638-4b40-b55d-e4068f3bbdbc
State: Peer in Cluster (Connected)
 
Hostname: 192.168.100.2
Uuid: fdd07241-ab67-4847-8d2f-220a47ce2fed
State: Peer in Cluster (Connected)
 

   
Perfecto! ahora ya tenemos a los equipos conectados. Luego creamos nuestro primer repositorio, siendo root:
 

1
2
3

mkdir -p /glusterfs
gluster volume create NOMBRE-DEL-VOLUMEN replica 2 transport tcp 192.168.100.1:/glusterfs/nombre-del-volumen 192.168.100.2:/glusterfs/nombre-del-volumen
Creation of volume replicate has been successful 

  
Si quieres asignar permisos para que solo se conecten dentro de tus direcciones, puedes hacerlo ahora así:
 

1

gluster volume set NOMBRE-DEL-VOLUMEN auth.allow 192.168.100.*

   
Ahora, hay que iniciar el volúmen:
 

1
2

gluster volume start NOMBRE-DEL-VOLUMEN
Starting volume NOMBRE-DEL-VOLUMEN has been successful

 
 
Si hasta aqui no tienes ningún problema, entonces ya está listo tu repositorio en cluster. Lo que sigue ahora es conectar el volúmen a el punto de montaje donde tendrás tus páginas, que normalmente es en /var/www.
 
En el web1:

1

mount -t glusterfs 192.168.100.1:/glusterfs/nombre-del-volumen /var/www

 
Y en el web2:

1

mount -t glusterfs 192.168.100.2:/glusterfs/nombre-del-volumen /var/www

  
Puedes agregar el automontado en /etc/fstab, aunque en mi experiencia no siempre funciona, de hecho en CentOS nunca funciona, por que la red y el servicio de GlusterFS se inician después de el montado de dispositivos. Por lo menos no cuando las maquinas que corren el servidor de Gluster también corren el cliente de Gluster.
 
Recuerda que también puedes usar CIFS (SAMBA) y NFS para conectarte a un servidor Gluster, aunque nosotros no lo usamos.
 
Una vez que se haya montado el folder (tardará unos segundos) puedes probar que haya funcionado creando un archivo en el web1 y revisandolo en el web2:
 
 
web1:

1

echo hola > /var/www/archivo.txt

 
 
web2:

1

cat /var/www/archivo.txt

 
 
Si pudiste hacer esta prueba, felicidades! está listo tu sistema de archivos para soportar tu arquitectura de alta disponibilidad.
 
Por cierto, nota que una vez que tengas todo funcionando será necesario hacer algunos ajustes para mejorar el rendimiento, pero de eso hablaremos al final de esta serie de artículos.
 
En nuestro siguiente artículo vamos a hablar de la configuración del servidor de MySQL en replicación maestro/maestro y activo/activo.