OpenStack Endpoint Load Balancer¶

To enable Openstack services for a single cloud to be installed in a highly available configuration without requiring that each unit of a service is in the same broadcast domain.

Problem Description¶

As a cloud administrator I would like to simplify my deployment so that I don’t have to manage a corosync and pacemaker per OpenStack API service.
As a cloud architect I am designing a new cloud where all services will be in a single broadcast domain. I see no need to use the new central loadbalancer and would like to continue to have each service manage its own VIP.
As a cloud architect I would like to spread my control plane across N racks for redundancy. Each rack is in its own broadcast domain. I do not want the users of the cloud to require knowledge of this topology. I want the endpoints registered in Keystone to work regardless of a rack level failure. I am using network spaces to segregate traffic in my cloud and the OpenStack loadbalancer has access to all spaces so I only require one set of loadbalancers for the deployment.
As a cloud architect I would like to spread my control plane across N racks for redundancy. Each rack is in its own broadcast domain. I do not want the users of the cloud to require knowledge of this topology. I want the endpoints registered in Keystone to work regardless of a rack level failure. I am using network spaces to segregate traffic in my cloud. I want the segregation to extend to the load balancers and so will be requiring a set of load balancers per network space.
As a cloud architect I am designing a new internal cloud and have no interest in IPv6, I wish to deploy a pure IPv4 solution.
As a cloud architect I am designing a new cloud. I appreciate that it has been 18 years since the IETF brought us IPv6 and feel it maybe time to enable IPv6 within the cloud. I am happy to have some IPv4 where needed and am looking to deploy a dual stack IPv4 and IPv6.
As a cloud architect I am designing a new cloud. I appreciate that it has been 18 years since the IETF brought us IPv6 and wish to never see an IPv4 address again. I am looking to deploy a pure IPv6 cloud.
As a cloud architect I wish to use DNS HA in conjunction with the OpenStack loadbalancer so that loadbalancer units can be spread across different subnets within each network space.
As a cloud administrator I would like to have the OpenStack load balancers look after HA and so will be deploying in an Active/Passive deployment. I will need to use a VIP for the loadbalancer in this configuration.
As a cloud architect I have an existing hardware loadbalancers I wish to use. I do not want to have to update it with the location of each API service backend. Instead I would like to have the OpenStack load balancers in an Active/Active configuration and have the hardware loadbalancers manager traffic between haproxy instance in the OpenStack loadbalancer service. I do not need to use a VIP for the loadbalancer in this configuration. My hardware loadbalancers utilise vip(s) which will need to be registered as the endpoints for services in Keystone.
As a cloud administrator haproxy statistics are fascinating to me and I want the statistics from all haproxy instances to be aggregated.
As a cloud administrator I would like haproxy to be able to perform health checks on the backends which assert the health of a service more conclusively than simple open port checking.
As a cloud administrator I want to be able to configure max connections and timeouts as my cloud evolves.
As a charm author of a service which is behind the OpenStack load balancer I would like the ability to tell the loadbalancer to drain connection to a specific unit and take it out of service. This will allow the unit to go into maintenance mode.

Proposed Change¶

New interface: openstack-api-endpoints¶

This interface allows a backend charm hosting API endpoints to inform the OpenStack loadbalancer which services it’s hosting and on which IP address and port frontend API requests should be sent to on the backend unit. It also allows the backend charm to inform the loadbalancer which frontend port should be used for each service.

Example - neutron-api (single API endpoint per unit):

endpoints:
  - service-type: network
    frontend-port: 9696
    backend-port: 9689
    backend-ip: 10.10.10.1
    check-type: http

Example - nova-cloud-controller (multiple API endpoints per unit):

endpoints:
  - service-type: nova
    frontend-port: 8774
    backend-port: 8764
    backend-ip: 10.10.10.2
    check-type: http
  - service-type: nova-placement
    frontend-port: 8778
    backend-port: 8768
    backend-ip: 10.10.10.2
    check-type: http

A single instance of the OpenStack Loadbalancer application will only service a single type of OpenStack API endpoint (public, admin or internal). The charm will use the network space binding of the frontend interface to determine which IP or VIP (if deployed in HA configuration) should be used by the backend API service for registration into the Cloud endpoint catalog.

Having processed the requests from all backend units, the loadbalancer now needs to tell the backend application the external IP being used to listen for connections for each endpoint service type:

endpoints:
  - service-type: nova
    frontend-ip: 98.34.12.1
    frontend-port: 8774
  - service-type: nova-placement
    frontend-ip: 98.34.12.1
    frontend-port: 8778

The backend service now updates the endpoints in the Keystone registry to point at the IPs passed back by the loadbalancer.

This interface is provided by each backend API charm and consumed via the backend interface on the OpenStack loadbalancer charm. Each backend charm would provide three instances of this interface type:

provides:
  public-backend:
    interface: openstack-api-endpoints
  admin-backend:
    interface: openstack-api-endpoints
  internal-backend:
    interface: openstack-api-endpoints

Taking this approach means that the backend charm can continue to be the entry point/loadbalancer for some endpoint types, and push the loadbalancing for other entry points out to the OpenStack Loadbalancer charm (or multiple instances).

Updates to keystone endpoint calculation code¶

Currently the following competing options are used to calculate which EP should be registered in Keystone:

os-*-network set do resolve_address old method
dnsha use dnsha
os-*-hostname set use hostname
juju network space binding via extra-bindings
prefer ipv6 via configuration option
presence of {public,internal,admin}-backend relations to openstack loadbalancers

OpenStack Loadbalancer charm¶

New charm - OpenStack Loadbalancer - with corresponding tests & QA CI/setup.

Alternatives¶

Extend existing HAProxy charm.
Use DNS HA.

Implementation¶

Assignee(s)¶

Primary assignee:: unknown

Gerrit Topic¶

Use Gerrit topic “osbalancer” for all patches related to this spec.

git-review -t osbalancer

Work Items¶

Provide OpenStack Loadbalancer Charm¶

Write draft interface for LB <-> Backend
Write unit tests for Keystone endpoint registration code
Write Keystone endpoint registration code

Mojo specification deploying and testing Mistral¶

Write Mojo spec for deploying LB in an HA configuration

Repositories¶

A new git repository will be required for the Mistral charm:

https://git.openstack.org/openstack/charm-openstack-loadbalancer

Documentation¶

The OpenStack Loadbalancer charm should contain a README with instructions on deploying the charm. A blog post is optional but would be a useful addition.

Security¶

No additional security concerns.

Testing¶

Code changes will be covered by unit tests; functional testing will be done using a combination of Amulet, Bundle tester and Mojo specification.

Dependencies¶

None

OpenStack Endpoint Load Balancer