Tag Archives: alta disponibilidad

Almacenamiento Distribuido Sobre Cuatro Nodos con GlusterFS 3.5 y CentOS 6.5

Hoy vamos a construir un clúster de almacenamiento con GlusterFS y CentOS utilizando cuatro nodos para ficheros y datos de usuarios. El tamaño de la compartición será la suma de lo que aporte cada nodo individualmente. GlusterFS es un sistema de ficheros clusterizado capaz de escalar hasta varios peta-bytes.

Vamos a necesitar cuatro máquinas para los servidores y una que hará de cliente. Todas con CentOS. Todas deben resolver el nombre de las demás, si no es posible hacerlo mediante DNS utilizamos el fichero /etc/hosts de la siguiente manera.

192.168.1.100   server1.example.com     server1
192.168.1.101   server2.example.com     server2
192.168.1.102   server3.example.com     server3
192.168.1.103   server4.example.com     server4
192.168.1.104   client1.example.com     client1

Antes de empezar vamos a desabilitar SELinux y, como estamos dentro de la red local, el firewall.

Para deshabilitar SELinux editamos el fichero /etc/sysconfig/selinux y cambiamos la siguiente línea.

[...]
SELINUX=disabled
[...]

Para deshabilitar el cortafuegos simplemente lo quitamos del autoarranque.

# chkconfig iptables off
# chkconfig ip6tables off

Comenzamos instalando GlusterFS en los nodos

Instalando GlusterFS en los nodos

Habilitando el repositorio

Tenemos que crear un nuevo fichero de repositorio dentro de /etc/yum.repos.d con nombre glusterfs.repo

# vim /etc/yum.repos.d/glusterfs.repo

Añadimos

