0

This question has been asked before as AWS ALB - how to route existing sessions to Server A, and new sessions to Server B? but the answer is unsatisfactory and potentially out of date since the Load Balancer rules have become richer since 2021.

So, the question again, Given two identical servers, A and B, how can I use ALB to route new sessions to server B while I monitor sessions logging off server A over the course of several days, such that I can eventually turn off server A without disruption? I'm thinking of something like adding a querystring to the login URL and then forcing that onto a new target group which only includes server B. Once logged in, all of the inner URLs will be to the original two-server target group, such that existing sessions will continue in their sticky state but hopefully new sessions will be sticky to server B.

It seems a fairly standard use case so I'm hoping there is a canonical answer.

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470
pinoyyid
  • 21,499
  • 14
  • 64
  • 115
  • 1
    Are you wanting a particular session to go to a particular server (using Sticky Sessions), or are you just saying the you want 'current' requests to finish before decommissioning a server? Why should it be done "over the course of several days", given that requests would normally take a few seconds? Also relevant: [ELB Connection Draining – Remove Instances From Service With Care | AWS News Blog](https://aws.amazon.com/blogs/aws/elb-connection-draining-remove-instances-from-service-with-care/) – John Rotenstein Mar 22 '23 at 00:06
  • @JohnRotenstein I have 2 Tomcat instances on two servers. Normally, users' logged in sessions are distributed over the two servers in a single TG and I have stickiness enabled based on the JSESSIONID cookie. Before upgrading the server code on A, I want to have any new login sessions directed to B, leaving all existing sessions on their current servers (including A). It will take a few days for all of my users to have logged out and back in again, at which point all sessions will be on B and I'm free to upgrade A without disrupting any extant sessions. Draining for i hour doesn't achieve this. – pinoyyid Mar 22 '23 at 10:43

1 Answers1

1

AWS advises strongly in highly-available architectures. Use-cases that require in having exactly one server being the whole application are discouraged, while still possible. Your architecture doesn't sound like it follows the AWS Well Architectured Framework and therefore there isn't a "switch" or "best-practice" to solve your use-case.

Improvements that could be made to your architecture would be to offload the sessions to ElastiCache or even RDS (depending on load requirements) and converting the application servers from unique (having the session information) to uniform (= all being the same). There are libraries that can store Tomcat session data into Redis (ElastiCache) for example. After switching to ElastiCache you can use blue-green deployments to switch users to the new server(s) gradually.

If you insist in you current architecture, I think you have to do implement the steps DIY. I'll call the two server "old version" and "new version":

  • Move the old version and new version to each own TargetGroup
  • Mark requests with the server they should be routed to and add rules in the ALB
    • You can use a cookie, but parsing cookies in the ALB has some restrictions. It can work if you use a unique string.
    • If you have full control over the frontend, you can use a custom header - which is easier.

If you have full control over the frontend (for example SPA applications) you can also generate different solutions and route to different backends on a version update.

I was considering solutions used for blue-green deployments, but these are random in sending clients to blue or green deployments.

Augunrik
  • 1,866
  • 1
  • 21
  • 28