Offer NFS/CIFS cloud storage
Perhaps as a fork of CloudFiles, or just as an additional feature, I'd like to have persistent storage available to any server via a 'mounting' interface.
Please send me some use cases
Don Myers commented
My 2 Cents. I would like something like a NFS mount point because once the server is running customers can upload additional resources like images for example. Of course if they are getting their page from Server 1 then Server 2 and Server 3 are now out of sync. If I could mount a NFS volume to say /var/www/uploads then they would all "see" the same files in the uploads directory. I could also server files from this directory using apache http://example.com/uploads/image1.jpg
Right now, I upload my code and manually upload assets in the CDN.
Using NFS, I can upload my code and assets to Cloud Files and then, when I spin up a server, have it take the code from Cloud Files.
It also allows me to do some Redis backup with a simple bash script rather than the pretty heavy script I have now.
It also allows me to use rsync to backup servers and desktop that are not at Rackspace.
Check Zadara Storage, as high performance NAS as a Service for Rackspace cloud customers. www.zadarastorage.com
@bill Our experience with cloud files has been positive, so that is an interesting idea. We're currently struggling with some of the same issues. In our case, we're looking at a central git repo with a script to pull the files down to each server via puppet. That ensures that if the central repo goes down our sites stay up.
Bill Stoidis commented
I just had that need at a project. When using multiple web servers with a load balancer, it's easier to have these webservers share a NFS storage for wwwroot instead of having syncing the contents to each every time.
use case : adding a datastore to pretty much any hypervisor to store snapshots, deltas etc.
All such data stores need a "proper" client and NFS works well...
paul lashbrook commented
Our use case is in a HA set-up to have a central store for compiled template files (compiled to PHP files) so that each of the app servers don’t need to carry a copy of the files, by allowing mounting we could scale our SaaS application past the limits of the diskspace of an app server.
In our case, we can't use the Cloud Files CDN because there is no SSL with CNAMES. What we'd like to do is a persistent mount for our files that aren't on the same server. Because it's mounted, SSL should be handled by the mounting server's apache? Now the question becomes, would it be bound by IP or could it be bound by an authentication mechanism? And how would that work? @moink, I could see your scenario too...if you have MySQL binary transaction files turned on, they are HUGE. Being able to have those live on a mounted server could be really cool. @Ed, would the mount point be included in the snapshot of the server? If it had its own backup mechanism, I could see that as a good way to get around some of the backup size issues.
Looking around on the forum, I feel like this overlaps with [http://feedback.rackspacecloud.com/forums/71021-product-feedback/suggestions/979509-need-ability-to-add-storage-to-cloud-servers] and [http://feedback.rackspacecloud.com/forums/71021-product-feedback/suggestions/997213-the-ability-to-choose-amount-of-ram-and-hd-space-s]. I'd be satisfied with any of these solutions. I love the idea of attaching NFS to a remote dev machine (my laptop?), but who cares if RS offers it? With gobs of block storage, I'd spin up my own NFS-providing VM, or somethin'.
* Persistent storage for spinning up instances that rely on serving central content.
* Large database application, archiving data. This wouldn't need a super powerful VM. For example, library/archival storage. Low access rate, but having the data available is important.
* Remote backup solutions/file server.
While lots of cloud apps are, or can be designed to use CloudFiles-esque storage, there is *everything else* that uses block-device storage, addressable through mounting interfaces. Wide-bandwidth access to storage from anywhere is something that sounds good to me! Slow access to a system on premises from a remote location sounds bad. Also, upgrading the uplink just to allow better access also sounds bad.
Khazret Sapenov commented
good idea, count my cents in! If you need use cases, let me know.