A load balancer distributes incoming traffic across origin pools to guarantee high availability and reliability. For example, for a large online shopping website, a load balancer can ensure that user requests are evenly distributed across multiple origins, instead of overwhelming a single origin.
Scenarios
Web page: suitable for accelerating websites with dynamic and static resources such as small file transfers and API operations. Examples: personal blog website, small UGC community, small independent e-commerce site.
API operation: suitable for accelerating dynamic API operations. Generally, such operations do not require caching. Examples: account password verification, order payment, log upload, real-time data synchronization API operations.
Images and videos: suitable for accelerating static files services. Examples: large image downloads, online video streaming, game installation packages.
Using a load balancer
Create a load balancer: A load balancer manages and steers incoming traffic among multiple origin pools to ensure high service availability and stability.
Apply the load balancer: Apply your load balancing settings by adding a DNS record that points your domain to the load balancer you configured.
Create a load balancer
With granular traffic steering policies, a load balancer ensures that user requests can be evenly distributed across origin servers.
Step 1: Select origin
Configure multiple origin servers for your website to process user requests. These origin servers can be added to the same origin pool and you can create multiple pools. Create one or more origin pools as origin servers to improve service performance and ensure high availability.
In the ESA console, choose Websites and click the name of the website you want to manage.
In the left-side navigation pane, choose .
On the Load Balancing page, click Create.
In the Select Origin step on the Create Load Balancer page, set the parameters according to the following descriptions.
The following describes parameters for creating a load balance:
Domain Name
The domain name of the load balancer. The domain name can be referenced as the origin of an Edge Security Acceleration (ESA)-covered domain name or a TCP/UDP-proxied application.
Origin Pool
Select an existing origin pool, or create a new one.
A load balancer can have up to 20 origin pools.
You can select only pools that are created for websites on the same plan. For more information, see Create an origin pool.
Order: Pools with smaller ordinal numbers have higher priority. Requests are first sent to the highest priority pool. If that pool is unavailable, the system will try the next pool in order.
Fallback Pool
Requests are sent to the fallback pool if all origin pools in the load balancer are detected unavailable. Origin servers in the fallback pool are always marked healthy, without any health checks applied to them.
Click Next.
Step 2: Configure traffic steering policy
A traffic steering policy determines how traffic is distributed across origin pools. Configure a policy to steer incoming traffic based on the failover order or pool weights.
Select a traffic steering policy.
The following describes parameters for setting up traffic steering policy:
Failover steering
The policy is suitable for scenarios that require high reliability and data consistency.
By default, all requests are diverted to the pool with the highest priority. Requests are routed to a lower-priority pool if the highest-priority pool is unhealthy or disabled.
Weighted steering
The policy is suitable for scenarios where many concurrent requests are involved, and the load must be proportionally distributed to origin pools.
You can assign different weights to your origin pools. ESA steers traffic across the pools based on their weights. The weight ranges from 1 to 100.
A weight of 0 indicates that no requests are sent to the pool.
Geo steering
The policy is suitable for scenarios where Geo steering is based on the originating geographical region or country.
Geo steering allows you to distribute requests across different origin pools based on the country/region. Generally, all origin servers in an origin pool reside in the same country or region. For more information about the regions that support traffic steering policies, see Supported regions.
If you set a secondary region, its priority of the secondary region is higher than that of the primary region.
Arrange the Order of your origin pools.
Optional. Click Advanced Settings, and then enable Session Persistence.
You can enable session persistence in two modes: by Client IP or by Cookie. By default, session persistence is disabled. This feature is suitable for scenarios that require persistence of user sessions.
For example, in an online shopping scenario, consecutive requests from the same user may be distributed across several servers. This can lead to loss of important information, such as logon details and the shopping cart records, which compromises the user experience. Session persistence routes requests from the same client to the same origin server, which ensures a consistent user experience and data integrity.
Select Retry Policy Upon Origin Failure.
If a user request fails to reach an origin server due to network fluctuations or other issues, two origin retry policies are available:
Within the same pool: If the origin request fails, it is routed to another origin server in the same pool. This is the default retry policy.
In another pool: If the origin request fails, it is routed to a healthy origin server in a pool with the next highest priority.
Click Next.
Step 3: Configure probe
You must configure a probe to detect the health status of your origin servers. A load balancer probes the health status of your origin servers by using the ICMP Ping, HTTP, HTTPS, TCP, or UDP ICMP protocol. If the probe fails for the number of times that you specified on an origin, the origin is marked unhealthy.
In the Configure Probe step, select a Protocol.
Set other parameters.
ICMP Ping
The protocol is used to probe the network connectivity of an origin server to determine whether the origin server is reachable.
The following shows ICMP Ping parameters:
Advanced settings
Probe Interval (seconds)
Default value: 60. Valid values: 10 to 3600.
Timeout (Seconds)
Default value: 5. Valid values: 1 to 10.
Health Check
Unhealthy Threshold
The default value is 1, indicating that the health status of the origin server is determined based on a single probe. If you set Unhealthy Threshold to N, a healthy origin server is marked as unhealthy after N consecutive failed probes. Valid values: 1 to 5.
Healthy Threshold
The default value is 1, indicating that the health status of the origin server is determined based on a single probe. If you set Healthy Threshold to N, an unhealthy origin server is marked as healthy after N consecutive successful probes. Valid values: 1 to 5.
HTTP/HTTPS
The protocols are suitable for web applications. They can identify response status codes of HTTP/HTTPS probe requests. The following shows the priority framework for health check configurations:
Configured Host in the monitor: This takes the highest priority. If a Host header is specified in the monitor configuration, the Host header is used for health checks.
Origin server Host: This has the second highest priority. If no Host header is specified in the monitor configuration, the Host header of the origin server is used for health checks.
Load balancer domain name: This serves as a fallback option. If both options are unavailable, the domain name of the load balancer is used for health checks.
The following shows HTTP/HTTPS parameters:
Probe URL Path
The URL path of the HTTP health check. For example,
/health/test.txt. Default value:/.Port
By default, port 80 is used for HTTP and port 443 for HTTPS. Valid values: 1 to 65535.
Advanced settings
Probe Interval (seconds)
Default value: 60. Valid values: 10 to 3600.
Request Method
Default value: GET. Valid values: GET and HEAD.
Timeout (seconds)
The timeout before the probe fails. Default value: 5. Valid values: 1 to 10.
Follow 301/302 Redirects
Specifies whether the probe request follows 301/302 redirects. Turned off by default. If you enable it, the probe request follows 301/302 redirects up to 3 times.
Custom Request Header
You can add up to 10 request headers in a probe request. The default User-Agent header cannot be overridden.
Health Check
Expected Status Code
Default value: 2xx. If the specified status code is returned, the origin server is marked as healthy. You can add multiple status codes or code ranges. Valid values: 100 to 9999. The status code must start with one or more consecutive digits followed by one or more consecutive wildcards "x". Examples: 2xx, 200, 33xx, 222x, and 8888.
Unhealthy Threshold
The default value is 1, indicating that the health status of the origin server is determined based on a single probe. If you set Unhealthy Threshold to N, a healthy origin server is marked as unhealthy after N consecutive failed probes. Valid values: 1 to 5.
Healthy Threshold
The default value is 1, indicating that the health status of the origin server is determined based on a single probe. If you set Healthy Threshold to N, an unhealthy origin server is marked as healthy after N consecutive successful probes. Valid values: 1 to 5.
TCP
The protocol is suitable for TCP-based applications. The origin server status is monitored based on the TCP probe connection.
The following shows TCP parameters:
Port
The port for the TCP probe request.
Advanced settings
Probe Interval (seconds)
Default value: 60. Valid values: 10 to 3600.
Timeout (seconds)
Default value: 5. Valid values: 1 to 10.
Health Check
Unhealthy Threshold
The default value is 1, indicating that the health status of the origin server is determined based on a single probe. If you set Unhealthy Threshold to N, a healthy origin server is marked as unhealthy after N consecutive failed probes. Valid values: 1 to 5.
Healthy Threshold
The default value is 1, indicating that the health status of the origin server is determined based on a single probe. If you set Healthy Threshold to N, an unhealthy origin server is marked as healthy after N consecutive successful probes. Valid values: 1 to 5.
UDP ICMP
The protocol is suitable for UDP-based applications. If the port returns an ICMP Port Unreachable message within the Timeout period, the origin server is marked as unhealthy.
The following shows UDP ICMP parameters:
Port
The port for the UDP probe request.
Advanced settings
Probe Interval (seconds)
Default value: 60. Valid values: 10 to 3600.
Timeout (seconds)
Default value: 5. Valid values: 1 to 10.
Health Check
Unhealthy Threshold
The default value is 1, indicating that the health status of the origin server is determined based on a single probe. If you set Unhealthy Threshold to N, a healthy origin server is marked as unhealthy after N consecutive failed probes. Valid values: 1 to 5.
Healthy Threshold
The default value is 1, indicating that the health status of the origin server is determined based on a single probe. If you set Healthy Threshold to N, an unhealthy origin server is marked as healthy after N consecutive successful probes. Valid values: 1 to 5.
NoteNone (not recommended): No probes are performed. If you do not want ESA POPs to probe your origin servers, select None for Protocol. The health status of the origin servers is not checked, and unhealthy servers cannot be brought offline right away, which may lead to reduced service availability. We recommend that you enable active probing to ensure your business availability.
Click Next.
Step 4: Configure custom rule
If you need to optimize traffic distribution based on your business requirements, such as security-sensitive operations for financial transactions, create a rule to directly route traffic to the origin pool with the highest priority. Specify fields such as Client IP and Header in your custom rules to match requests for traffic steering.
On the page that appears, specify the Rule Name.
Specify If requests match in the Rule Content section. For setting up rules, see Work with rules.
Select Respond with Specified Content or Override in the Then execute... section, and then click OK.
On the page that appears, click Next.
Step 5: Review
Review and verify the parameters that the Review section displays. After you confirm the parameters are correct, click OK.
Apply the load balancer
After the load balancer is created, you must add DNS records for configuration. A unified access point for the site enhances availability and security, and simplifies operational management.
In the ESA console, choose Websites and click the name of the website you want to manage.
In the left-side navigation pane, choose .
On the Records page, click Add Record. On the page that appears, set Record Value to Load Balancer, and then specify the Load Balancer that you created.
Configure other parameters as needed, click Next, select a scenario, then click OK.
