在 Hyper-V 网络虚拟化 (HNV) 中，客户被定义为一组部署在数据中心的虚拟机的“拥有者”。 客户可以是多租户公共数据中心的一家公司或企业，或者是私有数据中心的一个部门或业务单位。 每个客户可以在该数据中心有一个或多个 VM 网络，而每个 VM 网络由一个或多个虚拟子网组成。

VM 网络

• 每个 VM 网络由一个或多个虚拟子网组成。 一个 VM 网络构成一个独立边界，VM 网络中的虚拟机可相互通信。 因此，同一个 VM 网络中的虚拟子网不得使用重叠的 IP 地址前缀。

• 每个 VM 网络包含一个用于标识 VM 网络的路由域。 标识 VM 网络的路由域 ID (RDID) 由数据中心管理员或者数据中心管理软件（如 System Center 2012 R2 虚拟机管理器 (VMM)）分配。 RDID 是一个 Windows GUID - 例如“{11111111-2222-3333-4444-000000000000}”。

虚拟子网

• 虚拟子网为同一个虚拟子网中的虚拟机实行第三层 IP 子网语义。 虚拟子网是一个广播域（与 VLAN 相类似）。 同一虚拟子网中的虚拟机必须使用相同的 IP 前缀。

• 每个虚拟子网都属于一个 VM 网络 (RDID)，并分配有唯一的虚拟子网 ID (VSID)。 VSID 在数据中心内部必须是唯一的，可在 4096 到 2^24-2 的范围内。

VM 网络和路由域的主要优点是能让客户将网络拓扑带到云中。 在图 2 的示例中，Contoso 公司有两个不同的网络：研发网络和销售网络。 由于这些网络有不同的路由域 ID，因此彼此之间不能进行交互。 也就是说，Contoso 研发网络与 Contoso 销售网络相互独立，尽管它们都属于 Contoso 公司。Contoso 研发网络包含三个虚拟子网。 注意：一个数据中心内的 RDID 和 VSID 都是唯一的。

图 2：客户网络和虚拟子网

在图 2 中，VSID 为 5001 的虚拟机能通过 HNV 将其数据包路由或转发到 VSID 为 5002 或 5003 的虚拟机中。 在将数据包送往 Hyper-V 交换机之前，HNV 将把传入数据包的 VSID 更新为目标虚拟机的 VSID。 这只有在两个 VSID 都属于一个 RDID 的情况下才能实现。 如果数据包上的 VSID 与目标虚拟机的 VSID 不匹配，数据包会被丢弃。 因此，带有 RDID1 的虚拟网络适配器不能将数据包发送到带有 RDID2 的虚拟网络适配器。

注意
在上述的数据包流描述中，“虚拟机”实际上指的是虚拟机上的“虚拟网路适配器”。 通常一台虚拟机只有一个虚拟网络适配器。 在这种情况下，虚拟机和虚拟网络适配器具有相同的含义。 由于一台虚拟机可以有多台虚拟网络适配器，这些虚拟网络适配器可以有不同的虚拟子网 ID (VSID) 或路由域 ID (RDID)，HNV 专门侧重虚拟网络适配器之间发送和接收的数据包。

每个虚拟子网定义一个第三层 IP 子网以及一个类似于 VLAN 的第二层 (L2) 广播域边界。 当虚拟机广播数据包时，广播只限于与 VSID 相同的交换机端口相连接的虚拟机。 每个 VSID 可与 PA 的多播地址相关联。 VSID 的所有广播流量均通过此多播地址进行发送。

注意
HNV 不依赖于广播或多播。 对于 VM 网络中的广播或多播数据包，将使用 PA 多播 IP 地址（如果已配置）。 但是，许多数据中心运营商都不会在其环境中启用多播。 因此，如果 PA 多播地址不可用，将使用智能 PA 单播复制。 这意味着，数据包只会单播到针对数据包所在的特定虚拟子网配置的 PA 地址。 此外，不管主机上存在多少个相关虚拟机，都只为每个主机发送一个单播数据包。

除作为一个广播域外，VSID 也能提供隔离。 HNV 中的一个虚拟网络适配器与具有一个 VSID ACL 的 Hyper-V 交换机端口相连接。 如果数据包到达这个具有不同 VSID 的 Hyper-V 交换机端口，该数据包会被丢弃。 只有数据包的 VSID 与交换机端口的 VSID 相匹配，数据包才能被送到 Hyper-V 交换机端口。 正因为如此，在上述图 2 的示例中，该数据包从 VSID5001 向 VSID5003 虚拟机传送时，在送达目标虚拟机之前，必须更改数据包的 VSID。

