Network Virtualization: Shooting Star or Brave New World?

SDN, Big Data, cloud platforms, and next-generation application workloads may make network virtualization a necessity. Here's why—and how.

By  | Posted Apr 29, 2014
Page of   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

By Kevin Deierling

Editor's Note: Occasionally, Enterprise Networking Planet is proud to run guest posts from authors in the field. Today, Kevin Deierling of Mellanox makes the case for network virtualization as a necessary part of the data center ecosystems of the future.

When it first appeared in the early 2000’s—in the wake of the dotcom bubble implosion—the idea of server virtualization was met with great skepticism. However, over the course of the past decade, leaders like VMware have helped server virtualization drive the most significant transformation in the data center since the PC due to key advantages like server utilization improvement, operational expense reduction, and increased infrastructure efficiency.

Fast forward 15 years. It is now the network's turn to be virtualized. Network virtualization technologies were initially received with great fanfare and billion-dollar acquisitions but have since moved from Gartner’s proverbial "height of over-stated expectations" to the "trough of reality." Opponents, including some large networking incumbents, derisively refer to the closely related SDN not as "Software Defined Networking," but as "Software that Does Nothing."

So the question is this: Will network virtualization follow the path of a technology like the OS2 operating system, or is it emerging as a disruptive and transformative new technology, the way server virtualization did?

Many argue that network virtualization will ultimately fail because it does not provide the same benefits as server virtualization. They argue that unlike physical servers, existing networking equipment already has monitoring and management frameworks that allow switches to operate at or near capacity while being easily managed. But this perspective is entirely myopic and self-serving. It views the network as an isolated and independent element, entirely distinct from compute and storage resources.

In fact, traditional three-tier architectures are crumbling beneath the brave new world of Big Data and cloud computing. Applications like Hadoop and NoSQL databases and cloud platforms like Azure, OpenStack and vCloud are fundamentally changing network architectures. Instead of networking being managed as a means to connect discrete components in a data center, architects of scalable cloud infrastructure must take a holistic view of resources to build a single integrated platform. From this vantage point, network virtualization becomes absolutely essential to provide an elastic and scalable workload capacity engine, rather than a connection between discrete physical elements which are managed individually.

Essentially, network virtualization is the natural and necessary evolution of server virtualization. It allows the entire data center to be managed as a single, giant (essentially infinite) compu-storage resource able to meet dynamic application workloads on demand. When viewed from this perspective, network virtualization delivers precisely the same utilization, OPEX, and efficiency benefits that drove the success of server virtualization.

So let’s look at the implications and requirements for this new world of virtualized networks and elastic cloud workload capacity.

SDN architecture

Figure 1 shows the virtual and physical view of a software defined network. The physical network includes switches, routers and servers. The virtual view shows that there are multiple networks that are logically isolated from one another.  At the boundary between these two views within the server is the OpenvSwitch (OVS), which performs the steering and encap/decap functions required to map between physical and virtual networks. The OVS can be implemented as a purely software function, though for performance reasons related to the heavy processing load imposed by virtualized tunneling, a hybrid hardware/software approach using virtualization-aware NICs is preferred.

There are elements that typically characterize SDN: overlay networks, centralized management, and standardized APIs. The first two elements are required, while standardized APIs are nice to have to enable interoperability and uniform control in a heterogeneous environment, as well as to avoid proprietary APIs.

Benefits of Overlay Networks in SDN

The addition of overlay networks improves isolation between virtual networks and allows easier management of VM-based workloads. Each virtual domain has its own network and link (VIP and VMAC -based inner packet) addresses encapsulated within the outer packet. This allows VMs to operate completely independently of the actual physical addresses used to move the packets through the network. Thus, VM migration of a workload from one physical machine to another does not affect a VM-based application, which retains the same virtual addresses. Instead, the move occurs by changing the mapping of the tunneled virtual address to the appropriate physical address. This is performed by the centralized management platform, as I will describe in more detail in the next section.

Centralized Virtual Network Management Platform

SDN is often described as the separation of the control and data planes, where the control plane decides where a given packet should be forwarded using sophisticated routing algorithms and the data plane does the actual forwarding as instructed. In fact, with network virtualization, the control plane makes forwarding decisions and more. A centralized virtual network management platform(VNMP), such as Open Daylight, has complete visibility of both the physical and virtual networks. The VNMP serves as a trusted entity to perform virtual network discovery, routing, management, monitoring, and isolation. Higher-level applications like load balancing, threat detection/prevention, and orchestrationcan invoke the services of the VNMP to perform the required functions, such as VM migration or controlling access to virtual network resources.

One example makes abundantly clear the value of centralized management of a virtualized network. Consider moving a VM from one physical server to another for either load balancing or performance purposes. In the old world of purely physical networks, such a move would require a new MAC and IP address to be associated with the VM. This new information would need to be propagated to every server, switch and router in the network, requiring application-level changes and routing table updates to reflect the new physical location of the VM. Now imagine trying to do this very quickly in an automated fashion.  In large networks with a great number of servers and switches, an automatic update is virtually impossible, almost guaranteeing that VM migration will result in significant downtime. And all this because a purely virtual entity (the VM) was unnecessarily tied to the physical address of the server on which it was currently being hosted.

This can all be overcome with network virtualization. The virtual IP address of the VM remains unchanged, so neither applications nor physical network infrastructure need to change. Instead, only the mapping from the virtual to physical addresses needs to be updated. And this occurs in one place, since the centralized virtual network management platform is responsible to maintain the virtual-to-physical address translations. As a result, a VM migration becomes as simple as updating the VNMP with the desired change. Granted, the VNMP needs to push this information to each of the OVS entities in the network, but automation becomes much easier than in the independent updates required in a physical network.

Standardized SDN API

To avoid vendor lock-in, a standardized API is preferred for the VNMP to communicate with the embedded OVS agents in order to control the virtual networks. OpenFlow is one such API that has gained significant traction and broad industry support. The flexibility of OpenFlow is such that it can be used not just to interface to software but also to hardware, with at least one hardware vendor converging on this API to control both the forwarding plane in its switch hardware and to control the hardware OVS embedded in virtualization-optimized NICs.

Summary

As a result of these key elements, SDN-based, virtualized networks are able to:

  • Control and manage virtual network connections between virtual machines
  • Monitor and control access and communications between the virtual and physical resources
  • Deliver flexibility in both deployment and  operational updates of virtual resources

Used together, these capabilities allow SDN-based data centers to operate more efficiently and with better scalability than conventionally networked infrastructure. Specifically, SDN and network virtualization improve physical resource utilization, reduce operational expense, and deliver application efficiency, extending and improving upon the benefits delivered by the earlier and now wildly successful server virtualization technologies. In this case, past is prologue, and SDN and network virtualization will succeed by delivering precisely the same business CAPEX and OPEX savings that resulted in the success of server virtualization.

Header photo courtesy of Shutterstock.

Kevin Deierling, MellanoxKevin Deierling has served as Mellanox's vice president of marketing since March 2013. Previously, he held various business and technical leadership roles, including as chief architect at Silver Spring Networks. Deierling has contributed to multiple technology standards through organizations including the InfiniBand Trade Association and PCI Industrial Manufacturing Group. Mr. Deierling holds a degree in Physics from UC Berkeley.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter