Sistemas de alta disponibilidad bajo Linux

ArticleCategory: [Choose a category for your article]

System Administration

AuthorImage:[Here we need a little image form you]

[Photo of the Author]

TranslationInfo:[Author and translation history]

original in en Atif Ghaffar
en to es Javier Palacios

AboutTheAuthor:[A small biography about the author]

Atif es un camaleón. Cambia su papel de administrador de sistemas a programador, a formador, a jefe de proyecto, o a lo que haga falta para hacer el trabajo.
En algunas ocasiones, puedes encontrarle programando o escribiendo documentación en su portatil, mientras se encuentra sentado en el aseo.
Atif considera que debe mucho a Linux, y a los proyectos y comunidad de fuente abierta por haber sido sus maestros.
Puedes averiguar más sobre él en su homepage

Abstract:[Here you write a little summary]

A la hora de diseñar sistemas para misiones críticas, ya sea durante el desarrollo o mientras se construyen físicamente con procesadores, cables, etc., uno debe hacerse las siguientes preguntas:

Cuando me hago estas preguntas, la mayor parte de las veces obtengo la misma respuesta.
Seré despedido :)

Por otra parte, cuando me pregunto "¿Fallará el Sistema Operativo?" obtengo siempre esta respuesta: No. No estamos ejecutando extensiones de 32 bits para un sistema parcheado para 16 bits de un sistema operativo de 8 bits originalmente diseñado para un microprocesador de 4 bits, que no aguantaría una competición de 1 bit.
(obtuve esto del .sig de un correo)
Ahora abordaremos una discusión en profundidad.

ArticleIllustration:[This is the title picture for your article]

High Availability systems under Linux -- Image borrowed from http://lwn.net/Gallery/i/suits.gif

ArticleBody:[The article body]

¿Por qué Alta Disponibilidad?

Aunque confío en Linux ciegamente, no confío tanto en las empresas que hacen las máquinas, las fuentes de alimentación, las tarjetas de red, las placas base, etc., y siempre me preocupa porque, si alguno de ellos falla, mi sistema no será usable y, por tanto, sus servicios no estarán disponibles. Más aún, habré arrastrado todos los servicios de la compañía, aunque ellos no dependan directamente de mí. Por ejemplo

Por supuesto que podría suceder lo mismo en un servidor Windows, pero entonces no habrá mucha conmoción porque los dummies están acostumbrados a ello. Pero puedo asegurar que, si esto pasa en una caja Linux, habrá múltiples "no se puede confiar en Linux", etc. por parte de la dirección.

En una de las compañías para las que trabajé, el servidor NFS proporcionaba datos a un servidor web corporativo, al servidor de intranet, al servidor de bases de datos, y a muchos otros servicios que harían pararse la compañía. In one of the companies I worked for, the NFS server was feeding data to a corporate web server, Intranet server, database server, and many other services that will bring the company to a halt. Cierto que NFS era una mala elección, pero olvidemos eso para simplificar el ejemplo. Este servidor proporcionaba alta disponibilidad usando la solución para clusters de Sun, que te costaría ambos brazos y piernas. Y otro de los servicios de mayor importancia era la intranet, usada por más de 1500 personas.
Discutamos en concepto con una cierta profundidad.

¿Qué es Alta Disponibilidad?

Alta Disponibilidad es aquello que tú digas que es. Algunas cosas que precisan alta disponibilidad son algunos servicios que hacen que tu empresa pueda funcionar:

Estos servicios pueden fallar por dos motivos

Para prevenir los fallos de hardware, la dirección toma múltiples precauciones al comprarlo, como disponer de fuentes de alimentación redundantes, RAID 5, etc. Lo que se suele pasar por alto son los malos comportamientos de software. Se puede creer o no, pero he visto colgarse cajas linux por un problema repentino con la tarjeta de red, sobrecalentamiento de la CPU, etc.
El gran jefe no está realmente interesado en si falló la corriente o si el sistema paró por una tarjeta de red defectuosa. Lo único que le preocupa a tus jefes, a los empleados y a los clientes es que el "servicio" debe estar disponible. Observamos que es recalcado el palabra servicio. Obviamente, el servicio lo proporciona una maquina, y redirigir el servicio y su actividad a una máquina en perfecto estado es el reino de la Alta Disponibilidad.

