If your live web application has more than a couple of users, and they don’t both sit right next to you, you need to cluster it. This is not for performance reasons – a single server can easily cope with the load on most web applications. It is not even for reliability reasons – problems are most likely to be in the application code which runs on all cluster members, than in the infrastructure. You need to cluster for upgrade and maintenance reasons.
Cluster for manageability
A dispatcher should sit on your public web address, and proxy requests to one of many (most likely two) back end servers. When you need to release a new version of your application, upgrade your server, or even your hardware, you can take that server out of the cluster. Once the server is upgraded, it goes back in the cluster and the other one comes out.
Sticky sessions instead of session clustering
If your application does not use sessions, you can let the proxy choose a different back end server for each request. If you have sessions, you could replicate the session. This means the back end servers communicate to share session data. This can be done via the database or via sockets or shared memory. This is complex to setup and slows your application. Much easier and faster is sticky sessions. A good proxy allows you to pin each session to a server, so that one users stays on one server for the duration of their session.
Front end dispatcher software
You won’t have to get out of bed if one of the servers goes down
Get the proxy to take care of https, meaning your back end servers don’t need to.
You can do last minute testing by taking a server out of the cluster, releasing the new version of your application to it, and browsing straight there to test. It’s a live, private server !
You can tell the security officer that your application server is not directly accessible from the outside world.
Happy clustering !