How can I troubleshoot the Classic Load Balancer session stickiness feature?

Lesedauer: 5 Minute
0

I have a Classic Load Balancer with duration-based or application-controlled session stickiness. The load balancer is configured to route client HTTP or HTTPS sessions to the same registered instance. However, client requests are routed to different registered instances.

Short description

By default, a Classic Load Balancer routes each request to the registered instance with the fewest outstanding requests. Use sticky sessions (session affinity) to configure a load balancer to bind user sessions to a specific instance. All requests from a user during a session are sent to the same instance.

A load balancer sticky session fails for the following reasons:

  • The registered instance doesn't insert an application cookie.
  • The client doesn't return the cookies in the request header.
  • The registered instance inserts an incorrectly formatted cookie.
  • The HTTP or HTTPS request passes through more than one load balancer with stickiness turned on.

Note: The load balancer session stickiness feature supports only HTTP or HTTPS listeners.

Resolution

Application-controlled session stickiness

Check for HTTP errors

Check for HTTP errors with your Classic Load Balancer. For more information, see Troubleshoot a Classic Load Balancer: HTTP Errors.

Check that your application inserts application and AWSELB cookies

Run a command similar to the following to the load balancer DNS name. In the command response, check that your application inserts and application cookie that runs on a backend instance. Also check in the response that the load balancer inserts an AWSELB cookie.

[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null <your-elb-name>

Note: Although the curl utility is native to Linux, you can install it on Windows. In the preceding example, replace <your-elb-name> with your load balancer name.

The following is an example response to the command:

...

< Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/
< Set-Cookie: 
AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

Note: If there's no AWSELB cookie in the response, then there's no stickiness between the client and the backend instance.

Check that the registered instance inserts an application cookie

Run a command similar to the following to verify that the registered instance inserts an application cookie. This command sends an HTTP request directly to the registered instance IP address.

[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null <backend-instance-ip-address>

The command returns a response similar to the following example:

...

< Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/

...

Verify that the cookie name that the registered instance generates is the same as the cookie name that's configured on the load balancer.

Verify that the client sends the application and AWSELB cookies

Verify that the client sends both the application and AWSELB cookies. Take a packet capture on the client or use the browser's web debugging tools to retrieve the cookie information in the request header. If the client fails to include either the application of the AWSELB cookie, then the stickiness won't work.

Configure the backend instance to display the instance ID

To configure the backend instance to display the instance ID, run a script similar to the following. The script uses instance metadata to display the instance ID.

<?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');
echo "instance id = " . $instance_id . "\\xA";
?> 

Review your load balancer access log

Review your load balancer access log. Check if requests from the same user route to different registered instances.

Verify the format of the cookie

Verify that the cookie the application inserts is formatted correctly for HTTP (on the IETF Datatracker website).

Turn on stickiness for only one load balancer

If your request passes through multiple Classic Load Balancers, then verify that stickiness is turned on for only one load balancer. If more than one load balancer inserts a cookie, then it replaces the original cookie and stickiness fails.

Duration-based session stickiness

Check for stickiness between client and backend instance

Run a command similar to the following to the load balancer DNS name. Check for an AWSELB cookie in the response. If there's no AWSELB cookie in the response, then there's no stickiness between the client and the backend instance.

[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null <your-elb-name>

Note: Replace <your-elb-name> with your load balancer name.
The command returns a response similar to the following example:

...

< Set-Cookie: 
AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

Verify that the client sends the AWSELB cookie. Take a packet capture on the client or use the browser's web debugging tools to retrieve the cookie information in the request header. If the client fails to include the AWSELB cookie, then the stickiness doesn't work.

Check the configured duration

Check the configured duration of the load balancer. If the cookie expiration period isn't valid, then client sessions no longer stick to the registered instance. The load balancer must issues a new cookie.

Turn on stickiness for only one load balancer

If your request passes through multiple Classic Load Balancers, then verify that stickiness is turned on for only one load balancer. If more than one load balancer inserts a cookie, then it replaces the original cookie and stickiness fails.

Related information

Configure sticky sessions for your Classic Load Balancer

describe-load-balancers

Application-controlled session stickiness

Duration-based session stickiness

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 8 Monaten
Keine Kommentare