PDF de programación - Alta disponibilidad para Linux

Alta disponibilidad para

Linux

Juan Pedro Paredes

[email protected]

Este documento relata los principios básicos de la alta disponibilidad,
además de dar un enfoque a la problemática que ha llevado el desarrollo
de estos sistemas.

Luego se enumeraran las características que hacen de Linux un sistema
operativo robusto para su uso en estos sistemas. Además se comentaran
diversas soluciones ya creadas.

1. Introducción

Actualmente Linux es conocido, como un sistema operativo estable; la problemática se
genera cuando el hardware, no es tan fiable como se desearía. En la mayoría de los
casos, cuando un sistema falla normalmente es debido a un fallo de hardware o a un
fallo humano (debido a un error en la administración del sistema).

En los casos en que un fallo hardware provoca graves consecuencias, debido a la
naturaleza del servicio (aplicaciones críticas), se implementan sistemas tolerantes a
fallos (fault tolerant ó FT); en los cuales, el servicio esta siempre activo. El problema
de estos sistemas, es que son extremadamente caros y normalmente no hay
presupuesto. Además suelen ser soluciones cerradas, totalmente dependientes de la
empresa contratada. Se suele poner un servidor tolerante a fallos, varias interfaces de
red, con tomas de alimentación redundantes y climatización especial.

Los sistemas de alta disponibilidad (high availability ó HA), intentan obtener
prestaciones cercanas al la tolerancia a fallos, pero a un precio muchísimo más
interesante. Esta es una opción, que la ha hecho crecer en importancia dentro del

1

Alta disponibilidad para Linux

mundo empresarial. La alta dsiponibilidad está basada en la replicación de elementos,
mucho más baratos que un sólo elemento tolerante a fallos. Naturalmente, si hablamos
de replicar servidores, hablaremos de un clúster d e alta disponibilidad (ver Figura 2).
Sistemas tolerantes a fallos los podemos encontrar en entornos muy críticos, tales como
una central nuclear o el sistema de navegación de una aeronave moderna.

Figura 1. Sistema HA de 2 nodos

1.1. Sistemas de alta disponibilidad y sistemas
tolerantes a fallos

En un sistema tolerante a fallos, cuando se produce un fallo hardware, el hardware
asociado a este tipo de sistema es capaz de detectar el subsistema que falla y obrar en
consecuencia para restablecer el servicio en segundos (o incluso décimas de segundo).

2

Alta disponibilidad para Linux

El cliente del servicio no notará ningún tiempo de fuera de servicio. En los sistemas de
alta disponibilidad existen los tiempos de fuera de servicio; son mínimos pero existen,
van desde 1 minuto o menos hasta 5 o 10 minutos, según sea el caso. En teoría esta es
la única diferencia entre ambos, pero en los últimos años, se ha ido acercando la idea de
alta disponibilidad a la idea de tolerancia a fallos, debido al abaratamiento de hardware,
y de ciertas tecnologías que han ido surgiendo. Estas tecnologías han evolucionado de
tal forma, que han logrando que subsistemas donde había que recurrir a la alta
disponibilidad ahora, se puede lograr tolerancia a fallos a bajo precio. De todos modos
en un sistema (como veremos en la siguiente sección) hay muchos elementos y
subsistemas, y algunos subsistemas tolerantes a fallos siguen siendo demasiados caros.

En la mayoria de los análisis, que se hacen de un sistema de servicio, si la aplicación
puede estar un mínimo tiempo fuera de servicio, y podemos permitir que el cliente
pierda la sesión o la conexión, temporalmente, la alta disponibilidad es una opción muy
apropiada. Hay soluciones de alta disponibilidad en las cuales las conexiones se
mantienen y las sesiones se recuperan.

2. SPOF (Single Point Of Failure ó punto simple
de fallo)

La regla básica para hacer un sistema de alta disponibilidad es la replicación de
elementos (Recordando la idea de RAID, Redundant Array of Independent Disks). Con
SPOF se quiere hacer referencia a cualquier elemento no replicado y que puede estar
sujeto a fallos; afectando con ello al servicio. Se debe evitar el SPOF en cualquier
subsistema del sistema, ya que en caso de fallo puede peligrar el servicio de datos por
culpa de un subsistema.

Por ejemplo, un adaptador de red que da acceso a un servidor a una red es un SPOF,
una controladora SCSI también. Si en un entorno de servidores falla uno y no puede ser
reemplazado fácilmente por otro, en los tiempos anteriormente mencionados, el
servidor se considerará como SPOF.

En el caso de alta disponibilidad (con hardware y software adecuado) se puede
reemplazar un adaptador de red o un servidor automáticamente. No sólo los servidores
han de ser redundantes si no los elementos que facilitan el servicio, como routers,
bridges o la propia red local.

Es conveniente olvidar la redundancia a cierto nivel, pues habrá un nivel en que la alta
disponibilidad se hace extremadamente cara, consideremos que sólo tenemos un único

3

