Forum Discussion

Chris_Phillips's avatar
Chris_Phillips
Icon for Nimbostratus rankNimbostratus
Mar 16, 2011

Best practises for config sync when making changes via icontrol

Howdy,

 

 

I've a build system which is successfully adding and removing nodes and pool members, and all is pretty sweet, however I'm unsure about how best to approach issues like config sync when this is happening. How do other people deal with maintaining config integrity between an HA pair? Ideally I'd rather not be syncing at all - it strikes me as very odd that config sync still seems to only check timestamps of configs rather than actual differences line by line. I'd feel much more comfortable to be able to do something like add a pool member on the standby device, make sure it comes up happy, and then add it to the active device. As I'd then have made the same change on both sides, the configsync should *not* need changing, but there's no logic to know that. Obviosuly I can call a config sync within iControl, but I'd rather not need to. Maybe we should make a tranche (sp?) of changes on standby and the flip the whole lot over in a single sync? This seems reasonable when rebuilding entire pool contents wholesale, but we're also looking at trickle rebuilding pool members, rebuilding every back end machine once every 48 hours or something (so need to elegantly bring the boxes in and out of service with iControl) so there then being no big switch to pull ever.

 

 

 

So what's the recommended (a good enough) approach for dealing with this when we're very frequently rebuilding systems and want to ensure we have consistency between the boxes.

 

 

 

Thanks

 

 

Chris

 

dev
devops
iControl
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Mar 16, 2011
    hi Chris,

     

     

    The overhead for saving the config to a UCS is fairly low. However, the impact of loading the config can be significant. So ideally, try to avoid loading a UCS on an active unit. You can make the changes via iControl to just the active unit in batches. Once you're done with the batch, you could sync the config to the standby peer.

     

     

    If you would like more intelligent handling of config sync state detection, you could open a case with F5 Support and describe the improvements.

     

     

    Aaron
  • Chris_Phillips's avatar
    Chris_Phillips
    Icon for Nimbostratus rankNimbostratus
    Mar 16, 2011
    So this suggests making these changes on the active and syncing to standby at the end? As our rebuild procedure currently involves forcing down node members (which will one day including waiting for connections to drain) rebuilding and then reenabling, doing this sort of thing on the standby makes no sense at all...