Este tutorial muestra cómo combinar cuatro servidores de almacenamiento únicos (que ejecutan Ubuntu 12.10) en un almacenamiento replicado distribuido con GlusterFS. Los nodos 1 y 2 (replicación 1), así como el 3 y 4 (replicación 2), se reflejarán entre sí, y la replicación 1 y la replicación 2 se combinarán en un servidor de almacenamiento más grande (distribución). Básicamente, esto es RAID10 a través de la red. Si pierde un servidor de la replicación 1 y uno de la replicación 2, el volumen distribuido continúa funcionando. El sistema cliente (también Ubuntu 12.10) podrá acceder al almacenamiento como si fuera un sistema de archivos local. GlusterFS es un sistema de archivos en clúster capaz de escalar a varios peta-bytes. Agrega varios bloques de almacenamiento sobre la interconexión Infiniband RDMA o TCP/IP en un gran sistema de archivos de red paralelo. Los bloques de almacenamiento se pueden fabricar con cualquier hardware básico, como servidores x86_64 con SATA-II RAID e Infiniband HBA.
Debido a que ejecutaremos todos los pasos de este tutorial con privilegios de root, podemos anteponer todos los comandos en este tutorial con la cadena sudo, o convertirnos en root ahora mismo escribiendo
Los cinco sistemas deberían poder resolver los nombres de host de los otros sistemas. Si esto no se puede hacer a través de DNS, debe editar el archivo /etc/hosts para que tenga el siguiente aspecto en los cinco sistemas:
127.0.0.1 localhost.localdomain localhost
192.168.0.100 server1.example.com server1
192.168.0.101 server2.example.com server2
192.168.0.102 server3.example.com server3
192.168.0.103 server4.example.com server4
192.168.0.104 client1.example.com client1
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts |
(También es posible usar direcciones IP en lugar de nombres de host en la siguiente configuración. Si prefiere usar direcciones IP, no tiene que preocuparse si los nombres de host se pueden resolver o no).
2 Configuración de los servidores GlusterFS
servidor1.ejemplo.com/servidor2.ejemplo.com/servidor3.ejemplo.com/servidor4.ejemplo.com:
GlusterFS está disponible como paquete para Ubuntu 12.10, por lo que podemos instalarlo de la siguiente manera:
apt-get install glusterfs-server
El comando
glusterfsd --version
ahora debería mostrar la versión de GlusterFS que acaba de instalar (3.2.5 en este caso):
[email protected]:~# glusterfsd --version
glusterfs 3.2.5 compilado el 31 de enero de 2012 07:39:58
Revisión del repositorio:git://git.gluster.com/glusterfs.git
Copyright (c) 2006-2011 Gluster Inc.
GlusterFS viene SIN NINGUNA GARANTÍA EN ABSOLUTO.
Usted puede redistribuir copias de GlusterFS bajo los términos del Licencia pública general de GNU.
[email protected]:~#
Si usa un firewall, asegúrese de que los puertos TCP 111, 24007, 24008, 24009-(24009 + cantidad de ladrillos en todos los volúmenes) estén abiertos en server1.example.com, server2.example.com, server3.example.com y servidor4.ejemplo.com.
A continuación, debemos agregar server2.example.com, server3.example.com y server4.example.com al grupo de almacenamiento de confianza (tenga en cuenta que estoy ejecutando todos los comandos de configuración de GlusterFS desde server1.example.com, pero puede ejecútelos desde server2.example.com o server3.example.com o server4.example.com porque la configuración se replica entre los nodos GlusterFS; solo asegúrese de usar los nombres de host o direcciones IP correctos):
servidor1.ejemplo.com:
En server1.example.com, ejecute
gluster peer probe server2.example.com
gluster peer probe server3.example.com
gluster peer probe server4.example.com
La salida debe ser la siguiente:
[email protected]:~# gluster peer probe server2.example.com
Sonda exitosa
[email protected]:~#
El estado del grupo de almacenamiento de confianza ahora debería ser similar a este:
gluster peer status
[email protected]:~# gluster peer status
Número de pares:3
Nombre de host:server2.example.com
Uuid:600ff607-f7fd-43f6-af8d-419df703376d
Estado:Par en clúster (conectado)
Nombre de host:server3.example.com
Uuid:1d6a5f3f-c2dd-4727-a050-0431772cc381
Estado:Par en clúster (conectado)
Nombre de host:server4.example.com
Uuid:0bd9d445-0b5b-4a91-be6f-02b13c41d5d6
Estado:Peer in Cluster (Connected)
[email protected]:~#
A continuación, creamos el recurso compartido replicado distribuido llamado testvol con dos réplicas (tenga en cuenta que la cantidad de réplicas es la mitad de la cantidad de servidores en este caso porque queremos configurar la replicación distribuida) en server1.example.com, server2.example.com , server3.example.com y server4.example.com en el directorio /data (se creará si no existe):
gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data server3.example.com:/data server4.example.com:/data
[email protected]:~# gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data server3.example.com:/data server4.example.com:/data
La creación del volumen testvol ha sido exitosa. Inicie el volumen para acceder a los datos.
[email protected]:~#
Iniciar el volumen:
gluster volume start testvol
Es posible que el comando anterior le indique que la acción no tuvo éxito:
[email protected]:~# gluster volume start testvol
La prueba de volumen inicial no ha tenido éxito
[email protected]:~#
En este caso, debe verificar la salida de...
servidor1.ejemplo.com/servidor2.ejemplo.com/servidor3.ejemplo.com/servidor4.ejemplo.com:
netstat -tap | grep glusterfsd
en ambos servidores.
Si obtiene un resultado como este...
[correo electrónico protegido]:~# netstat -tap | Grep Glusterfsd
TCP 0 0*:24009*:*Escuchar 1110 /Glusterfsd
TCP 0 0 Localhost.localdom:1019 Localhost.Localdo:24007 establecido 1110 /glusterfsd
[Correo electrónico protegido]:~ #
... todo está bien, pero si no obtiene ningún resultado...
[correo electrónico protegido]:~# netstat -tap | grep glusterfsd
[correo electrónico protegido]:~#
[correo electrónico protegido]:~# netstat -tap | grep glusterfsd
[correo electrónico protegido]:~#
[correo electrónico protegido]:~# netstat -tap | grep glusterfsd
[correo electrónico protegido]:~#
... reinicie el demonio GlusterFS en el servidor correspondiente (server2.example.com, server3.example.com y server4.example.com en este caso):
servidor2.ejemplo.com/servidor3.ejemplo.com/servidor4.ejemplo.com:
/etc/init.d/glusterfs-server restart
Luego verifique la salida de...
netstat -tap | grep glusterfsd
... de nuevo en estos servidores - ahora debería verse así:
[correo electrónico protegido]:~# netstat -tap | Grep Glusterfsd
TCP 0 0*:24009*:*Escuchar 1152 /Glusterfsd
tcp 0 0 localhost.localdom:1018 localhost.localdo:24007 establecido 1152 /glusterfsd
[correo electrónico protegido]:~ #
[correo electrónico protegido]:~# netstat -tap | Grep Glusterfsd
TCP 0 0*:24009*:*Escuchar 1311 /Glusterfsd
TCP 0 0 Localhost.localdom:1018 Localhost.Localdo:24007 establecido 1311 /Glusterfsd
[Correo electrónico protegido]:~ #
[correo electrónico protegido]:~# netstat -tap | Grep Glusterfsd
TCP 0 0*:24009*:*Escucha 1297 /Glusterfsd
tcp 0 0 localhost.localdom:1019 localhost.localdo:24007 establecido 1297 /glusterfsd
[correo electrónico protegido]:~ #
Ahora regrese a server1.example.com:
servidor1.ejemplo.com:
Puede verificar el estado del volumen con el comando
gluster volume info
[email protected]:~# gluster volume info
Nombre del volumen:testvol
Tipo:Distributed-Replicate
Estado:Iniciado
Número de ladrillos:2 x 2 =4
Tipo de transporte:tcp
Bricks:
Brick1:server1.example.com:/data
Brick2:server2.example.com:/data
Brick3:server3.example.com:/data
Brick4:server4.example. com:/data
[correo electrónico protegido]:~#
De forma predeterminada, todos los clientes pueden conectarse al volumen. Si desea otorgar acceso únicamente a client1.example.com (=192.168.0.104), ejecute:
gluster volume set testvol auth.allow 192.168.0.104
Tenga en cuenta que es posible utilizar comodines para las direcciones IP (como 192.168.*) y que puede especificar varias direcciones IP separadas por comas (por ejemplo, 192.168.0.104, 192.168.0.105).
La información del volumen ahora debería mostrar el estado actualizado:
gluster volume info
[email protected]:~# gluster volume info
Nombre del volumen:testvol
Tipo:Distributed-Replicate
Estado:Iniciado
Número de ladrillos:2 x 2 =4
Tipo de transporte:tcp
Bricks:
Brick1:server1.example.com:/data
Brick2:server2.example.com:/data
Brick3:server3.example.com:/data
Brick4:server4.example. com:/data
Opciones reconfiguradas:
auth.allow:192.168.0.104
[email protected]:~#
3 Configuración del cliente GlusterFS
cliente1.ejemplo.com:
En el cliente, podemos instalar el cliente GlusterFS de la siguiente manera:
apt-get install glusterfs-client
Luego creamos el siguiente directorio:
mkdir /mnt/glusterfs
¡Eso es todo! Ahora podemos montar el sistema de archivos GlusterFS en /mnt/glusterfs con el siguiente comando:
mount.glusterfs server1.example.com:/testvol /mnt/glusterfs
(¡En lugar de server1.example.com, también puede usar server2.example.com o server3.example.com o server4.example.com en el comando anterior!)
Ahora debería ver el nuevo recurso compartido en los resultados de...
mount
[email protected]:~# mount
/dev/mapper/server5-root on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid, nodev)
sysfs en /sys escriba sysfs (rw,noexec,nosuid,nodev)
fusectl en /sys/fs/fuse/connections escriba fusectl (rw)
ninguno en /sys/kernel /debug tipo debugfs (rw)
ninguno en /sys/kernel/security tipo securityfs (rw)
udev en /dev tipo devtmpfs (rw,mode=0755)
devpts en /dev/ pts tipo devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs activado /ejecutar tipo tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
ninguno activado /ejecutar/bloquear escriba tmpfs (rw,noexec,nosuid,nodev,size=5242880)
ninguno en /ejecutar/shm escriba tmpfs (rw,nosuid,nodev)
/dev/sda1 en /tipo de arranque ext2 (rw)
servidor1.ejemplo.com:/testvol en /mnt/glusterfs escriba fuse.glusterfs (rw,allow_other,default_permissions,max_read=131072)
[email protected]:~#
... y...
df -h
[email protected]:~# df -h
Sistema de archivos Tamaño Usado Avail Use% Montado en
/dev/mapper/server5-root
29G 1.1G 27G 4% /
udev 238m 4.0k 238m 1%/dev
TMPFS 99m 212k 99m 1%/run
ninguno 5.0m 0 5.0m 0%/ejecución/bloqueo
ninguno 247m 0 247m 0%/run/shm
/dev/sda1 228M 24M 193M 11 % /boot
server1.example.com:/testvol
58G 2.1G 53G 4 % /mnt/glusterfs:
proteted] ~#
En lugar de montar el recurso compartido GlusterFS manualmente en el cliente, puede modificar /etc/fstab para que el recurso compartido se monte automáticamente cuando se inicie el cliente.
Abra /etc/fstab y agregue la siguiente línea:
vi /etc/fstab
[...]
server1.example.com:/testvol /mnt/glusterfs glusterfs defaults,_netdev 0 0 |
(De nuevo, en lugar de server1.example.com, ¡también puede usar server2.example.com o server3.example.com o server4.example.com!)
Para probar si su /etc/fstab modificado está funcionando, reinicie el cliente:
reboot
Después del reinicio, debería encontrar el recurso compartido en las salidas de...
df -h
... y...
mount
4 Pruebas
Ahora vamos a crear algunos archivos de prueba en el recurso compartido GlusterFS:
cliente1.ejemplo.com:
toque /mnt/glusterfs/test1
toque /mnt/glusterfs/test2
toque /mnt/glusterfs/test3
toque /mnt/glusterfs/test4
toque /mnt/glusterfs/ test5
toque /mnt/glusterfs/test6
Ahora revisemos el directorio /data en server1.example.com, server2.example.com, server3.example.com y server4.example.com. Notará que tanto la replicación 1 como la replicación 2 contienen solo una parte de los archivos/directorios que componen el recurso compartido GlusterFS en el cliente, pero los nodos que componen la replicación 1 (servidor 1 y servidor 2) o la replicación 2 (servidor 3 y servidor 4) contienen el mismo archivos (duplicación):
servidor1.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test1
-rw -r--r-- 1 root root 0 2012-12-17 15:49 test2
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test4
-rw-r--r-- 1 raíz raíz 0 2012-12-17 15:49 test5
[correo electrónico protegido]:~#
servidor2.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test1
-rw -r--r-- 1 root root 0 2012-12-17 15:49 test2
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test4
-rw-r--r-- 1 raíz raíz 0 2012-12-17 15:49 test5
[correo electrónico protegido]:~#
servidor3.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test3
-rw -r--r-- 1 root root 0 2012-12-17 15:49 test6
[correo electrónico protegido]:~#
servidor4.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test3
-rw -r--r-- 1 root root 0 2012-12-17 15:49 test6
[correo electrónico protegido]:~#
Ahora cerramos server1.example.com y server4.example.com y agregamos/eliminamos algunos archivos en el recurso compartido GlusterFS en client1.example.com.
servidor1.ejemplo.com/servidor4.ejemplo.com:
shutdown -h now
cliente1.ejemplo.com:
rm -f /mnt/glusterfs/test5
rm -f /mnt/glusterfs/test6
Los cambios deberían estar visibles en el directorio /data en server2.example.com y server3.example.com:
servidor2.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test1
-rw -r--r-- 1 root root 0 2012-12-17 15:49 test2
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test4
[correo electrónico protegido]:~#
servidor3.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test3
[correo electrónico protegido]:~#
Arranquemos server1.example.com y server4.example.com nuevamente y echemos un vistazo al directorio /data:
servidor1.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test1
-rw -r--r-- 1 root root 0 2012-12-17 15:49 test2
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test4
-rw-r--r-- 1 raíz raíz 0 2012-12-17 15:49 test5
[correo electrónico protegido]:~#
servidor4.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test3
-rw -r--r-- 1 root root 0 2012-12-17 15:49 test6
[correo electrónico protegido]:~#
Como puede ver, server1.example.com y server4.example.com no notaron los cambios que ocurrieron mientras estaban inactivos. Esto es fácil de arreglar, todo lo que tenemos que hacer es invocar un comando de lectura en el recurso compartido GlusterFS en client1.example.com, por ejemplo:
cliente1.ejemplo.com:
ls -l /mnt/glusterfs/
[email protected]:~# ls -l /mnt/glusterfs/
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test1
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test2
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test3
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test4
[email protected]:~#
Ahora eche un vistazo al directorio /data en server1.example.com y server4.example.com nuevamente, y debería ver que los cambios se han replicado en estos nodos:
servidor1.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test1
-rw -r--r-- 1 root root 0 2012-12-17 15:49 test2
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test4
[correo electrónico protegido]:~#
servidor4.ejemplo.com:
ls -l /data
[email protected]:~# ls -l /data
total 0
-rw-r--r-- 1 root root 0 2012-12-17 15:49 test3
[correo electrónico protegido]:~#
5 Enlaces
- GlusterFS:http://www.gluster.org/
- Documentación de GlusterFS 3.2:http://download.gluster.com/pub/gluster/glusterfs/3.2/Documentation/AG/html/index.html
- Ubuntu:http://www.ubuntu.com/