It sound like you know about it so how would you do it?

I would set up a NFS server (or multiple, depending on demand) at each data center, have a script that syncs unix users with their users database, and set up quota and traffic shaping depending on pricing scheme.

Really, it's not that difficult.

I don't know why Linode is not doing it. Could be cost, could be business reasons, who knows, but I'm pretty sure it's not technical.

Amazon and Rackspace charge through the teeth for storage space. For my money I don't need a SAN. If I needed to share across Linodes in a datacenter I'd probably use sshfs to start with. NFS isn't reliable.

Amazon Elastic Block Storage (high reliability and availability virtual block devices that can be attached to EC2 instances) is 11 cents/GB/month. Or $11/month for 100GB. This is in addition to 160GB of locally attached storage that comes with m1.small instances (about the same price as Linode 1GB).

It's not cheap but it's something I can work with. Right now Linode charges $40/96GB.

There is also one-click differential snapshot backup of EBS storages to S3 (offsite).

Compared to Linode 1GB, m1.small has more memory (1.7GB), more storage (160GB with reasonably priced additional storage over EBS), but much slower CPU.

Not really considering Rackspace.

http://www.rath.org/Tales%20from%20the% ... %20Support
That's by the author of S3QL.

Sorry correction - EC2 instance storage is not persistent. It gets cleared after shutdown, so it's only a scratchpad. So there is no free storage.

You have no need to sync user IDs between the client and the server and doing so would be a total nightmare as the various client ranges would overlap. Just export a correctly sized file system to the correct clients and let the client end worry about user ID to user name mapping. You don't need quotas at all if the exported file systems are the correct size to began with.




NFS as a protocol is perfectly reliable and in common use all over the world. It's still the standard way to share file systems between unix machines.

It isn't reliable.

Uh what? I will say it's reliable enough for us to have used as our backend datastores for a large VMWare cluster for over three years. With no "reliability" issues at that.

Having worked with several storage vendors, something like this is definitely do-able for Linode. I don't know what type of hardware Linode is running on (last I knew was years ago using 2U servers) but having fiber for storage and an entirely separate fiber network just for the SAN would be a huge resource sink to every node. I could see a fix in one of two ways:

1. Deploy storage and have a specific subset of hosts connected to it. If you need SAN storage, your Linode will have to migrate.
2. Deploy a NAS (I've had very good luck with NetApp FAS) and make everything available via NFS.

I'll speak to #2 in more detail... NetApp does offer automation through their DataOnTap SDK. You can provision storage on the fly. Set up a filer and create the disk aggregates manually, then automate the rest. A user needs storage? They can submit a ticket or do it as an Linode Extra. Run a script that creates a new volume (say 100GB) and makes it available via NFS to a specific IP or via security settings.

We use the Netapp FAS Filers at work for our Windows CIFS shares, I've done this automation via powershell. The admin picks which filer, how big, what share name, etc and the script does the rest. Their automation tools are very powerful.

If you're going to sit there and talk about "oh gosh well NFS is just so unreliable, lets just use a SAN" you're likely mis-informed, been using bad implementations, or have very little experience with today's offerings.

iSCSI, anyone?

There are some sweet iSCSI storage systems with similar design like VMware clusters - multiple autonomous nodes (each with own controller) with availability to migrate volumes between the nodes on the fly.

If you don't need this kind of functionality, you can go with something even simpler (and I guess cheaper).

The connection could be (probably) done at the hypervisor level if Linode wants extra security/isolation, or you could use software iSCSI initiator inside your VPS if you'd have a network interface on the storage network.

_________________
rsk, providing useless advice on the Internet since 2005.

NFS as a protocol is rock-solid reliable. Many people shift terabytes over it daily without issues.

If you find it to be unreliable that's not due to flaws with the protocol itself, the issues are elsewhere.

I've always thought that this was Linode's greatest missing feature. A SAN would be awesome, especially if you could mount your SAN shares on more than one Linode (unlike Amazon EBS).

It isn't reliable.

I like iSCSI, it always worked well for me, so i've mentioned it.

I wouldn't use NFS when I have a familiar alternative available /because/ I've never worked with it, am not familiar with it, and heard many scary stories; but note I've used the word "stories" there.

So could someone - jebblue or not - explain what's wrong and/or unreliable with NFS? I'm curious.

_________________
rsk, providing useless advice on the Internet since 2005.

Would you be so kind as to spare a minute to express your reasons for not trusting the reliability of NFS? Repeating a statement doesn't make it true, especially without any supporting arguments.

_________________
me | voltaireMC