|
> > > 2. CIP->FWMARK
> > > Any examples where/why (2) is needed?
> > > But switching the LVS code always to use (2) for the
> > > persistent fwmark services is possible.
> > In my opinion, here are some pros and cons of case 2:
> [snip]
> I hope this feature (2) will be implemented in the next LVS
> version (if Wensong don't see any problems). I.e. the templates
> can be changed to case (2) for the persistent fwmark services.
> For now we (I and Horms) don't see any problems after this change.
> Then connections from one client IP to different VIPs (from the same
> fwmark service) will go to the same real server (only for the persistent
> fwmark services).
Do you see any reason why enabling CIP->FWMARK for all cases would be a bad
thing?
That is, not only using case 2 for persistent FWMARK, but just whenever
FWMARK was used. Personally, I cannot ever forsee a scenerio when a person
would setup an FWMARK for load balancing and want each VIP associated with
that FWMARK to act independently. <?>
I've always thought that the scheduling algorithms should look directly at
the real servers rather than the real server stats for each particular
virtual server. That is, least connection scheduling would look at the total
number of connections on a real server, not just the connections from that
particular VIP. Round-robin would go round-robin from real server to real
server based on the last connection from ANY VIP to the real servers...
However, before FWMARK I realized that this would probably very difficult to
do especially in cases where an LVS administrator was load balancing to a
number of different real server clusters that may overlap.
FWMARK, to me, just by causing all VIPs marked with a particular FWMARK to
look like one big VIP makes it possible to do basically that which I just
described. I don't see why anyone would not want such functionality with the
FWMARK services. If one did want such functionality, he would probably
partition the VIPs associated with his FWMARK into separate FWMARKs or even
explicit VIP entries anyway.
|
