Virtualization roulette: One 10G switch is never enough

The old joke 'If you can't afford two Porsches, you can't afford one' might apply to 10G switches, but there's a poor man's alternative

Last week I hit on the theme of just because you can do something, it doesn't mean that you should. That was in the context of "saving" time and money by shoehorning a bunch of VMs onto two physical hosts that can technically handle the load when it's a far better idea to spread things out and run three or four physical hosts instead. Feel free to adjust those numbers up to scale -- it's basically the same concept on an eight-host cluster that should actually be 12.

Other aspects of consolidation and conservation come into play with virtualization clusters, and switching is certainly one of them. With the push to 10G well under way, it's enticing to string up a cluster of hosts on a 10G switch and reap the rewards of faster migrations, faster IP storage, and faster interaction between VMs on separate hosts. However, I see a fair amount of single-switch deployments of 10G in production. I'm not so sure that's a great idea.

[ Also on InfoWorld: Virtualization showdown: Microsoft Hyper-V 2012 vs. VMware vSphere 5.1 | Get expert networking how-to advice from InfoWorld's Networking Deep Dive PDF special report | Get the latest practical info and news with InfoWorld's Data Center newsletter. ]

10G is still expensive, certainly moreso than aggregated 1G connections, but that shouldn't result in a scenario where the loss of a 10G switch spells doom for the virtualized infrastructure. While that may seem obvious, it happens more than you might expect.

For the larger shops, bite the bullet and buy redundant switches, configured as separate entities or as a stack. Depending on the vendor and its software support, a stack may be less redundant than two separate switches because a software oops in one switch can affect the switching operation of the other in certain circumstances. In a server-centric 10G deployment, there's little to be gained in a stack anyway, unless you need aggregated 10G pipes from your hosts.

A better solution is to run an active/passive failover link configuration with the two legs run to different switches. Ideally the active links of each host would be balanced across the two switches so that the overall switching load is shared. With bonded 10G uplinks, or 40G between the switches, you should be good to go, able to survive the loss of any switch at any time. If you need 20G bonded from each host (or a pair of 20G links across four 10G interfaces on the host), a stack may make more sense or a modular switch with redundant everything. This is not the place to cut corners.

However, some deployments may have a hard time justifying multiple 10G switches for a relatively low overall port count. If all I need are 16 10G switchports, buying two 24-port 10G switches seems like serious overkill to a nontechie looking over the budget. It's a fact of life that important items get cut from projects based on raw numbers like these, lacking context or understanding. Sometimes all we can do is figure out a way to live with the result until the issue can be properly addressed later on or in a new budget cycle.

1 2 Page 1
Page 1 of 2