Virtualization Rant: Solid Networking Skills Required

January 24, 2009

<RANT>My local pastor recently completed a series on getting your life “from here to there,” and it made me think: what single administrative skill and knowledge base is necessary to make robust virtualization solutions work? Is that a simple question? Are there simple answers?

Looking at how the market leader, VMware, has grown its IP to include infrastructure virtualization, it may be easy to look at what’s being virtualized and say knowledge of operating systems to be virtualized and related administration skills are the most important. After all, they started out virtualizing operating systems, right? While this is a critical issue for business systems in general, virtualization neither depends on that knowledge nor requires its mastery to be successfully implemented. Likewise, the need for that knowledge is independent of whether or not virtualization technologies are being used.

Some may be compelled to think that system management knowledge is key. After all, things get a lot more complex once virtualization is introduced, right? While I would compare the elevation of complexity that virtualization introduces to saying learning to drive makes getting from point-A to point-B more complex, like operating system knowledge, systems management tools work pretty much the same inside and outside of the virtual world. If anything, virtualization tools change management ideas in new directions, replacing now-antiquated processed with newer, deeper ones.

Still – and I’ve touched on storage and computational components as being a key infrastructure factors in previous blogs – others may insist that knowledge of storage and/or computational architectures are where the rubber meets the road. Indeed, these elements are very important to a successful implementation and they do the most to determine stability, performance and reliability. However, these are ever becoming commodity items that are quickly becoming plug-and-chug factors that end-users and systems administrators have next to no influence over (beyond vendor choices and architectural pairings.) Once chosen, these elements they become static elements of the infrastructure (and/or) eco-system and, as I try to caution regularly, their commoditization make reliance on any single source product or technology ultimately folly.

Clinton was Wrong: It’s the Networks, Stupid

So I ask myself: what single thing – beyond the hypervisor itself – brings all these elements together to produce the desired effect? How do workloads today – physically or virtually bound – deliver their payloads? It’s all about the networks that interconnect them! While that may sound axiomatic, many discussions I’ve had lately focus on the more obvious elements and ignore networking – especially in virtual infrastructures – altogether.

Example: Today a company buys “brand-X” switches to interconnect their business systems. Assuming each (physical) system requires 2-port(s) to interconnect application space and 2-ports to interconnect with storage, even a small company with only 10 servers is looking at 40-ports of redundant (i.e. stackable) GigabitEthernet ports – plus user ports and reciprocal storage ports . Not a big deal, but assuming these workloads could be 100% virtualized, port densities could be reduced by at least 60%.

You might say: “Big deal, server consolidation delivers that savings.” And you’d be right, but now there is a new way to interconnect elements in your business networks now that port costs are not so obvious nor directly tied to individual workloads. Virtual switches and port groups supplant complex switch configurations and switches that handle the majority of hypervisor-to-hypervisor traffic are mostly trunking VLANs instead of flat entities. (Here’s a thought: considering that virtual switches impress and strip 802.1q tags at ingress/egress points, are managed – even VLAN-aware – switches really needed for hypervisor interconnections?)

Cutting to the Chase

That last parenthetical is really my point: virtualization is pushing switching architectures (and decisions) to the hypervisor and away from the physical fabric too, just like it did with computational hardware. While I don’t recommend ditching a Cisco switch in favor of the unmanaged D-Link variety at 50%/port savings, approaching the network question from the hypervisor side becomes very appealing in small enterprise solutions.

Need more reasons? Try looking at LeftHand, Vyatta, pfSense or Proxmox and see how storage, networks and virtualization are rapidly becoming intertwined. An array of hypervisors – with a properly configured layer-2 physical interconnecting infrastructure – can provide HA routing, switching, storage and firewall functions all within the same replicable framework through software and workload virtualization. Just as routers and firewalls have gone from “dedicated hardware” to “appliances” (usually Linux or BSD based), so the hardware appliance could easily become (and is becoming) the virtual appliance.

Make Mine a Double

Small businesses be ready, your infrastructure is becoming a series of containerized entities managed by software delivered on commodity computational and switching hardware. A three or four node hypervisor stack with SAS-attached storage (could be SATA with expanders) can provide redundant storage, redundant firewall, redundant security appliances, redundant content filtering and network policy management without any dedicated equipment.

What makes it all work? Interconnecting networks and the people who have a deep understanding of what make them work and how to make them work for you. There, I’ve said it.</RANT>

%d bloggers like this: