Balanceador de carga HTTP

[Aldrin Martoq]

On Thu, 2008-08-28 at 21:15 -0400, Mario Gonzalez wrote: 
> 2008/8/28 Aldrin Martoq <amartoq en dcc.uchile.cl>:
> > Necesito instalar un balanceador de carga para HTTP, pero que mantenga
> > una "sesion" siempre con el mismo servidor (mediante cookies).
>  Una idea:
>  Porque en vez de "compartir" la sesíón y luego balancear la carla,
> mejor tener un "director" el cual vea quien puede procesar la próxima
> conexión entrante y luego abrir la sesión?

No te entiendo. La sesion es $_SESSION en php o HttpSession de java,
como ejemplos.

Como requisito las aplicaciones no se pueden modificar; esperan datos en
la sesion para poder funcionar (por ejemplo, si haces un login).
Entonces si un cliente web entra siempre tiene que llegar al mismo
servidor.

Por eso no entiendo a que te refieres con compartir la sesion ya que no
esta siendo compartida; tampoco entiendo a que te refieres con abrir la
sesion.

> Hace un buen tiempo atrás programé códigos web en Python usando un
> framework que se llama Django. Una forma de escalar con este framework
> es usar una DB central y múltiples servidores web delante de él.
> http://www.djangobook.com/en/1.0/chapter20/  Sección "Scaling", te
> puede dar otro punto de vista.

En general todas las arquitecturas "3-capas" se reducen a un monton de
servidores en la linea del frente y un tremeeeeeendo servidor de bases
de datos (o un monton de tarros con algun mecanismo de sincronizacion).

La forma usual de balancear la carga es que cualquier nodo pueda
responder, para ello se necesita que toda la info de la sesion este
centralizada (quizas la aplicacion mediante una base de datos o algun
otro mecanismo del ambiente). El problema es que eso agrega contencion y
eso pega en el performance/problemas; por ejemplo en WebSphere AppServer
(IBM) puedes configurar que todos los nodos del cluster compartan la
sesion entre ellos: esto es increiblemente costoso y en la mayoria de
los casos es contraproducente, pues en la mayoria de los casos quienes
escriben la aplicacion guardan muchos datos en la sesion y usualmente
involucra una reprogramacion de la aplicacion. Otro efecto practico de
esta arquitectura es que necesitas un servidor de bases de datos
alrededor de 3 veces mas grande que los del frente...



Por supuesto se pueden hacer cosas rechoras, pero eso se reduce bastante
cuando no eres quien escribe la aplicacion ...

Saludos!

-- 
Aldrin Martoq <amartoq en dcc.uchile.cl>
http://aldrinvideopodcast.podshow.com/