Hello Malcolm,
It starts getting interesting :)
> > What for? You break the flow of TCP which is fundamental. You can set
> > the timeout very high but this is nonsense and defeats the purpose of
> > load balancing. Give me an example where you would need such a thing.
> >
>
> I am setting up an LVS cluster which load balances XDMCP sessions. When
Ok, so we're talking about UDP, right? This puts the whole stuff in a
different light. Unfortunately right now I don't understand too much
about this protocol but I'm more then willing to help you getting your
setup working. A happy user is a good user :)
> users log in, they will want to remain connected until they log out
> (past experience shows that they get upset when kicked off after a
> timeout is imposed). In this cluster configuration, the load balancing
> is something that occurs over a long period of time, and I am using the
> cluster more from the point of view of providing a single IP address to
> the client network, coupled with better availability of the service
> overall.
Sounds pretty reasonable.
> The cluster will be reasonably balanced, if you take a long term view
> (think glacier [XDMCP] versus stream [HTTP] =]).
:) granted, except that you should not mix apples and oranges, or in
your example TCP and UDP. The load imbalance seen can have completely
different roots regarding the two protocol families.
> Once the first revision of the cluster, using NAT with plain RR, is
> established, I shall be trying other load-balancing mechanisms and will
> move to DR. However, my priorities now are documentation (first draft
> finished, but ugly) and deployment (waiting on the Data Centre admin to
> arrange a rack). I intend to publish my docs, along with the scripts
> some time in the next few weeks -- I'll fling them at my WWW site.
Very good.
> So, it turns out that the Pen stuff is of no use to LVS. That's fine
> with me, no problem. Just trying to present an open outlook.
Perfect. And you made me curious enough to find a reasonable solution
for your setup if this is still a problem. I have certain ideas in mind:
o You could set a very high UDP timeout so templates expire every 24 hours
or so. Is this still unpracticable? If so proceed to the second proposal.
o We need to add a flag for such persistency with unlimited UDP template
timeouts. Adding this to the LVS is not such a big deal but has some
very important impacts:
- The connection template table will always grow and eat memory unless
we provide a mechanism to flush certain entries (this wish comes up
every once and then) or you reboot the machine
- table synchronisation will not work or is quite difficult to make
working
You can consider yourself lucky using such a (insecure) protocol based
on UDP. There would be no possibility to make this happen for TCP streams.
Let me know you wishes,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|