|
I'd like to get people's reaction to my ideas for how to combine
IP-based load balancing with the requirements for persistence
at the application session level.
I am not an expert in LVS load balancing but I do know my
network layers and TCP/IP stuff.
Yesterday, I had to help deal with the "ARP problem" in the
LVS load balancer, the details of which I will spare you.
Note, I did not set up LVS, nor did I configure it. I work
more on our database and application code. However, I have
thought about load balancing and have some basic questions
about what appear to be mis-designs and incorrect uses of
load balancing when it comes to coping with application
level persistence (such as "cookies", etc.).
Many systems are designed to use IP-based load balancing. This
presents the problem of how to allow for application level
persistence. A typical solution seems to be to peg a given
source-IP/destination TCP port (or ports) to map to a specific
virtual IP.
That solution has the following problems:
1. client IP numbers can change from one TCP conversation to
another. They usually don't, but they could. There is no
IETF standard preventing IP "drift" in the client.
2. Pegging the destination virtual IP based on the source IP
is not an optimal way to distribute load. Ideally, you would
like to fully randomize load and only maintain a persistent
mapping of client IP to real server IP for the duration of
a single TCP conversation.
I propose that a better solution is to use IP-based load balancing
only up to the point at which an application-level session is
established. At that point, the application should redirect the
communication to a static IP that is not load balanced.
In this way, you get the best of both worlds:
1. IP number of a client changing is no longer a problem since
the load balancer is only involved in TCP conversations and
is no longer concerned with session-level persistence since
once the real server starts a session it informs the client
to use a real IP to continue the application level session.
2. The load balancer can do fully random source-IP-to-virt-IP
mappings, since the only persistence needed is now for
single TCP conversations
To summarize... Use LVS load balancing in an optimal way to
randomize the selection of web servers (say) and then, once
a session is started (usually a few "screens" into the user-
level use of a web site), have the application refer to a
static IP (its own non-virtual IP) to handle the rest of the
user-level session.
What do you think?
There is still the issue of Fail Over for the case of a server
having active sessions.
Another problem I saw in the LVS HOWTO was a suggestion to deal
with session data by copying session data to all real servers.
That, of course, is not practical.
But, what is practical, as a way to achieve fail-over of the
real server, is to copy session data from a pool of real servers
to a **single** stand-by server. In the event of fail-over of any
one machine in the pool, you arrange for that stand-by to come
up in the place of the failed server.
In this way, only one copy operation needs to be done per
real server - i.e. N servers do N copy operations, as opposed
the bad idea in the LVS HOWTO of doing NxN copy operations.
This can be done via a heart-beat active/passive kind of
fail over scenario and, I believe, done in a way that is
independent of the servers being directed to by LVS.
Your thoughts?
Thanks
Dennis
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
