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.
si tienes aplicaciones ya hechas mejor ni lo intentes, pero si por
ejemplo tienes una sesion en php, eso es por un lado una cookie y por
otro un archivo temporal en el servidor.
Ese archivo lo puedes cambiar por una entrada en la base de datos, asi
sea cual sea el servidor que atienda los requerimientos podra obtener
y modificar la informacion asociada a la cookie.
Este enfoque es mejor, porque por ejemplo, el servidor original podria
caerse y otro podria reemplazarlo sin perder la sesion. Si vas a
desarrollar desde 0 trata de usar base de datos en vez de sesiones
automaticas del php.
sobre los balanceadores no se buscas software libre o estas en un
proyecto mayor. Si el lo segundo revisa el hardware de barracuda y f5,
esos hacen lo que quieres pero baratos no son.
From [EMAIL PROTECTED] Fri Aug 29 18:45:00 2008
From: [EMAIL PROTECTED] (Aldrin Martoq)
Date: Fri Aug 29 18:45:11 2008
Subject: Balanceador de carga HTTP
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
On Fri, 2008-08-29 at 17:47 -0400, Juan Manuel Doren wrote:
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.
si tienes aplicaciones ya hechas mejor ni lo intentes, pero si por
ejemplo tienes una sesion en php, eso es por un lado una cookie y por
otro un archivo temporal en el servidor.
Ese archivo lo puedes cambiar por una entrada en la base de datos, asi
sea cual sea el servidor que atienda los requerimientos podra obtener
y modificar la informacion asociada a la cookie.
Este enfoque es mejor, porque por ejemplo, el servidor original podria
caerse y otro podria reemplazarlo sin perder la sesion. Si vas a
desarrollar desde 0 trata de usar base de datos en vez de sesiones
automaticas del php.
sobre los balanceadores no se buscas software libre o estas en un
proyecto mayor. Si el lo segundo revisa el hardware de barracuda y f5,
esos hacen lo que quieres pero baratos no son.
Gracias por todas sus respuestas. Hasta el momento haproxy hace
exactamente lo que quiero. Algunas respuestas:
1.- No tengo mayores datos de la implementacion, asi que debo tratar a
los webservers y las aplicaciones como tontas... En principio, son
apache tomcats 4.x;
2.- Por ende, no quiero modificar la logica de las aplicaciones ni el
ambiente de los servidores web. Estoy tanteando alguna solucion simple
sin cambiar el ambiente ni las aplicaciones.
3.- haproxy puede detectar cuando un webserver se muere, asi que lo
elimina de la lista. En ese caso, una sesion activa sera redirigida a
otro webserver que no tenia idea de la sesion; y bueno ahi la aplicacion
tendra que manejarse como si desconociera la sesion (no veo problemas).
Como comentarios a las tecnologias que propusieron:
1.- Usar memcached no es una solucion fuerte para manejar datos
guardados en una sesion. La razon es que un cache distribuido no te
garantiza atomicidad... hmm quizas si tienes una sola instancia [2].
Un cache distribuido es bueno para hacer cache de datos no criticos
resueltos por una base de datos (asi alivianas la carga de la base de
datos), pero no para actualizar data!! (tratar el cache como un store de
una base de datos).
Es por esto que almacenan un timestamp con los datos en el cache
distribuido y en tu logica considerar el tiempo del dato y si
corresponde refrescarlo contra la base de datos; si necesitas guardar
datos criticos en el cache tienes que modificar la logica de tu
aplicacion de manera que asegure borrar/actualizar los datos del cache
con cada update en la base de datos.
2.- Por lo mismo que la solucion de compartir la sesion de WebSphere es
tan repenca: tiene que asegurar atomicidad [1]. Eso lo hace lento y feo,
sobretodo si se meten muchos datos en la sesion.
3.- No se como les ha ido configurando PHP o Tomcat, pero a simple vista
tiene lo mismos problemas que 2. Otra solucion es configurar el ambiente
para que guarde la sesion en la base de datos, pero tampoco me parece
buena idea (mas que nada por evitar otro cuello de botella y dejar la
arquitectura lo mas simple).
4.
