On Thu, 2008-08-28 at 21:15 -0400, Mario Gonzalez wrote: > 2008/8/28 Aldrin Martoq <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]> http://aldrinvideopodcast.podshow.com/
