LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: LVS-DR and https

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: LVS-DR and https
From: Horms <horms@xxxxxxxxxxxx>
Date: Thu, 31 Jul 2003 08:37:51 +0900
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
<Prev in Thread] Current Thread [Next in Thread>