如果 Hyper-V 交换机端口没有 VSID ACL，那么附加在该交换机端口的虚拟网络适配器就不在 HNV 虚拟子网之内。 从虚拟网络适配器发出的数据包如果没有 VSID ACL，就会通过 Hyper-V 交换机而不会发生更改。

虚拟机发送数据包时，Hyper-V 交换机端口的 VSID 与这个数据包相关联。 在接收端，HNV 将 OOB 中的 VSID 以及解封的数据包发送到 Hyper-V 交换机。 在接收端，HNV 执行策略寻找，并在数据包送达 Hyper-V 交换机之前，将 VSID 添加到 OOB 数据中。

注意
Hyper-V 交换机扩展可以在提供程序地址 (PA) 空间和客户地址 (CA) 空间中工作。 这意味着，VSID 适用于交换机扩展。 这可使交换机扩展能感知多租户。例如，防火墙交换机扩展可将带有 VSID 为 5001的 OOB 的 CA IP 地址 10.1.1.5 和 VSID 为 6001 的相同 CA IP 地址区分开来。

与在物理网络中一样，路由是 HNV 的重要组成部分。 需要了解两个重要的方面：如何在虚拟子网之间路由数据包，以及如何在虚拟网络外部路由数据包。

在 HNV 中的每个虚拟网络适配器都与两个 IP 地址相关：

• 客户地址 (CA)   由客户基于其内部网络基础结构所指定的 IP 地址。 通过这一地址，客户可与虚拟机交流网络流量，如同未移到一个公有或私有云中一般。 CA 对虚拟机是可见的，并且可由客户访问。

• 提供程序地址 (PA)   由托管商或数据中心管理员基于其物理网络基础结构所指定的 IP 地址。 PA 出现在网络上的数据包中，这些数据包可与托管虚拟机的、运行 Hyper-V 的服务器进行交换。 PA 在物理网络上是可见的，但在虚拟机上不可见。

CA 维护着客户的网络拓扑，该网络拓扑经过虚拟化，可采用 PA 的实施方式，从实际的基础物理网络拓扑中脱离出来。 下图展示了因网络虚拟化而在虚拟机 CA 与网络基础设施 PA 之间所建立的概念关系。

图 6：物理基础结构的网络虚拟化概念图

在该图中，客户虚拟机在 CA 空间中发送数据包，并通过自身的虚拟网络或“隧道”遍布物理网络基础结构。 在以上示例中，通道被想象成带有绿色发货标签（PA 地址）的 Contoso 和 Fabrikam 数据包的“封套”，从左边的源主机发送到右边的目标主机。 关键在于主机如何确定与 Contoso 和 Fabrikam CA 相对应的“发货地址”（PA 地址）、“封套”如何套在数据包上、目标主机如何打开数据包并将数据包正确发送到 Contoso 和 Fabrikam 目标虚拟机上。

这一简单的类比突显出网络虚拟化的重要方面：

• 将每台虚拟机的 CA 映射到物理主机的 PA。 同一个 PA 可能有多个关联的 CA。

• 根据映射，将虚拟机在 CA 空间中发送的数据包放置在一个含有 PA 源和目标对的“封套”中。

• CA-PA 映射必须允许主机为不同的客户虚拟机区分数据包。

因此，网络虚拟化机制旨在将虚拟机使用的网络地址虚拟化。 下一部分将描述地址虚拟化的实际机制。

HNV 支持基本路由封装实现网络虚拟化 (NVGRE) 作为一种机制来虚拟化 IP 地址：

基本路由封装 此网络虚拟化机制将基本路由封装 (NVGRE) 用作通道报头的一部分。 在 NVGRE 中，虚拟机的数据包被封装在另一个数据包中。 如图 7 所示，新的数据包报头含有合适的源和目标 PA IP 地址，另外还有存储在 GRE 报头密钥字段中的虚拟子网 ID。

图 7：网络虚拟化 - NVGRE 封装

虚拟子网 ID 可让主机为任何指定的数据包确定客户虚拟机，尽管数据包上的 PA 和 CA 可能出现重叠。 这可让同一台主机上的所有虚拟机分享一个 PA（如图 7 所示）。

共享 PA 对网络可扩展性产生很大的影响。 网络基础设施必须知悉的 IP 和 MAC 地址数量得以大幅减少。 例如，如果每台终端主机平均有 30 台虚拟机，网络基础设施需要知悉的 IP 和 MAC 地址数量将减少到三十分之一，数据包中嵌入式虚拟子网 ID 还能轻易地将数据包与实际客户联系起来。

