|
On Sat, 29 Jul 2006, Paul Pech wrote:
Yes, you are right, FIN_WAIT is not being synchronised. But state 'NONE'
seems to get synchonised from lb1 to lb2, just without the same
expiration time as set on lb1.
I think the idea was to make the synchronisation as
lightweight as possible and only pass the minimum to make
the machine continue operation on failover. Presumably
NONE is required.
I have tried to issue the command 'ipvsadm -A -t 10.0.0.222:80 -s lc -p
3610 -M 255.255.255.0' on lb2 before starting the backup synchronisation
daemon on lb2, but this does not change the entries for expiration times
on lb2.
don't know what's supposed to happen there.
Well, this was a shot in the dark I tried to get the
expiration times to synchronise. As it does not work, the
command should not be issued on lb2.
I missed what you were doing. The backup director will be
taking it's ipvsadm commands from the active director. You
could run any ipvsadm command on the backup director before
starting the synch demon and it would be wiped out.
This is only important when lb1 fails and lb2 takes over.
In this case, almost all information about persistency is
lost, as lb2 will only recall persistent connections that
occured in the last three minutes (although the default
setting for persistency is 300 seconds, so where does it
get the 180 seconds from?).
erm, this (people seeing different persistence timeouts
depending where they looked) has come up before and I forget
the answer. A search of the archive with "persistence" and
"180" didn't get any hits. There's nothing in the HOWTO
either (searching in the Persistence section for "180").
Presumably it's two pieces of code that were written at
different times.
sorry don't know
Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
|
