How to Overcome Infrastructure Virtualization Myths

Lately, as infrastructure virtualization companies are making a bigger and bigger splash in the data center, we've begun to see inaccurate information being spread by competing technologies—mostly those that use a proprietary stack. I'm a supporter of infrastructure virtualization trends regardless of the company involved (as seen in products, for example, that include but are not limited to Scalent V/OE, Egenera and Unisys uAdapt).

So, with that in mind, and in the spirit of my company Storage Switzerland (so named because neutrality ensures that you are receiving accurate information from us), I want to take a moment to shed some light on reality. In this article, I will discuss the three major infrastructure virtualization myths, as well as share some tips about how to overcome them.

Myth No. 1 is the "Storage" Myth: Infrastructure virtualization uses too much storage because the technology boots full, stored images instead of assembling images on the fly.

How to overcome the "Storage" Myth

There are really two issues here: risk and storage space. From a storage space perspective, it's conceptually possible that full images could take up more space than component-assembled images. But storage is cheap. Plus, these days boot images are relatively small compared with all the other data sets in the enterprise. It's hard to believe that a single gold master image per situation could cause significant storage issues.

In contrast, real-time image assembly is fraught with risk. Do you really want your server built on the fly at every boot? Seems like a lot of moving parts—and thus, a lot of opportunity for error. I am a firm believer in using technology to save disk space but only when you can do so with limited risk and significant payoff in space savings. Creating boot images on the fly does neither.

Myth No. 2 is the "Security" Myth: Infrastructure virtualization companies introduce a security risk because they leverage virtual and private networks.

How to overcome the "Security" Myth

The general answer here would be: "Things are more secure." Egenera actually uses a proprietary hardware backplane. This would seem to be very secure in that no hacker would know its approach. However, because it is proprietary, we don't know for sure. You would need to thoroughly test that.

Unisys uAdapt and Scalent V/OE leverage standard industry VLAN (virtual LAN) technology. This, if used correctly, is about the most secure approach you can find to networking! What does "correctly" mean in this case? Let's cite Cisco Systems on the topic (from the "Double-Encapsulated 802.1Q/Nested VLAN Attack" paragraph of the Cisco Catalyst 6500 Series Switches VLAN Security White Paper):

"[For security in 802.1Q trunking], always pick an unused VLAN as native VLAN of all the trunks; don't use this VLAN for any other purpose."

As both Unisys and Scalent claim to do this, all seems to be well. Comparing all of this with the all-too-common practice in the server virtualization world of building a wide-open flat network, infrastructure virtualization is significantly more secure.

Myth No. 3 is the "Overhead and Risk" Myth: Infrastructure virtualization companies add another component (server and agent) to data center management. Isn't this a failure risk?

How to overcome the "Overhead and Risk" Myth

In a sense, every bit of software is a failure risk. But let's examine what each adds and what happens if each fails.

Egenera is hardware-based. So you would think it would have better performance, right? Unfortunately, it turns out that it is also in the data path; that is, all data flowing to and from your data center servers must pass through the Egenera controller. So that will add some overhead and block some protocols. Also, if the Egenera controller fails, it blocks access to all of your managed servers.

Unisys and Scalent, on the other hand, are not in the data path. So there's no overhead added there. Even if their control servers failed, your data center servers would remain 100 percent accessible. Each does ask for an agent to be installed on the managed servers. But the odds of that agent causing a failure are infinitesimal. Even if one did, the server would simply reboot on another physical machine—with the same storage and network connectivity (the point of infrastructure virtualization.)

Contrast those two approaches with the assembly approach mentioned in Myth No. 1. I think it's safe to say that there's comparatively little overhead and risk added by any infrastructure virtualization player relative to other approaches.

The bottom line

So, what's the net? As always, be careful of the FUD. The older vendors are clinging to proprietary software applications, so don't be scared off. Infrastructure virtualization is here to stay. Ironically, what this tends to be is a delaying tactic that vendors will use until they right their technology.

Infrastructure virtualization is a "now" technology. Its positive impacts on the data center are well worth the time for you to examine and test these solutions.