Exportar (0) Imprimir
Expandir Tudo

Hyper-V Network Virtualization Overview

Publicado: fevereiro de 2012

Atualizado: fevereiro de 2012

Aplica-se a: Windows Server 2012

[Este tópico é uma documentação de pré-lançamento e está sujeito a alterações em versões futuras. Tópicos em branco são incluídos como espaços reservados.]

With the success of virtualized data centers, IT organizations and hosting providers (providers who offer colocation or physical server rentals) are offering flexible virtualized infrastructures that make it easier to offer on-demand server instances to their customers. This new class of a service is referred to as infrastructure as a service (IaaS). Windows Server 2012 provides all the required platform capabilities to enable enterprise customers to build private clouds and transition to an IaaS operational model, and also to enable hosting providers to build public clouds and offer IaaS solutions to their customers.

Network virtualization in Windows Server 2012 provides policy-based, software-controlled network virtualization, which reduces the management overhead that is faced by enterprises when they are expanding dedicated IaaS clouds. Network virtualization also provides better flexibility for cloud hosting providers, scalability for managing virtual machines, and higher resource utilization.

Problem

An IaaS scenario where multiple virtual machines from different divisions (dedicated cloud) or different customers (hosted cloud) requires secure isolation. Currently, virtual LANs (VLANs) are the mechanism most organizations use to provide address space reuse, and tenant isolation. A VLAN uses explicit tagging in the Ethernet frames, and it relies on Ethernet switches to enforce isolation and restrict traffic to network nodes of the same tag. The main drawbacks with VLANs are:

  • Increased risk of an inadvertent outage due to cumbersome reconfiguration of production switches whenever virtual machines or isolation boundaries move in the dynamic data center.

  • Limited scalability because typical switches support no more than 1,000 VLAN IDs (maximum of 4,094).

  • VLANs cannot span multiple logical subnets, which limits the number of nodes within a single VLAN and restricts the placement of virtual machines based on physical location. Even though VLANs can be enhanced or stretched across physical intranet locations, the stretched VLAN must be all on the same subnet.

In addition to the drawbacks presented by VLANs, virtual machine IP address assignment presents other significant issues, including:

  • Moving to a cloud platform typically requires reassigning IP addresses for the service workloads.

  • Policies (security, management, and other) are tied to IP addresses.

  • Physical locations determine the virtual machine IP address.

  • The topological dependency of virtual machine deployment and traffic isolation.

The IP address is the fundamental address that is used for layer 3 network communication. In addition to being an address, there is semantic information associated with an IP address. For example, one subnet might contain specific services or be in a distinct physical location. Firewall rules, access control policies, and Internet Protocol security (IPsec) security associations are commonly linked to IP addresses. Unfortunately, when moving to the cloud, the IP addresses must be changed to accommodate the physical and topological restrictions of the data center. This renumbering of IP addresses is burdensome because all of the associated policies based on IP addresses must also be updated.

When data center network administrators plan the physical layout of the data center, they must make decisions about where subnets will be physically placed and routed in the data center. These decisions are based on IP and Ethernet technologies that are 30 years old. These technologies influence the potential IP addresses that are allowed for virtual machines running on a specific server or server blade that is connected to a specific rack in the data center. When a virtual machine is provisioned and placed in the data center, it must adhere to the choices and restrictions regarding the IP address. Therefore, the typical result is that data center administrators assign IP addresses to the virtual machines, forcing the virtual machine owners to adjust all their policies that were based on the original IP address. This renumbering overhead is so high that many enterprises deploy only new services into their cloud platform, leaving legacy applications alone.

Solution

