|
Hi Dennis,
I'm not expert in LVS, I'm sure the experts will give you better answer
on LVS.
However, If you mean web applications, we do have web applications
running on
load balanced servers behind LVS.
Our solution to the application session problem is to store
application's session
information in nfs shared directory or store session information in
database.
In either case it won't matter which real server the client will be
redirected to,
the web application will always have access to the session information.
For other applications (e.g. samba) we use the persistent option in
ldirectord to send the client
to the same real server for a predefined duration of time, which should
be higher or equal
to the session timeout of the application. To have failover in this
case the application itself
should be able to transfer session information to another real server,
which is beyond
LVS's responsibility.
btw, There might be multiple clients from the same IP (if clients are
behind the same NAT)
but I can not think of a case with one client from multiple IPs.
Client IP is usually part of the unique information to identify a client.
Mehrdad
On 08/03/2010 6:25 PM, Dennis Allard wrote:
> 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
>
_______________________________________________
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
|
