Still no support for incremental snapshots though right?
Amazon Elastic File System – Production-Ready in Three Regions
111–120 of 122 posts
Re: Amazon Elastic File System – Production-Ready in Three Regions
#112I think it is worth mentioning that Azure offer something similar with Samba / CIFS/ SMB protocol. [1] This is the underlying tech that powered their Docker volume plugin as well [2] I'm using in production for serving up small images to some web servers, and I'm currently in playground with docker stuff. So far, so good. I'm impressed. [1] https://azure.microsoft.com/en-us/documentation/articles/sto... [2] https://a…
A notable difference is that Azure file shares have a 5 TB limit for the whole share, and a 1 TB limit on the size of any given file [1], while EFS has no limit on the size of the file system, and a 52 TB limit on the size of any given file. [2]
Disclosure, work for AWS.
[1] https://azure.microsoft.com/en-us/documentation/articles/sto...
Re: Amazon Elastic File System – Production-Ready in Three Regions
#113Earlier quoted context omitted.
Maybe but unfortunately the database doesn't support "backup store" that we can use directly S3, it just writes the data to specified directory in a filesystem. We should either fork the database or implement "S3 backed" filesystem and we picked the latter one. Unfortunately the performance FUSE is not that good for read and writing data to S3 is somehow expensive.
Why not have a service watch for filesystem changes and then upload to S3?
AFAIK, there is no synchronous way to do it and if I do it asynchronously, partial data loss is possible.
Re: Amazon Elastic File System – Production-Ready in Three Regions
#114This is really cool but also kind of a shame. I feel like it will encourage bad behavior. I can see people using this to deploy code by deploying onto the shared volume so that all their instances get an "instant update". Which is great when it works, but lord help you when EFS goes down and every app server you have is hung on a broken NFS connection.
If people want to deploy that way, I suppose that using rsync to update a local clone, and running from that, would minimize this problem.
Re: Amazon Elastic File System – Production-Ready in Three Regions
#115Earlier quoted context omitted.
It sounds like a disaster waiting to happen. The latency of NFS is just too high (Even if it is very fast for NFS) for it to be safe for a database.
We're running Oracle on NFS volumes, and some MySQL databases also with no problems whatsoever. It'll never be as fast as local disk but the flexibility it provides is very nice.
That's normal NFS. Amazon's offerings, if you have a 10 gigabyte database, you can only get 500KB/sec bandwidth --
Re: Amazon Elastic File System – Production-Ready in Three Regions
#116Earlier quoted context omitted.
I think that deploying onto a shared volume is exactly the workload that EFS encourages. That things will stop functioning can be said about any (AWS) technology. "Lord help you when (S3|RDS|SQS|etc.) goes down and every (thing) you have is hung up on a broken (thing) connection." The rational argument here is that if uptime is important to you, the solution is to utilize multiple regions, of which EFS is now in 4. Y…
Assuming all assets get stored on S3, the other common writing scenario is logging. How would multiple machines writing to the same log file work?
Generally, you wouldn't write to the same log file. Prepending/Appending the instance name to the file would be enough to make it unique.
Re: Amazon Elastic File System – Production-Ready in Three Regions
#117Earlier quoted context omitted.
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?
Exactly! The code base is going on 15 years old and was built with no knowledge of S3 or it's ilk. For that reason each WWW server has to have a local copy of all the assets (or at least a significant portion).
Re: Amazon Elastic File System – Production-Ready in Three Regions
#118Earlier quoted context omitted.
We're running Oracle on NFS volumes, and some MySQL databases also with no problems whatsoever. It'll never be as fast as local disk but the flexibility it provides is very nice.
That's normal NFS. Amazon's offerings, if you have a 10 gigabyte database, you can only get 500KB/sec bandwidth -- http://docs.aws.amazon.com/efs/latest/ug/performance.html
Huh. well that's kinda shitty.
Our NetApp can saturate 10GBe without even trying.
Re: Amazon Elastic File System – Production-Ready in Three Regions
#119Earlier quoted context omitted.
Also, it is a full-fledged NFS-mounted file system. I would be very wary of running a database from that.
It sounds like a disaster waiting to happen. The latency of NFS is just too high (Even if it is very fast for NFS) for it to be safe for a database.
I was more thinking about the risk of locking not working as intended on NFS (http://0pointer.de/blog/projects/locking2. See also the section on Nightmare File System in the UNIX-Haters Handbook (https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook)).
There are workarounds for the stateless mess of NFS in modern linuxes, but if you accidentally access a NFS-mounted database from multiple AWS instances, you might get into big trouble, especially when the machines in question run different OSes (e.g. Windows and Linux) or OS versions.
Re: Amazon Elastic File System – Production-Ready in Three Regions
#120Earlier quoted context omitted.
I think that deploying onto a shared volume is exactly the workload that EFS encourages. That things will stop functioning can be said about any (AWS) technology. "Lord help you when (S3|RDS|SQS|etc.) goes down and every (thing) you have is hung up on a broken (thing) connection." The rational argument here is that if uptime is important to you, the solution is to utilize multiple regions, of which EFS is now in 4. Y…
Assuming all assets get stored on S3, the other common writing scenario is logging. How would multiple machines writing to the same log file work?
It wouldn't. NFS is not fully POSIX compliant, largely due to not being cache coherent. In particular, O_APPEND is not supported.