Network virtualization in Windows Server 2012 removes the constraints of VLAN and hierarchical IP address assignment for virtual machine provisioning. It makes IaaS cloud computing easy for customers to implement, and easy for hosting providers and data center administrators to manage. In addition, network virtualization maintains the necessary multitenant isolation and security requirements. The following list summarizes the key benefits and capabilities of network virtualization in Windows Server 2012:

  • Uncouples workloads from internal IP addresses. Enables customers to keep their internal IP addresses while moving workloads to shared IaaS cloud platforms. Uncoupling workloads from internal IP addresses minimizes the configuration changes that are needed for IP addresses, DNS names, security policies, and virtual machine configurations.

  • Decouples server and network administration. Server workload placement is simplified because migration and placement of workloads are independent of the underlying physical network configurations. Server administrators can focus on managing services and servers, while network administrators can focus on overall network infrastructure and traffic management.

  • Removes the tenant isolation dependency on VLANs. In the software-defined, policy-based data center networks, network traffic isolation is no longer dependent on VLANs, but enforced within host computers running Hyper-V based on the multitenant isolation policy. Network administrators can still use VLANs to manage traffic for the physical infrastructure where the topology is primarily static.

  • Enables flexible workload placement. Allows services and workloads to be placed or migrated to any server in the data center. They can keep their IP addresses, and they are not limited to a physical IP subnet hierarchy or VLAN configurations.

  • Simplifies the network and improves server and network resource utilization. The rigidity of VLANs and dependency of virtual machine placement on physical network infrastructure results in overprovisioning and underutilization. By breaking the dependency, the increased flexibility of virtual machine workload placement can simplify network management and improve server and network resource utilization.

  • Works with existing infrastructure and emerging technology. Network virtualization can be deployed in current data center environments, and it is compatible with the emerging data center “flat network” technologies, such as the Transparent Interconnection of Lots of Links (TRILL) architecture that is intended to expand Ethernet topologies.

  • Supports configuration by using Windows PowerShell and WMI. You can use Windows PowerShell to enable scripting and automation of administrative tasks.

Network virtualization in Windows Server 2012 requires Windows Server 2012 with the Hyper-V role.

Server virtualization is a concept that allows multiple server instances to run on a single physical host computer concurrently, yet isolated from each other, with each server instance operating as if it is the only server running on the physical computer. Network virtualization provides a similar capability, in which you can run multiple virtual network infrastructures, potentially with overlapping IP addresses, on the same physical network. With network virtualization, each virtual network infrastructure operates as if it is the only one running on the shared network infrastructure. Figure 1 shows this relationship.

Figura 1

Figure 1  Virtualization for servers and networks

To virtualize the network with Windows Server 2012, each virtual machine is assigned two IP addresses:

  • The customer address is the IP address that is assigned by the customer based on their intranet infrastructure. This address allows the customer to exchange network traffic with the virtual machine as if it had not been moved to a public or private cloud. The customer address is visible to the virtual machine and reachable by the customer.

  • The provider address is the IP address that is assigned by the hosting provider based on their physical network infrastructure. The provider address appears in the layer-3 packets that are exchanged with the server that is running Hyper-V and is hosting the virtual machine. The provider address is visible on the physical network, but not to the virtual machine.

The layer of customer addresses maintains the topology of the customer network, which is virtualized and decoupled from the actual underlying physical network or physical network addresses, as implemented by the layer of provider addresses.

There are two techniques to virtualize the IP address of the virtual machine. One technique, called IP rewrite, modifies the customer IP address of the packets on the virtual machine before they are transferred on the physical network. IP rewrite is used to provide better performance because the networking offload technologies in Windows, such as virtual machine queue (VMQ), continue to operate as they have in the past.

The other IP virtualization technique is IP encapsulation. In IP encapsulation, all of the virtual machines packets are encapsulated with a new header before being sent on the physical network. IP encapsulation offers better scalability because all of the virtual machines on a specific host can share the same provider IP address. The tenents are identified by examining the header of the encapsulated packet, which contains a tenant network ID. Because all of the virtual machines are sharing the provider IP address, the switching infrastructure only needs to know about the IP address and media access control (MAC) address for the provider address. This can result in a 20 times or greater reduction in the number of addresses that need to be learned by the network infrastructure, thus reducing the size of IP/MAC tables. Large IP/MAC tables are expensive because they require high-end switches.

With network virtualization in Windows Server 2012 any virtual machine workload can run unmodified on any server running Windows Server 2012 with Hyper-V, within any physical subnet. To do so, the server running Windows Server 2012 with Hyper-V must have the required policy settings that can map between the two addresses. This approach enables many benefits, which include cross-subnet live migration, customer virtual machines running IPv4 while the hosting provider is running an IPv6 data center (or vice-versa), and the use of IP address ranges that overlap between customers.

Consider the example in Figure 2.

Figura 2

