In a message dated: Thu, 23 May 2002 07:03:16 EDT
"Tilly, Lawrence" said:
>Hi, Paul.
>
>It's 6:30am and has already been a long day for me, so please forgive =
>any disjointed thoughts. :-} =20
>
>Anyway, I'm not very familiar w/ LVS-IP because I haven't used that, but =
>the problem w/ balancing SSL is when the encrypted transaction hits your =
>load balancer the balancer is unable to read any of your session =
>information (it's encrypted). So it just throws you at one of the web =
>servers in question (round robin usually). The web server decrypts the =
>transaction and is able to do any load balancing at that level before =
>sending the transaction on to an application server (if applicable). The =
>web server then encrypts the return data before sending it back out thru =
>the balancer to the user. At no point does the balancer see unencrypted =
>session information. I'm not sure if / how LVS-IP might overcome that =
>problem, but I'm going to try putting some bandwidth into reading up on =
>it this week.
LVS can be used in basically 1 of 3 ways:
IP-Tunnelling
Direct Routing
NAT
NAT is what it sounds like; your LVS director node NATs all traffic
between the client and the web server. You think you're talking to
one particular system, but you may be talking to any of several.
Direct Routing allows for the load balancer and the clients to all be
connected to the same subnet/segment, i.e. you can use a hub, and
your load-balancer acts like a router to direct packets to a specific
node on the segment.
IP-Tunnelling allows the load balancer to direct the request to one
of several different servers, but the return traffic does not go back
through the the load-balancer node; instead, the rest of the
tranaction is carried out directly between the client and the server
designated to that client.
Also note, that the load balancing algorithm is separate from the
client/server connection method. Whereas the mechanism by which the
client and server converse with each other is one of the above 3
methods, the load balancing mechanism can be one of:
Round-Robin Scheduling
Weighted Round-Robin Scheduling
Least-Connection Scheduling
Weighted Least-Connection Scheduling
Locality-Based Least-Connection Scheduling
Locality-Based Least-Connection with Replication scheduling
Destination Hashing Scheduling
Source Hashing Scheduling
Some of these may not be available for use with certain connection
schemes mentioned above;i.e. certain combinations of connection
scheme and scheduling algorithms may either be impossible, or
other-wise negate each other.
I'll leave the description/definition of the scheduling algorithms to
the LVS web site:
http://www.linuxvirtualserver.org/docs/scheduling.html
You can find more about LVS at:
http://www.linuxvirtualserver.org
But anyyway, as I mentioned before, I *think* ssl connections with
load-balancing may be possible using the IP-tunneling and a
"persistent port" on the director. There's more info about
persistent or "sticky" connections (such as http cookie, https,
ftp, ssl, etc.) here:
http://www.linuxvirtualserver.org/docs/persistence.html
So, in short, I *do* think it's possible, and of course, it *can* be
done with Linux. However, I don't know how easy, economical,
efficient, or scalable such a solution may be. Those decisions are
left to the individual implementor :)
--
Seeya,
Paul
----
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************
