Using Load Balancers in Contrail

Invoking LBaaS Drivers

The provider field specified in the pool configuration determines which load balancer drivers are selected. The load balancer driver selected is responsible for configuring the external hardware or virtual machine load balancer.

Supported load balancer drivers include:

• HAProxy

• A10 Networks

• F5 Networks

• Avi Networks

Benefits of Creating Configuration Objects

Starting with Contrail 3.0, the Neutron LBaaS plugin creates required configuration objects (such as pool, VIP, members, and monitor) in the Contrail API server, instead of within the Neutron plugin context, as in previous releases.

This method of configuration has the following benefits:

• Configuration objects can be created in multiple ways: from Neutron, from virtual controller APIs, or from the Contrail UI.

• The load balancer driver can make inline calls, such as REST or SUDS, to configure the external load balancer device.

• The load balancer driver can use Contrail service monitor infrastructure, such as database, logging, and API server.

Figure 1 provides an overview of the Contrail LBaaS components.

Figure 1: Contrail LBaaS components with neutron-lbaas

Using a Service Appliance Set as the LBaaS Provider

In OpenStack Neutron, the load balancer provider is statically configured in neutron.conf, which requires restart of the Neutron server when configuring a new provider. The following is an example of the service provider configuration in neutron.conf.

In Contrail Release 3.0 and greater, the Neutron LBaaS provider is configured by using the object service-appliance-set. All of the configuration parameters of the LBaaS driver are populated to the service-appliance-set object and passed to the driver.

During initialization, the service monitor creates a default service appliance set with a default LBaaS provider, which uses an HAProxy-based load balancer. The service appliance set consists of individual service appliances for load balancing the traffic. The service appliances can be physical devices or virtual machines.

Sample Configuration: Service Appliance Set

The following is a sample configuration of the service appliance set for the LBaaS provider:

Sample Configuration: Single Service Appliance

The following is a sample configuration of a single service appliance:

Understanding the Load Balancer Agent

The load balancer agent is a module in the service monitor. The service monitor listens on the RabbitMQ configuration messaging queue (vnc_config.object-update) to get configuration objects. The dependency tracker triggers changes to all related objects, based on configuration updates.

The dependency tracker is informed to notify the pool object whenever the VIP, member, or health monitor object is modified.

Whenever there is an update to the pool object, either directly due to a pool update or due to a dependency update, the load balancer agent in the service monitor is notified.

The load balancer agent module handles the following:

• Loading and unloading LBaaS driver-based service appliance set configuration.

• Providing the abstract driver class for the load balancer driver.

• Invoking the LBaaS driver.

• Load balancer-related configuration.

F5 Networks Load Balancer Integration in Contrail

This section details use of the F5 load balancer driver with Contrail.

Contrail Release 3.0 implements an LBaaS driver that supports a physical or virtual F5 Networks load balancer, using the abstract load balancer driver class, ContrailLoadBalancerAbstractDriver.

This driver is invoked from the load balancer agent of the contrail-svc-monitor. The driver makes a BIG-IP interface call to configure the F5 Networks device. All of the configuration parameters used to tune the driver are configured in the service-appliance-set object and passed to the driver by the load balancer agent while loading the driver.

The F5 load balancer driver uses the BIG-IP interface version V1.0.6, which is a Python package extracted from the load balancer plugin provided by F5 Networks. The driver uses either a SOAP API or a REST API.

• F5 Load Balancer Global Routed Mode
• Initial Configuration on an F5 Device
• Initial Configuration on an MX Series Device Used as DC Gateway

F5 Load Balancer Global Routed Mode

The F5 load balancer driver is programmed in global routed mode using a property of the service-appliance-set.

This section describes the features and requirements of the F5 load balancer driver configured in global routed mode.

The following are features of the global routed mode.

• All virtual IP addresses (VIPs) are assumed to be routable from clients and all members are routable from the F5 device.

• All access to and from the F5 device is assumed to be globally routed, with no segregation between tenant services on the F5 device. Consequently, do NOT configure overlapping addresses across tenants and networks.

• The F5 device can be attached to the corporate network or to the IP fabric.

The following are requirements to support global routed mode of an F5 device used with LBaaS:

• The entire configuration of the F5 device for Layer 2 and Layer 3 is preprovisioned.

• All tenant networks and all IP fabrics are in the same namespace as the corporate network.

• All VIPs are in the same namespace as the tenant and corporate networks.

Traffic Flow in Global Routed Mode

This section describes and illustrates the behavior of traffic flow in global routed mode.

The information in this section is based on a model that includes the following network topology:

Corporate Network --- DC Gateway (MX device) --- IP Fabric --- Compute nodes

