Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon Elastic File System – Production-Ready in Three Regions

aws.amazon.com

Post reply on HN
Print view View original

61–70 of 122 posts

Re: Amazon Elastic File System – Production-Ready in Three Regions

#61

Post by lsaferite »

lucaspiller wrote: post #51
Corrado wrote: post #46

Earlier quoted context omitted.

I think EFS is meant for large read-heavy patterns, at least that's what we used it for. For example, I help run an e-commerce site that has a lot of content (JS, CSS, images, etc.) that we serve up from 10 dedicated servers as well as 30 general servers. When we release new content we have to update each of the servers and make sure that everything got installed properly everywhere. With EFS, we just have to update…

Why don't you use S3 and Cloudfront to serve all the assets?

Maybe their platform wasn't designed around using S3 and retrofitting that into the platform is a significant task compared to using EFS as the backing store with CloudFront mediating client access?

Re: Amazon Elastic File System – Production-Ready in Three Regions

#62

Post by ngrilly »

RossM wrote: post #36
ngrilly wrote: post #31

To store small files (10 to 1000 KB) uploaded by users in a web app, what is the best tool, S3 or EFS?

Object storage (i.e. s3+cloudfront) is still the correct way to store immutable files. that said, I know this will be used when the options are to rewrite filesystem access to an abstract (i.e. fs/s3/azure/etc) or just use nfs. People already use s3fs-fuse[1] which is dubious at best. [1]: https://github.com/s3fs-fuse/s3fs-fuse

Would you say that the main choice criteria is immutability?

Immutable files => Object storage => S3

Mutable files => File storage with POSIX semantics => EFS/NFS

Re: Amazon Elastic File System – Production-Ready in Three Regions

#63

Post by lsaferite »

Corrado wrote: post #49

I am excited by EFS but during the beta it didn't perform as well as I would have liked. I had a small Wordpress install that I wanted to make elastic in that I could have multiple web servers and all of the data was stored apart from the AMI. After testing my setup I found that latency was way too high and the performance of my site was terrible. I'm guessing it's because the amount of data was really low (100MB) an…

Was it not possible to use the S3 plugin for WP to offload all the content files to S3 + CloudFront?

Re: Amazon Elastic File System – Production-Ready in Three Regions

#64

Post by pyre »

zeisss wrote: post #60
jedberg wrote: post #50

Earlier quoted context omitted.

The difference is that all of those services are accessed via an API, which means your client can do clever things when it fails, like timeout, give a fallback, find an equivalent resource in another zone or region, etc. With EFS, it's exposed as NFS, which hooks in much deeper. If it goes down, there isn't anything you can do to work around the problem, unless you start hacking your own file system kernel modules.

Can't you measure and timeout on the file-descriptor writes too?

Do you want to start wrapping your system calls to read files in code that forks to periodically check for a hung system call?

Re: Amazon Elastic File System – Production-Ready in Three Regions

#65

Post by bhouston »

Are there any third party performance metrics yet? Read/write ops per second, and read/write bytes per second from one or many machines?

Would love to see this in comparison to a 10Gbps (or 1Gpbs) attached spinning rust or SSD NSF drive. That would really help me understand what tradeoffs are happening here.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#66

Post by boucher »

jedberg wrote: post #9
jeffbarr wrote: post #4

Earlier quoted context omitted.

Not at present. I would be interested in learning about use cases for this. Post here or find me online, as you wish.

One use case would be one that came up a while back here on HN -- The person had a large binary blob that they needed to load up every time their Lambda function ran. If they could mount EFS from Lambda, they could put the large binary blob there. Depending on how they wrote their code, if the Lambda could seek to the right part of the file then this would work, but if it has to load the entire file into RAM anyway,…

Couldn't you just download the portion of the one file you want from S3? Unless EFS is significantly faster...

From a caching perspective, you wouldn't seem to gain much in lamda. You can cache in memory/tmpfs until your container eventually dies, and then you likely aren't on the same machine so there's no EFS level caching to take advantage of.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#67

Post by jeffbarr »

Corrado wrote: post #49

I am excited by EFS but during the beta it didn't perform as well as I would have liked. I had a small Wordpress install that I wanted to make elastic in that I could have multiple web servers and all of the data was stored apart from the AMI. After testing my setup I found that latency was way too high and the performance of my site was terrible. I'm guessing it's because the amount of data was really low (100MB) an…

We addressed this use case during the preview. Could you try it again now?

Re: Amazon Elastic File System – Production-Ready in Three Regions

#68

Post by shatgupt »

jeffbarr wrote: post #4
atrilumen wrote: post #2

Can EFS be mounted from the Lambda environment?

Not at present. I would be interested in learning about use cases for this. Post here or find me online, as you wish.

I would like to have a media pipeline where a media goes through QC check, thumbnail, preview generation and some other processing which are independent of each other. My media can range from 1-15GB, so if I can store it in EFS which can be mounted in Lambda, I can use various Lambda functions which can simply read from a common storage without downloading every time from S3.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#69

Post by rincebrain »

Corrado wrote: post #48
boraturan wrote: post #15

Seems like no Windows support?

That's a good question. Originally it was Linux only as the EFS client was locked to NFS 4.0 and the Windows Server NFS client was 4.1 (why 4.1 is not backwards compatible, I don't know). However, the announcement mentioned using the PowerShell cmdlets to attach EFS volumes, and in fact the PowerShell help pages have specific commands for working with EFS. So, my guess is that it is now available for Windows and Jeff…

The EC2 example shows mounting with nfsvers=4.1, so I'm guessing it got resolved by bumping the version supported.

Re: Amazon Elastic File System – Production-Ready in Three Regions

#70

Post by cothomps »

jedberg wrote: post #32
hdra wrote: post #28

Earlier quoted context omitted.

I have to admit that is the first use case that I thought of when I read this. No more messing around with AMIs and launch config whenever an update is deployed. You bring up a good point on the EFS being a point of failure though. What use case do you think the EFS is good for? It seems like even worse for data storage since IO can easily become a bottleneck.

> What use case do you think the EFS is good for Out of band big data/data pipeline processing. Something where you want an easy way to sync your data but can handle extended downtimes.

Or scenarios where you can use EFS to stage data 'for something else' (i.e. shared image / upload content that stages to a CDN, etc.)

Keep in mind (and this comes from hard experience in 'traditional' NFS web server architecture) - if you mount everything on an NFS volume, you ensure that

1) If something goes wrong on that NFS mount, everything goes wrong. (bad code deploy? All nodes are down!)

2) If you rely on an NFS mount to store everything (e.g. trust keystores for JVMs,etc.) your entire infrastructure is dependent on the I/O capabilities of that NFS mount.

3) No matter how clever you are (or how much you trust NFS clients/versions) you will deal with file locking if you are doing a fair amount of read/write from multiple nodes to a single NFS mount.

Short story - EFS will make some of the 'hard' things with distributed nodes possible, but don't make the easy things impossible to troubleshoot.

Post reply on HN