Concepts - Load Balancer
The Public Cloud Load Balancer is built on the OpenStack Octavia project and offers a wide range of configuration options. The goal of this page is to explain the different configuration concepts that are powering the Load Balancer so that you have a high-level understanding of all the features and the associated configuration items.
Load Balancer Configuration concepts
Here are two drawings of two configurations: a simple one that contains the minimum number of concepts to configure a Load Balancer and a more complex one that uses them all. The following information defines each concept used in those configurations.
Listener
The listener specifies a listening endpoint where the incoming traffic is received. Its main attributes are the protocol and the port, for instance, HTTPS and 443. Note that you can have multiple listeners on one Load Balancer.
The following protocols are available for incoming traffic: HTTP, HTTPS, TCP, UDP, and SCTP.
A specific protocol is PROMETHEUS, which enables configuration of a Prometheus endpoint and does not handle traffic itself. This is used to export metrics to Prometheus for monitoring, but it is not used to route application traffic. Find more information about this configuration on this page.
Pool
A pool specifies a group of members to which the listener forwards client requests. A pool is associated with one listener. For complex configuration using L7 Policies, a listener can be associated with multiple pools. The main pool attributes are the load balancing algorithm (e.g., Round Robin) and the protocol that is used to query the members, e.g., HTTPS.
The following protocols are available: HTTP, HTTPS, PROXY, PROXYV2, SCTP, TCP, or UDP.
You can find more information on proxy protocol here.
The following table provides the compatibility matrix between the listener protocol and the pool protocol:
Member
A member represents the configuration for a target back-end server to which the traffic is sent. Its main attributes are its IP (e.g. 192.168.1.10) and a port (e.g. 443). A member is part of a pool.
Health Monitor
The health monitor defines how the load balancer will check the health of the pool members. Its main attributes are the check method (e.g. PING) with various delays and timeouts. It is associated with exactly one pool.
The following Health Monitors are available: HTTP, HTTPS, PING, SCTP, TCP, TLS-HELLO, and UDP-CONNECT.
The following table provides the compatibility matrix between the pool protocol and the Health Monitor type:
L7 rule
An L7 rule is a single logical expression that is used to match a condition present in a given HTTP or terminated HTTPS request. L7 rules typically match against a specific header or part of the URI. An L7 rule is associated with exactly one L7 policy.
For example, an L7 rule can evaluate if a URI begins with “/api”.
L7 policy
An L7 policy associates one or many L7 rules with a listener. Its main attribute is the action that is performed if all the L7 rules evaluation returns true. For example, a user could specify an L7 policy so that any client request that matches the L7 rule “request URI starts with ‘/api’” should get routed to a specific “api” pool.
When a request is received by a listener, the L7 policies are evaluated in the order defined by the position attribute. If the evaluation returns true then the evaluation stops and the L7 policy action is executed. If all L7 policies return false then the request is forwarded to the listener default pool.
Network considerations
Depending on whether your applications are private only, or need to be accessible from the Internet, the Load Balancer will require a Gateway and a Floating IP.
The requirements for the Public Cloud Load Balancer vary, depending on incoming traffic type (private or public) and member IP addresses (private or public). The following chapters show the three different types of architecture the Load Balancer can address. The table below also shows the prerequisites of the network/additional components related to each architecture.
Private to Private Load Balancer
Incoming traffic originates from a private network and is routed to instances accessible from this private network. In this case, a Floating IP or Public Gateway is not needed.
Public to Private Load Balancer
Incoming traffic from the Internet is directed to a Floating IP address associated with the Load Balancer. For this Floating IP to function properly, a Gateway is required: it ensures the routing between the public IP address (Floating IP) and the private IP address of the Load Balancer. The instances behind the Load Balancer are located on a private network and have no public IP, which ensures they remain completely private and isolated from the Internet.
Public to Public Load Balancer
This setup is less common, but can be used when your backends must remain directly accessible from the Internet (for example, for third-party integrations), while still benefiting from a Load Balancer.
Incoming traffic from the Internet is directed to a Floating IP address associated with the Load Balancer. For this Floating IP to function properly, a Gateway is required: it ensures the routing between the public IP address (Floating IP) and the private IP address of the Load Balancer. The instances to which the Load Balancer routes traffic are accessible with a public IP. Hence, the Load Balancer uses the Floating IP with an egress to reach these instances.
Network prerequisites
*: according to the control interface you choose, either those components will be created for you (OVHcloud Control Panel) or you will have to specifically create them (OpenStack CLI, Terraform, or GUI).
Operating and Provisioning status
Two statuses are used for all the Load Balancer concepts. The operating status describes how the component is operating, whereas the provisioning status describes the lifecycle state. The provisioning status is inherited from the components that are "contained" by the father component. For instance, if a member is updated, its provisioning status will change as well as the provisioning status of the pool, the listener, and the load balancer. As such in the description below, when the wording "component" is used, it means the component and all its contained "components".
Provisioning status
The wording is slightly different between OpenStack and OVHcloud. The following table provides both versions for comparison:
Operating status
ONLINE: The component is operating normally, e.g., all pool members are healthy.DRAINING: Applicable to a member of a UDP pool: the member is not accepting new connections, this happens because itsweighthas been set to0.OFFLINE: The status after a disable action or settingadmin_state_uptofalseis done on a component (listener or load balancer). This status is also used during the component creation.DEGRADED/GRADIENT: Applicable to pool & load balancer only. One or more of the contained components are in ERROR. For instance, if a member is inERRORthen the pool and the load balancer are inDEGRADEDas well.ERROR: The component has failed. For instance, the member is considered as failing if its health monitoring fails. A pool is considered as failed if all its members are inERROR.NO_MONITOR: When no health monitor is configured for this pool, the member and the pool will have aNO_MONITORstatus. This has no impact on the listener or the load balancer operating status.
Go further
- An exhaustive technical documentation on the OpenStack project page.
- Configure your first load balancer with this guide.
Browse all the Networking guides.
Browse the rest of the OVHcloud US documentation for guides on our other products and services.
Learn more about Public Cloud Network on the OVHcloud US website.