Listeners, pools, members, and health monitors
Understand the parts of a load balancer, the protocols, algorithms, and settings each one accepts, and what the provisioning and operating statuses mean.
A load balancer receives traffic on its VIP and passes it on to your servers. It's made of four kinds of parts: listeners take the traffic in, pools spread it across members, members receive it, and health monitors check the members. Each part has its own settings and its own status.
Load balancer and VIP
The load balancer is the object that owns the VIP, the listeners, and the pools. It belongs to one project and runs in the project's region.
VIP. The VIP is an address in a subnet of one of the project's networks. When you create the load balancer, you choose the subnet and either leave the address to the platform or set it yourself. A fixed address must be inside the subnet's range, and it can't be the subnet's gateway, network, or broadcast address. It can be outside the subnet's allocation pool. The subnet and the address can't be changed after creation.
Size
The size is lb.small, lb.standard, or lb.large. The platform looks for a load balancer flavor with the same name in the region and uses it when the region defines one. When the region has no flavor with that name, the load balancer uses the region's default, whichever size you chose. The size doesn't change the hourly rate, and it can't be changed after creation.
Listeners
A listener accepts traffic for one protocol on one port of the VIP and hands it to its default pool.
| Protocol | What it takes |
|---|---|
| HTTP | HTTP traffic. |
| HTTPS | HTTPS traffic. The console doesn't ask for a certificate for this protocol. |
| TCP | TCP connections. |
| TERMINATED_HTTPS | HTTPS traffic that ends at the load balancer, which needs a TLS certificate. |
Important
You can't create a TERMINATED_HTTPS listener in the console.
- Port. Each listener on a load balancer needs its own port.
- Connection limit. The default is 20,000. You can change it later.
- Default pool. The pool that receives the listener's traffic. The wizard connects its listener to its pool. For a listener that you add later, see Connect a listener to a pool.
A listener's protocol and port can't be changed after it's created. To use another protocol or port, add a new listener, connect it to a pool, and delete the old one.
Pools
A pool is a group of members that share one protocol and one balancing algorithm. Its protocol is the one the load balancer uses to reach the members: HTTP, HTTPS, TCP, or PROXY. A pool's protocol can't be changed after it's created.
Listener and pool protocols
A listener can only hand traffic to a pool whose protocol fits its own. If the load balancing service refuses the pair, the load balancer goes to Error, and its Activity tab shows the reason. Delete it, and create a new one with a pair that the service accepts.
An HTTP listener with an HTTP pool is a pair that the service accepts. Load Balancers runs on OpenStack Octavia, which defines every pair it accepts; see the listener and pool protocol combinations in the Octavia API reference.
Balancing algorithms
| Algorithm | Value in the API | How it spreads traffic |
|---|---|---|
| Round robin | ROUND_ROBIN | Members take turns. |
| Least connections | LEAST_CONNECTIONS | Each new connection goes to the member with the fewest active connections. |
| Source IP | SOURCE_IP | Connections from the same client IP address go to the same member. |
You can change a pool's algorithm later.
Session persistence
Session persistence keeps a client on the same member.
| Option | What it uses |
|---|---|
| None | No persistence. |
SOURCE_IP | The client's IP address. |
HTTP_COOKIE | A cookie that the load balancer sets. |
Use SOURCE_IP or HTTP_COOKIE. You set it on the wizard's Pool step or later by editing the pool. A pool that you add on the load balancer's page starts without persistence.
Members
A member, shown as a target on the load balancer's page, is an IP address and a port that receives traffic from a pool.
- Address. In the wizard, select one of the project's servers, and the console fills in its fixed IP address, or its Floating IP when it has no fixed IP address. You can also enter any address. On the load balancer's page, you always enter the address.
- Port. The default is 8080.
- Weight. The default is 1. You can set it in the wizard. Targets that you add on the load balancer's page get a weight of 1.
- Role. The Role column shows Primary or Backup. Members that you add in the console are primary members.
The wizard names its members member-1, member-2, and so on. A pool can't contain the same address and port twice.
Health monitors
A health monitor probes the members of one pool, and a pool has at most one. When a load balancer has no health monitor at all, its Health monitors tab says: No health monitors configured. Targets are not actively checked.
| Field | Rules |
|---|---|
| Monitor type | HTTP, HTTPS, TCP, or PING. Can't be changed after the monitor is created. |
| Delay (s) | The interval between probes, in seconds. |
| Timeout (s) | How long a probe waits, in seconds. |
| Max retries | A whole number. |
| URL path | HTTP and HTTPS monitors only. |
| Expected codes | HTTP and HTTPS monitors only. The HTTP status codes that count as healthy. |
For the values that the wizard starts with, see Health monitor. In the console, you attach a health monitor when you create the load balancer. After that, you change monitors with the REST API; see Change health monitors.
Statuses
A load balancer carries two statuses: the provisioning status says where it is in its lifecycle, and the operating status says how it was working when the platform last recorded it. Listeners, pools, members, and health monitors carry an operating status too.
Provisioning status
| Status | What it means |
|---|---|
| Pending create | The platform is building the load balancer. Changes to its listeners, pools, and health monitors, new targets, and deletion are refused until it's done. |
| Active | The load balancer is built and accepts changes. |
| Pending delete | The platform is deleting the load balancer. If the service doesn't confirm the deletion, the load balancer stays in this state while the platform retries. |
| Error | The build failed or was canceled, or the load balancing service reports the load balancer in error. Changes to its listeners, pools, and health monitors, and new targets, are refused. Delete it, and create a new one. |
The list's filters group Pending create and Pending delete under Provisioning.
Operating status
The operating status is Online, Degraded, Offline, Error, or No monitor. The targets of a pool without a health monitor show No monitor. On the Overview tab, Healthy targets counts the members that are Online.
When statuses change
The platform records the statuses when it finishes an operation on the load balancer, such as creating it or adding a listener, a pool, or a target. It also reads the project's load balancers from the load balancing service at regular intervals and records what the service reports: the statuses, and the listeners, pools, members, and health monitors as they exist there. A load balancer whose provisioning status is pending is left alone until it settles.
Between two reads, the Health column shows each member's status as last recorded, so a member that stops responding shows the change after the next read. Refresh reloads the load balancer's record from the platform; it doesn't make the platform read the load balancing service.