clustering (Openmosix)

[Rodrigo Henriquez M. - Corporacion Linux S.A.]

El mié, 18-08-2004 a las 22:20, Alvaro Herrera escribió:
[...]
 
> > La verdad es que es practicamente imposible dada la cantidad
> > gigante de factores (archivos abiertos, procesos, manejo de 
> > sesiones, etc, etc).
> 
> Right.  No me acuerdo del ICQ pero ciertamente es _muy_ dificil.
> 
> Quizas sea posible migrar los programas cliente.  Pero antes de poder
> aseverar algo asi me gustaria que me dijeras si a nivel de kernel se
> puede migrar una conexion TCP,

AFAIK depende del tipo de conexion y la cantidad de fd que lleve
asociados.

No es lo mismo (intentar) migrar una conexion HTTP que una SSH,
por poner un ejemplo.

Hace poco estuve (tratando mas que nada) de hacer un plugin para
heartbeat que permitiera replicar las conexiones ssh de un nodo
a otro.

La verdad es que me la gano. La cantidad de cosas asociadas que
lleva cada conexion (en el caso de SSH : File Descriptors, referencias
a PPIDs, punteros a direcciones de memoria entre otras cosas _sabrosas_
casi imposibles de determinar) me hizo abortar el proyecto. 

No tenia forma de tomar todas las precauciones necesarias para migrar
fielmente la conexion.

Mi unica opcion en este caso, es aprender el protocolo SSH completo
entre otras cosas mas y no tengo tiempo para eso :-(

En el caso de una conexion de PostgreSQL me imagino que debe ser una
_ensalada_ similar.


>  y como harias al otro extremo para
> cambiar la direccion de destino.  O el cluster comparte direcciones
> virtuales y hay alguna especie de proxy?

El cluster maneja una IP que es flotante entre ambos nodos y que se
encuentra en el nodo que este activo en el cluster. 

Claro que eso es en un modelo Activo/Pasivo.

En un modelo Activo/Activo, se puede asignar un balanceador de trafico
antes de los dos (o mas nodos) o se puede balancear con VRRP o algun
protocolo de enrutamiento redundante.


> > Irrumpir en algo asi, es mucho mas traumatico que meterse en
> > el disen~o de postgresql para hacer replicacion nativa (lo
> > cual me imagino que es muy traumatico :) ).
> > 
> > Lo unico que conozco que hace algo similar pero no es nativo
> > es Slony (http://gborg.postgresql.org/project/slony1/projdisplay.php).
> 
> Slony-I es el proyecto de replicacion Postgres mas importante.
> (switchover, replica entre versiones, etc).  A que te refieres con que
> no es nativo?  

Que no viene directamente embebido dentro de las opciones de postgresql
(como lo hace MySQL). Ahora, no digo que esto sea una desventaja.



> Sea como sea, no tiene nada que ver con migrar procesos;

Obviamente. 


> las bases de datos siguen siendo separadas (aunque sean replicas
> exactas).

Yup.


> Slony-I se libera por el Postgres Global Development Group (los mismos
> que liberan Postgres), bajo la misma licencia, y el desarrollo lo hacen
> las mismas personas ... se conserva como un proyecto separado para
> permitir que funcione limpiamente entre distintas versiones (es decir,
> para progresar independientemente, y no tener que soportar una version
> antigua solo porque venia con un Postgres antiguo).
> 
> Lo de hacer "replicacion nativa" no tiene mucho sentido en general; creo
> que a lo que te estarias refiriendo es a hacer replicacion sincrona
> versus asincrona (que es lo que hace Slony-I, y todo el resto de
> sistemas de replicacion)

No.

Me referia a que no venia directamente embebido como una opcion mas
dentro de PostgreSQL.

Pero como comentaste recien, la separacion es mas efectiva ya que 
permite realizar replicacion independiente de la version.

BTW, ya he probado Slony y anda "de pelos".

Saludos.



-- 
Rodrigo Henriquez M.		http://www.corporacionlinux.cl
Corporacion Linux S.A. 		Fonos: 02 2442988 - 02 2444250