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 _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
