I have a solution where an ELB is configured to use sticky sessions. How can I actually verify that requests for a client is actually routed to one and the same instance in the auto-scaling group behind the ELB?
For web applications, in my dev/testing environments, I usually grab the instance-id using the EC2 meta data service and spit it out in the HTML. That way I can see what instance is serving my request.
Other than that, to my knowledge there is no way to verify sticky sessions are working unless you log session ids and all requests and check through all of your logs across each of the relevant instances.
ELB access logs contain both the requesting client's and the backend instance's IP.
Related
I created a Target Group with two AWS Jenkins instances following the below documentation.
https://www.jenkins.io/doc/tutorials/tutorial-for-installing-jenkins-on-AWS/
Then I created an ALB and use the Target Group as the listener.
I used Amazon ACM and enable HTTPS on my ALB. I added a CNAME Record in the Route 53 for ALB DNS Name.
Now when I am trying to login using the CNAME I am observing the following scenario
If I have multiple EC2 instances in my TG and I keep on trying to login but it only succeeds after 3rd or 4th attempt. What is the reason for this ? How to debug this? Can I setup Cloudwatch logs at the ELB level to check this ?
If I have only one EC2 instance in my TG then the login always succeeds in first attempt.
If I login directly to each of the instances I can login to them always in first attempt.
Also if I enable stickiness at the TG level then even if I have both the EC2 instances in my TG then I can login with my first attempt using the CNAME ? Why do I have to enable stickiness and the impact of this ?
Is there way for me to know if I am deploying a web application(3rd party like Jenkins) if and when I need to enable stickiness and the side effect of doing this action ?
Thanks in advance.
Load balancers send traffic to one of the EC2 instances in the TG. The Jenkins responds with session tokens and cookies so your browser and the server are in sync.
When there is only 1 instance all the traffic is sent to it.
When there are two or more instances then the traffic is sent to each of them in turn, typical round-robin behavior.
The problem is that the Jenkins Controller is not a clusterable resource.
Basically Jenkins A has no idea that the other Jenkins exists.
So, what is happening is that the login request goes to Jenkins A, that responds with a session token, then the login redirect happens and your browser makes the request for the dashboard page and sends in the session token, this request gets sent to Jenkins B which promptly denies all knowledge of the session token and bounces you back to the login page.
The Advice from Jenkins is to have a main instance and a "warm" standby that is brought online when the main goes down.
If you are running a cluster in order to build more things then you probably need to run more Agents and connect them to the Controller so that they can be provisioned by an AutoScaling group and scaled up when needed and down when it is all quiet.
I have created a Jmeter script to check the performance of a site. The website is hosted in AWS with elastic scaling and with sticky sessions. Basically the AWS load balancer will assign a session cookie to each user so the load balancer can direct the user to the correct instance.
source
My problem is, as I'm using a cookie manager and clearing all the cookies with each iteration. Does it clear these assigned cookies too? I suspect this because the script error rate is lower when we execute the script on a single AWS instance than in auto-scaling ( multiple instances )
Any idea ?
I don't know about how do you "clear" cookies, if you use this box of the HTTP Cookie Manager:
then it removes all cookies on each new iteration of the Thread Group (other loop generation options like Loop Controller or While Controller will not trigger clearing of cookies)
Also if your Load Balancer has more that one IP address you might want to add the DNS Cache Manager to your Test Plan in order to avoid DNS requests caching on JVM or OS side.
The problem was not with the JMeter script. It's with the AWS ELB in a elastic server config. We had configured a Alarm to remove the instance from load balancer, so even with the stickey sessions enabled when the instance is removed it generated the error.
After moving the session managemet to a Elasticache - Redid based solution, this issue will be fixed.
Thank you all who supported.
I have an Application load balancer and have 4 app servers created in single target group. After enabling the session stickiness in front load balancer, request is not routing to single healthy instance; instead it is routing to multiple EC2 instance, which is breaking my application.
Any alternative ideas to have this point to single EC2 instance in the target group rather hopping to any random EC2 instance whenever I try to hit the application URL.
You need to make sure that initial request should be handled by the instance of your choice. Then you can use 'Application-Controlled Session Stickiness' to to associate the session with the instance that handled the initial request.
Please read Configure Sticky Sessions for Your Classic Load Balancer - Elastic Load Balancing. This might help.
Also if you have 4 servers in target group and want to send request to only 1 server, then you can remove rest of the three servers temporarily and initiate a request. In that case, request will always go to that single server, you wanted. Then you can add back rest of the three servers again. Now you can set the stickiness to associate the session with the session with the first server, you wanted.
I have heard about two approaches to store user session in Amazon AWS. One approach is to use cookies stickiness with Load Balancer and the other is to store user session to ElastiCache. What are the advantages and disadvantages if I want to use the EC2 Load Balancer as well as ElastiCache? Where should I store the user session?
AWS LB stickiness is something else, you can not store thing in LB stickiness, this is controlled by AWS underlying service. The load balancer uses a special cookie to track the instance for each request to each listener. When the load balancer receives a request, it first checks to see if this cookie is present in the request. If so, the request is sent to the instance specified in the cookie. If there is no cookie, the load balancer chooses an instance based on the existing load balancing algorithm.
you can use the sticky session feature (also known as session
affinity), which enables the load balancer to bind a user's session to
a specific instance. This ensures that all requests from the user
during the session are sent to the same instance.
LB sticky sessions just route the subsequent request same ec2 instance from the same user, it will help application like WebSocket.
lb-sticky-sessions
So if you are looking for a way to management and store sensitive data and that data should be available across multiple nodes then you need
Distributed Session Management using Redis or Memcached. if you use case is just to stick the subsequent request to the same EC2 instance then LB stickiness is enough.
There are many ways of managing user sessions in web applications,
ranging from cookies-only to distributed key/value databases,
including server-local caching. Storing session data in the web server
responding to a given request may seem convenient, as accessing the
data incurs no network latency. The main drawback is that requests
have to be routed carefully so that each user interacts with one
server and one server only. Another drawback is that once a server
goes down, all the session data is gone as well. A distributed,
in-memory key/value database can solve both issues by paying the small
price of a tiny network latency. Storing all the session data in
cookies is good enough most of the time; if you plan to store
sensitive data, then using server-side sessions is preferable.
building-fast-session-caching-with-amazon-elasticache-for-redis
I have created a LBCookieStickinessPolicy for my ELB.
But I can't seem to find on any AWS documentation a command that retrieves the instances that are currently 'sticked' (I mean, the actual instance that the ELB is sending load now).
I only find the commands that create the policy itself (create-lb-cookie-stickiness-policy & create-app-cookie-stickiness-policy) ...Any ideas?
Sticky sessions mean that a single user's web browser gets stuck to a single server instance (unless the server goes down or the user clears cookies). The ELB still distributes load across all the servers attached to it. The ELB would distribute multiple users across multiple server instances.
So there is no way to see what you are looking for because the ELB is always using all instances. Now if you just had a single user on your website, you could look at the server logs of each web server to determine which server that user is "stuck" to. In general you would need to look at the web server logs to see which servers are currently receiving traffic.