Nova nodes use Backends to discover which servers to route traffic to once processed. In its simplest form, a Backend is one or more IP addresses that Nova load balances to. These can also be discovered in more advanced ways.

Interface Example


Simple Backend

The default Backend type for many Nova deployments, the Simple Backend is a list of IP addresses and ports to route traffic from a Nova. With the example of a webserver, this is effectively a list as below:

You can also specify Weights and Primary/Backup servers on Simple Backends, to tailor your routing to what works best for your application.

DNS-resolved Backend

DNS-resolved Backends allow you to use hostnames or DNS names to resolve Backend servers. The main difference between this Backend and using a hostname in the Simple Backend is the lifetime of the result. In AWS, Azure, and other use cases the IP address of a hostname may change - and this backend mode makes the ADC recheck the DNS name every health check interval.

This allows for dynamic backends in your configuration. The other options from the Simple Backend still apply, with an example below:

You will also configure resolvers for this backend, where you specify which DNS servers to use in order to perform the lookups. Note that in cloud environments you must use the appropriate ones to have internal traffic routing.

You can configure the number of seconds to cache replies for, allowing you to set a TTL (Time To Live).

Cloud API Backend

Cloud API backends vary by the cloud provider but the general idea is to use an API to discover which servers to send traffic to, as opposed to IP addresses or hostnames. An example of this is in Amazon AWS. If you have autoscaling enabled for a set of servers they may scale up or scale down and the ADC will not know of the change in servers. With Nova you can instead direct traffic to an AWS AMI ID. This means it will automatically discover any servers and dynamically adjust your routing as you scale.

AWSBased on AMI ID.
Microsoft AzureBased on attached tags
Google CloudBased on attached tags
DigitalOceanBased on attached tags
LinodeBased on attached tags

Service Discovery Backend

Service discovery is typically an API to a platform like Docker in order to discover the backends. We support using SRV records, which are common on platforms like Kubernetes. An example record follows: TTL class SRV priority weight port target

Where the description of the fields is as follows:

  • _service: standard network service name (taken from /etc/services) or a port number
  • _proto: standard protocol name (“tcp” or “udp”)
  • name: name of the service — the name used in the query
  • TTL: validity period for the response (this field is ignored by Nova as Nova maintains its own expiry data which is defined in the configuration)
  • class: DNS class (“IN”)
  • SRV: DNS record type (“SRV”)
  • priority: priority of the target host. Lower value = higher preference
  • weight: relative weight in case of records with the same priority. Higher number = higher preference
  • port: port on which the service is configured
  • target: canonical hostname of the machine providing the service, ending in a dot

You can see an example of this below:

$ dig -t srv


;; ANSWER SECTION: 30 IN SRV 10 25 8080 30 IN SRV 10 25 8080 30 IN SRV 10 25 8080 30 IN SRV 10 25 8080


Using this system you can have Docker Swarm, Kubernetes, Consul, Rancher and others automatically inform the ADC about which systems are online for a given Backend.

Redirect Backend

A redirect backend always sends an HTTP location redirect back to any clients that arrive at it. Redirects can be done in Nova Rules, but this backend can be useful when doing hostname based routing.