The Corporate Network, the IP Fabric and all tenant networks use IP addresses from a single namespace, there is no overlap of the addresses in the networks. The F5 devices can be attached to the Corporate Network or to the IP Fabric, and are configured to use the global routed mode.

The role of the MX Series device is to route post-proxy traffic, coming from the F5 device in the underlay, to the pool members in the overlay. In the reverse direction, the MX device takes traffic coming from the pool members in the overlay and routes it back to the F5 device in the underlay.

The MX device is preprovisioned with the following:

• VRF connected to pool network 2

• ability to route traffic from inet.0 to the pool network

The MX routes the traffic from inet.0 to public VRF and sends traffic to the compute node where the pool member is instantiated.

The F5 device is preprovisioned with the following:

• publish route to attract VIP traffic

• pool network subnet route that points to the MX device

The F5 device is responsible for attracting traffic destined to all the VIPs, by advertising a subnet route that covers all VIPs using IGP.

The F5 device load balances among different pool members and sends traffic to the chosen member.

The following figure shows the traffic flow in global routed mode.

Figure 2: Global Routed Traffic Flow

A similar result can also be achieved on the switch to which the F5 is attached, by publishing the VIP subnet in IGP and using a static route to point the VIP traffic to the F5 device.

The MX should attract the reverse traffic from the pool members going back to the F5.

Routing Traffic to Pool Members

For post load balancing traffic going from the F5 device to the pool members, the MX Series device needs to attract traffic for all the tenant networks.

Routing Reverse Traffic from Pool Members to the F5 Device

The MX should attract the reverse traffic from the pool members going back to the F5.

Example: Creating a Load Balancer

Use the following steps to create a load balancer in Contrail Release 3.0 and greater.

1. To configure a service appliance set, use the script in /opt/contrail/utils to create a load balancer provider. With the script, you specify the driver and name of the selected provider. Additional configuration can be performed using the key-value pair property configuration.

   /opt/contrail/utils/service_appliance_set.py --api_server_ip <ip address>--api_server_port 8082 --oper add --admin_user admin --admin_password <password> --admin_tenant_name admin --name f5 --driver "svc_monitor.services.loadbalancer.drivers.f5.f5_driver.OpencontrailF5LoadbalancerDriver" --properties '{"use_snat": "True", "num_snat": "1", "global_routed_mode":"True", "sync_mode": "replication", "vip_vlan": "trial2"}'

2. Add the actual device information of the load balancer.

   /opt/contrail/utils/service_appliance.py --api_server_ip <ip address>--api_server_port 8082 --oper add --admin_user admin --admin_password <password> --admin_tenant_name admin --name bigip --service_appliance_set f5 --device_ip 10.204.216.113 --user_credential '{"user": "admin", "password": "<password>"}'

3. Refer to the load balancer provider while configuring the pool.

   neutron lb-pool-create --lb-method ROUND_ROBIN --name web_service --protocol HTTP --provider "f5" --subnet-id <subnet id>

4. Add members to the load balancer pool. Both bare metal webserver and overlay webserver are allowed as pool members. The F5 device can load balance the traffic among all pool members.

   neutron lb-member-create --address <ip address>--protocol-port 8080 --weight 3 web_service

   neutron lb-member-create --address <ip address> --protocol-port 8080 --weight 2 web_service

5. Create a VIP for the load balancer pool.

   neutron lb-vip-create --name httpserver --protocol-port 80 --protocol HTTP web_service --subnet-id <subnet id>

6. Create the health monitor and associate it with the load balancer pool.

   neutron lb-healthmonitor-create --delay 3 --type HTTP --max-retries 3 --timeout 3

   neutron lb-healthmonitor-associate <nnnnn-nnnnn-nnnn-> web_service

Using the Avi Networks Load Balancer for Contrail

If you are using the Avi LBaaS driver in an OpenStack Contrail environment, there are two possible modes that are mutually-exclusive. The Avi Vantage cloud configuration is exactly the same in both modes:

• Neutron-based Avi LBaaS driver - In this mode, the Avi LBaaS driver derives from Neutron and resides in the Neutron server process. This mode enables coexistence of multiple Neutron LBaaS providers.

• Contrail-based Avi LBaaS driver - In this mode, the Avi LBaaS driver derives from Contrail and resides in the service-monitor process. This mode enables coexistence of multiple Contrail LBaaS providers.

  Note:

  In a Contrail environment, you cannot have a mix of Contrail LBaaS and Neutron LBaaS. You must select a mode that is compatible with the current environment.

• Installing the Avi LBaaS Neutron Driver
• Installing the Avi LBaaS Contrail Driver
• Configuring the Avi Controller