Skip to main content

Director High Availability

Director instances with the same configuration and receiving the same data will largely make the same decisions. This can be used to set up Director in a High Availibility (HA) capacity in your network by using them in an 'active-active' setup.

Example Deployment​

plantuml

In the diagram above, two separate Director instances are configured. Each has identical configuration except for their BGP section, as each will need a unique BGP Router ID. They point to the same rWeb, and establish a BGP session with each Edge Router. The Edge Routers are configured to send their flow samples to both Director instances.

In this setup, the first instance will make the same announcements to both edge routers as the second instance, and will withdraw announcements similarly. If one of the instances goes down, the other one will continue to maintain the correct set of announcements.

Non-BGP Setups​

If you aren't using BGP to perform traffic shaping operations in your network, but instead are using scripts, more care must be taken to allow independent editing of config. As mentioned in the caveats section, you'll need to make sure the scripts can handle two different instances trying to update the same configuration on a target router. The facilities to handle this will depend on your router model. For example, Cisco model routers have the concept of Configuration Lock.

rWeb High Availability​

Director can only be configured to talk to a single rWeb. If rWeb is set up as a cluster for its own high availability purposes, it's recommended that you set up a load balancer in front of the cluster so that incoming requests are sent to the current primary. Director should then be configured to use the load balancer as its rWeb address, ensuring it gets configuration data regardless of which rWeb is the primary.

Caveats​

While two Director instances with the same configuration and receiving the same data will make the same decisions, a real world implementation will be subject to varying effects. Flow samples can get lost in transit, timing of events will not be the exact same for both instances, and in general the set of information provided to each instance will not proceed in perfect lockstep. This shouldn't matter in most practical cases, but can be more observable in cases where network behavior is right around the edge of your workflow triggers (rather then well under or over them.md).