I have multiple frontend servers churning out the HTML pages , behind a load balancer.

Just wondering what is the best practice to update the frontend app while users are surfing the site.

The objectives:

  1. ensure each user see either the new or old version, but not flip between both.
  2. ensure load is still evenly distributed amongst servers that are not being updated.
  3. no disruption to service.

My thoughts:

  1. Divide the servers into groups.
  2. Take out a group from load balancing and wait for it to finish off current requests.
  3. Update the app and OS, etc.
  4. put the group back to load balancing.
  5. Pick another group and repeat steps 2-5.

While in process, some servers will have the new version, so to ensure users do not flip between the old and new ones, do I enable sticky session?

What you have above seems like a reasonable update procedure, however you can also use persistence or a sticky session so that when a user goes to a web server, they will be routed to the same web server for the life of their browser session (or for the next hour, or whatever you decide to configure). This also allows for some A/B testing if you need to get user feedback on a new feature or just allow for the possibility of a bug (just pull server group B from the pool if an issue is discovered during A/B testing with that group).

There are some concerns you should be aware of with sticky sessions: Eg, source address persistence can be problematic if you have a thousand users behind a firewall - then you have a huge group that always goes to a single web node. Maybe you really don't want a cookie to do persistence, etc.

But, there really is no agreed "best practice" on this - the best practice is going to the the one that meets your business need in this case. You should just collect all of your options and choose the workflow that best meets your needs.

  • what are the alternative methods? Sticky sessions are necessary, right? For users with cookies disabled, does that mean they cannot have sticky sessions? – Lucas Jun 29 at 16:13
  • It just depends on the architecture of your app. You don't need sticky sessions if the web servers are stateless or of the state is shared amongst the cluster - eg, is there a login? Do all web servers know all of the login tokens? For users with cookies disabled, you can often have fallback persistence - eg, use source address if cookies can't be used. I've also seen persistence based on ssl session ID. – James Shewey Jun 29 at 16:48
  • well since we can only update the servers group by group, there are some with the old and new versions of the app, hence we need sticky sessions right, to prevent a user from going to old and new. – Lucas Jun 30 at 4:52
  • ...if you choose to update them that way, yes. But you can also deactivate group A, update it, Deactivate Group B and Active Group A simultaniously, Update group B and then reactivate group B, in which case you wouldn't need sticky sessions. – James Shewey Jun 30 at 16:40
  • that's assuming we only have 2 groups? What if we have > 2 groups? – Lucas Jun 30 at 17:29

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.