edificio para nuestro sistema, perfectamente podemos considerarlo como SPOF (en
caso de incendio en el edificio), pero replicar en otro edificio el sistema, se puede salir
de presupuesto.

Alta disponibilidad para Linux

3. Servicio de datos

El servicio de datos y sus interrupciones es lo que nos ha llevado a adoptar medidas con
tolerancia a fallos o alta disponibilidad. En alta disponibilidad, se denomina servicio de
datos a un determinado servicio y los recursos necesarios para que el servicio sea
ofrecido a un cliente (grupo de recursos). En otros entornos HA, se denominan logical
host o software packages a la unión de servicio de datos y grupo de recursos asociados
a este.

Estos grupos de recursos han de implementar mecanismos necesarios, para que sean
completamente flexibles entre nodos del clúster; es decir puedan ser suplantados o
conmutados físicamente entre restantes nodos sin que el servicio de datos cambie en
absoluto. Esta “virtualización” del recurso va a permitir que un nodo pueda suplantar la
función de otro dentro del clúster. El servicio de datos sólo sera penalizado con el
tiempo de conmutación necesario para los grupos de recursos y la puesta en marcha del
servicio de datos.

Como ejemplos: una dirección virtual (en TCP/IP, IP Aliasing) para que la dirección
del servicio de datos pueda migrar entre nodos. Debe considerarse el servicio de datos
del clúster como una entidad única capaz de ofrecer servicios. El software de alta
disponibilidad debe ser capaz de abstraer el clúster que lo soporta y ofrecer dichos
servicios.

4. Dinámica HA

Se considera dinámica HA a todas las reconfiguraciones del clúster que garanticen la
máxima disponibilidad del servicio de datos. Esta dinámica esta orientada a los nodos
integrantes del clúster y la forma en la cual el clúster responde. Se denomina de la
siguiente manera:

Failover

Es un término genérico que se usa cuando un nodo debe asumir la responsabilidad
de otro nodo, importar sus recursos y levantar el servicio de datos. Se ha de

4

Alta disponibilidad para Linux

entender que una situación de failover es una situación excepcional, para cual la
alta disponibilidad ha sido concebida, el fallo de un nodo. Si sólo queda un nodo
en el cluster, tras los fallos de los demás, estaremos en un SPOF hasta que el
administrador del sistema, verifique y restaure el clúster. También se ha de
entender que el servicio de datos sigue levantado, que es el objetivo de la alta
disponibilidad.

Takeover

Es un failover automático se produce cuando un nodo nota un fallo en el servicio
de datos. Para ello debe haber cierta monitorización con respecto al servicio de
datos. El nodo que se declara fallido es forzado a ceder el servicio y recursos, o
simplemente eliminado.

Switchover o Giveaway

Es un failover manual, consiste en ceder los recursos de un servicio de datos y este
mismo, a otro nodo del clúster, mientras se realizan ciertas tareas administrativas.
A este procedimiento se le denomina “Node outage”.

Splitbrain

Para la gestión de un clúster HA es necesario un mecanismo de comunicación y
verificación entre nodos integrantes. Por este mecanismo, cada nodo debe
gestionar los recursos que corresponden a cada uno, segun el estado del clúster; a
su vez cada nodo debe hacer chequeos o latidos (beats) a sus compañeros.

Un Splitbrain (división de cerebros) es un caso especial de failover, en el cual falla
el mecanismo de comunicación y gestión de un clúster de dos nodos. Es una
situación en la cual cada nodo cree que es el único activo, y como no puede saber
el estado de su nodo compañero, tomará acciones en consecuencia, forzando un
takeover.

Esta situación es peligrosa, los dos nodos intentaran apropiarse de todos los
recursos, incluyendo el servicio de datos. El peligro aumenta sobre todo cuando
tenemos recursos delicados, como recursos de almacenamiento, ya que cada nodo
podría tomar y escribir por su cuenta, y quebrar a integridad de datos.

Para evitar este problema, cada nodo debe actuar de una forma prudente, y utilizar
los recursos compartidos como señal de que se esta vivo. La forma de proceder de

5

Alta disponibilidad para Linux

cada nodo es similar, ya que cada uno cree que su compañero ha desaparecido.
Después de que un nodo aprecia este problema, tiene indicado que reserve un
recurso llamado quorum. Un recurso quorum, es un recurso compartido, que se ha
preestablecido en ambos nodos como tal. Este recurso es un recurso exclusivo,
sólo un nodo del cluster puede reservarlo. Como este recurso sólo puede ser
reservado por un nodo, el nodo que llegue tarde a la reserva del recurso, entiende
que debe abandonar el clúster y ceder todos sus recursos. El quórum es utilizado
como simplemete, método de decisión.

Otra forma de evitar esta situación, un poco mas violenta, es que un nodo elimine
a su compañero; el primero que apague a su compañero se queda con todos los
recursos. Es un mecanismo muy brusco, pero muy eficaz. Para este caso existen
tarjetas especializadas en esta tarea.

4.1. Grupos de recursos de un servicio de datos

Pensando en un servicio de datos cual