Does anyone else cringe when someone suggestions using NFS in production? I can't be the only one that has been woken up at 2am because of an NFS outage.
Amazon Elastic File System
161–170 of 217 posts
Re: Amazon Elastic File System
#162Earlier quoted context omitted.
Maybe you didn't notice, but they just invented the Watch. Imagine...if you could put a whole entire clock...on your wrist. Almost everybody has a wrist!
Says the guy who will own one within a year. Or the Android knock off.
Re: Amazon Elastic File System
#163Re: Amazon Elastic File System
#164Earlier quoted context omitted.
Maybe you didn't notice, but they just invented the Watch. Imagine...if you could put a whole entire clock...on your wrist. Almost everybody has a wrist!
Says the guy who will own one within a year. Or the Android knock off.
Re: Amazon Elastic File System
#165http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch11_03.h...
This is a step back from the right direction to me.
Re: Amazon Elastic File System
#166I wish AWS would be a little more technical in their product descriptions and announcements. If there was ever an audience that wants technical data about how this type of technology will scale and compares to existing technology like glusterfs it would be the AWS users. Instead the performance specifications are ".. and is designed to provide the throughput, IOPS, and low latency needed for a broad range of workload…
We'll be providing a lot more details later.
Re: Amazon Elastic File System
#167Earlier quoted context omitted.
For the record, there has never been anything stopping you from spinning up an NFS EC2 that all of your other EC2s can use.
Except that your one EC2 instance is a single point of failure, from instance through host through availability zone, and that providing reliable, multi-node NFS is hard (even with GlusterFS). And you have to resize your block devices to store more stuff. And... And... :-)
Which is why new services like these are always preferable.
Re: Amazon Elastic File System
#168Earlier quoted context omitted.
As has been mentioned, EBS can only be mounted to one instance at a time. If you could mount it to multiple it would effectively be the same thing, but then you have all sorts of write-locking issues. As the rest of the comments also allude, a lot of the cloud-entrenched world has abandoned NFS, or at least in AWS circles. I'm not one of these people. Rather than relying solely on puppet->all instances to handle mult…
Would it be a good idea to store Mysql db on EFS to be shared among load-balanced instances?
The right way to do that (in AWS world) would be RDS accessible to all instances in the security group. This yields locking control to the application level and not the file system. For obvious reasons this makes a lot of sense.
There are of course non-ACID / NoSQL solutions for which this might be an acceptable practice, but in general I'd say it's fraught with peril.
Re: Amazon Elastic File System
#169EFS is a great addition to AWS. We have SAN as a service via EBS, now we get NFS as a service. Great. The question (for me) now becomes "where do we go from here?" Infinite NFS is great, but what I've always wanted is infinite EBS that is fully integrated from file system to SAN. In other words, something that behaves like a local file system (without the gotchas of NFS like a lack of delete on close), but I don't ha…
Re: Amazon Elastic File System
#170EFS is a great addition to AWS. We have SAN as a service via EBS, now we get NFS as a service. Great. The question (for me) now becomes "where do we go from here?" Infinite NFS is great, but what I've always wanted is infinite EBS that is fully integrated from file system to SAN. In other words, something that behaves like a local file system (without the gotchas of NFS like a lack of delete on close), but I don't ha…
Wouldn't EBS w/ thin provisioning get you most of this? Just create a massive volume, and you get billed for the space actually used. (and the volume size could also function as a limit on your bill.)