Windows Server 2012 : A complete virtualization platform (part 4) - Network virtualization

1/23/2014 2:43:23 AM

2. Network virtualization

In the IaaS cloud computing model, the cloud provider runs a datacenter that offers “VMs for rent” along with dynamically allocated resources. The customer owns the VM and manages it as “its server” in the cloud. The meaning of the terms cloud provider and customer can differ, of course, depending on whether you’re talking about a shared private cloud or a shared public cloud. Specifically, the following points apply:

In the shared private cloud scenario, the cloud provider is the organization itself, which owns and operates its own datacenter, whereas the customers might be different business units, departments, or offices in different locations.
In the shared public cloud scenario, the cloud provider is the hosting company, whereas the customers might be large enterprises, mid-sized companies, or even small businesses. The hosting company owns and manages the datacenter and may “rent out” servers to customers, offer colocation of customer-owned servers, or both.

In both scenarios, the cloud provider can provide the numerous benefits of cloud computing to its customers, but typically not without problems using today’s technologies. For example, VLANs are typically used by cloud providers to isolate the servers belonging to one customer from those belonging to other customers and provisioned from the same cloud. VLANs accomplish this by adding tags to Ethernet frames. Then Ethernet switches can be configured to enforce isolation by allowing nodes that have the same tag to communicate with each other, but not with nodes having a different tag. But VLANs have several limitations:

They have limited scalability because typical Ethernet switches support no more than 1,000 VLAN IDs (with a theoretical maximum of 4,094).
They have limited flexibility because a single VLAN can’t span multiple IP subnets.
They have high management overhead associated with them because Ethernet switches need to be reconfigured each time a VLAN is added or removed.

Another problem that customers often experience when contemplating moving their computing resources to the cloud is IP addressing. The issue is that the customer’s existing infrastructure typically has one addressing scheme, whereas the datacenter network has an entirely different addressing scheme. So when a customer wants to move one of its servers into the cloud, typically by virtualizing the workload of the existing physical server so the workload can be run as a VM hosted within the cloud provider’s datacenter, the customer is usually required to change the IP address of their server so it can fit the addressing scheme of the cloud provider’s network. This can pose difficulties, however, because IP addresses are often tied to geographical locations, management policies, and security policies, so changing the server’s address when its workload is moved into the cloud may result in routing issues, servers moving out of management scope, or security policies failing to be applied properly.

It would simplify cloud migrations a lot if the customer’s servers could keep their existing IP addresses when their workloads are virtualized and moved into the cloud provider’s datacenter. That way, the customer’s existing routing, management, and security policies should continue to work as before. And that’s exactly what network virtualization does!

How network virtualization works

Network virtualization is a new feature of Windows Server 2012 that lets you keep your own internal IP addresses when moving your servers into the cloud. For example, let’s say that you have three on-premises physical servers having private IP addresses 192.168.33.45, 192.168.33.46, and 192.168.33.47, and you want to move these servers to the datacenter of a cloud provider called Fabrikam. These servers are currently in the 192.168.0.0/16 address space, and Fabrikam’s datacenter uses 10.0.0.0/24 for its datacenter network’s address space. If Fabrikam has Windows Server 2012 deployed in its datacenter, you’re in luck because your servers can keep their existing IP addresses when their workloads are migrated into VMs running on Fabrikam host machines. This means that your existing clients, which are used to accessing servers located on the 192.168.0.0/16 subnet, will be able to continue doing so with no modifications needed to your routing infrastructure, management platform, or network security policies. That’s network virtualization at work.

But what if another customer of Fabrikam uses the exact same subnetting scheme for its own virtualized workloads? For example, let’s say that Northwind Traders also has been using 192.168.0.0/16 on its private network, and one of the servers it’s moved into Fabrikam’s datacenter has the exact same IP address (192.168.33.45) as one of the servers that you’ve moved into Fabrikam’s datacenter? No problem! Network virtualization in Windows Server 2012 provides complete isolation between VMs belonging to different customers even if those VMs use the exact same IP addresses!

Network virtualization works by allowing you to assign two different IP addresses to each VM running on a Windows Server 2012 Hyper-V host. These two addresses are:

The customer address, which is the IP address that the server had when it resided on the customer’s premises before it was migrated into the cloud. In the previous example, this might be the 192.168.33.45 address for a particular server that the customer wants to move to the cloud.
The provider address, which is the IP address assigned by the cloud provider to the server once the server has been migrated to the provider’s datacenter. In the previous example, this could be 10.44.2.133, or some other address in the 10.0.0.0/24 address space.

From the customer’s perspective, communication with the migrated server is just the same as if the server still resided on the customer’s own premises. This is because the VM running the customer’s migrated workload can see and use its customer address and thus can be reached by other hosts on the customer’s network. The VM cannot see or use its provider address, however, because this address is visible only to the hosts on the cloud provider’s network.

Network virtualization thus lets the cloud provider run multiple virtual networks on top of a single physical network in much the same way as server virtualization lets you run multiple virtual servers on a single physical server. Network virtualization also isolates each virtual network from every other virtual network, with the result that each virtual network has the illusion that it is a separate physical network. This means that two or more virtual networks can have the exact same addressing scheme, yet the networks will be fully isolated from one another and each will function as if it is the only network with that scheme.

