Thanks for the info. That approach seems workable, but complicated, so
I decided to pull an end run around. I disabled persistence, moved
sessions into mysql, and am relying on mysql's replication to ensure
that all servers have the session data.
I think as we scale up I will probably have to set it up to force the
clients to go to a single server (master/slave replicated) for session
info, but am hoping to avoid this due to latency issues since I am
operating in a WAN environment.
This is probably a naive question, but is there any way for the director
to identify that a request is coming from a client behind a nat router?
I was thinking of playing with the source to see if I could get it to
use something other than wan ip address to uniquely identify each
client. I really do not know much about lvs or tcp/ip (beyond my Uni
Data Communications course), but am a professional C/C++ programmer.
Just thought I would ask if you guys have any thoughts on this before I
waste a bunch of time digging into the source.
Thanks,
Matthew Smart
President
Smart Software Solutions Inc.
108 S Pierre St.
Pierre, SD 57501
Phone: (605) 280-0383
Skype: msmart13
Email: msmart@xxxxxxxxxxxxxxxxxxxx
Graeme Fowler wrote:
> On Sat, 2007-06-23 at 13:30 -0500, Matthew Smart wrote:
> <snip LVS with multiple NAT client explanation>
>
>
>> The problem I have is that all clients from a given location get
>> directed to the same realserver. Since the majority of clients are
>> located in the same office, we are not getting a good load balance. I
>> found the following thread in the archives which addresses this issue:
>> http://archive.linuxvirtualserver.org/html/lvs-users/2005-04/msg00116.html
>>
>> That thread mentions that the realservers need tuning for ARP. I have
>> used the arp flags for 2.6 in the manner show in howtos online. Can you
>> elaborate on this comment and possibly direct me to some resources
>> discussing what can be done in this circumstance?
>>
>
> I don't think you have an ARP problem - your LVS is working as designed,
> if not as desired.
>
> I'm not sure, given that you only ever have three client addresses here,
> that you'll get the behaviour you want - it'll always be imbalanced with
> such a low number of client addresses.
>
> *However* - you could get creative - well, I think this would help you,
> anyway...
>
> The clients will only come from three source IP addresses, but
> presumably if they have half-decent NAT kit that means a range of source
> port numbers will be involved (you'd have to work the ranges out by
> observation, I expect).
> You could then setup a bunch of inbound netfilter (iptables) rules on
> the director(s) to assign a different netfilter MARK value (fwmark
> value) to various source port ranges; you could then have multiple
> virtual services assigned via fwmark values instead of VIP (you'd still
> need the VIP on the realservers for this to work though, if you're using
> DR).
>
> Just as a theoretical example, using three realservers:
>
> group source ports 1-20000 connecting to VIP into fwmark 1
> group source ports 20001-40000 connecting to VIP into fwmark 2
> group source ports 40001-65535 connecting to VIP into fwmark 3
> (you could make this as granular as you want to)
>
> have a virtual server definition for fwmark 1:
> RS1 weight 200
> RS2 weight 100
> RS3 weight 100
>
> have a virtual server definition for fwmark 2:
> RS1 weight 100
> RS2 weight 200
> RS3 weight 100
>
> have a virtual server definition for fwmark 3:
> RS1 weight 100
> RS2 weight 100
> RS3 weight 200
>
> The total weight for each server is identical (400) but the spread
> within each group is slightly different. The clients, however, should
> see no change.
>
> The only problem I can see with this is that persistence will only work,
> I think, if the clients stay within the same port range. If a given
> client's source port drifts into a different range then it will, very
> likely, drift onto a different RS - but persistence on all three virtual
> services might take care of that, given that persistence is actually
> done by source IP; as long as all three realservers are included in each
> virtual service I *think* the persistence will carry. Horms or Joe might
> want to check that statement, mind you.
>
> Give it a try and see if it helps.
>
> Graeme
>
>
> _______________________________________________
> 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
>
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
|