Cluster de Alta disponibilidad

[Masf Gmail]

ballester.david en gmail.com escribió:
> 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.
>
>
>   


Yo tengo más o menos el mismo problema. Trabajo en una empresa y acabo 
de poner un servidor para ofrecer hosting sobre un Ubuntu Dapper drake 
LTS. El panel de control instalado es PLESK. Me gustaría saber cómo 
puedo tener sincronizadas dos máquinas para que en el momento que una 
caiga, la otra entre en funcionamiento, o mejor aún, que las dos estén 
activo/activo y que se repartan la carga. El problema de esto último es 
que como tú has mencionado antes, qmail, ya que PLESK utiliza qmail para 
el servidor de correo.

Me gustaría que por lo menos me comentaseis donde puedo encontrar 
información para montar esta infraestructura ya que lo veo esencial en 
una empresa que quiera dar un servicio permanente.

Muchas gracias. Saludos.
Miguel Ángel.