Versions Compared

Old Version 4

changes.mady.by.user Ian Southam

Saved on

compared with

New Version 5

changes.mady.by.user Ian Southam

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Create a persistent config.  This means that configuration is maintained across crashes and reboots.  Also every configuration command sent to the router will ensure that all configuration items are still correct.
  • Implement a redundant VPC redundancy for VPCs (Virtual private cloud)

Provisioning process

...

  • The basic configuration of the box is setup using the information passed to the router in the "cmd_line"
  • Any previous configuration already present from before the reboot of the box is also applied.  This means that routers can now happily survive being rebooted from outside cloudstack.  Something that was not previously the case.

 

Redundancy

The redundant vpc is achieved using the same mechanism as with the virtual router.  Keepalived in combination with contrackd. 

The configuration is maintained by configure.py and modules under /opt/cloud/bin/cs also deal with the keepalived calls to promote to master, set backup or set fault (see /opt/cloud/bin/master.py).

There are some differences with the virtual router implementation:

  • Keepalived is left to decide who will be master and who not.   We do not interfere with this process but instead simply report it to the management server.   This daemon has undergone many years of development to avoid split brains etc..  We do not see a role for cloudstack to try and reinvent this wheel
  • VRRP traffic goes over the lowest configured guest interface.  This means, that a vpc router is not redundant until it has at least one guest network configured!
  • Adding a new guest network can cause a master/backup election and can cause disruption to the network traffic for some seconds.
  • Script based provisioning, think terraform etc. goes very fast and keepalived takes some time to settle down.  You may see a situation in which when many provisioning commands are sent one after the other affecting guest networks that it takes 20-30 seconds to settle down.