0

I am currently building a simple webapp architecture on AWS, as follow: Elastic Load Balancer - multiple front ends - RDS database.

I have also set up an NFS server to store all images uploaded by users through the web app, such as profile pics mainly (I can't use S3 for this, I am only following the specs I get...).

The front ends VMs are spawned by an autoscaling group. When a VM is spawned, it downloads the web app sources from an S3 bucket. The problem is, I have some huge files within those sources (static files mainly, such as mp4 or images) I am thinking about storing those big static files on the NFS server as well, because it takes too much time to download from S3.

So My question is: When is it relevant to store a file on the NFS, and when is it be better to let it on each front end? e.g if I store mp4 on the NFS, why not storing the whole web application on this NFS?

note: I don't want to build an AMI containing those files, as it is not flexible enough when modifying them

1

This all comes down to performance. If your NFS storage is fast enough then there is nothing to stop you putting all your web app & web content files on it so they are accessible to all your front end VM's.

That said, the most common reason for people not doing this is because the extra network latency involved in retrieving files from networked storage converts to an added delay when clients are loading your web app/site in their browser.

Obviously this depends on the underlying storage of the VM but usually local storage is almost always lower latency and therefore is preferred for storing static content. A lot of load balanced deployments I have been involved with make use of DRDB for keeping the static content in sync available to all web servers.

  • I think EC2 has network storage anyways (except for the ephemeral data). NFS is typically quite slow when doing alot of requests (statting all files in a directory for example). But in this specific use case I think this would work quite well. – Jeroen Aug 24 '15 at 14:31
  • thanks for mentioning DRDB, I did not think about it. I understand the performance concern, I indeed see the latency when dumping traffic. @Jeroen, EC2 has network storage, but if I go with EBS optimized I can get pretty good performances. Anyway, I think I will store the mp4 files to the NFS for now, as they are not accessed a lot and take way too long when spawning an instance. For the other static files, I am going to dig the DRDB solution! thanks for your help! – Tom Aug 24 '15 at 14:42
  • Just thought about it: maybe also when doing live code deployment, it is better to keep the web app files on different front ends, so that I can modify 1 server at a time (i.e I would not kill the whole application) – Tom Aug 24 '15 at 14:44
  • @Tom You are correct, if updating your web front ends by removing one from the load balancer at a time, DRBD complicates things. Some deployments split the balance into two mini clusters using two separate DRBD groups, one for cluster A and one for cluster B. That way you can remove one 'mini cluster' at a time to test your new code without having to break the DRBD. Alternatively you can use a file sync tool manually to keep the web servers in sync such as Rsync and only run it when you make changes to the static content. – tomstephens89 Aug 24 '15 at 15:28
  • 1
    thanks for all this feedback and advices @tomstephens89, will run some tests about all this! – Tom Aug 24 '15 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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