Technically it supported it before, but you had to configure everything manually (or with your own automation). Having it native is a lot nicer, and brings provisioning of NFS-style volumes up to par with the current Kubernetes experience.
Amazon Elastic Container Service now supports Amazon EFS file systems
11–20 of 31 posts
Re: Amazon Elastic Container Service now supports Amazon EFS file systems
#12Earlier quoted context omitted.
It's terrible. Very slow when we tried to use it. There are ways to work around this, and ways to tune the performance, but honestly it was not worth it for our use case and instead we found a way to make EBS work. EFS is a great way to get a lot of iowait on your cpu graphs. Would not recommend it for anything that had to be fast.
> we found a way to make EBS work. Can you say more about what you did with EBS? It seems like it would be necessary to make some compromises in availability and disaster recovery because any given EBS volume is restricted to the availability zone where it was created.
We were hosting third party software in an EKS cluster and needed a way to share state between components of this system. We tried EFS initially but it actually killed the EKS cluster with iowait under load. We found a way to divert most of the systems requirements to local emptydir volumes, leaving only infrequently accessed media files on EFS
Re: Amazon Elastic Container Service now supports Amazon EFS file systems
#13How's the performance on EFS? Has anyone used it in production that is willing to share their experience? We evaluated it for a relatively simple use case, and the performance seemed abysmal, so we didn't select it. I'm hoping that we made a mistake in our evaluation protocol, which would give me an excuse to give it another try.
It's terrible. Very slow when we tried to use it. There are ways to work around this, and ways to tune the performance, but honestly it was not worth it for our use case and instead we found a way to make EBS work. EFS is a great way to get a lot of iowait on your cpu graphs. Would not recommend it for anything that had to be fast.
Would you recommend it for a CMS like system (Drupal) that's backed by a CDN?
Re: Amazon Elastic Container Service now supports Amazon EFS file systems
#14How's the performance on EFS? Has anyone used it in production that is willing to share their experience? We evaluated it for a relatively simple use case, and the performance seemed abysmal, so we didn't select it. I'm hoping that we made a mistake in our evaluation protocol, which would give me an excuse to give it another try.
It feels like the performance and cost is really built around a very specific use case that basically boils down to "write logs and only read a tiny fraction of those logs".
And then, I've seen way too many people treat it like a traditional file system, and stick things on it that don't expect to find themselves on NFS, and wonder why they get corrupted files.
And, really, I tend to avoid the AWS services with "Burst Balances". It's painful to get a system running smoothly only to have it grind to a halt when you use it under load because some burst balance somewhere went to zero. Your mileage may vary, of course.
Re: Amazon Elastic Container Service now supports Amazon EFS file systems
#15How's the performance on EFS? Has anyone used it in production that is willing to share their experience? We evaluated it for a relatively simple use case, and the performance seemed abysmal, so we didn't select it. I'm hoping that we made a mistake in our evaluation protocol, which would give me an excuse to give it another try.
It's terrible. Very slow when we tried to use it. There are ways to work around this, and ways to tune the performance, but honestly it was not worth it for our use case and instead we found a way to make EBS work. EFS is a great way to get a lot of iowait on your cpu graphs. Would not recommend it for anything that had to be fast.
I have to agree with this- I found it challenging to tune EFS to get the claimed performance. The most important details of any system like this are: provision a very large filesystem, use large files, use lots of concurrent access (threads or machines).
There is a whole market of small companies that make high performance filers that do what many people want but they also have limits (high cost/byte).
Re: Amazon Elastic Container Service now supports Amazon EFS file systems
#16How's the performance on EFS? Has anyone used it in production that is willing to share their experience? We evaluated it for a relatively simple use case, and the performance seemed abysmal, so we didn't select it. I'm hoping that we made a mistake in our evaluation protocol, which would give me an excuse to give it another try.
It feels like the performance and cost is really built around a very specific use case that basically boils down to "write logs and only read a tiny fraction of those logs". And then, I've seen way too many people treat it like a traditional file system, and stick things on it that don't expect to find themselves on NFS, and wonder why they get corrupted files. And, really, I tend to avoid the AWS services with "Burs…
EC2 SSDs have Burst Balances as well, and have since 2016: https://aws.amazon.com/blogs/aws/new-burst-balance-metric-fo...
Re: Amazon Elastic Container Service now supports Amazon EFS file systems
#17This is going to make running teamcity or jenkins from fargate, much simpler.
Re: Amazon Elastic Container Service now supports Amazon EFS file systems
#18This is great news! Yes, these containers are supposed to be stateless, but I was tasked with converting an app at my previous job over to using ECS on Fargate and we hit so many issues because of the limits on storage per container instance. We ended up having to tweak the heck out of nginx caching configurations and other processes that would generate any "on disk" files to get around the issues. Having EFS availab…
> Yes, these containers are supposed to be stateless,
You got it backwards. NFS type services help containers be stateless because they are a separate service accessed through an interface where all the state is handled by a third party.
Thus by using a NFS-type service to store your local files, you are free to kill and respawn containers at will because their data is persisted elsewhere.
Re: Amazon Elastic Container Service now supports Amazon EFS file systems
#19Oh man, awesome. We had a rather janky workload where ECS would spin up an EC2 that would then mount an EFS volume and then write a file over to S3. This is going to make that so much easier and cleaner.
If you're wondering why you'd ever have to do something like that, the answer is SAP.
Re: Amazon Elastic Container Service now supports Amazon EFS file systems
#20Earlier quoted context omitted.
It feels like the performance and cost is really built around a very specific use case that basically boils down to "write logs and only read a tiny fraction of those logs". And then, I've seen way too many people treat it like a traditional file system, and stick things on it that don't expect to find themselves on NFS, and wonder why they get corrupted files. And, really, I tend to avoid the AWS services with "Burs…
EC2 SSDs have Burst Balances as well, and have since 2016: https://aws.amazon.com/blogs/aws/new-burst-balance-metric-fo...
Trust me, I know. We have alarming on all of our SSD burst balances after a few painful lessons.
At least those are mostly OK, since in our case at least, the really EBS hungry clients now have volumes of 1024 GB or more, so the burst balance issues don't apply.