使用 Windows Server 2012 和更高版本，HNV 完全支持即开即用的 NVGRE；不需要升级或购买新的网络硬件，如 NIC（网络适配器）、交换机或路由器。 这是因为，在线 NVGRE 包是 PA 空间中的常规 IP 包，可与当前的网络基础结构相兼容。

Windows Server 2012 优先考虑兼容标准。 在与主要的产业合作伙伴（Arista、BroadcomArista、Dell、Emulex、Hewlett Packard 和 Intel）的共同努力下，Microsoft 发行了一份介绍基本路由封装 (GRE) 使用情况的 RFC 草案，它是现有的 IETF 标准并且是网络虚拟化封装协议的一部分。 有关详细信息，请参阅以下 Internet 草案：使用通用路由封装的网络虚拟化。 随着人们意识到 NVGRE 能运用到商业中，NVGRE 将带来更多益处。

下图展示了一个两名客户在云数据中心交互的部署案例，其中 CA-PA 关系由 HNV 策略所定义。

图8：多租户部署案例

思考图 8 中的示例。 在转到托管提供商的共享 IaaS 服务之前：

• Contoso 公司运行的是一台 SQL Server（名为 SQL），IP 地址为 10.1.1.11，以及一台 Web 服务器（名为 Web）IP 地址为 10.1.1.12，并用其 SQL Server 处理数据库事务。

• Fabrikam 公司运行的是一台 SQL Server（也名为 SQL），IP 地址为 10.1.1.11，以及一台 Web 服务器（也名为 Web），IP 地址为 10.1.1.12，并用其 SQL Server 处理数据库事务。

Contoso 公司和 Fabrikam 公司将其各自的 SQL Server 和 Web 服务器移至同一托管提供商的共享 IaaS 服务，而巧合的是，这些服务器在 Hyper-V 主机 1 中运行 SQL 虚拟机，在 Hyper-V 主机 2 中运行 Web (IIS7) 虚拟机。 所有虚拟机都保持其原有的内部网 IP 地址（其 CA）。

配置虚拟机时，托管提供商为两家公司都指定了以下虚拟子网 ID (VSID) 以及 PA：

• Contoso 公司虚拟机的 PA：VSID 为 5001，SQL 为 192.168.1.10，WEB 为 192.168.2.20

• Fabrikam 公司虚拟机的 PA：VSID 为 6001，SQL 为 192.168.1.10，WEB 为 192.168.2.20

托管提供商创建策略设置，这些设置包括 Fabrikam 公司的客户虚拟子网（将 Fabrikam 公司虚拟机的 CA 映射到其分配的 PA 和 VSID）和 Contoso 公司的独立客户虚拟子网（将 Contoso 公司虚拟机的 CA 映射到其分配的 PA 和 VSID）。 提供商将这些策略设置应用于 Hyper-V 主机 1 和 Hyper-V 主机 2。

当 Hyper-V 主机 2 上的 Contoso 公司 Web 虚拟机查询位于 10.1.1.11 的 SQL Server 时，会发生以下情况：

Hyper-V 主机 2，基于其策略设置，转化以下位置数据包中的地址：

• 源：10.1.1.12（Contoso 公司 Web 的 CA）

• 目标：10.1.1.11（Contoso 公司 SQL 的 CA）

封装的数据包含有：

• GRE 报头中的 VSID 为：5001

• 外部源：192.168.2.20（Contoso 公司 Web 的 PA）

• 外部目标：192.168.1.10（Contoso 公司 SQL 的 PA）

当在 Hyper-V 主机 1 上接收数据包时，基于其策略设置，它会解封以下 NVGRE 数据包：

• 外部源：192.168.2.20（Contoso 公司 Web 的 PA）

• 外部目标：192.168.1.10（Contoso 公司 SQL 的 PA）

• GRE 报头中的 VSID 为：5001

解封的数据包（原始数据包来自于 Contoso 公司 Web 虚拟机）被传送到 Contoso 公司 SQL 虚拟机：

• 源：10.1.1.12（Contoso 公司 Web 的 CA）

• 目标：10.1.1.11（Contoso 公司 SQL 的 CA）

当 Hyper-V 主机 1 上的 Contoso 公司 SQL 虚拟机响应查询时，会发生以下情况：

Hyper-V 主机 1，基于其策略设置，转化以下位置数据包中的地址：

