|
On Wed, Jul 30, 2003 at 08:24:11PM +0200, Christian Wicke wrote:
> Hello Horms,
>
> sorry if I repeat stuff that is already said somewhere in this mailing list.
> I
> just found this project because the debian package was listed in the debian
> weekly news. I browsed a little bit through the list and found your mail.
>
> >The other reason that persistance is a good idea relates to session
> >resumption. This allows subsequent connections to be set up much
> >faster if an end-user connects to the same real server. Some Layer 4
> >Switching implementations allow persistance bassed on session Id for
> >this reason. LVS doesn't do this. And it is a bit hard to put into
> >the current code (when I say a bit, I mean more or less impossible).
>
> At my work we used a comercial product for load balancing. We have some
> Apache/Tomcat-servers which a accessed through HTTPS. Our wish was that any
> customer returns to the same server as he logged in before. If this fails the
> customer has to relogin.
>
> To achieve this there are several strategies. Here are they and their
> advantages/disadvantages:
>
> 1.Fix IP-ranges for each server.
> 1.a distribute by taking the last Byte of the IP and do modulo number of
> servers
> Advantage: Pretty equal distribution
> Disadvantage: People with dial on demand change their IP-address and have to
> relogin
> 1.b distribute by fix ranges of the beginning of the IP-address
> Adv: People with DOD have no problem
> Disa: Difficult to put equal load on each
>
> 2. Remember which customer went on which server using a big table.
> This table should be persitent so you can restart the load dispatcher without
> kicking out all the customers.
> New customers should go to the table with the least load.
> Based on what do we identify the customer?
> 2.a The IP-adress.
> Disa: DOD-people get kicked out.
> 2.b The SSL-Session
> Disa: Some Versions of IE restart the SSL-Session without reason. They get
> kicked out
> 2.c Both, the SSL-session and (if it's a new SSL-session) the IP-adress.
> Disa:Sounds complicated huh?
> 2.d Do reverse proxy with some apaches based on IP and do a second load
> dispatching with the HTTP-request from Apache to Tomcat based on the
> session-ID.
> This would require some logic to be plugged in to extract the Tomcat- (or
> whatever-server's-) session-ID from the request.
> You need to do reverse proxy first, because you cannot extract the session-id
> from an encrypted https-request.
>
> 2.d would be the best solution. But we gave up the fight and sticked with
> something between 2.a and 1.a and told DOD-people to set up their timeout.
Currently LVS supports 2.a. 1 is also possible to set up
but probably not desirable. 2.b was what I was trying to describe,
it is not supported. 2.c is just a variabt of that, and if 2.b was
supported it could be done too, but 2.b isn't supported. 2.d is
possible, but isn't LVS.
--
Horms
|
