dic 31

Bueno…y para despedir el año pero antes de que el abuso de la comida y el alcohol nublen mi poca capacidad de escribir, vamos a seguir con la serie que empezamos en el último post HekaFS: Configurando un volumen simple pero esta vez configuraremos un volumen distribuido, es decir con alta disponibilidad de datos y servicio.

Para ello, usaremos dos servidores con la configuración descrita en el primer post, con un directorio /export0 en cada uno que en realidad será un logical volume, nos servirá para exportarlo a cliente y replicar datos entre los dos servidores.

[root@glsrv0 ~]# df -h /export0
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vgnas0-lvexport 10G 357M 8.7G 4% /export0

[root@glsrv1 ~]# df -h /export0
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vgnas0-lvexport 10G 357M 8.7G 4% /export0

 

Una vez con los sistemas de ficheros preparados, creamos el volumen replicado:

[root@glsrv0 ~]# hfs_add_volume -r 2 test0 192.168.1.20:/export0 192.168.1.21:/export0
Volume test0 added.
= 192.168.1.20 =
add_local(test0,) OK on glsrv0
= 192.168.1.21 =
add_local(test0,) OK on glsrv1

Con esto tendremos creado el volumen test0 asociado al /export0 de cada servidor. Ahora toca asociar un tenant.

[root@glsrv0 ~]# hfs_add_tenant tenant0 <secret> 10000 20000 10000 20000
Tenant tenant0 added.
= 192.168.1.20 =
add_local(tenant0) OK on glsrv0
= 192.168.1.21 =
add_local(tenant0) OK on glsrv1

[root@glsrv0 ~]# hfs_enable_tenant tenant0 test0
enabling test0
Volumes test0 enabled for tenant0.
= 192.168.1.20 =
Volumes enabled for tenant0 on glsrv0
= 192.168.1.21 =
Volumes enabled for tenant0 on glsrv1


Con esto lo tenemos creado y asociado el volumen que acabamos de configurar. Ahora sólo nos falta irnos al cliente y montarlo:

[root@mail0 ~]# hfs_mount glsrv0 test0 tenant0 <secret> /mnt/
running glusterfs -f /var/lib/hekafs/test0.vol /mnt/

[root@mail0 ~]# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/var/lib/hekafs/test0.vol 10G 128K 9.0G 1% /mnt

Ahora, las pruebas de verdad…crearemos un fichero y tiraremos el primer nodo:

[root@mail0 ~]# ls -la /mnt/test.img
-rw-r--r--. 1 root root 10485760 Dec 31 2011 /mnt/test.img

[root@glsrv0 ~]# ls -la /export0/tenant0/test.img
-rw-r--r--. 1 10000 10000 10485760 Dec 31 17:25 /export0/tenant0/test.img

[root@glsrv1 ~]# ls -la /export0/tenant0/test.img
-rw-r--r--. 1 10000 10000 10485760 Dec 31 17:25 /export0/tenant0/test.img

Replicar…replica :)

Y después de tirar el nodo 1, los datos todavía son accesibles…y hemos podido crear test2.img

[root@mail0 ~]# ls -la /mnt/
total 20484
drwxrwxrwt. 1 root root 34 Dec 31 2011 .
dr-xr-xr-x. 23 root root 4096 Nov 12 16:57 ..
-rw-r--r--. 1 root root 10485760 Dec 31 2011 test2.img
-rw-r--r--. 1 root root 10485760 Dec 31 2011 test.img

 

Una vez restaurado el servicio los datos son actualizados en el nodo caído. Al menos sobre el papel…cumple lo que promete, habría que someterlo a un caso real o algunas pruebas para ver como se comporta, pero hasta aquí funciona! :)

Los comentarios están cerrados.

preload preload preload