Nfs – The best way to share a file uploads directory across horizontally scaling web servers

In 90% of the hosting situations you will run into, you'll have far more webservers than storage servers which alters your network design quite a bit. You'll run storage servers in pairs, as many primary/primary fileservers don't support more than mirrored replication. Large NFS servers will likely handle a dozen or so webservers if you have a 10g backbone. Your connecting lines will be virtual connections as you'll run web lan on one vlan, storage lan on a separate vlan, gigE for the web lan, 10g for the storage lan depending on budget. You mention dual primary storage servers, and then mention NFS mounts which are somewhat exclusionary. Are they truly running shared nothing or is it a dual head/dual shelf/single fcal setup?

Run your load balancers in dual primary to reduce the cutover time and increase potential throughput. Don't use more than 40% of their capacity so that you have enough spare once you have a failure.

You also need to account for MySQL/PostgreSQL/Cassandra/etc clusters as well -- they don't particularly like NFS mounts.

Lefthand Networks has a distributed filesystem product. GlusterFS is somewhat mature and would work depending on your workload. MogileFS/Hadoop is another possibility. Also, take a look at Ceph, GFS and OCFS.

As for the number of mounts, you'll mount each NFS server once or possibly twice per webserver. Dozens of mounts wouldn't be unheard of, but, you might end up segregating your web clusters to eliminate having hundreds of mounts. Hadoop can present itself to your network as a single global filesystem across a distributed network.

Disclaimer: You'd be mad to listen to me without doing a tonne of testing AND getting a 2nd opinion from someone qualified - I'm new to this game.

The efficiency improvement idea proposed in this question won't work. The main mistake that I made was to think that the order that the memcached stores are defined in the pool dictates some kind of priority. This is not the case. When you define a pool of memached daemons (e.g. using session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211") you can't know which store will be used. Data is distributed evenly, meaning that a item might be stored in the first, or it could be the last (or it could be both if the memcache client is configured to replicate - note it is the client that handles replication, the memcached server does not do it itself). Either way will mean that using localhost as the first in the pool won't improve performance - there is a 50% chance of hitting either store.

Having done a little bit of testing and research I have concluded that you CAN share sessions across servers using memcache BUT you probably don't want to - it doesn't seem to be popular because it doesn't scale as well as using a shared database at it is not as robust. I'd appreciate feedback on this so I can learn more...

Ignore the following unless you have a PHP app:

Tip 1: If you want to share sessions across 2 servers using memcache:

Ensure you answered Yes to "Enable memcache session handler support?" when you installed the PHP memcache client and add the following in your /etc/php.d/memcache.ini file:

session.save_handler = memcache

On webserver 1 (IP: 192.168.0.1):

session.save_path="tcp://192.168.0.1:11211"

On webserver 2 (IP: 192.168.0.2):

session.save_path="tcp://192.168.0.1:11211"

Tip 2: If you want to share sessions across 2 servers using memcache AND have failover support:

Add the following to your /etc/php.d/memcache.ini file:

memcache.hash_strategy = consistent
memcache.allow_failover = 1

On webserver 1 (IP: 192.168.0.1):

session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211"

On webserver 2 (IP: 192.168.0.2):

session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211"

Notes:

• This highlights another mistake I made in the original question - I wasn't using an identical session.save_path on all servers.
• In this case "failover" means that should one memcache daemon fail, the PHP memcache client will start using the other one. i.e. anyone who had their session in the store that failed will be logged out. It is not transparent failover.

Tip 3: If you want to share sessions using memcache AND have transparent failover support:

Same as tip 2 except you need to add the following to your /etc/php.d/memcache.ini file:

memcache.session_redundancy=2

Notes:

• This makes the PHP memcache client write the sessions to 2 servers. You get redundancy (like RAID-1) so that writes are sent to n mirrors, and failed get's are retried on the mirrors. This will mean that users do not loose their session in the case of one memcache daemon failure.
• Mirrored writes are done in parallel (using non-blocking-IO) so speed performance shouldn't go down much as the number of mirrors increases. However, network traffic will increase if your memcache mirrors are distributed on different machines. For example, there is no longer a 50% chance of using localhost and avoiding network access.
  • Apparently, the delay in write replication can cause old data to be retrieved instead of a cache miss. The question is whether this matters to your application? How often do you write session data?
• memcache.session_redundancy is for session redundancy but there is also a memcache.redundancy ini option that can be used by your PHP application code if you want it to have a different level of redundancy.
• You need a recent version (still in beta at this time) of the PHP memcache client - Version 3.0.3 from pecl worked for me.