CODEWITHSUNDEEP
sessionarchitecturescalabilityhigh-availabilitydistributed-system
devsda
devsda

Reputation: 4222

How to avoid single point of failure from given distributed architecture

I went through this video - Scalability Harvard Web Development David Malan

This is where I got stuck. Explaining the problem -

enter image description here

Lets assume LB is using round robin kind of approach.

As per First image, all servers are storing session in their local space, that is not accessible to other servers. If same request comes next time, and if LB redirects this request to another server, then that server will ask about authentication. That is very irritating from user point of view.

As per second image, all servers are sharing sessions. In this case, when next request comes from same client, and LB redirects to another server. Now, instead of asking for authentication, it will fetch information from Session host.

This is mentioned in above video link.

Question -

  1. Now session host become single point of failure. If the host is down, it will impact availability badly. How can we avoid such case ?

Upvotes: 2

Views: 2181

Answers (3)

na-98
na-98

Reputation: 889

For this exact reason, usually session hosts (eg memcache) are fronted with a VIP (virtual IP) and have more than one hosts. In a distributed architecture you generally want to have 1-N hosts. Most companies that operate at scale generate use data storage like Couchbase (memcahce buckets) to store session state because it's fast, redundant, and highly scalable.

Upvotes: 0

techuser soma
techuser soma

Reputation: 4877

Implementing Session host as a replicated data store helps remove single point of failure. Example, using a replicated cache like Hazelcast will keep the cache replicated and distributed thus eliminating the single point of failure. There are others like Memcached and Mongo. Automatic fail over on these can be achieved via virtual ip addresses.

Upvotes: 0

user1468899
user1468899

Reputation: 77

You have these options (assuming session is something which cannot be lost at any cost)

1) The session data store is a highly available data store. For eg: You can use MongoDB replica set for such a session store. It consists of three nodes of MongoDB with a master and two slaves (minimum) and when the master goes down one of the nodes is promoted as the master. This election may take a few seconds but the session would not be lost.

2) Use an in memory data sharing library which does data partioning as well as replication. An example would be Hazelcast for Java. It gives you object level sharing across the web tier and here you can store the session which is shared. Please note AFAIK there is no data persistence in this case (on disk).

3) The most scalable approach that I have used till now is to have client side session and no server side data/session storage. What you can do in this case is to have a very long secret key stored in each app server and you set all the data in the cookie after encrypting the data with this secret key. The only problem with this approach is that you need to be very selective with what you store in the session as there is a limit to the data size on cookie. This encryption is a 2-way. Most of the SAAS based tools use this approach.

Upvotes: 2

Related Questions