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 |
