Balance traffic across multiple origins
Spread the requests of an application across several origin addresses with a Load Balancer connector and a Rules Engine rule that sets it.
You can spread the requests of an application across several origin servers by enabling Load Balancer on a connector. A Rules Engine rule then sends the requests to that connector, and Load Balancer distributes them among its addresses with a balancing algorithm. To connect an application to a single origin, refer to Connect an application to an origin.
An account that has not migrated to API v4 configures load balancing in the legacy Origins of the application. For more information, refer to Origins.
Choose the interface you work in. The prerequisites and the procedures change with your choice.
Prerequisites
- An application served by a workload. To create both, refer to Applications quickstart.
- Two or more origin servers that hold the same content and are set up the same way for the application.
- Access to Azion Console. To sign in, refer to Access Azion Console.
Plan the addresses
The example on this page balances three origin servers. Each one is hosted with a different storage provider or cloud service, because server outages rarely occur at the same time. All three hold the same content and are set up the same way for the application. Two of them share the traffic, and the third stands by for maintenance and traffic surges.
| Address | Server | Load capacity | Weight | Server role | Active |
|---|---|---|---|---|---|
example.com | Primary | High | 3 | primary | Always |
example.net | Secondary | Medium, enough for large surges of traffic | 2 | primary | Always |
example.org | Backup | Low | 1, the default when the weight is left blank | backup | Only during maintenance or a traffic surge |
The weight follows the load capacity of each server. Both example.com and example.net are primary, and the higher weight makes example.com the preferred address for connections. example.org stays inactive until maintenance or a surge needs it. For how the weight, the server role, and the active state distribute requests, refer to Load Balancer.
Create a connector with Load Balancer
Load Balancer belongs to the connector, under attributes.modules in the API. A connector created without Load Balancer keeps it disabled until you enable Load Balancer on the connector. This is the attributes.modules object of an HTTP connector the API created with no load balancing:
To balance the three addresses of the example with the Round-Robin algorithm, the connector carries these values. Each key is under attributes:
| Key | Value in the example |
|---|---|
type | http |
modules.load_balancer.enabled | true |
modules.load_balancer.config.method | round_robin |
modules.load_balancer.config.max_retries | 0 |
modules.load_balancer.config.connection_timeout | 60 |
modules.load_balancer.config.read_write_timeout | 120 |
addresses[].address | example.com, example.net, and example.org |
addresses[].modules.load_balancer.weight | 3, 2, and 1 |
addresses[].modules.load_balancer.server_role | primary, primary, and backup |
addresses[].active | true, true, and false |
connection_options.transport_policy | preserve |
connection_options.host | ${host}, which forwards the Host header of the user’s request |
In Azion Console, you set up connectors in the Connectors menu, not in a tab of the application. For each field, refer to Load Balancer and Connector settings.
To create the connector with the API, send the values of the table in a POST request to /v4/workspace/connectors. Copy the ID of the connector, which the API returns in data.id. The rule that sends requests to the connector names it by this ID.
Send requests to the connector
A connector receives no request until a rule sets it. The rule in this section runs in the Request Phase of the application. Its criterion matches every path, with the ${uri} variable, the starts_with operator, and / as the argument, so the connector serves the whole application. Its behavior sets the connector.
The ${uri} variable works on every application. A criterion on ${request_uri} needs Application Accelerator on the application. For every variable and operator, refer to Rules Engine for Applications.
To create the rule with the API, send a POST request to the request_rules endpoint of the application. Replace <application-id> with the ID of your application, and <connector-id> with the ID of the connector:
The API answers 202 and returns the rule:
The rule is the first of the application’s Request Phase, at order 0.
For the behavior and its attributes, refer to Set Connector.
Confirm that the application answers
The rule takes a few minutes to propagate. Until then, the application answers as it did before the rule existed.
To confirm the route, send a request to the domain of your workload, with that domain in place of <your-workload-domain>:
The response comes from one of the active addresses of the connector. A workload’s domain ends in .map.azionedge.net, and the API returns it in workload_domain when it creates the workload. If the response does not come from your origin servers yet, send the request again until it does. If it never does, refer to Troubleshoot Applications.