Figure 2   Customer address virtualization

Prior to moving to the shared IaaS service of the hosting provider, Blue Corp and Red Corp ran the following server configurations:

  • A SQL Server (named SQL) at the IP address 10.1.1.1.

  • A web server (named WEB) at the IP address 10.1.1.2, that uses its SQL Server for database transactions.

Blue Corp and Red Corp move their respective SQL and web servers to same shared IaaS service of the hosting provider where they run the SQL virtual machines in Hyper-V Host 1 and the web virtual machines in Hyper-V Host 2.

All virtual machines maintain their original intranet IP addresses (their customer addresses). Both companies are assigned the following provider addresses by their hosting provider when the virtual machines are provisioned:

  • Provider addresses for Blue Corp virtual machines: SQL is 192.168.1.10, WEB is 192.168.1.12

  • Provider addresses for Red Corp virtual machines: SQL is 192.168.1.11, WEB is 192.168.1.13

The hosting provider creates policy settings, which consist of an isolation group for Red Corp that maps the customer addresses of the Red Corp virtual machines to their assigned provider addresses and a separate isolation group for Blue Corp that maps the customer addresses of the Blue Corp virtual machines to their assigned provider addresses. The provider applies these policy settings to Hyper-V Host 1 and Hyper-V Host 2.

When the Blue Corp WEB virtual machine on Hyper-V Host 2 queries its SQL Server at 10.1.1.1, the following happens:

  1. Hyper-V Host 2, based on its policy settings, starts with the addresses in the packet from:

    • Source: 10.1.1.2 (the customer address of Blue Corp WEB)

    • Destination: 10.1.1.1 (the customer address of Blue Corp SQL)

  2. Hyper-V Host 2 translates those addresses to:

    • Source: 192.168.1.12 (the provider address for Blue Corp WEB)

    • Destination: 192.168.1.10 (the provider address for Blue Corp SQL)

  3. When the packet is received at Hyper-V Host 1, based on its policy settings, it will accept the addresses in the packet from:

    • Source: 192.168.1.12 (the provider address for Blue Corp WEB)

    • Destination: 192.168.1.10 (the provider address for Blue Corp SQL)

  4. Hyper-V Host 1 then translates the addresses back to:

    • Source: 10.1.1.2 (the customer address of Blue Corp WEB)

    • Destination: 10.1.1.1 (the customer address of Blue Corp SQL)

  5. Hyper-V Host 1 delivers the packet to the Blue Corp SQL virtual machine.

When the Blue Corp SQL virtual machine on Hyper-V Host 1 responds to the query, the following happens:

  1. Hyper-V Host 1, based on its policy settings, starts with the addresses in the packet from:

    • Source: 10.1.1.1 (the customer address of Blue Corp SQL)

    • Destination 10.1.1.2 (the customer address of Blue Corp WEB)

  2. Hyper-V Host 1 translates those addresses to:

    • Source: 192.168.1.10 (the provider address for Blue Corp SQL)

    • Destination: 192.168.1.12 (the provider address for Blue Corp WEB)

  3. When it is received at Hyper-V Host 2, based on its policy settings, it will accept the addresses in the packet from:

    • Source: 192.168.1.10 (the provider address for Blue Corp SQL)

    • Destination: 192.168.1.12 (the provider address for Blue Corp WEB)

  4. Hyper-V Host 2 then translates the addresses to:

    • Source: 10.1.1.1 (the customer address of Blue Corp SQL)

    • Destination: 10.1.1.2 (the customer address of Blue Corp WEB)

  5. Hyper-V Host 2 delivers the packet to the Blue Corp WEB virtual machine.

A similar process for traffic between the Red Corp WEB and SQL virtual machines uses the settings in the Red Corp isolation group. With network virtualization, Red Corp and Blue Corp virtual machines interact as if they were on their original intranets, but never with each other—even though they are using the same IP addresses. The separate addresses (customer addresses and provider addresses), the policy settings of the hosts running Hyper-V, and the address translation between the customer address and provider address for inbound and outbound virtual machine traffic isolate these two sets of servers from each other.

The setting and maintenance of the network virtualization capabilities require the use of a policy management server, which can be integrated into the management tools that provide virtual machine management.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários

Contribuições da comunidade

A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft