Introduction

Sticky Session Overview

Sticky sessions enable a load balancer to consistently route requests from the same client to the same backend target (server or server group) instead of distributing them evenly across multiple targets. For example, routing a client's requests to the same server allows the server to maintain session state. If the requests of the client are distributed to two different servers, each server may lose key information on the other server.

Therefore, it is usually necessary to maintain consistent client connections through a load balancer. Huawei Cloud ELB supports two types of sticky session policies:

• Sticky sessions: Backend servers maintain local session data, simplifying the application architecture or improving application performance because the servers can maintain or cache session state information locally. Huawei Cloud provides three types of sticky sessions: source IP address, load balancer cookie, and application cookie.
• Sticky sessions between backend server groups: In scenarios such as blue-green deployments, multiple versions of an application may be deployed, and the client is expected to continue using the same version of the application during a session. To achieve this, sticky sessions can route all requests from a client to the same backend server group rather than to the same backend server.

These two policies can be used independently or together.

Load Balancer Subnets and Routing

1. Internet traffic reaches the load balancer through its EIP or domain name.
2. The load balancer is associated with a VPC subnet and routes traffic to a backend server in a backend server group based on the configured load balancing algorithm.
3. The load balancer routes the traffic to the backend ECS. (For application load balancers, you may need to configure forwarding policies.)
4. The route table routes traffic within the VPC, between the load balancer subnet and the backend server subnet, and then to the ECS.
5. The ECS returns the outbound traffic to the load balancer based on the route table along the original path.
6. The load balancer routes the traffic out through its public network interface and returns it to the Internet through the internet gateway.

How Do I Select a Proper Sticky Session Policy?

Answering the following questions will help you determine your sticky session policy:

1. Question 1: Are you using WebSockets?
   • Yes: WebSockets are inherently sticky, so you do not need to use any sticky session policy.
   • No: Continue to the next question.

2. Question 2: Are you planning a blue-green deployment (where requests from the same client need to be continuously routed to the same backend server group)?
   • Yes: At the minimum, use sticky sessions between backend server groups and continue to the next question.
   • No: Continue to the next question.

3. Question 3: Do you need to route some or all traffic from a client to the same backend server repeatedly?
   • Yes: Continue to the next question.
   • No: You do not need to enable sticky sessions.

4. Question 4: Are you using a Layer 4 protocol (TCP/UDP) or a Layer 7 protocol (HTTP/HTTPS/gRPC)?
   • Layer 4 protocol: Use sticky sessions of the source IP address type.
   • Layer 7 protocol: Continue to the next question.

5. Question 5: Do you want your backend application or client cookie to control the sticky session status and duration?
   • Yes: Use sticky sessions of the application cookie type.
   • No: Use sticky sessions of the load balancer cookie type.

Sticky Sessions Not Used

If sticky sessions are not enabled for a load balancer, the load balancing algorithm (such as weighted round robin) configured by the customer is used by default to distribute requests to different backend servers.