Ejemplos de implementación de Alta Disponibilidad

En este ejemplo vamos a construir un cluster Activo/Pasivo en el que corre un apache, que sirve la intranet. Para ello, usaremos una máquina potente, con montones de RAM y muchas CPU, y otra tan sólo con lo necesario para proporcionar el servicio en cuestión. La primera máquina será el nodo maestro, mientras que la segunda será el nodo de respaldo. El trabajo del nodo de respaldo es hacerse cargo de los servicios del nodo maestro si cree que dicha máquina no está respondiendo.

Como funciona ésto

Pensemos como los usuarios acceden a la intranet. Escriben http://intranet/ en su navegador web, y el servidor DNS los redirije hacia 10.0.0.100 (por ejemplo).
Podemos colocar dos servidores corriendo el servicio de intranet con diferentes direcciones IP, y simplemente hacer que el servidor DNS redirija hacia el respaldo si el nodo maestro se va abajo. Ciertamente esa es una posibilidad, pero hay algunos detalles como los caches de los clilentes, los ficheros /etc, y que tal vez quieras corres el mismo servidor DNS en alta disponibilidad.
Otra posibilidad es que, si el nodo maestro falla, el respaldo asuma su dirección IP y pase a ser él quien atienda las peticiones. Este método se conoce como IP takeover, y es el que usaremos en los ejemplos. De esa forma los navegadores seguirán accediendo a http://intranet/, que será traducido a 10.0.0.100 si el nodo maestro falla, sin necesidad de hacer cambios en el DNS

Hasta aquí hemos llegado

¿Cómo hablan los clusters?

¿Cómo pueden un nodo saber que su compañero ha fallado?
Cada uno de ellos habla con el otro a través de un cable serie y mediante un cable ethernet (por redundancia, los cables pueden fallar) y se comprueban mutuamente los latidos. Como los que tenemos todos) Si el latido para, probablemente estás muerto. El programa que monitoriza los latidos se llama, adivinemos ..., hearthbeat (latido en inglés), y está accesible en http://www.linux-ha.org/download/ El programa que realiza la suplantación de IP (el IP takeover) se llama fake, y está integrado dentro de hearthbeat.
Si no dispones de una tarjeta de red extra para colocar en ambas máquinas, puedes ejecutar heartbeat únicamente sobre un cable serie (modem nulo). Aunque las tarjetas de red son baratas, por lo que conviene instalarlas para obtener redundancia.

Preparando los nodos del cluster

Como dijimos más arriba, usaremos una máquina potente, y otra no tanto. Ambas máquinas están equipadas con dos tarjetas de red cada una, y al menos un puerto serie. Necesitaremos un enlace cruzado RJ45 (ethernet) de categoría 5 y un cable modem nulo (cable serie para enlace cruzado). Usaremos la primera tarjeta de red en cada máquina para sus direcciones IP (eth0), y la segunda para la red privada que se encargará del latido (eth1), y daremos a cada máquina sus nombres y direcciones IP. Por ejemplo, eth0 será en cada nodo
clustnode1 con direccion IP 10.0.0.1
clustnode2 con direccion IP 10.0.0.2

Ahora reservaremos una dirección IP para uso flotante, que será la IP del servicio del que hablábamos antes, y será 10.0.0.100 (con nombre intranet). De momento no la asignaremos a ninguna máquina.
A continuación configuramos la tarjeta de red secundaria en ambas máquinas, otorgándoles direcciones IP en un rango fuera de uso. Por ejemplo, usaremos como máscara 255.255.255.0, y daremos a cada una de las tarjetas las direcciones
clustnode1 dirección IP 192.168.1.1
clustnode2 dirección IP 192.168.1.2

Continuamos conectando el cable serie a los puertos serie de las máquinas, y asegurándonos de que se ven mutuamente. Si nos aseguramos de que lo conectamos al mismo puerto en ambas máquinas todo será mucho más fácil. Podemos consultar http://www.linux-ha.org/download/GettingStarted.html

Instalando heartbeat

Instalar el software es bastante directo. heartbeat está disponible como paquete rpm y en formato tar.gz, tanto en forma binaria como en fuentes. Si experimentas problemas durante la instalación, entonces probablemente no debas asumira la responsabilidad de instalar un sistema de Alta Disponibilidad. Hay una excelente guía Primeros pasos con Linux-HA de modo que no voy a repetir aquí esa misma información.

