Reliable Cloud host ?
george.herbert at gmail.com
Tue Feb 28 01:03:28 UTC 2012
On Mon, Feb 27, 2012 at 3:45 PM, William Herrin <bill at herrin.us> wrote:
> On Mon, Feb 27, 2012 at 2:19 PM, George Herbert
> <george.herbert at gmail.com> wrote:
>> Failing to have central shared storage (iSCSI, NAS, SAN, whatever you
>> prefer) fails the smell test on a local enterprise-grade
>> virtualization cluster, much less a shared cloud service.
> Hi George,
> Why would you imagine that a $30/month virtual private server is built
> on an enterprise-grade virtualization cluster? You know what it costs
> to builds fibre channel SANs and blade servers and DR. In what
> universe does $30/mo per customer recover that cost during the useful
> life of the equipment?
As I stated, one can either do it with SANs or with alternate storage.
Amazon hit those price points with a custom distributed filesystem
that's more akin to the research distributed filesystems than anything
else. It's using node storage, but not single-node locked; if the
physical dies it should not lose the data.
Amazon wrote that filesystem, but one could approach the problem with
an OTS research / labs distributed FS using blade or 1U internal disks
and duplicate what they did.
In the "enterprise" space, there's a lot more variety and flexibility
too. I bought a 100 TB (raw) NAS / storage unit for well under $30k
not that long ago. Even accounting for RAID6 and duplicate units on
the network (network RAID1 across two units doing RAID6 internally),
that would cover something like 250 "standard" AWS instances, or about
$100/unit for the storage. At typical useful amortization (24 to 48
months) that's about $2 to $4/month/server.
That's not an EMC, a Hitachi, a BlueArc, a NetApp, a Compellant, even
a Nexsan. But one can walk up the curve relatively smoothly from that
low end point to the bestest brightest highest-tier stuff depending on
one's customers' needs.
> A VPS is 2012's version of 2002's web server + CGI and a unix shell.
> Quite useful but don't expect magic from it.
There are plenty of services that know what they should do and do it
reasonably well. AWS, above.
There are also a lot of services that (without naming names) are
floating out there in sketchy-land.
One should both know better and expect better. It's possible to
design reliable services - with geographical redundancy and the like
between service providers, in case one corks - out of unreliable
services. One should do some of that anyways, with clouds. But the
quality of the underlying service varies a lot. If you're paying AWS
prices for non-replicated storage, think carefully about what you're
doing. If you're paying half of what AWS costs, and duplicating
locations to handle outages, then you're probably ok. If you're
paying more and getting better service, ok.
-george william herbert
george.herbert at gmail.com
More information about the NANOG