|
Last week I decided to move forward with testing, then implementing
connection sync in my IPVS production setup. The configuration is
LVS-NAT with keepalived and two (failover pair) directors. Kernel is
vanilla 2.6.17.7 and keepalived 1.1.13, the latter a custom build of an
RPMforge source RPM. This setup has been completely stable over
approximately the past two years.
I'd like to share some observations with the list and see if anyone has
comments:
. When initially bringing up the sync daemon on the standby director, as
expected the daemon comes up as ipvs-syncmaster. When I next brought
it up on the primary director using a service keepalived reload or
restart, the standby indefinitely remained in master mode. It appears
to take a VRRP failover/failback event (e.g. a sleep 2 between
keepalived stop/start on the primary) for keepalived to make
ipvs-syncmaster on the standby to switch to ipvs-syncbackup. Is this
normal behavior?
. When ipvs-sync* is running, the box maintains a load av of 1.0. I
read this has something to do with the kernel syncdaemon code using the
wrong sleep function. Anyone know in which kernel this might be fixed
(beyond 2.6.17.7)? I might just patch the existing kernel since it was
built from source anyway, and has proven otherwise quite stable. But I
have some other IPVS boxes running 2.6.18-xen (as a dom0).
. For an FTP server behind the director, IPVS data connection sync info
appears in the standby if passive mode is used (which we do), but at
least in initial testing I couldn't get the data connection to keep
going through a failover event. The control connection fails over
normally. Was this an anomaly in my testing, or *should* it work? I
wonder if it might have to do with some portion of the needed state in
the ipfilter connection table and hence not replicated.
Cheers,
Dave
|
