Overview
Application Load Balancer (ALB) distributes incoming application layer traffic to targets based on user-defined policies. Each load balancer is defined by a Listener, which processes forwarding rules and routes traffic to targets. Targets are selected via the round-robin method.
Unlike Network Load Balancer (NLB), which operates at Layer 4 of the OSI model, ALB operates at Layer 7. If your balancing logic needs to process HTTP requests and their attributes, use ALB. If routing performance is critical, limit the logic to Level 4 and route TCP traffic using NLB.
ALB can be used in two ways:
Public load balancing: The Listener is open and accepts client connections directly from the Internet. ALB serves as an edge device that handles north-south traffic in and out of the data center.
Private load balancing: The Listener is on a private network and handles east-west traffic inside the data center.
Features
Advanced Routing: ALB supports a wide range of advanced routing options when it comes to configuring Forwarding Rules. Routing for incoming requests can be based on the HTTP method, HTTP header, hostname, path, or a query string parameter. This is not limited to request forwarding based on a load balancing algorithm.
Supported protocols: HTTP
Available ports: 1 - 65,535
Fixed Response: It is also not always unavoidable to forward traffic only to preconfigured targets. ALB can be configured to return a fixed response or redirect to another host. This is a very convenient option for customers who wish to avoid setting up a separate machine to perform such trivial tasks.
Health Checks: ALB also carries out periodical checks which monitor registered targets before redirecting traffic to them. This feature is optional, but it improves the overall performance and makes the entire architecture redundant and highly available.
Flow Logs: This feature allows you to capture data related to IPv4 network traffic flows. They can help with monitoring, debugging and logging data. Flow logs are stored in an IONOS S3 Object Storage bucket.
High Availability: This feature refers to the ability of the application load balancer to handle increased traffic and provide reliable and consistent performance, even in the event of a single component failure. It ensures that the service is always available, even in the case of component failures or maintenance.
Architecture
Each ALB requires at least one Listener, a Forwarding Rule and a Target Group. A Listener is a process that checks for connection requests, using the protocol and port that you configure. Each Listener is defined by Forwarding Rules, which determine how ALB routes requests to its registered targets inside of Target Groups.
Listener
The Listener accepts connections from clients through a public IP address (primary IPv4) and a configured port. This process can also listen for additional IP addresses. Listener IP addresses can be private (for the local network) or public (available on the Internet).
Public IP Listener: A public IP address is required for an ALB connected to the Internet.
Note: Public IP addresses must be reserved in advance. Learn how.
Private IP Listener: No input is required to assign the first (primary) listener IP address. The listener's private primary IP address will be assigned automatically during provisioning.
You can configure each Listener by defining specific Forwarding Rules. The rules you set determine how ALB routes requests to its registered targets. Each rule consists of a priority, one or more actions, and one or more conditions. There must be a default rule action, so if none of the other conditions of the rule are met, the action for the default rule is executed. The default rule is evaluated last.
Tutorial: Listeners can be configured from the Forwarding Rules tab in the Inspector.
Target Group
A target group is a set of one or more registered targets. For each target, you must specify an IP address, port number and weight. Any object with an IP address in your VDC can be a target, such as a VM, another load balancer, etc.
You may create multiple target groups for convenience and reuse them to configure different ALB forwarding rules. You can register the same target with multiple target groups.
Tutorial: Targets can be configured from the Target Group Manager in the DCD
Health Checks
A Health Check is a periodical query to a registered target to test its current status. Checks are performed to ensure that traffic is only forwarded to active and healthy targets.
Note: All health check-related metrics are configurable from the Target Group Manager.
TCP Health Check: This check attempts to establish a TCP connection on the configured backend port. Targets are polled at regular intervals. If the target does not respond, the health check fails, and the target is removed from the balancing rotation. If the target resumes responding, it is included in the rotation again.
HTTP Health Check: ALB periodically sends HTTP requests to registered targets to check their status.
Health Check Properties
You can set up Health Checks for each registered Target Group. Although Health Check settings are properties of Target Groups, it is the ALB that performs them once the Target Group is bound to the Forwarding Rule. Health Checks have three parameters that are configurable by users: Retries, Check Timeout, and Check Interval.
Check Timeout is the amount of time the ALB waits for a TCP connection to open. This value depends on the type of health checks used. The Check Timeout for the ALB HTTP health check actually sets two timeouts: the timeout to open a TCP connection to the target, and the timeout to receive an HTTP response from the target after the TCP connection is established.
Check Interval is the time in ms that the ALB waits after a health check is completed and before sending the next one. If the check interval is less than the check timeout, then the check timeout is equal to the check interval.
How are Health Checks Conducted?
Health Checks are synchronous; the next check only starts after the previous ones have been completed. This means that the time between the start of two checks can be divided into two consecutive phases: Check Duration and Check Interval. The Check Interval phase always starts only after the end of the Check Duration phase. The Check Duration phase ends if either the expected response is received from the target within the check timeout period, or if the Check Timeout is reached.
Thus, the check duration depends on the performance of the target and may vary over time. This means that depending on the target state, the frequency of checks may change over time.
For ALB, the check duration is limited by the Check Timeout parameter. For TCP health checks, the maximum check duration is equal to the check timeout. For HTTP health checks, the maximum possible check duration is twice the check timeout - one timeout to open a TCP connection and one timeout to receive an HTTP response from the target.
Maintenance Window
The Managed Application Load Balancer will be regularly maintained by IONOS and updated with the latest software versions and new features. IONOS reserves a weekly maintenance window which it can use for regular updates. It is scheduled every Monday between 02:00 - 04:00 am local time of the data center in which the Managed Application Load Balancer service is deployed. During maintenance, a service interruption of up to 5 seconds may occur. Aside from that service interruption, no further service impact is anticipated, and the Managed Application Load Balancer will continue to operate within its service description and configuration.
Additional update deployments may be possible and carried out outside the maintenance window, for example, in the case of urgent security patches.
Limitations
Each Application Load Balancer must have at least one Listener and supports up to 10 Listeners.
ALB is not configured to support Source NAT (SNAT). Therefore, targets cannot initiate network connections through the load balancer.
Last updated