Configurando el cluster

Configurando el latido

Si tenemos los ficheros de configuración de heartbeat en /etc/ha.d, editamos el fichero /etc/ha.d/authkeys con nuestro editor favorito 

#/etc/ha.d/authkeys
auth 1
1 crc
#end /etc/ha.d/authkeys

Más adelante podremos cambiarlo a md5 o sha si nos sentimos más comodos, pero para los tests iniciales dejaremos en 1 el mecanismo de autentificación. En el fichero /etc/ha.d/ha.cf 
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility     local0
deadtime 10
serial  /dev/ttyS3  #change this to appropriate port and remove this comment
udp     eth1      #remove this line if you are not using a second network card.
node    clustnode1
node    clustnode2
Y en /etc/ha.d/haresources 
#masternode ip-address service-name
clustnode1 10.0.0.100 httpd
Esto define a clustnode1 como nodo maestro, de forma que si clustnode1 se va abajo clustnode2 tomará el servicio a su cargo, pero que cuando vuelva a estar disponible asumirá de nuevo el servicio. Este es el motivo por el cual usamos una máquina potente y otra de menor entidad (clustnode1 es la mejor). El segundo elemento define la dirección IP que se debe asumir para el servicio, y el tercero el nombre del servicio en cuestión. Cuando una máquina asume el servicio, intenta ejecutar 
/etc/ha.d/httpd start
y si no es posible intenta 
/etc/rc.d/init.d/httpd start
Si clustnode2 está dando el servicio, ejecutará 
/etc/ha.d/httpd stop
o bien 
/etc/rc.d/init.d/httpd stop
Cuando acabamos la configuración de clustnode1 podemos copiar los ficheros al nodo de respaldo. En el directorio /etc/ha.d/rc.d encontraremos un script llamado ip-request, que hará el trabajo de asignar las direcciones IP y otras tareas. Ahora podemos arrancar /etc/rc.d/init.d/heartbeat en ambas máquinas.

Instalaremos una página de índice diferente en cada una de las máquinas que harán de servidor http. Por ejemplo, en clustnode1
echo hello world from clustnode1 >/yourWwwDocRoot/index.html
y enclustnode2
echo hello world from clustnode2 >/yourWwwDocRoot/index.html
Debemos asegurarnos que en ninguno de los nodos se inicia el servidor http al arrancar la máquina, eliminando los enlaces en los directorios rcN o, mejor aún, moviendo los scripts de arranque "httpd" o "apache" de /etc/rc.d/init.d/ a /etc/ha.d/rc.d/ en ambas máquinas.
Si todo se preparó correctamente y hearbeat está corriendo de forma correcta, clustnode1 tendrá la dirección IP 10.0.0.100 y será el que responda a las peticiones http. Podemos hacer un par de intentos para asegurarnos que efectivamente lo hace. Si todo parece correcto, paramos clustnode1 y, en 10 segundos, clustnode2 asumirá el servicio y la dirección IP.
Es decir, el tiempo máximo fuera de servicio será 10 segundos.

Respecto a la integridad de los datos

Cuando el servicio httpd se mueve de un nodo a otro, no ve los mismos datos. Pierdo todos los ficheros que estaba creando con los CGI's del httpd.
Hay dos respuestas para eso

  1. No escribir nunca en ficheros desde un CGI, usando una base de datos en red. MySQL es bastante buena.
  2. Puedes enganchar ambos nodos a una caja de almacenamiento SCSI externa, asegurándote de que la utiliza un sólo nodo en cada momento, y también cambiando el ID SCSI de una de las máquinas a 6, y dejando el otro en 7. Lo he intentado con tarjetas SCSI 2940 SCSI, y he podido hacerlo sin problemas. La mayor parte de las tarjetas baratas no te permitirán hacer eso.
    Algunos controladores RAID se venden como capaces de trabajar en cluster, pero conviene asegurarse de que podrás cambiar el ID del host de control de la tarjeta sin necesidad de comprar el kit para clusters de Microsoft. Yo dispongo de adaptadores NetRaid de HP y definitivamente no soportan Linux. Tuve que romperlos para poder sentir que habia empleado el dinero en algo.
