Network Virtualization in Hyper-V. Concept
In Windows Server 2012 , network virtualization technology (Network Virtualization, NV) has appeared, providing the possibility of virtualization at a fundamentally new level - the network segment level. Unlike the usual server virtualization, NV will allow you to virtualize IP subnets and completely hide the real IP addressing used in your infrastructure from virtual machines (VMs) and applications inside the VM. In this case, VMs can still interact with each other, with other physical hosts, with hosts on other subnets.
From a technological point of view, network virtualization is a rather complicated mechanism, so it’s probably not possible to make a more or less complete overview of this technology in one post. Today we will discuss the concept and architecture, in the next post I will focus on configuring NV, then we will talk separately about the organization of external access to VM running on a virtualized network.
Let's start with the fundamental question: “What is network virtualization for?”
')
In the case of server virtualization with a few reservations, the OS inside the VM works as if it were installed on a physical server and was the only OS on this hardware. Such an abstraction allows you to run several isolated instances of virtual servers on the same physical. By analogy, network virtualization leads to the fact that a virtual network, or rather, in this context, a virtualized network, functions as if it were a physical network. Accordingly, this level of virtualization allows you to create and use multiple virtual networks, possibly with overlapping or even completely coinciding IP address spaces, on the same physical network infrastructure. And this network infrastructure, generally speaking, can include an arbitrary number of physical servers and network equipment (see the figure below).
In the above figure, virtual machines from the blue network and the red network belonging to different departments or organizations can use the same IP addresses, can be running on the same or different physical hosts, but on the one hand, they will be are completely isolated from each other, and, on the other hand, they will without any problems interact with other network objects (real or virtual) of their department or organization. This implies the appointment of NV technology, the advantages and main scenarios of its application.
Greater flexibility in the placement of VMs within the data center
NV provides a certain freedom when deploying VMs within the data center. In particular, VM placement involves setting up an IP address corresponding to the physical network segment, and setting up a VLAN to provide isolation. Since NV allows coexistence on the same VM host with the same IP addresses, we are no longer bound by the IP addressing scheme used in the data center and do not rest on the restrictions imposed by the VLAN.
Simplified VM transfer to the cloud
Since when using network virtualization, the IP address and configuration of the VM remain unchanged, this greatly simplifies the process of transferring the VM to the neighboring organization's data center, to the hosting cloud or public cloud. Both application clients and IT administrators continue to use their tools to interact with the VM / application without reconfiguration.
Live Migration out of subnet
VM dynamic migration is limited to the limits of an IP subnet (or VLAN). If you migrate VMs to another subnet, you will need to reconfigure the IP inside the guest OS with all the ensuing consequences. However, if live migration is performed between two hosts with Windows Server 2012 with NV enabled, then the hosts can be located in different segments of the physical network, while network virtualization will ensure the continuity of network communications of the roaming VM.
Increased utilization of physical hosts and networks
The lack of dependence on IP addressing and VLANs allows you to more evenly load physical hosts and more efficiently utilize available resources. It should be noted that NV supports VLANs, and you can combine both isolation methods, for example, by isolating NV traffic in a dedicated VLAN for this purpose.
When configuring NV, a pair of IP addresses is associated with each virtual network adapter (vNIC):
In the process of network interaction, the VM forms a packet with the sender and receiver addresses from the CA space. Such a package leaves the VM and the Hyper-V host is packed into a package with the sender and recipient addresses from the PA space. PA addresses are determined based on the virtualization policy table. After that, the packet is transmitted over the physical network. The Hyper-V host that received the packet, based on the same virtualization policy table, performs the reverse procedure: retrieves the source packet, determines the recipient VM, and redirects the source packet with the CA addresses of the desired VM.
Thus, network virtualization ultimately boils down to virtualizing the addresses used by virtual machines. In turn, address virtualization in Hyper-V Windows Server 2012 is possible using two mechanisms: Generic Routing Encapsulation and IP Rewrite. Consider briefly each of them.
In the first mechanism, the source packet with CA addresses is encapsulated into a GRE structure (Generic Routing Encapsulation, see RFC 2890 ), which is packaged in an IP packet with the necessary PA addresses. A unique virtual subnet identifier (Virtual Subnet ID, the “GRE key” field in the figure), which owns the source packet, and the MAC addresses of the sender's and recipient's virtual network adapters are also added to the GRE header.
The subnet identifier allows the recipient host to correctly identify the VM for which the packet is intended, even if the CA addresses in the VM of different customers may coincide. The second important feature of this mechanism is that, regardless of the number of VMs running on a VM host, one PA address is enough to transfer packets from any VMs. This significantly affects the scalability of the solution when using the GRE mechanism of address virtualization. Finally, it should be noted that the described scheme is fully compatible with the existing network equipment and does not require any updating of network adapters, switches or routers.
However, in the future, it would not be superfluous that the switch or router could analyze the Virtual Subnet ID field of the packet, and the administrator could set the appropriate rules for switching or routing packets based on this field. Or, for example, so that all tasks related to GRE unpacking take on the network adapter. To this end, Microsoft, together with partners, developed the NVGRE standard — Network Virtualization using Generic Routing Encapsulation, which is currently in the IETF Draft stage. In particular, this standard regulates the 24-bit Tenant Network Identifier (TNI) field for storing the subnet identifier, protocol type 0x6558, indicating the NVGRE packet, and other nuances.
The second mechanism is somewhat simpler in its ideology. Each CA-address is assigned a unique PA-address. When a packet leaves the VM, the Hyper-V host in the IP packet header replaces the CA addresses with PA addresses and sends the packet to the network. The receiving host performs the return address replacement and delivers the VM packet. As follows from the described algorithm, on each physical host with the Hyper-V role, it is necessary to configure as many PA addresses as the CA addresses are used in all virtual machines running on this host that use network virtualization.
Encapsulating packages with GRE requires additional overhead. Therefore, for scenarios with high bandwidth requirements, for example, for VMs actively using a 10Gbps adapter, IP Rewrite is recommended as once. For most other cases, the GRE mechanism is optimal. Well, with the advent of equipment supporting NVGRE, this mechanism will not yield IP Rewrite in performance.
In the terminology of Hyper-V Network Virtualization, the customer is the "owner" of the VM group deployed in the data center. In practice, if we are talking about the data center of the hosting service provider, such a customer could be any company or organization. If we are talking about a private cloud, then the customer, as a rule, is a department or division of the organization. In any case, the customer can own one or several networks (Customer Network), and each such network consists of one or several virtual subnets (Virtual Subnet).
Customer Network
Virtual subnet
The use of these two concepts allows the customer to transfer their network topology to the cloud. In fig. Below are two Blue company networks - the R & D network and the sales department network. Initially, these networks are isolated and should not interact with each other. Since these networks are assigned different RDIDs when migrating to Hyper-V Network Virtualization, the VMs of these networks cannot “see” each other. In this case, for example, VMs from virtual subnets 1, 2, and 3 of the R & D network can exchange packets.
NV is only available in Windows Server 2012.
On hosts with Hyper-V Network Virtualization, a virtualization policy must be maintained, which actually sets and stores information about CA and PA spaces, RDID and VSID, and the address virtualization mechanisms used. Windows Server 2012 contains a set of software interfaces (APIs) with which the software can manage all aspects of NV. In the simplest case, such control software can be PowerShell scripts; in an industrial scenario, System Center 2012 Virtual Machine Manager SP1 (VMM) performs this role. I draw attention to the fact that it was with the release of SP1 in System Center 2012 appeared support for Windows Server 2012, and therefore NV.
The settings specified in the virtualization policy are directly applied by the NDIS (Network Driver Interface Specification) filter driver, called Windows Network Virtualization (WNV). The WNV filter is located below the Hyper-V Extensible Switch. This means that the Hyper-V switch and all its extensions (if any) work with CA addresses and do not know anything about PA addresses. However, VSIDs are available to the switch and extensions, so the Hyper-V Extensible Switch is able to distinguish, for example, CA addresses 10.0.0.5 belonging to different customers.
If network virtualization is enabled for the VM, then for the Hyper-V Extensible Switch ports to which the virtual network adapters of this VM are connected, the hypervisor includes access control lists (ACL). Read more about ACL here . The ACL indicates the VSID of the virtual subnet that owns the VM. Any packets arriving at this switch port with a VSID other than the one specified in the ACL are ignored.
Taking this logic into account, moving packages looks like this. Outgoing from the VM packet through the port of Hyper-V Extensible Switch gets into the WNV filter, which analyzes the NV virtualization policy and applies the necessary operations to the packet (replacing the IP address or packing in GRE), after which the packet is sent to the network.
On the receiving side, the incoming packet falls into the WNV filter, which analyzes the NV virtualization policy. If the incoming packet is a GRE packet, the filter reads the VSID field from the GRE header, retrieves the original IP packet and sends it along with the VSID to that Hyper-V Extensible Switch port to which the vNIC of the virtual machine is connected with the CA address corresponding to the recipient in the header of the original IP packet. If the transmitted VSID matches the VSID in the port's ACL, the switch sends the packet to the virtual machine. If the virtualization mechanism used is IP rewrite, the filter changes the PA addresses in the packet to CA addresses based on the information from the virtualization policy, determines the VSID for the same pairs of PA and CA addresses and sends a packet with already CA addresses along with the VSID to the appropriate Hyper-V Extensible Switch port. If the transmitted VSID matches the VSID in the port's ACL, the switch sends the packet to the virtual machine.
The described logic applies when a packet is transferred between VMs located on the same or different hosts with Windows Server 2012 and the elevated Hyper-V role. The situation is somewhat more complicated if a packet from a VM, in which, for example, a certain business application is running, must get to the workstation with the client part of this business application. In this case, we will need to configure Hyper-V Network Virtualization Gateway, which we will discuss separately.
In the next post I will explain how to configure NV using: 1) PowerShell scripts, 2) VMM.
In the meantime, you can:
Hope the material was helpful.
Thank!
From a technological point of view, network virtualization is a rather complicated mechanism, so it’s probably not possible to make a more or less complete overview of this technology in one post. Today we will discuss the concept and architecture, in the next post I will focus on configuring NV, then we will talk separately about the organization of external access to VM running on a virtualized network.
Let's start with the fundamental question: “What is network virtualization for?”
')
What is network virtualization for?
In the case of server virtualization with a few reservations, the OS inside the VM works as if it were installed on a physical server and was the only OS on this hardware. Such an abstraction allows you to run several isolated instances of virtual servers on the same physical. By analogy, network virtualization leads to the fact that a virtual network, or rather, in this context, a virtualized network, functions as if it were a physical network. Accordingly, this level of virtualization allows you to create and use multiple virtual networks, possibly with overlapping or even completely coinciding IP address spaces, on the same physical network infrastructure. And this network infrastructure, generally speaking, can include an arbitrary number of physical servers and network equipment (see the figure below).
In the above figure, virtual machines from the blue network and the red network belonging to different departments or organizations can use the same IP addresses, can be running on the same or different physical hosts, but on the one hand, they will be are completely isolated from each other, and, on the other hand, they will without any problems interact with other network objects (real or virtual) of their department or organization. This implies the appointment of NV technology, the advantages and main scenarios of its application.
Greater flexibility in the placement of VMs within the data center
NV provides a certain freedom when deploying VMs within the data center. In particular, VM placement involves setting up an IP address corresponding to the physical network segment, and setting up a VLAN to provide isolation. Since NV allows coexistence on the same VM host with the same IP addresses, we are no longer bound by the IP addressing scheme used in the data center and do not rest on the restrictions imposed by the VLAN.
Simplified VM transfer to the cloud
Since when using network virtualization, the IP address and configuration of the VM remain unchanged, this greatly simplifies the process of transferring the VM to the neighboring organization's data center, to the hosting cloud or public cloud. Both application clients and IT administrators continue to use their tools to interact with the VM / application without reconfiguration.
Live Migration out of subnet
VM dynamic migration is limited to the limits of an IP subnet (or VLAN). If you migrate VMs to another subnet, you will need to reconfigure the IP inside the guest OS with all the ensuing consequences. However, if live migration is performed between two hosts with Windows Server 2012 with NV enabled, then the hosts can be located in different segments of the physical network, while network virtualization will ensure the continuity of network communications of the roaming VM.
Increased utilization of physical hosts and networks
The lack of dependence on IP addressing and VLANs allows you to more evenly load physical hosts and more efficiently utilize available resources. It should be noted that NV supports VLANs, and you can combine both isolation methods, for example, by isolating NV traffic in a dedicated VLAN for this purpose.
Hyper-V Network Virtualization Concept
When configuring NV, a pair of IP addresses is associated with each virtual network adapter (vNIC):
- Customer Address (Customer Address, CA) . The address configured by the customer inside the VM. This address is visible for the VM and OS itself inside it, at this VM address is visible for the customer's infrastructure, this address does not change when the VM moves within the data center, or beyond it.
- Provider Address (Provider Address, PA) . Address assigned by the data center administrator or hoster, based on the physical network infrastructure. This address is used when sending packets over the network between Hyper-V hosts running VMs and NV technology configured. This address is visible in the physical network segment, but not visible for the VM and the guest OS.
In the process of network interaction, the VM forms a packet with the sender and receiver addresses from the CA space. Such a package leaves the VM and the Hyper-V host is packed into a package with the sender and recipient addresses from the PA space. PA addresses are determined based on the virtualization policy table. After that, the packet is transmitted over the physical network. The Hyper-V host that received the packet, based on the same virtualization policy table, performs the reverse procedure: retrieves the source packet, determines the recipient VM, and redirects the source packet with the CA addresses of the desired VM.
Thus, network virtualization ultimately boils down to virtualizing the addresses used by virtual machines. In turn, address virtualization in Hyper-V Windows Server 2012 is possible using two mechanisms: Generic Routing Encapsulation and IP Rewrite. Consider briefly each of them.
Generic Routing Encapsulation
In the first mechanism, the source packet with CA addresses is encapsulated into a GRE structure (Generic Routing Encapsulation, see RFC 2890 ), which is packaged in an IP packet with the necessary PA addresses. A unique virtual subnet identifier (Virtual Subnet ID, the “GRE key” field in the figure), which owns the source packet, and the MAC addresses of the sender's and recipient's virtual network adapters are also added to the GRE header.
The subnet identifier allows the recipient host to correctly identify the VM for which the packet is intended, even if the CA addresses in the VM of different customers may coincide. The second important feature of this mechanism is that, regardless of the number of VMs running on a VM host, one PA address is enough to transfer packets from any VMs. This significantly affects the scalability of the solution when using the GRE mechanism of address virtualization. Finally, it should be noted that the described scheme is fully compatible with the existing network equipment and does not require any updating of network adapters, switches or routers.
However, in the future, it would not be superfluous that the switch or router could analyze the Virtual Subnet ID field of the packet, and the administrator could set the appropriate rules for switching or routing packets based on this field. Or, for example, so that all tasks related to GRE unpacking take on the network adapter. To this end, Microsoft, together with partners, developed the NVGRE standard — Network Virtualization using Generic Routing Encapsulation, which is currently in the IETF Draft stage. In particular, this standard regulates the 24-bit Tenant Network Identifier (TNI) field for storing the subnet identifier, protocol type 0x6558, indicating the NVGRE packet, and other nuances.
IP Rewrite
The second mechanism is somewhat simpler in its ideology. Each CA-address is assigned a unique PA-address. When a packet leaves the VM, the Hyper-V host in the IP packet header replaces the CA addresses with PA addresses and sends the packet to the network. The receiving host performs the return address replacement and delivers the VM packet. As follows from the described algorithm, on each physical host with the Hyper-V role, it is necessary to configure as many PA addresses as the CA addresses are used in all virtual machines running on this host that use network virtualization.
Encapsulating packages with GRE requires additional overhead. Therefore, for scenarios with high bandwidth requirements, for example, for VMs actively using a 10Gbps adapter, IP Rewrite is recommended as once. For most other cases, the GRE mechanism is optimal. Well, with the advent of equipment supporting NVGRE, this mechanism will not yield IP Rewrite in performance.
Customer Network and Virtual Subnet
In the terminology of Hyper-V Network Virtualization, the customer is the "owner" of the VM group deployed in the data center. In practice, if we are talking about the data center of the hosting service provider, such a customer could be any company or organization. If we are talking about a private cloud, then the customer, as a rule, is a department or division of the organization. In any case, the customer can own one or several networks (Customer Network), and each such network consists of one or several virtual subnets (Virtual Subnet).
Customer Network
- The customer network defines the isolation boundary of the virtual machines. In other words, VMs belonging to the same customer network can interact with each other. As a result, virtual subnets belonging to the same customer network should not use intersecting IP address spaces.
- Each customer network is identified using a special Routing Domain ID (RDID), which is assigned by the data center administrator or management software, such as System Center 2012 Virtual Machine Manager . RDID has a global identifier (GUID) format, for example {11111111-2222-3333-4444-000000000000}.
Virtual subnet
- The virtual subnet uses the semantics of the IP subnet and thus defines the broadcast domain (broadcast domain) for the VM. Virtual machines on the same virtual subnet must use the same IP perfix, that is, belong to the same IP subnet.
- Each virtual subnet belongs to one customer network (associated with one RDID) and is identified by the unique Virtual Subnet ID (VSID) already familiar to us. VSID can take values from 4096 to 2 ^ 24-2.
The use of these two concepts allows the customer to transfer their network topology to the cloud. In fig. Below are two Blue company networks - the R & D network and the sales department network. Initially, these networks are isolated and should not interact with each other. Since these networks are assigned different RDIDs when migrating to Hyper-V Network Virtualization, the VMs of these networks cannot “see” each other. In this case, for example, VMs from virtual subnets 1, 2, and 3 of the R & D network can exchange packets.
Hyper-V Network Virtualization Architecture
NV is only available in Windows Server 2012.
On hosts with Hyper-V Network Virtualization, a virtualization policy must be maintained, which actually sets and stores information about CA and PA spaces, RDID and VSID, and the address virtualization mechanisms used. Windows Server 2012 contains a set of software interfaces (APIs) with which the software can manage all aspects of NV. In the simplest case, such control software can be PowerShell scripts; in an industrial scenario, System Center 2012 Virtual Machine Manager SP1 (VMM) performs this role. I draw attention to the fact that it was with the release of SP1 in System Center 2012 appeared support for Windows Server 2012, and therefore NV.
The settings specified in the virtualization policy are directly applied by the NDIS (Network Driver Interface Specification) filter driver, called Windows Network Virtualization (WNV). The WNV filter is located below the Hyper-V Extensible Switch. This means that the Hyper-V switch and all its extensions (if any) work with CA addresses and do not know anything about PA addresses. However, VSIDs are available to the switch and extensions, so the Hyper-V Extensible Switch is able to distinguish, for example, CA addresses 10.0.0.5 belonging to different customers.
If network virtualization is enabled for the VM, then for the Hyper-V Extensible Switch ports to which the virtual network adapters of this VM are connected, the hypervisor includes access control lists (ACL). Read more about ACL here . The ACL indicates the VSID of the virtual subnet that owns the VM. Any packets arriving at this switch port with a VSID other than the one specified in the ACL are ignored.
Taking this logic into account, moving packages looks like this. Outgoing from the VM packet through the port of Hyper-V Extensible Switch gets into the WNV filter, which analyzes the NV virtualization policy and applies the necessary operations to the packet (replacing the IP address or packing in GRE), after which the packet is sent to the network.
On the receiving side, the incoming packet falls into the WNV filter, which analyzes the NV virtualization policy. If the incoming packet is a GRE packet, the filter reads the VSID field from the GRE header, retrieves the original IP packet and sends it along with the VSID to that Hyper-V Extensible Switch port to which the vNIC of the virtual machine is connected with the CA address corresponding to the recipient in the header of the original IP packet. If the transmitted VSID matches the VSID in the port's ACL, the switch sends the packet to the virtual machine. If the virtualization mechanism used is IP rewrite, the filter changes the PA addresses in the packet to CA addresses based on the information from the virtualization policy, determines the VSID for the same pairs of PA and CA addresses and sends a packet with already CA addresses along with the VSID to the appropriate Hyper-V Extensible Switch port. If the transmitted VSID matches the VSID in the port's ACL, the switch sends the packet to the virtual machine.
The described logic applies when a packet is transferred between VMs located on the same or different hosts with Windows Server 2012 and the elevated Hyper-V role. The situation is somewhat more complicated if a packet from a VM, in which, for example, a certain business application is running, must get to the workstation with the client part of this business application. In this case, we will need to configure Hyper-V Network Virtualization Gateway, which we will discuss separately.
In the next post I will explain how to configure NV using: 1) PowerShell scripts, 2) VMM.
In the meantime, you can:
- view network virtualization in action in the first module of the course " New features of Windows Server 2012. Part 1. Virtualization, networks, storage ";
- Learn more about Hyper-V Network Virtualization in the third module of the course “ Windows Server 2012: Network Infrastructure ”;
- Download the original presentation (in English), the slides from which I used in this post, with a detailed description of the packet flow process in NV.
Hope the material was helpful.
Thank!
Source: https://habr.com/ru/post/173159/
All Articles