|
True. I'm more familiar with using LVS in the DR context so I didn't
think about this context.
You could write another static scheduler to do this for NAT, or possibly
change the scheduler to acommodate NAT usage. There would basically be
two parts for this change, one is adding the concept of "static"
schedulers, the other would be the actual static scheduler.
Of course, if the new scheduler doesn't help you can just not use it and
it shouldn't affect performance negatively assuming I code it correctly
which isn't a 100% valid assumption :).
Ryan Leathers wrote:
it would be hiddeous in situations where many folks connect to lvs stuff
from behind a NAT though. maybe it could be taken a step farther using
a source mapped tag from an 802.1q frame built on the fly on the NAT
device. tag values = unique connections - - or something along those
lines. thats probably pie in the sky though since not every NAT device
can do 802.1q let alone build on-the-fly tags based on source address.
On Fri, 2004-02-06 at 14:17, Brett E. wrote:
Jacob Coby wrote:
I assume you are the person that mentioned this previously.
What does this scheduler do for someone? When would people
use it?
It almost looks ideal for https and database connections.
-Jacob
This is true, it would have the same effect as setting the persistence
timeout to infinity so the key exchange would happen only once per IP.
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|