Un paso posterior seria comprar tajetas de Fibrechannel, un hub Fibrechannel y un dispositivo de almacenaje Fibrechannel para crear una pequeña SAN. Es claramente más costoso que usar SCSI compartido, pero es una buena inversión. O puedes usar GFS (Global File System, más abajo en los recursos) sobre Fibrechannel, lo que permite acceso transparente al almacenamiento desde todas las máquinas como si se tratara de un almacenamiento local. Actualmente uso GFS en un entorno de producción formado por 8 máquinas, dos de las cuales se encuentran en una configuración de Alta Disponibilidad similar a la descrita aquí.

Y sobre clusters activo/activo

Si dispones de un buen sistema de almacenamiento que permita acceso concurrente, resulta muy fácil construir un servidor activo/activo. Ejemplos son GFS y Fibrechannel. Si te bastan filesystems de red como NFS puedes usarlos, aunque yo no recomendaría hacerlo. En cualquier caso, siempre puedes eviar el servicio A a clustnode1 y el servicio B a clustnode2, como hace el fichero haresource 

clustnode2 172.23.2.13 mysql
clustnode1 172.23.2.14 ldap
clustnode2 172.23.2.15 cyrus
En mi caso, usando GFS para almacenamiento, no existe problema con el acceso concurrente, y se pueden correr tantos servicios como sean capaces de manejar las máquinas. En la configuración anterior, clustnode2 es el master para mysql y cyrus, mientras que clustnode1 es el master para LDAP. Si clustnode2 cae, clustnode1 asume la dirección IP y los servicios.

Recursos

Linux-HA.org
La página de Alta Disponibilidad bajo Linux
kimberlite clustering technology
Un cluster Kimberlite soporta dos nodos conectados a un SCSI compartido o a un almacenamiento Fibre Channel, en un entorno activo/activo tolerante a fallos. El software proporciona la capacidad para detectar cuando cualquiera de los nodos abandona el cluster, y dispara automáticamente scripts de recuperación que realizan las tareas necesarias para restaurar las aplicaciones en el nodo restante. Cuando el nodo vuelve a unirse al cluster, las aplicaciones pueden moverse de vuelta a él, de forma manual o automática, si así se requiere. Se proporcionan ejemplos de scripts de recuperación. Kimberlite está diseñado para los más altos requerimientos de integridad de datos, y es extremadamente robusto. Es adecuado para su despliege en cualquier entorno que requiera alta disponibilidad para aplicaciones Linux sin modificar.
ultra monkey
Ultra Monkey es un proyecto que pretende crear sistemas de alta disponibilidad con balanceo de carga en redes locales usando componentes de fuente abierta sobre el sistema operativo Linux. En el momento actual, el objetivo es producir una granja web escalable con alta disponibilidad, aunque la tecnología es fácilimente ampliable hacia otros servicios como el email y el FTP.
Linux Virtual Server
El Linux Virtual Server es un servidor de alta disponibilidad y altamente escalable construído en base a un cluster de servidores reales, con el balanceador de carga corriendo bajo Linux. La arquitectura del cluster es transparente a los usuarios finales, que sólo ven un único servidor virtual.
4U cluster / 4U SAN (Shameful plug)
4U cluster y 4U SAN son el cluster de alta disponibilidad y la implementación SAN de nuestra compañia 4Unet. Si eres un ISP o una compañia de telecomunicación y precisas alta disponibilidad, 4Unet es el sitio correcto para preguntar.
NOTA: 4Unet es un integrador, no vende clusters ni SANs, sino que los implemente para sus clientes. Todas las tecnologías usadas en estos cluster/SAN son de fuente abierta.
Los clientes de 4Unet son únicamente ISPs y compañías de telecomunicaciones.
Global File System
El Global File System (GFS) es un sistema de ficheros de clusters de discos compartidos para Linux. GFS soporta journaling y recuperación de fallos en los clientes. los nodos del cluster GFS comparten físicamente el mismo almacenamiento mediante FibreChannel o dispositivos SCSI compartidos. El filesystem aparece como local en cada uno de los nodos, y GFS sincroniza el acceso a ficheros a lo largo del cluster. GFS es totalmente simétrico, lo que quiere decir que todos los nodos son equivalentes, y no existen ningún servidor en el que se pueda producir un cuello de botella ni elementos con fallos críticos. GFS usa caché de lectura y escritura a la vez que mantiene la semántica completa del sistema de ficheros UNIX.