3

I have been working on a website with a client for some time now and the site itself has grown massively in popularity. We are now at the stage where the single machine we have hosting the site is struggling to keep up requests and we have optimised the site itself as far as we can go (caching etc).

We are now at the stage where we need to add another server to take the extra strain which leads to my question - what potential pitfalls and caveats do I need to be aware of or test the site for when moving to a web farm or clustered hosting environment?

Improve this question

3 Answers 3

Reset to default
1

There are several possible caveats:

Sessions

If sessions are stored server side, (i.e. PHP), both servers will need access to a shared session storage path. Otherwise, you'll lose sessions as the load balancer sends request from one server to the other, or possibly (gasp) have one user with two unique sessions. This can get particularly frustrating with AJAX. 'Sticky' sessions may also be possible, depending on your load balancer.

Temporary Files

Both servers should share the same /tmp directory, if indeed you use any kind of temporary files while working to serve requests. This could be a temporary archive that is compressed for a download, a flat file DB that keeps track of something, whatever.

SQLite Locking

If you use SQLite3, you may notice some quirks that never surfaced before, especially if you are using something like NFS to share the database files between the servers. NFS is slow with this, so I recommend using something else. Distributed file systems like Lustre are easy to set up, or you could use GFS/OCFS2.

SSL

You probably want the load balancer to be what handles the SSL handshake, which then makes the request to the back end servers using any old self signed certificate.

Some general notes:

  • As noted, use a high performance file system for sharing directories. All shared files should live on network storage, not one of the web servers. Otherwise, if one goes down, both are useless, kind of defeats the purpose.

  • If the site uses a RDBMS, you have two options. Run it on both nodes and use a master-master sync, or put the DB server on its own home. I recommend the second because that gives your web servers a lot more elbow room to operate.

  • Load balancers need redundancy too.

In most cases, you can go from a single server to a load balanced farm with little to no changes to the actual site / application itself, but you will need to make sure that all nodes can read and write to the same files. This may require you to add some logic for locking in the app itself.

Improve this answer
2
  • Why do the backend servers needs SSL enabled? Why not just communicate with them over plain old unencrypted HTTP? (Assuming you're on a secure network.)
    – Annika Backstrom
    Nov 17, 2011 at 19:54
  • @AdamBackstrom If you can take assumption out of that, and ensure it's the case, then yes :) Unless you've actually visited the DC and verified that it's impossible to plug in to the private network without alarm, it's a trivial precaution. Unless you, yourself have seen it and verified it, you can't vouch for it. Data centers do brain dead things, frequently.
    – Tim Post
    Nov 17, 2011 at 20:37
0

Session state (if that's an issue) is a potential issue. Most load balancing appliances can use sticky sessions, meaning that a user that ends up on SERVER1 to start will remain on SERVER1, usually through the use of a cookie stored in browser memory. The only caveat with this is that when SERVER1 goes offline for any reason, that user will have to log in again on another server.

I've started bypassing this on my apps (they're CF apps) by sharing sessions in the server farm. So one machine going down will not impact the user experience.

The only other challenge I've faced in replicating the content correctly to all servers in the farm. There's software out there to do this (robocopy, Fling from NCH software are two I've used), but I've still had instances where the sync didn't work 100% of the time.

Improve this answer
0

Does your application care about state? If a user has one request served by one machine and then another served by another, does it matter? If you need to persist some form of state between requests, then everything is more complicated and there are various ways to deal with the problem.

If you don't need to worry about state, then good job building your site, and you things should be relatively ok with a proxy and a few backend servers.

If you do need to persist state, there are various ways to create a sticky session through the proxy so that the same backend server handles all requests from a single user, but there are also a lot of things that make those sessions hard to keep sticky.

You can also persist state in a common medium on the backend, so each server will load the same state for the same user. You can do this with a database (maybe too slow) or something like memcached.

Are you scaling up the number of database servers too? That will bring in another bunch of problems to worry about.

Some of the session issues are discussed in the Stack Overflow Podcast Number 63

For testing, make sure you hit a similar test cluster hard so you can see how your requests do when they are directed across many servers, because many requests from the same client to different backends is where you are likely to have issues, so make sure something in your test plan causes that to occur.

You may also want to read about Stack Overflow's network config

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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