Cluster de Alta disponibilidad

Mie Abr 25 10:07:27 BST 2007

El mié, 25-04-2007 a las 01:24 -0400, Jose Luis Olave escribió:
> Hola,
> 
> Acabo de terminar un servidor de Correo, Gateway, Web , etc en un
> empresa. Resulta que ahora necesitan que esté en Alta disponibilidad
> (http://linux-ha.org/) lo que permite que si el servidor1 falla este
> es detectado por hertbeat y los servicios son switchado al servidor2.
> 
> He leido bastante y he visto varias alternativas (DRB con heartbeat,
> ultramonkey, OpenMoisx, etc) la verdad no se cual es lo mejor y lo que
> yo necesito solo es un cluster de alta disponibilidad y no de carga de
> balance. 
>  
> Lo que necesito es que es que el servidor1 se copien los datos al
> servidor2 y si el servidor1 se cae automáticamente el servidor2 tome
> los procesos y obviamente envíe un aviso.
> 
> Alguien ha tenido una experiencia al respecto? 
> 
> Muchos saludos,

Eso deberían habértelo dicho antes de hacer todo el montaje. Me explico.

Montar un servicio en alta disponibilidad no es problemático. Existen
muchas soluciones como las que has comentado, pero tan importante es
decidir que aplicaciones usar para gestionar un cluster como que
aplicaciones serán capaces de reaccionar o adaptarse correctamente al
cluster que hayamos implementado. 

Por ejemplo, un servidor web apache, un tomcat o un servidor de BD mysql
tienen muchas opciones que facilitan la integración de estos en un
entorno de alta disponibilidad ( algunos casos activo/activo y otros por
fuerza activo/pasivo ), y por su propia arquitectura se pueden emplear
distintos métodos aún sin necesidad de configurar esas opciones que te
comento. En cambio, pueden haber aplicaciones como por ejemplo qmail que
por su propio diseño ( hace un uso muy particular de los inodos de los
filesystems donde residen las colas de proceso de mails ) que hacen muy
complicado la creación de un cluster activo/activo ( mi ideal ). En
qmail 1.0.3 se ha creado el mini-qmail, que es una instalación de qmail
sin colas y los mensajes son redirigidos al servidor central, y ese no
está en cluster. Lo único que obtienen es la división de carga de
envío/recepción entre varios mini-qmails, pero no es un cluster
activo/activo real. Esto que comento se que existe pero no la he
implementado, con lo que no hablo con total conocimiento de causa, ojo .

Dentro de la definición de un cluster, ya sea particular o para
terceros, lo primero que hay que responder son las 2 preguntas base:

¿Qué tiempo de pérdida de servicio estoy dispuesto a tolerar?

¿Qué cantidad de datos estaría dispuesto a perder?

La respuesta a estas dos preguntas son las que decidirán que tipo de
cluster montar y con que aplicaciones ( ya sea para la gestión de los
nodos como las aplicaciones en sí que dan el servicio )

Si puedes dar más información sobre este host, como podría ser:

- Aplicaciones corriendo actualmente

- Características del hardware ( tipo de discos ( en algún tipo de
RAID? ) , cuantas ethernets ( todas ocupadas o alguna libre?) ... )

- Posibilidad o no de disponer de storage compartido ( cabina, scsi )

En cuanto a teoría de clusters, me gustaría matizar un poco la
información que das al principio.

"(...)
empresa. Resulta que ahora necesitan que esté en Alta disponibilidad
(http://linux-ha.org/) lo que permite que si el servidor1 falla este es
detectado por hertbeat y los servicios son switchado al servidor2.
(...)"

Ojo con el tema de 'el servidor1 falla'. ¿Que ocurre si el servidor1 no
falla pero si que falla el apache del servidor1?. Aquí entramos en la
monitorización, y hay que decidir que es lo que hará saltar las alarmas:
¿Que el server en su totalidad se quede frito ( fuente alimentación,
kernel panic... ) o que alguno de los servicios que se ofrecen deje de
estar activo ( ¿bug server http? caída de BD...? ). Dependiendo de la
respuesta tendrás que usar un tipo u otro de heartbeat, de sistema o de
servicio ( heartbeat no es una aplicación, es un concepto )

"(...)
He leido bastante y he visto varias alternativas (DRB con heartbeat,
ultramonkey, OpenMoisx, etc) la verdad no se cual es lo mejor y lo que
yo necesito solo es un cluster de alta disponibilidad y no de carga de
balance.
(...)"

DRDB implica cluster activo/pasivo para el mismo servicio/datos.

OpenMosix no creo que sea el cluster que andas buscando. Openmosix ( o
por ejemplo Beowulf ) son un conjunto de librerías/parches al kernel y
metodologías para distribuir la carga de proceso entre varios nodos,
pero esa carga es la resultante de correr una aplicación concreta
diseñada y desarrollada específicamente para ese tipo de cluster. Por
ejemplo, el cluster que andas buscando tú es del tipo mantenimiento de
servicio, en cambio, los cluster OpenMosix/Beowulf son usados por tipos
de industrias que necesitan procesar una gran cantidad de datos para
obtener un resultado concreto ( previsión meteorológica,
automovilística, farmacéutica/química, renderizado... ), lo que implica
que las aplicaciones que corran sobre dicho cluster deben estar
preparadas ( diseñadas y compiladas ) para el uso efectivo de las
ventajas de estos tipos de cluster.

Hay que pensar como se verá desde 'el exterior' ese cluster, así como
los pasos ( automáticos o manuales ) cuando haya un switchover
( caída/recuperación de un nodo ) y por lo tanto los elementos
intermedios entre 'lo exterior' y el cluster ( lo ideal es que en ningún
momento importe cuantos o cual nodo está caído o levantado )

Particularmente no me gustan los clusters activo/pasivo ya que es tener
hardware desaprovechado esperando a que pase algo. En todo caso, si las
aplicaciones necesariamente deben ser montadas sobre un cluster
activo/pasivo, puedes mirar de dividir servicios y que cada nodo haga de
'standby' del otro, pero al mismo tiempo sean los primarios para un
determinado servicio/dato. El problema de esta solución es que caiga el
nodo que caiga siempre tendrás parada de servicio, en cambio, si tienes
toda la carga en un nodo activo y el otro standby, tienes un 50% de
probabilidades de en caso de caída de un nodo quedarte sin servicio.

Hay que mirar muchas cosas antes de decidir que hacer y me estoy
enrollando demasiado.

Si necesitas más info házmelo saber

Saludos

D.

-- 
http://dballester.blogspot.com
The Ubuntu Counter Project - user number # 4472
counter.li.org #206389