In many organizations, virtualization technology is managed by the systems team, the data center team, or a specialized virtualization team. Seldom do I see network teams responsible for the virtual layer. This makes sense, but it can make managing the network requirements around virtualization difficult.
While it's true that virtualization has had a dramatic impact on the shape and size of most of our computing environments, we sometimes overlook the impacts that it's had on our network topology and the demands placed up on it. Physical distribution switches with solid security and tight integration with core switches for things like VLANs, security, and traffic management have been replaced, or at least augmented, by virtual switches. Most virtual switches lack features like port level security, netflow support, and trunking and encapsulation support. To get an advanced switch featureset you'd need to implement a virtual switch from a networking vendor vs. the free, out of the box virtual switches provided by the virtualization vendors. However, because these switches are usually implemented by the systems or virtualizations teams it's usually too late before the network team is aware of the change. Likewise, whether or not the virtual switch will share VLAN information with the upstream core swtich usually isn't high on the list of priorities for the team responsible for virtualizing the application server infrastructure.
Regardless of which virtualization vendor you choose and whose virtual switches your deploy, virtual switches have significantly altered our network designs and topologies. Surprisingly, in most data centers that I visit, when I look over their network drawings they still only include the physical switches.
**Tip - when you update your network diagrams be sure you include both virtual and physical switches, virtual and physical LANs and ports.
Possibly the most significant way that virtualization has impacted our networks is that it has enabled us to exponentially increase the density of our computing environments. Dense environments require ultra high speed infrastructure in order to avoid I/O and network bottlenecks.
The most dangerous aspect of these phenomena is that they can sneak up on you. When the systems team mentions that they're going to start deploying a few virtual servers it most likely seems harmless and probably will be at first. However, virtualization technology is usually very successful and before you know it you've got hundreds of new VMs.
When I was a teenager, a friend and neighbor (when you live in the country a neighbor is anyone you can ride a horse or ATV to within 30 minutes) called and asked for some help. His dad had hurt his back so Sunday they were going to go get a truck load of wood. Would I be willing to help them load it up? Hey, I'm the kind of guy that's always eager to help out a friend so I said no problem. Now, typically, a pickup truck will hold about one rick of wood, which is a stack of 16" logs that's stacked 8 feet long and 4 feet tall (this varies some geographically). Anyhow, when I get out to where we're cutting wood I realize that they didn't bring a pickup truck. They brought the largest dump truck that I'd ever seen. The sides must have been eleven feet tall. Even throwing the wood in meant that you had to split it first so that it was light enough to throw way up over the side. We loaded somewhere between 17 and 20 ricks of wood that day and me being the biggest, strongest, and most experienced of the group I did more than my share. I've learned to quantify terms like "truck load" since then.
Keep that story in mind when someone tells you that they want to add a new server to one of your subnets. Is it a physical application server? Is it a blade server with 20 or more blades in it, each running 10 VMs? Could it be a UCS server capable of hosting hundreds of VMs?
Likewise, as a network engineer you need to understand when upgrades to things like VMWare's VSphere5 are planned to occur. Within VSphere5 you can do things like:
- Over the network vMotion - move VMs from one vSphere instance to another
- Storage vMotion - move VMDKs across the network from one SAN to another
These features, while making VMs and their disk kernal files even more portable, can have an enormous impact on the network. You may have some work to do to ensure that you can reliably meet the demands of this technology on your network without impacting other network based applications and technologies.
Flame on...
Josh
Josh Stephens is Head Geek and VP of Technology at SolarWinds, an IT management software company based in Austin, Texas. He shares network management best practices on SolarWinds GeekSpeak and thwack. Follow Josh on Twitter@sw_headgeek and SolarWinds @solarwinds_inc.