Description of problem:
Dynamic routing using protocols such as BGP or OSPF provides a mechanism for load balancing and high availability which is different from the traditional active/standby virtual IP plus load balancer approach used in OSP today. This RFE is for BGP dynamic routing on the controller nodes in order to provide high availability and load balancing in an active/active configuration using layer 3 routing for shared virtual IPs.

Version-Release number of selected component (if applicable):
OSP 17 (either Tech Preview or supported TBD)

Additional info:
Dynamic routing allows hosts to advertise IP addresses to attached routers via routing protocols. A technique known as IP Anycast may be used where more than one host advertises the same IP address(es) to attached routers, and any of the hosts may receive traffic to or send traffic from the advertised IP addresses. Traffic will automatically be routed to the host with the fewest number of routing hops, or will be load-balanced between multiple hosts with the same number of hops.

This approach is desirable because it allows for N-way active/active IP endpoints for services and APIs, as well as distributed IP endpoints in DCN or edge scenarios. There is no requirement for controllers to share one or more layer 2 networks, because there is no shared MAC address, and layer 3 routing is used instead of ARP to direct traffic to the IP endpoints. This allows controllers to be placed in different leaf domains in a spine/leaf topology, or in different sites in a distributed or edge computing topology.

The initial implementation has been designed around BGP as the routing protocol and the FRR (Free Range Routing) routing software package. Similar to the existing active/passive HA + load-balancer approach, Pacemaker is utilized for service management and fencing, but IP anycast is used for virtual IP endpoints instead of Pacemaker active/passive virtual IPs. Some services managed by Pacemaker only operate in active/passive fashion, where only one controller may be active at one time. Clients may connect to any cluster server via the shared endpoint IP address, and HAProxy is used to proxy traffic to the one active controller for that service.