: What potential issues do I need to be aware of in a multi server/clustered environment? I have been working on a website with a client for some time now and the site itself has grown massively

@Rivera981

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.

Vote Up Vote Down

@Michele947

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

Vote Up Vote Down

@Hamm4606531

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.

Vote Up Vote Down