Category Archives: data center workstation virtualization

Gartner: clueless in the cloud.

Vern Burke, SwiftWater Telecom
Biddeford, ME

I’ve just been reading about the uproar over the Gartner “Magic Quadrant” for cloud computing infrastructure. I think they need some remedial education before they pass themselves off as cloud computing pundits.

Defining “cloud computing” precisely is something that people have been squabbling over quite some time now. This is because most of the people squabbling can’t separate the core characteristics that truly define cloud computing from all the little details that define the many flavors of it.

Even though people tend to disagree on what cloud computing really is, it’s pretty clear what it is NOT. It isn’t “classic” data center services. This is what had me shaking my head over Gartner declaring Amazon weakness because they don’t offer co-location, or dedicated private physical servers.

Having started as a classic data center provider here, SwiftWater Telecom, my own operation, provides both classic data center services such as co-location AND cloud computing services and the combination of these things gives us more flexibility to meet customer’s needs through combination. On the other hand, the classic side of the coin isn’t a weakness or a strength of the cloud computing side. It just means I have a wider range of tools to satisfy more customer needs.

After previously having gone around with Lydia Leong of Gartner about a hairbrained suggestion to chop public clouds into private ones (“Cloud computing: another ridiculous proposal.”), I can only conclude that they only have enough handle on cloud computing to be dangerous.

Trying to mix a requirement for traditional data center offerings in to the equation when
when the subject is supposed to be “cloud computing infrastructure” is the most clueless thing I’ve seen in quite a while.


What you REALLY should be asking your cloud computing provider.

Vern Burke, SwiftWater Telecom
Biddeford, ME

I’ve been reading quite a bit of back and forth over cloud computing provider Service Level Agreements and endless checklists that purport to be everything a customer should ask a potential cloud computing provider. There’s a lot of aimless noise and sniping back and forth that is missing a very critical point.

Let me start of by saying, as an approach to insuring service uptime, classic percentage based SLAs are worthless. The SLA tells you nothing about whether you can expect your cloud computing provider to keep your service running or not, only the penalty if they fail. Your goal as a cloud computing customer isn’t to extract the maximum compensation for the failure of your cloud service, it’s to insure that your cloud service doesn’t fail in the first place!

Failures of data center hardware are an inevitable fact of life, even with the most conscientious engineering and operation. The data center failures of the past year have shown that even the big data centers fall well short of the “most conscientious engineering and operation” goal. Given this fact of life, here are the things you should REALLY be asking your cloud computing provider.

1. Do they have the ability to automatically restart workloads on the remaining running physical cloud capacity if part of the capacity fails.

This is something that has stood out like a sore thumb with a lot of the big cloud providers. Failures of underlying physical hardware on Amazon’s AWS service kills the workloads that were running on that hardware, even though the vast amount of capacity is still up and running in the cloud. If your cloud provider can’t automatically restart your workload in case of failure, run away.

In the SwiftWater Telecom cloud (using the Xen Cloud Control System) failed workloads are restarted automatically on remaining cloud capacity in minutes, not hours.

2. Do they offer a way to insure that redundant virtual servers never end up on the same physical server?

It doesn’t do much good to have redundant virtual servers in the cloud if they all die when one single physical host dies.

In the SwiftWater Telecom cloud, we offer what we call the Ultra Server. The Ultra Server combines redundant virtual servers with the “unfriend” feature of XCCS. Unfriending insures that the redundant servers never end up on the same physical server.

This means that nothing but a “smoking hole disaster” would ever cause a complete outage of an Ultra Server. Combine that with the automatic virtual server restoration of XCCS and the option to set up the Ultra Server between our separate data centers, and you have a cloud powered virtual server that is the next best thing to indestructible.

Stop concentrating on the penalties for failure, ask the right questions to find the cloud computing provider who has the right tools to keep your service from failing in the first place.

Will cloud computing actually save energy? Overcomplicating it.

Vern Burke, SwiftWater Telecom
Biddeford, Maine

I just read a piece discussing the debate over whether cloud computing actually saves energy or not. This piece shows that you can get silly about trying to quantify the unquantifiable.

The argument is really very simple here. The idea is that the energy cost of the networking equipment required to move data back and forth to a cloud computing provider offsets the energy gain from an end customer dumping an inefficient local data center in favor of cloud computing. If the original claim of cloud computing energy saving is over simplified, so is the argument against it.

First, any claim about the energy cost of the network would require a detailed analysis of how much energy is required to move a bit of data from point A to point B. Good luck trying to account for every single piece of power consuming electronic equipment in any path through the Internet. Good luck trying to account for every single piece of power consuming electronic equipment in every POSSIBLE path through the Internet that the data could take. Remember, you not only have to account for the networking equipment but also the communications carrier’s facilities that provide the link.

Second, it’s easier to make this claim when you have a local data center that’s only supporting local users. Add in remote users or add in a public facing website and now you’re generating cross Internet traffic from nearly anywhere. Take the first issue and multiply it thousands of times.