• 源：10.1.1.11（Contoso 公司 SQL 的 CA）

• 目标：10.1.1.12（Contoso 公司 Web 的 CA）

数据包封装地址:

• GRE 报头中的 VSID 为：5001

• 外部源：192.168.1.10（Contoso 公司 SQL 的 PA）

• 外部目标：192.168.2.20（Contoso 公司 Web 的 PA）

当在 Hyper-V 主机 2 处收到数据包时，它将基于策略设置，解封以下数据包:

• 源：192.168.1.10（Contoso 公司 SQL 的 PA）

• 目标：192.168.2.20（Contoso 公司 Web 的 PA）

• GRE 报头中的 VSID 为：5001

将解封的数据包发送到以下 Contoso 公司 Web 虚拟机：

• 源：10.1.1.11（Contoso 公司 SQL 的 CA）

• 目标：10.1.1.12（Contoso 公司 Web 的 CA）

Fabrikam 公司 Web 与 SQL 虚拟机之间用于通信的类似进程针对 Fabrikam 公司使用 HNV 策略设置。因此，在使用 HNV 时，Fabrikam 公司和 Contoso 公司虚拟机的交互就像在其原有的 Intranet 中进行一样。 尽管两家公司虚拟机使用的是相同的 IP 地址，也不会互相影响。

不同地址（CA 和 PA）、Hyper-V 主机的策略设置以及用于入站和出站虚拟机通讯的 CA 与 PA 之间的地址转换，将两组服务器互相隔离。 同时，虚拟化映射以及转化将虚拟网络构架从物理网络基础结构中脱离出来。 尽管 Contoso SQL 和 Web 以及 Fabrikam SQL 和Web 位于其自己的 CA IP 子网 (10.1.1/24)，两者的物理部署在两台有着不同的 PA 子网（分别为 192.168.1/24 和 192.168.2/24）的主机上进行。 这意味着通过 HNV，可以进行跨子网虚拟机配置和实时迁移。

注意
有关数据包流的详细信息，请下载 Hyper-V 网络虚拟化数据包流，PowerPoint 演示地址：http://www.microsoft.com/en-us/download/details.aspx?id=34782。

在 Windows Server 2012 中，HNV 策略实施以及 IP 虚拟化都由名为 Windows 网络虚拟化 (WNV) 的网络驱动程序接口规格 (NDIS) 轻型筛选器 (LWF) 执行。如图 9 所示，WNV 筛选器位于 Hyper-V 交换机下面。 这种体系结构的负面影响之一是，交换机扩展可能只能看到 CA 地址空间流量，而看不到 PA 空间的流量。

在 Windows Server 2012 R2 中，HNV 现已成为虚拟交换机的一部分，它使扩展能够同时洞察 CA 和 PA 空间地址。

图 9：HNV 体系结构

每台虚拟机网络适配器都配有一个 IPv4 和/或一个 IPv6 地址。 这些是虚拟机用来相互交流的 CA，并置于虚拟机的 IP 包中。 基于网络虚拟化策略，HNV 将 CA 虚拟化成 PA。

虚拟机发出一个源地址为 CA1 的数据包，该数据包已根据 Hyper-V 交换机中的 HNV 策略虚拟化。 基于 VSID 的特殊网络虚拟化访问控制列表能将虚拟机从其他不属于同一虚拟子网或同一路由域的虚拟机独立出来。

Windows 平台可为数据中心管理软件提供公共 API 来管理 HNV。Virtual Machine Manager 就是这样一种数据中心管理产品。 该管理软件包含所有 HNV 策略。 由于 Virtual Machine Manager 必须能感知虚拟机，最重要的是,它能在数据中心配置虚拟机以及整个客户虚拟网络，并且必须能感知多租户，因此，管理 HNV 策略是基于策略网络的自然延伸。

基于云的数据中心能带来许多好处，如改善可扩展性和资源使用情况。 为了实现这些潜在的好处，需要能基本解决动态环境中多租户可扩展性问题的技术。 HNV 旨在通过分离物理网络拓扑的虚拟网络拓拟来解决这些问题，并提高数据中心的运营效率。 HNV 构建在现有标准的基础之上，能在当前的数据中心运行，同时，随着 NVGRE 感知硬件的推出，其优势将会日益提高。 借助 HNV，客户现在可将其数据中心整合到私有云中，或者将其数据中心无缝延伸到拥有混合云的托管商环境中。

若要了解有关 HNV 的详细信息，请访问以下链接：