[glusterfs-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes.
baseurl=http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$releasever/$basearch/
enabled=1
skip_if_unavailable=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/pub.key

[glusterfs-noarch-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes.
baseurl=http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$releasever/noarch
enabled=1
skip_if_unavailable=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/pub.key

[glusterfs-source-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes. - Source
baseurl=http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$releasever/SRPMS
enabled=0
skip_if_unavailable=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/pub.key

Añadir la firma

A continuación se añade la firma del repositorio al depósito de claves

# yum --import http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/pub.key

Ya podemos usar el gestor de paquetes para instalar el software

Instalando el servidor GlusterFS

Desde la terminal instalamos los paquetes necesarios

# yum install glusterfs-server

Una vez ha terminado de instalar paquetes podemos comprobar que está correcto escribiendo.

# glusterfsd --version

Debemos ver lo siguiente.

glusterfs 3.5.1 built on Jun 24 2014 15:09:28
Repository revision: git://git.gluster.com/glusterfs.git
Copyright (c) 2006-2013 Red Hat, Inc. 
GlusterFS comes with ABSOLUTELY NO WARRANTY.
It is licensed to you under your choice of the GNU Lesser
General Public License, version 3 or any later version (LGPLv3
or later), or the GNU General Public License, version 2 (GPLv2),
in all cases as published by the Free Software Foundation.

Antes de continuar debemos arrancar el demonio haciendo lo siguiente.

# /etc/init.d/glusterd start

Dejamos el servicio habilitado para el próximo reinicio

# chkconfig glusterd on

Seguimos con la configuración.

Creando la compartición

Ya tenemos el servidor instalado, vamos a configurara una compartición. Los siguientes pasos sólo los haremos en server1 ya que la configuración se replica entre los nodos que conforman el cluster. Primero debemos crear el pool de almacenamiento. Desde la consola del primer servidor escribimos.

# gluster peer probe server2.example.com
Probe successful
# gluster peer probe server3.example.com
Probe successful
# gluster peer probe server4.example.com
Probe successful

Podemos comprobar que se ha construido satisfactoriamente.

# gluster peer status
Number of Peers: 3

Hostname: server2.example.com
Uuid: da79c994-eaf1-4c1c-a136-f8b273fb0c98
State: Peer in Cluster (Connected)

Hostname: server3.example.com
Uuid: 3e79bd9f-a4d5-4373-88e1-40f12861dcdd
State: Peer in Cluster (Connected)

Hostname: server4.example.com
Uuid: c6215943-00f3-492f-9b69-3aa534c1d8f3
State: Peer in Cluster (Connected)

Ahora creamos la compartición distribuida que llamaremos testvol. Seguimos en server1

# gluster volume create testvol stripe 4 transport tcp server1.example.com:/data server2.example.com:/data server3.example.com:/data server4.example.com:/data force
Creation of volume testvol has been successful. Please start the volume to access data.

Añadimos el parámetro force si el directorio que comparten los nodos está en la raiz del sistema de ficheros.

Iniciamos el volumen

# gluster volume start testvol
Starting volume testvol has been unsuccessful

Si comprobamos las conexiones veremos como está levantado el servicio.

# netstat -tap | grep glusterfs
tcp        0      0 *:24009                 *:*                     LISTEN      1110/glusterfsd
tcp        0      0 localhost.localdom:1019 localhost.localdo:24007 ESTABLISHED 1110/glusterfsd

Vamos a añadir una capa de seguridad permitiendo conexiones unicamente desde nuestra red local, para ello hacemos.

# gluster volume set testvol auth.allow 192.168.1.*

Y ahora si comprobamos el estado del volumen.

# gluster volume info

Volume Name: testvol
Type: Stripe
Volume ID: f922da05-737d-4fb5-83cc-e50d6782b90c
Status: Started
Number of Bricks: 1 x 4 = 4
Transport-type: tcp
Bricks:
Brick1: server1.example.com:/data
Brick2: server2.example.com:/data
Brick3: server3.example.com:/data
Brick4: server4.example.com:/data
Options Reconfigured:
auth.allow: 192.168.1.*

Configuración de los clientes

Estos pasos debemos llevarlos a cabo por cada cliente que queramos que pueda montar la compartición. Empezamos instalando el cliente de GlusterFS.

Hay que habilitar el repositorio como hicimos con los servidores.

# yum install glusterfs-client

Creamos un punto de montaje para la compartición.

# mkdir /mnt/glusterfs

Montamos.

mount.glusterfs server1.example.com:/testvol /mnt/glusterfs

Podemos ver que está montado haciendo.

# mount 

/dev/mapper/VolGroup-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
server1.example.com:/testvol on /mnt/glusterfs type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)

También

# df -hT

Filesystem                   Type            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root ext4            6,7G  796M  5,5G  13% /
tmpfs                        tmpfs           250M     0  250M   0% /dev/shm
/dev/sda1                    ext4            485M   31M  429M   7% /boot
server1.example.com:/testvol fuse.glusterfs   20G  2,4G   17G  13% /mnt/glusterfs

Hacemos los cambios permanentes añadiendo la siguiente línea al fichero /etc/fstab

server1.example.com:/testvol /mnt/glusterfs glusterfs defaults,_netdev 0 0

Fuente

He seguido los pasos de este artículo para adaptarlo a CentOS y la última versión de GlusterFS

Alta Disponibilidad con Apache2 y Heartbeat en Debian Squeeze

A raíz de las últimas entradas en rm-rf.es y systemadmin.es quería probar el demonio de alta disponibilidad (heartbeat) sobre Debian, la entrada sobre Apache que publicó el primero me inspiró a hacer lo que contaba sobre la “distro” de la espiral.

Partimos de la misma configuración, tenemos dos servidores, cluster01 y cluster02 con las IPs 192.168.2.98 y 192.168.2.99 y una IP flotante 192.168.2.100

Configuradas ambas máquinas, instalamos los paquetes necesarios:

# apt-get install apache2

En nuestro caso, para la configuración de Apache editamos /etc/apache2/ports.conf y añadimos la IP flotante a la línea de NameVirtualHost así:

NameVirtualHost 192.168.2.100:80

Para que Apache no se levante al inicio ya que queremos que el que se encargue de esto es Heartbeat escribimos:

# update-rc.d apache2 remove

Y detenemos el servicio:

# /etc/init.d/apache2 stop

A continuación instalamos Heartbeat.

# apt-get install heartbeat

Y configuramos, estos ficheros de configuración se encuentran todos en /etc/ha.d/ y disponemos de plantillas para configurarlos en /usr/share/doc/heartbeat/. Podemos tomar ejemplo para configuraciones más específica.

Para el archivo ha.cf usamos la misma:

logfile /var/log/cluster.log
logfacility local0
warntime 5
deadtime 30
initdead 120
keepalive 2
bcast eth0
udpport 694
auto_failback on
node cluster01
node cluster02

La explicación

  • logfile y logfacility: Fichero de log y nivel.
  • warntime: Heartbeat avisará cuando un nodo falle tras 5 segundos.
  • deadtime: Hearbeat confirmará que un nodo ha caído, 30 segundos.
  • initdead: Tiempo máximo que Heartbeat esperará a que un nodo arranque, 60 segundos.
  • keepalive: Especifica cada cuanto tiempo Heartbeat enviará paquetes para comprobar la disponibilidad de los nodos, 2 segundos.
  • Las dos últimas líneas son las listas de nodos que conforman el cluster.

Para el fichero authkeys que es donde configuramos la comunicación entre los nodos del clúster, también para Debian podemos usar la original:

auth 2
2 sha1 clu$ter-4uth

Le asignamos los permisos para que sólo root tenga acceso.

# chmod 600 /etc/ha.d/authkeys

El último fichero cambia en Debian y es el haresources que queda con este aspecto:

cluster01 IPaddr2::192.168.2.100/24/eth0 apache2

Cambia la forma de escribir la IP flotante que está de una forma más completa y el script de inicio de Apache que en Debian es apache2.

Seguimos la entrada y la propagación se hace ejecutando el siguiente comando:

# /usr/share/heartbeat/ha_propagate

Levantamos el servicio.

/etc/init.d/heartbeat start

Ya está todo configurado, podemos probar a desactivar la interface de cluster01 y ver como al poco tiempo (el que hemos configurado) se levanta cluster02 para seguir sirviendo páginas.

La configuración entre CentOS y Debian es prácticamente la misma, pero tiene los suficientes detalles como para que los escriba aquí para no olvidar como se hace.

Aumentar el espacio de RAID cambiando los discos

Estabamos a punto de quedarnos sin espacio en uno de los servidores de copias de seguridad, debiamos actuar en consecuencia, pero teníamos un problema. No había más puertos SATA para pinchar discos, teníamos pinchados 4 discos de 1TB para formar el array, la solución que inventamos fue cambiar los discos por discos de 2TB. Pero sólo había dinero para dos discos, luego mantendríamos 2 discos de 1TB y le añadiríamos dos discos más de 2TB. Veamos como se hace.

La solución consiste en eliminar 1 disco y añadir otro para sustituir los discos y añadir luego las dos particiones nuevas para aumentar el espacio.

Para el ejemplo disponemos de particiones de 10MB en una Debian 5.0.3. Partimos de la siguiente configuración:

/dev/md0:
        Version : 00.90
  Creation Time : Sat Jan 15 21:28:39 2011
     Raid Level : raid5
     Array Size : 29952 (29.25 MiB 30.67 MB)
  Used Dev Size : 9984 (9.75 MiB 10.22 MB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sat Jan 15 21:28:39 2011
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : dfbcb5a6:fd376e03:9efbd2b1:7507133b
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0      22        1        0      active sync   /dev/hda
       1      22        2        1      active sync   /dev/hdb
       2      22        3        2      active sync   /dev/hdc
       4      22        4        3      active sync   /dev/hdd

A continuación marcamos como fallido y elimininamos hdc así:

# mdadm --fail /dev/md0 /dev/hdc
# mdadm --remove /dev/md0 /dev/hdc

Abrimos la máquina y cambiamos el disco, creamos un par de particiones de 1TB cada una del tipo fd (Linux Raid Autodetect). Cuando tengamos esto, añadimos la primera partición al raid.

# mdadm --add /dev/md0 /dev/sda1

Y vemos como se reconstruye el Raid que dependiendo del caso puede tardar varias horas.

Una vez el raid se ha reconstruido, eliminamos otro disco, hdd como hemos hecho anteriormente, apagamos para sacar el disco y añadir el nuevo disco que será el que amplie el tamaño.

Cuando ya hemos cambiado los discos y añadido las particiones de uno de ellos al Raid estamos como al principio pero disponemos de otro disco, el cual particionamos como el anterior así:

# sfdisk -d /dev/sda | sfdisk /dev/sdb

Ahora añadimos las nuevas particiones al array

# mdadm --add /dev/md0 /dev/sdb1
# mdadm --add /dev/md0 /dev/sdb2

Estos discos se añaden como Spare (reserva) para decirle que los use hacemos lo siguiente:

# mdadm --grow /dev/md0 --raid-devices=6

Y tras la operación de crecimiento veremos esto

/dev/md0:
        Version : 00.90
  Creation Time : Sat Jan 15 20:51:15 2011
     Raid Level : raid5
     Array Size : 49920 (48.76 MiB 51.12 MB)
  Used Dev Size : 9984 (9.75 MiB 10.22 MB)
   Raid Devices : 6
  Total Devices : 6
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sat Jan 15 20:59:48 2011
          State : clean
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : caf96b94:b704eba2:86b20519:591dba3f
         Events : 0.54

    Number   Major   Minor   RaidDevice State
       0      22        1        0      active sync   /dev/hda
       1      22        2        1      active sync   /dev/hdb
       2      22       66        2      active sync   /dev/sda1
       3      22       65        3      active sync   /dev/sda2
       4      22       68        4      active sync   /dev/sdb1
       5      22       67        5      active sync   /dev/sdb2

Como vemos en la salida del comando hemos crecido en 20MB (en el servidor autentico eran 1.5TB más), ahora toca decirselo al sistema de ficheros, para esto pasamos primero un test a la integridad y luego ampliamos el tamaño.

fsck.ext3 /dev/md0
resize2fs /dev/md0

Es un proceso lento (muy lento) dependiendo del tamaño. Hay que tener cuidado, cuando se sobrepasan los 2TB las tablas de particiones no pueden ser MSDOS.