OT: Cloud Computing is coming to ...

Christopher A. Williams chriswfedora at cawllc.com
Fri Jul 23 21:58:55 UTC 2010

On Fri, 2010-07-23 at 14:23 -0600, Phil Meyer wrote:
> On 07/23/2010 12:59 AM, JD wrote:
> >
> > Can you describe the hardware of the private cloud
> > and the hardware of the non-cloud machine in the
> > location where you were involved in the installation
> > or configuration?
> > I would like to  know what is being compared to what
> > when claims of doubling the performance are made.
> >
> > For example if the cloud has a total of 400 cpus,
> > 100 TB of mirrored raid 5, 200 ports of 10GigE, and
> > 1600 GB ram,...etc...etc
> >    
> You are missing several key points here:
> Cloud Storage products from Amazon and/or Google do not need to, and 
> seldom does, contain a file locking mechanism, and therefore, a real 
> file system.  As such, cloud storage has no need of RAID X.

Actually, that's not completely true. All cloud infrastructure relies on
a storage platform of some kind, and all of the hypervisors that support
cloud environments do, indeed, employ some sort of file locking
mechanism at the physical storage layer. It's just that this happens at
a layer well below where the VM would see it. So, while it's there, from
the perspective of the VM it appears as if it's not and you don't really
care as long as you can get to your (virtual) disk when and as fast as
you need to.

> Could storage is not always, necessarily, concurrent, but usually 
> allowed to 'drift' across WAN links as necessary and prudent.

While this is possible, it actually doesn't happen all that often at all
from a practical perspective. Even then, when it does, it's almost
always happening within a single data center unless there is downtime
for the VM involved. When dealing with offline cloud storage,
replication across WAN links for DR purposes then becomes more routine.

> Also, if every physical compute system runs a hypervisor on the 
> hardware, you can't count CPUs as in: 2 Quad Core Xeons; you count them 
> as computation units per system, where the system could include 
> available hardware from hundreds of physical computers, without using 
> all of the resources of those physical computers.

...Well, that's certainly one way to count them. Also, in cloud
environments, a single VM is not going to be larger than the physical
server it is hosting. Dividing the workload of a single VM across
multiple physical systems is actually what grid computing is about.
Hypervisors don't do that. At least not yet.

In reality, we count vCPUs where it makes sense to do so. And then, it's
mainly for applications that are actually taking advantage of SMP
computing, and/or spawn large numbers of threads. Otherwise, we're back
to an Intel equivalent of MIPS calculations.

Also keep in mind that cloud is much more than public cloud providers.
Private internal cloud is a major piece of the overall picture.

> Look at the Cloud Harmony benchmarks for your favorite cloud provider here:
> http://blog.cloudharmony.com/2010/06/cloud-server-benchmarking-part-4-memory.html
> Consider that you can get (on paper) more throughput from an Isilon 
> platform than you can from the largest EMC or Hitachi RAID based device.
> The IT world is moving fast, away from fixed hardware specifications, 
> towards modular nodes that offer storage, cpu, or whatever.

Indeed...! The change continues to accelerate as well.


"There's two strategies to arguin' with a woman:
Neither one of 'em works."

--Cowboy Wisdom

More information about the users mailing list