2

I am not any networking or devops guy but I have to do this for my company because my company can't afford one, so pardon me for mistakes.

I have got a web app hosted in google cloud and I use load balancer provided by google cloud, in the backend I have 2 instances for the web app. The problem is that I am using file caching and caching is separate for both the servers. It is not HTTP caching or anything, it is backend caching from web app not nginx.

My servers are running Ubuntu 16.04 LTS.

How can I keep a common file cache server ? I want to keep a third server for file caching so that caching is common for both instances, and for that I am thinking to use NFS, is it good idea to use NFS for file caching ?

I have researched a lot over the internet and that is where I heard about NFS.

user1735921
  • 121
  • 5
  • 1
    "I am using file caching" that's unclear. Is it a web cache done with nginx? Or is it a file **storage** modified by webapps? Please add all the details. – kubanczyk Oct 01 '17 at 13:49
  • @kubanczyk updated question. I am using file caching by web apps with a cache key. – user1735921 Oct 02 '17 at 06:51
  • NFS stands for "networking file system". What it does (as of version 3, even though there's version 4, 3 is the one being commonly used) is it allows you to access files on a different computer over network. It has some caching, but caching isn't its primary purpose. To go even further, efficiency of transfer isn't its primary purpose (it's actually quite slow because it doesn't compress the payload and doesn't provide a way for the client to establish multiple connections, at least not in the client shipped with Linux kernel). – wvxvw Oct 02 '17 at 06:56

1 Answers1

3

A common file server for all of your instances is a problematic idea because it can become a bottleneck and a single point of failure. In that way it may end up defeating the purpose of using a load balancer in the first place.

In order to recommend a solution one would need to know a lot more about your system architecture. I can give a few suggestions which may or may not work depending on your architecture.

  1. Make sure that your instances can respond to all requests even if the cache VM is not responding. If the caches are only there for performance improvements the instances can probably respond without relying on the caches - just not as efficiently.
  2. Shard the cache. If you can compute a hash of the identity of the resource being cached and use that to choose between multiple cache VMs your design will be more scalable. And by using the same hash you can still benefit from your LB backends having access to results cached by other instances.
  3. Cache on the LB backends as well. Even if you have a shared cache it is a good idea to cache on the LB backends as well. It can protect against hotspots on your cache VMs and makes your service more resilient if one of the cache VMs is unavailable.

Your choice of protocol should be driven by how well you can live up to the above requirements. I don't think NFS is the best choice because it is difficult for the application layer to implement timeouts when one of the NFS servers does not respond. And the possibility for one NFS server not responding causing multiple LB backends to misbehave is a risk I would rather not have.

A protocol where the client side (running on the LB backends) is implemented in user mode is likely a better choice because any thread getting stuck because of a non responding cache server is more likely to be contained. And it is simpler to implement timeouts in the access to the cache VMs when it is implemented in user mode.

kasperd
  • 29,894
  • 16
  • 72
  • 122
  • There is a timeout of 60 seconds which I can decrease to 2 seconds and even if cache is not available the code will execute sql query and get the results. So yeah not dependent on cache, I am using it for performance only. So I guess I will have to use shard then as you suggest. Can you tell me what should I use for sharding file cache , rsync with cron job ? – user1735921 Oct 02 '17 at 06:58