In reality, the energy cost of moving data is pretty low compared the 95% under utilization rate commonly found in small local data centers. Wasting that much energy leaves a LOT of room to absorb the energy needed to ship bits across the network.

Add to this the massive economies of scale involved in cloud computing and I’d be hard pressed to see a situation where the energy cost of the network outweighed the energy saving of cloud computing.

Thursday data center tidbits: arguing against virtualization, NASA data goes free range

Vern Burke, SwiftWater Telecom
Biddeford, ME

First up today is a question I ran across asking if there are any circumstances that argue against server virtualization in the data center. The only thing I can think of is the requirement for specialized hardware. If your applications require specialized hardware, keep them on their own server, otherwise, get virtualizing!

The next piece is about NASA discovering that they’ve been selling excess PCs without properly cleaning sensitive data off them. And everyone is in a panic over cloud computing being a tremendous security threat? The biggest security threat is leaving your data in the care of people who have no focus on the security of it.

Data center doof of the week goes to Tumblr for managing to kill a database cluster AND kill their network for a day for the sake of scheduled maintenance. Squeaky red noses are enroute!

Wednesday data center tidbits, pt 2: #cloudcomputing security goes stupid.

Just read a piece about a supposed “insider attack” on VMware ESX. Um, duh, you give someone the root password to anything and they can copy data off it and manipulate the log files. The “security vendor” isn’t aware of any “attacks in the wild”, probably because this isn’t an attack at all. It’s not a bug, it’s not a “cloud computing security risk”, it’s giving the root password to the wrong person, duh.

It’s never pretty when someone jumps the shark and doesn’t make it all the way over. BeyondTrust, cloudwashing bozos of the day.

Email or call me or visit the SwiftWater Telecom web site for cloud computing services.


Wednesday data center tidbits: geothermal #datacenter cooling, #cloudcomputing and the Fed (again)

First up today is the piece about using geothermal cooling for data centers. In some ways, this is a great idea. You’re using the naturally cool deep earth as a heat sink for the data center waste heat and it’s a totally self contained system, you’re not throwing away precious fresh water. On the bad side, you’re expending energy to pump water (which is fairly heavy) in the opposite direction the waste heat in it wants to move it via convection. I don’t know, call me skeptical on this one.

Next up is the piece about the federal CIOs issuing a “cloud computing privacy framework”. The issue here appears to be mostly who owns customer data stored on a cloud. This is ridiculous. The customer owns the data, PERIOD. The cloud provider STORES the data on behalf of the customer. I don’t know where this goofy idea comes from that the cloud provider would have ANY right to use the customer’s data they’re storing (unless some sort of agreement specifically gave them that privilege). This isn’t rocket science and it’s not anywhere the level of crisis that the “cloud is dangerous!” crowd is making it out to be.

Email or call me or visit the SwiftWater Telecom web site for cloud computing services.


Load balancing the Xen Cloud.

One of the strongest benefits of cloud computing is that it gives you the ability to spread workloads over a number of servers that make up the cloud. This is great, but how do you make sure your workloads are spread out evenly and not bunched up on a few or even just one server in the cloud? In this post, I’ll be discussing load balancing the cloud as I do with Xen Cloud Control System and Xen Cloud Platform.

The goal of any load balancer, of course, is to spread the work on the cloud out to use the servers that make up the cloud as efficiently as possible. There are a couple of other considerations as well. The load balancer can’t cause the cloud to oscillate (endless shifting of load) as well as needing to deal with loads that can’t be moved.

With the XCCS load balancer, the first thing I do is make the determination that we’re only going to consider memory usage for a metric. My experience with XCP is that I’m 100% guaranteed to run out of memory long before CPU capacity. The second is that we’re going to set a 10% unbalance limit. If you try to push much closer than this, you run the very real risk of setting the cloud oscillating.

Now that we have the ground rules set, the first thing I do is identify the cloud servers with the highest and lowest amount of free memory. This starts the balancing with the two most extreme.

The next step is to identify the virtual machine with the lowest memory usage on the server with the least free memory. Moving the virtual machine with the smallest footprint is a conservative approach that once again insures that we don’t get things endlessly oscillating. A cloud that’s burdened by constantly shifting virtual machines is bad news.

Next is sanity checking to make sure the virtual machine we chose can be moved and that it can be moved to the server with the highest memory free. If this is the case, then that virtual machine is live migrated to the server with the most memory free.

The final step is for the load balancer to run the rest of its 5 passes and then further balancing waits for the next run of the load balancer. This approach makes sure that the load balancing process itself doesn’t use up all the resources and impact the working virtual machines running on the cloud.

A couple of runs of the XCCS load balancer and even the worst cloud can come out white and fluffy!

For more details on the XCCS load balancer, visit us here!

SwiftWater Telecom
Xen Cloud Control System