Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

High Availability for Containerized Contrail

Starting with Contrail 4.0, some modules of Contrail have been grouped by function and packaged in Docker containers. This document describes the Contrail container subsystems that can be deployed in high availability mode.

Containers for High Availability

The following Contrail container subsystems can be deployed in high availability mode:

  • contrail-lb

  • contrail-controller

  • contrail-analytics

  • contrail-analyticsdb

How High Availability is Handled in Contrail Containers

This section describes the mechanisms for accomplishing high availability in each of the Contrail containers.

contrail-lb

The Contrail load balancer container contrail-lb runs HAProxy, a de facto standard open source load balancer, and the BIRD protocol internet routing daemon.

  • HAProxy is used to load balance across mulitple instances of Contrail services.

  • BIRD is used to deploy contrail-lb in high availability mode.

Although the contrail-lb containers are expected to be deployed in different hosts, they can also be deployed in the same hosts where contrail-controller containers are deployed.

For more information about BIRD, see BIRD Babel protocol documentation.

High Availability for contrail-controller Container

The contrail-controller container runs the following services that can be scaled or clustered.

  • contrail-api—Can be scaled up. It is load-balanced by HAProxy running in the contrail-lb containers. All clients can connect to the load-balancer IP to communicate with contrail-lb.

  • cassandra—Clustered. The cassandra and client libraries have built-in load-balancing and failure detection mechanisms, and there is no need for cassandra to be behind HAProxy. However, multiple instances are clustered during deployment of the contrail-controller containers. All clients connect to the list of contrail-controller container IPs to communicate with cassandra.

  • zookeeper—Clustered. The zookeeper and client libraries have a built-in high availability using leader-follower architecture, and there is no need for zookeeper to be behind HAProxy. However, multiple instances are clustered during deployment of the contrail-controller containers. All clients connect to the list of contrail-controller container IPs to communicate with zookeeper.

  • rabbitmq—Clustered. The rabbitmq and client libraries can handle multiple rabbitmq instances. However, multiple instances are clustered and mirrored in queues during deployment of the contrail-controller containers. All clients connect to the list of contrail-controller container IPs to communicate with rabbitmq.

Note:

Only an odd number of contrail-controllers are supported, due to a limitation with zookeeper for leader-follower election.

contrail-analytics

The contrail-analytics container runs the following services that can be scaled or clustered.

  • contrail-analytics-api—Can be scaled up. It is load-balanced by HAProxy running in the contrail-lb containers. All clients connect to the load-balancer IP to communicate with contrail-analytics-api.

contrail-analyticsdb

The contrail-analyticsdb container runs the following services that can be scaled or clustered.

  • cassandra—Clustered. The cassandra and client libraries have built-in load-balancing and failure detection mechanisms, and there is no need for cassandra to be behind HAProxy. However, multiple instances are clustered during deployment of the contrail-controller containers. All clients connect to the list of contrail-analyticsdbr container IPs to communicate with cassandra.

  • kafka—Clustered. Kafka uses a zookeeper cluster running in the contrail-controller containers. Multiple instances of kafka are clustered during deployment of contrail-analyticsdb containers. All clients connect to the list of the contrail-analyticsdb container IPs to communicate with kafka.

Related Documentation