Virtualization's Impact on Networks

How virtualization and mobile VMs are changing the way we build networks

I've often postulated that virtualization would require the network to change, dramatically. There are two main vectors to this argument, one technical, one business. Given I haven't done a decent Jimmy Ray Purser-esque technical deep-dive yet here to establish my 'street cred' let me take a stab at the technical first, will hit the business side of this in a follow-on post someday soon.

The first issue is VM-Sprawl. Let's face it, once server and virtualization teams start using virtual machines, they tend to like them. Once they like them they go through the data center like a missionary looking for workloads to migrate to the new virtualized environment. Couple this with the app developers who for the first time get something in minutes to hours instead of months and you have a hockey-stick effect in the number of devices/VMs under management.

Secondly, as my friend Dino is often a fan of stating, "any computer science problem can be solved with another level of indirection/abstraction." The virtual machine, as an abstraction, enables the workloads to move. Once a VM can move two questions immediately jump to mind, a) how far can I move it? and b) what physical hosts can I move it too?

As most virtualization administrators find out there are a lot of network changes necessary to move VMs outside of the data center. In some network designs where the top-of-rack switch is the default gateway you can't even move the VM out of the rack, much less out of the country. As for how many hosts you can potentially move the VM to, we are limited to a potential of up to 64 in the current vSphere version; however, there is nothing that dictates those sixty-four have to be in the same rack, chassis, system, or even data center.

Not surprisingly then, in order to accommodate larger domains of servers with mobile workloads the network administrators have been pushed to build larger and flatter switched Layer-2 networks that span an increased number of physical servers across differing set of critical infrastructure components (pods, zones, PDU's, etc) so that the impact of the failure of a critical component is reduced.

Network teams have also been asked to look at stretching the reach of these Layer-2 networks across geographies. Now part of me is reminded of Vitalink bridged networks back in the late 1980's and early 1990's, because while we can use EoMPLS, VPLS, GRE, mGRE, L2TPv3, and other tunneling mechanisms to extend a Layer-2 network across a routed core to another part of the world people haven't quite figured out how to solve the questions of 'where is my default gateway?' 'how does my firewall know to move the policy too?' and 'what does my load balancer do when its real-IPs are now four time-zones away?' These problems need to be resolved, preferably in scalable and easy-to-manage consistent ways.

Eventually we hit the third evolution of virtualization which we are seeing with the introduction of VMware Fault Tolerance and Dynamic Resource Scheduling - performance requirements increase. Most servers in the data center today are connected at Gigabit Ethernet (GbE); however once we start doing active-state synchronization, and dynamic workload movement to solve for CPU/Memory utilization efficiency the network performance requirement starts going up. That's a lot of data to move! The higher performance the network infrastructure is the faster these dynamic reallocations and page-syncs are written to the receiving host, thus the more seamless the move is.

• Performance matters in these environments, especially as new advanced virtualization capabilities come to the market.
• Lossless transmission, Latency, and cable consolidation matter here as well, they make the infrastructure more deployable, and let workloads have better access to all available resources.
• Ethernet and IETF standards will nee to evolve to enable a synchronization of these larger and flatter Layer-2 networks, especially when globally distributed.
• Standards matter, but most companies I have worked with will go with the best solution that solves their business problems first, if the problems are pressing. Standards are important, but corporate and IT viability and resilience trump.
• Every day now, VMs are rolling in, starting to move, and then moving more dynamically. Every day new companies are trying new software capabilities that used to take significant hardware and systems efforts to solve. Every day the legacy network designs we have all built, supported, and operated will be stressed in ways they were not designed for.

What's on the horizon technically? I hope it is better integration between the network and the virtualization platforms with an eye towards ensuring the conjoined infrastructure can be really deployed, really managed, and take advantage of the full features and capabilities each discipline has.

dg

Follow me on Twitter or on loopback0, my tech blog

• Cisco
• Data Center
• LANs / WANs
• Cisco
• drs
• fault tolerance
• flat networks
• gre
• MPLS
• network
• virtualization
• vm-ft
• VMware
• Vsphere