On 8/16/12 2:41 AM, "Rohit Yadav" <rohit.ya...@citrix.com> wrote:
>Hi, > >At present the redundancy of the virtual redundant routers, VRRP [3], >operates outside the scope of CloudStack [2]. And any event that happens >outside of CS, like rebooting by ssh-ing into the router vms or a >crash/start, is not know by the management server (Sheng's comment[1]). > >Therefore, these bugs are resolved by design : >http://bugs.cloudstack.org/browse/CS-15907 >http://bugs.cloudstack.org/browse/CS-15942 > >Request for comments to handle events outside of CS's scope for redundant >routers: [2] > >1. Async Callback: > With bug http://bugs.cloudstack.org/browse/CS-15970 fixed, the >management server knows when router's redundant changed and CS re-applies >iptables rules when state changes from UNKNOWN (possible crash/reboot) to >MASTER/BACKUP. This may fix the issue at hand, but out-of-band operations on the VR is a generic problem. > >2. Pull mechanism: > On reboot, a script/daemon on the router pulls any updates or iptables >rules, but it won't work if management server is down. Also doesn't account for several other failure scenarios. > >3, Push mechanism: > CS periodically checks/resets/updates iptables rules etc. Cons: it's a >bad design. Not sure why you think this is a bad design. Every update to the virtual router gets a transaction id. You can design a background task to push updates to the VR whenever the txid is different from the database. This is similar to the design of the SecurityGroups feature. It isn't unlike a DB master-slave sync or in some respects to eventual consistency. You could even checksum the configuration to detect other inconsistencies. > >4. Modifying VRRP [3] [4] such that when one of the routers goes away, >the other one will be responsible to re-apply iptables rules. Cons: when >both/all go down. Modifying GPL software is a non-starter in most cases.
