Working with application load balancer pools

The IBM Cloud® Application Load Balancer for VPC (ALB) pool is a group of back-end targets that receive the inbound traffic from the load balancer and provide your outbound traffic response. The pool includes a protocol, a load-balancing algorithm, back-end targets (VPC instances), health checks for the back-end targets, and session stickiness.

In a load balancer configuration, a listener is considered the parent resource. You can associate pools with that listener in two ways, by referencing them directly or indirectly. For direct association, configure the pool as the listener’s default_pool. For indirect association, reference the pool from another pool through a failsafe_policy.target relationship, ensuring that the other pool is already linked to the listener.

The following conditions apply to all application load balancer pools:

• You can associate multiple pools with a listener when secondary pools are configured as failsafe_policy.target.
• Duplicate pool assignments are not allowed; each pool must be unique per listener.
• This feature is available only for Application family load balancers.
• When you use a failsafe_policy.target, the protocol must match the primary pool protocol or use an allowed compatible protocol. Currently, only http and https are considered compatible.

You can configure pools when creating a application load balancer, or later with the following procedure:

1. From your browser, open the IBM Cloud console and log in to your account.

2. Select the Navigation menu , then click Infrastructure > Network > Load balancers.

3. Click the application load balancer that you want to modify.

4. On the application load balancer's details page, click the Back-end pools tab, and then select the pool that you want to edit.

5. Configure the following options for your pool:

   • Pool Name: The name for your pool. Ideally, a name that describes the function that is performed by this pool.
   • Protocol: Select the protocol for your instances in this pool. The protocol of the pool must match the protocol of its associated listener. For example, if the listener uses HTTP, the pool must also use HTTP. Similarly, if the listener uses TCP, the pool must also use TCP.

   HTTP sends data as plain text that can be intercepted and is considered insecure. It is recommended to choose protocol as https instead of http. For more details see: https://www.cloudflare.com/learning/ssl/why-is-http-not-secure/

   • Method: Select how the load balancer distributes traffic across the instances in the pool:
     • Round robin: Forward requests to each instance in turn. All instances receive approximately an equal number of client connections.
     • Weighted round robin: Forward requests to each instance in proportion to its assigned weight. For example, you have instances A, B, and C, and their weights are set to 60, 60 and 30. Instances A and B receive an equal number of connections, and instance C receives half as many connections.
     • Least connections: Forward requests to the instance with the least number of connections at the current time.
   • Session stickiness: Select Whether all requests during a user's session are sent to the same instance.
   • Health check: Configure how the load balancer checks the health of the instances. For information about configuring health checks, see Working with health checks.

6. Select Request settings (optional) for your health checks. If you do not specify values, the default health check settings are used. The following options are available:

   • Request Method: Choose one of GET or POST. You can customize Request headers for both methods. You can optionally customize a Request body when you use the POST method.
   • Request Body: Specify the HTTP request body to use for health checks. If no value is specified, health check requests do not include a request body.
   • Host header: Include host header to ensure that the request uses HTTP/1.1 protocol. Otherwise, the system defaults to HTTP/1.0.
   • Add other request headers: Add one or more additional request headers.
     • Header name: For GET request method, choose one of content-type, accept, authorization, cookie, origin, referrer, or user-agent. For POST request method, choose one of content-type, content-length, application-json, or accept-encoding.
     • Value: Enter the value that corresponds to the specified Header name.

7. Select Response settings (optional) for your health checks. Customize successful response values during health checks. If you do not specify values, the default health check settings are used. The following options are available:

   • Response body: Enter response body text.
   • Response code: You can specify multiple comma separated values within the range of 100-599. To specify a range, use XX. For example, 2XX matches response in the range 200-299.

8. To add a backup pool to an existing pool, configure a failsafe policy. Ensure that at least one other pool already exists in the load balancer.

   • Action: The action to perform when the primary pool becomes unhealthy. When you edit a back-end pool in a load balancer, you can specify one of the following failsafe policy actions:
     • Forward: - The load balancer routes requests to a designated backup pool. This action provides a clean failover path to another set of application servers. You must have an existing backup pool configured and ready to receive traffic.
     • Drop: - The load balancer drops all incoming requests, and the client receives no response.
     • Fail: - The load balancer rejects requests with an HTTP 503 ("Service Unavailable") status code, informing the client that the service is temporarily down.
   • Target: The selection of the backup pool is done here. If you specify a target pool, then the action value must be forward

If instances in the pool are unhealthy and your application is running fine, verify the health protocol and health path values. Also verify that any security groups attached to the instances allow traffic between the load balancer and the instances.