4 ms·
At $enterprise-dayjob we've ended up using EFS in AWS after migrating an application that was using NFS. One of the main obstacles to adopting this was perceive
by shoo 8y ago
At $enterprise-dayjob we've ended up using EFS in AWS after migrating an application that was using NFS. One of the main obstacles to adopting this was perceived lack of security as EFS didn't support encryption of NFS connections between EC2 instances and EFS mount targets. AWS EFS released support for encrypting the NFS connections earlier this year, using Stunnel.
What's the corresponding story re security for cloud filestore?
- rrdharan 8y agoNot 100% certain but I don't think hyphen is a valid variable name character in any language whose variable references start with a $.
- regularfry 8y agoSymbols in common lisp and scheme can both start with $ and contain hyphens.
- mlrtime 8y agoHow did you get around the terrible performance of EFS. Are you not read/writing lots of small files?
- haggy 8y agoNobody should be writing many small files to EFS/S3/etc. It's very bad at that.
- brazzledazzle 8y agoNFS in general seems to struggle with that scenario. Do you get better performance with your own NFS server with that type of workload?
- chucky_z 8y agoUnrelated to EFS, but I found Gluster to have good performance for this use-case vs. NFS/CIFS.
- X-Istence 8y agoA NetApp filer on 40 Gbit/sec will do NFS plenty fast for running VMs directly to/from the system using ESXi for example. EFS is not even in the same ballpark in terms of speed :/
- brazzledazzle 8y agoRight, I’ve had that setup in the past and I wouldn’t disagree with that but I’ve also seen a netapp choke on lots of tiny files over NFS.
- shoo 8y agoGood question. The application had grown and ran in production over a number of years using NFS for storage before it was moved into AWS, so this probably naturally steered devs away from trying to use the shared file storage as a high performance cache (eg they might try it, and find it to be slow, and figure out a different way of doing whatever they needed to do, probably using the db). Our usage pattern for NFS did not generally involve needing to read or write many small tiny files with any degree of performance. E.g. we might need to do reads/writes of dozens of files, each of a few mb in a process, with the overall running time of the process being largely governed by our DB performance / patches of poorly written algorithmic code running in a slow scripting language. Amdahl's law - for us making the NFS access go infinitely fast or 5x slower hardly changes the overall total process execution time. I can certainly appreciate that EFS is an abysmally slow for dealing with large numbers of reads/ writes of tiny files, in another part of the system one of my colleagues set up a read only cache of a large number of tiny files in EFS, due to the per-file write latency it took around a week to load in < 100gb of data.
- cobookman 8y agoGCP encrypts data in transit [1] & at rest between GCE nodes [2]. I do not know if Cloud Filestore offers encryption on the NFS application layer. [1] https://cloud.google.com/security/encryption-in-transit/#virtual_machine_to_virtual_machine https://cloud.google.com/security/encryption-in-transit/#vir... [2] https://cloud.google.com/security/encryption-at-rest/ https://cloud.google.com/security/encryption-at-rest/
- boulos 8y agoThis isn't correct: it's only between VMs "if they leave a physical boundary". VMs in the same zone do not do that.