1

I am having difficulty understanding the nomenclature for this scenario:

Say I have one web server, Server A, in an ALB target group, and users hitting that server.

I would like to take that server offline, and replace it with Server B, without too much interruption to the existing user sessions.

So, I would plan to add Server B to the target group, and hopefully route all NEW sessions to Server B. All existing sessions (and no new sessions) would continue to hit Server A. I could then decide an appropriate time to remove Server A, once old user activity has slowed or ceased on Server A.

It doesn't seem that deregistration is used for this purpose. I don't see settings for sticky-sessions that refer only to NEW sessions.

What would be the best approach for this scenario?

user994277
  • 47
  • 1
  • 2
  • 8
  • I have same question - as soon as a target is deregistered, I'm observing that old sessions still go to new server. Even though the backend target has http "connection: keep-alive" header - that doesn't seem to be working. Did you find a working solution? – bits Jun 28 '21 at 18:34

1 Answers1

1

All sessions would have to be sticky, not just NEW sessions. In your description, the old sessions are "stuck" to the old server, and the new sessions are "stuck" to the new server. The closest you can get with ALB settings is to enable sticky sessions, and set an appropriate Deregistration Delay setting.

To have more control of this switch over you will need to use other AWS services besides ALB, such as AWS Global Accelerator.

Mark B
  • 183,023
  • 24
  • 297
  • 295
  • 1
    Indeed, our experience testing deregistration delay was that the moment you deregister the user, all subsequent hits are immediately routed to the new server, and the intent of deregistration delay is to allow "in-flight" sessions to complete prior to completing deregistration. Thanks for the link, it has some promising info. I will report back on what we discover there. – user994277 Feb 24 '21 at 20:07