To make this all happen, network virtualization needs a way of virtualizing IP addresses and mapping them to physical addresses. Network virtualization in Windows Server 2012 offers two ways of accomplishing this:

IP rewrite This approach modifies the customer addresses of packets while they are still on the VM and before they are transmitted onto the physical network.
IP encapsulation In this approach, all the VM’s packets are encapsulated with a new header before they are transmitted onto the physical network.

Although IP encapsulation offers better scalability, IP rewrite can provide better performance because it can use the existing capabilities of transferring some of the load to high-end network adapters that support such offloading.

Because network virtualization is intended for datacenters, implementing it requires that you have a VM management framework in place. System Center Virtual Machine Manager 2012 Service Pack 1 provides such a framework and lets you use PowerShell or WMI to create and manage virtual networks.

Benefits of network virtualization

Network virtualization is key to being able to build and provision multi-tenant cloud services, both for shared private clouds, where the “customers” are different business units or departments, and for public cloud scenarios, where the cloud provider offers “space to rent” to all comers. Network virtualization lets you create multi-tenant networks where each network is fully isolated from all other networks, and it does this without any of the limitations of or overhead associated with the job of creating and managing VLANs. This means that cloud providers can use network virtualization to create as many networks as you want—thousands and thousands of them for example if you are a large hosting provider—and then move workloads anywhere you want without having to perform the arduous (and error-prone) task of reconfiguring VLANs.

Network virtualization also provides greater flexibility for VM placement, which helps reduce overprovisioning and fragmentation of resources for the cloud provider. By enabling dynamic VM placement, the cloud provider can make best use of the compute, network, and storage resources within their datacenter and can monitor and control the provisioning of these resources more easily.

Regardless of whether you are a customer looking to migrate your server workloads into the cloud, an enterprise seeking to implement a shared private cloud for provisioning “servers for rent” to different divisions or locations, or a hosting provider wanting to offer cloud hosting services to large numbers of customers, network virtualization in Windows Server 2012 provides the foundation for achieving your goals. Table 2 summarizes the benefits of network virtualization to these different parties.

Table 2. The benefits that network virtualization can provide to customers, enterprises, and hosting providers

Owner	Benefits
The customer who owns the workload that needs to be moved into the cloud	Seamless migration to the cloud Easy to move your three-tier topology to the cloud
An enterprise seeking to deploy a shared private cloud	Easy cloud bursting Preserve your VM settings, IP addresses, and policies Cross premises server-to-server connectivity
A hosting provider wanting to offer secure, multi-tenant “servers for rent” using a shared public cloud	Flexible VM placement requiring no network reconfiguration Create and manage large number of tenant networks

Network virtualization operational challenges

The network virtualization capabilities found in Windows Server 2012 provides a fresh approach to an old problem, and that is primarily that of operator density. Operators, or service providers, are no longer interested in 1:1 solutions. They want more virtual servers per physical server today the same way they wanted more subscribers for a given pool of dial-up modems at the early of days of the World Wide Web. Density typically came at the price of mobility and scalability. Today, of course, this is less of an issue, at least in datacenter virtualization scenarios, as we can have density pushing the limits of hardware while maintaining mobility and scalability.

There was always one difficult problem to solve: how to extend the mobility and scalability of a single datacenter to two or more. This was often required either as datacenters ran out of space or often after a merger or acquisition. Nearly every customer I have worked with in the past five years has or had a datacenter relocation or consolidation project. The problem was now: how do I move these servers to new datacenters while maintaining all the monitoring and security policies associated with their location? The answer usually consisted of storage and network architects sitting down and installing new network and storage equipment which really extended the network subnet(s) from one datacenter to another. This, in a way, was the precursor to network virtualization, and we were able to learn a lot from this. Especially with respect to the newer problems we discovered as a result. Some of the problems we discovered included:

Application behavior Moving the VM from one datacenter to another typically introduced network latency. Some applications just did not behave well with the added latency.
Supportability It was now difficult for datacenter technicians to effectively know which datacenter a VM was located in by looking at its IP address.
Licensing It used to be that some vendors licensed their products to a single IP address. This proved challenging to customers, so certain vendors changed their licensing to be based on the MAC address of the host’s NIC. This meant that moving the VM (while keeping its IP) to another datacenter meant it had to keep the same MAC address. Although this is typically possible within a single management domain, this is impossible to predict when that VM was being moved, for instance, to a service provider or a private cloud provider.

Looking back at these problems, I realized the key to avoiding them was to involve the application and server operations. Although this sounds incredibly trivial in theory, it is incredibly difficult to do in practice. How often do you get involved in a project involving network virtualization if you are the corporate custodian or owner of the HR application, for instance?

Server virtualization forced teams to learn to communicate with other teams. Network virtualization will make that even more critical. When you decide to implement network virtualization features found in Windows Server 2012, consider adding teams with operational experience to your team and ensure key application support teams are also consulted.