This topic introduces failover steering, geo steering, and weighted steering policies. You can select a traffic steering policy that fits your business scenario.
Policy types
Two common traffic steering policies are failover steering and weighted steering. Failover steering involves designating one server as the primary server that handles all requests and placing one or more secondary servers in standby mode. Weighted steering involves distributing requests among multiple servers based on assigned weights.
Failover steering
If your business requires high reliability and data consistency, we recommend that you select the failover steering policy.
This is the default traffic steering policy. You can specify priorities for origin pools. By default, all requests are scheduled to the origin pool that has the highest priority. If the origin pool with the highest priority is abnormal or disabled, requests are rerouted to the next available healthy pool with lower priority.
Weighted steering
For handling high concurrency and evenly distributing loads across multiple server clusters, we recommend that you use the weighted steering policy.
You can specify weights for origin pools. Weights range from 0.01 to 1.00, which correspond to the percentage of requests that you want to allocate to each origin pool. Edge Security Acceleration (ESA) schedules a proportion of user requests to different origin pools based on the defined weights.
Setting an origin pool's weight to 0 means it will not receive any traffic.
Geo steering
Geo steering is designed for scenarios requiring international or regional traffic distribution. The policy enables routing to specific origin pools based on the user's geographic location, supporting both region and subregion settings.
Traffic can be steered to various origin pools depending on the user's location, usually with servers in a pool located within the same country or region. For more information, see Supported regions.
When a subregion is specified, it takes precedence over the region.
Advanced settings
Session persistence
Feature introduction
By default, session persistence is disabled. This feature is suitable for scenarios that require persistence of user sessions.
Scenario
For example, in an online shopping scenario, consecutive requests from the same user may be distributed across different servers. This can lead to loss of important information, such as the logon information of the user and the information about items in the shopping cart, which would compromise the user's shopping experience.
Solution
After you enable session persistence, requests from the same client are routed to the same origin server. This ensures a consistent user experience and data integrity.
Retry
If a user request fails to reach an origin server due to network fluctuations or other issues, two origin retry policies are available:
Retry within an origin pool: This is the default retry policy. If the origin request fails, the system selects another origin server from the same origin pool to retry the request.
Retry across origin pools: If the origin request fails, the system connects to the origin pool with the next highest priority and selects a healthy origin server from the pool to retry the request.