SDN VMware NSX网络原理与实践- 多虚拟化环境下的 NSX-MH【3.4】

9.1.4 KVM 基本架构

         KVM 是 Linux 内核的一部分，它的基本架构由两个组件构成。  libvirt：这是实现虚拟数据库的工具包。 运行 KVM 时，就应安装这个工具包，它 实现了 KVM 与 Linux 之间的交互，主要负责虚拟机的创建、虚拟内存的分配、vCPU 寄存器的读写以及 vCPU 的运行。  qemu： 用于模拟虚拟机的用户空间组件，提供 I/O 设备模型、访问外部设备的途径等。 由于 KVM 已经是 Linux 内核模块， 因此可以看作是一个标准的 Linux 字符集设备 （/dev/KVM）。 qemu 通过 libKVM 应用程序接口，用 fd 通过 ioctl 向设备驱动来发送创建、运 行虚拟机命令，运行了 Linux 的设备就会来解析并执行命令。 KVM 基本架构如图 9.2 所示。

        KVM模块使得运行了Linux的主机成为一个虚拟机监视器（Virtual Machine Monitor， VMM）， 并且在原有的两种Linux 执行模式（内核模式和用户模式） 的基础上，新增加了客户模式。  客户模式：执行非 I/O 的客户代码。 虚拟机运行在这个模式下。  用户模式：代表用户执行 I/O 指令。 qemu 运行在这个模式下。  内核模式：处理因 I/O 或者其他指令引起的客户模式退出（VM_EXIT），实现客户模块的切换工作。 KVM 模块工作在这个模式下。 用户模式的 qemu 利用 libKVM，通过 ioctl 进入内核模式，而 KVM 模块为虚拟机创建 虚拟内存、虚拟 CPU 后执行虚拟机 launch 命令，进入客户模式，加载并执行 Guest OS。 如果 Guest OS 在执行过程中发生外部中断，就会暂停并退出客户模式进行异常处理，处理 完毕后它重新进入客户模式完成相关操作。如果发生 I/O 事件或者信号队列中有信号抵达， 系统就会进入用户模式进行处理。 9.2 NSX-MH 解决方案概览 在 2.1 节， 我们就提出了一个问题—NSX 是否一定要部署在 VMware 的虚拟化环境 中？ 答案是否定的。

        NSX 可以部署在 VMware vSphere、 KVM、 Xen 等诸多虚拟化环境中。 后文会详细讨论 NSX 如何部署在多虚拟化环境中。 读者一定会问，为什么 VMware 作为全球市场份额最大的服务器虚拟化软件厂家，其 网络虚拟化平台却能支持其他的服务器虚拟化软件？这是因为 VMware 并不认为自己的 NSX 网络虚拟化平台是一种封闭的平台，而是可以为所有的服务器虚拟化架构所用。此外， NSX解决方案来自VMware收购的Nicira公司在被收购之前， Nicira公司就一直为基于Xen、 KVM 等开源虚拟化软件搭建的数据中心提供虚拟网络服务。 从本节开始，会详细阐述 NSX-MH 的架构、功能和流量模型。

9.2.1 NSX-MH 解决方案整体架构

        多虚拟化环境下的 NSX 解决方案简称为 NSX-MH（NSX for Multi-Hypervisor）架构。为 了搭建这个架构，需要下载并安装 NSX-MH 软件， 该软件当前的最新版本是 4.2.5。

        NSX-V 在推出时，为了匹配当时即将发布的 vSphere 6.0， 因此发布的第一个版本也使 用了 6.0 的版本号，而不是从 1.0 开始的。而 NSX-MH 则是 Nicira 的 NVP 的延续，其版本 号随着 NVP 的 1.0 版本一路走到 4.2.5 版本，即便在 Nicira 被 VMware 收购后，其版本号 还是传承了下来。在使用 NSX-MH 时，我们会看到在网页配置界面中还会保留一些 Nicira 公司的 Logo 和图标，而命令行配置界面中的命令也会经常包含 nvp 字样。

        在未来， NSX-V 和 NSX-MH 会进行整合，成为一套可以同时运行在所有虚拟机之上的网络虚拟化平台， Nicira 公司的 Logo、 nvp 字样也会被逐渐消除。 NSX-MH 架构与 NSX-V 架构在逻辑层次的划分上完全一致—管理平面、控制平面、 数据平面。管理平面和控制平面中使用的组件也基本相同—主要是 NSX Manager 和 NSX Controller，其中 NSX Controller 也可以使用集群式的部署方式。 NSX-MH 和 NSX-V 最大 的不同来自数据平面。在 NSX-V 中，服务器虚拟化软件是 vSphere，安装了 vSphere 的物理服务器称为 ESXi 主机， 其上可以运行多个虚拟机，这些虚拟机可以通过 vSphere 分布式交换机互相连接起来； 而 NSX 网络虚拟化的其他组件和功能（主要是逻辑交换 机、分布式逻辑路由器、分布式防火墙，但不包括 NSX Edge 提供的功能），都是基于 vSphere 分布式交换机搭建的。

        而 NSX-MH 中，底层虚拟化平台可能是 vSphere，也可 能是 Xen 或 KVM，在它们之上安装的虚拟机是通过最早由 Nicira 公司设计并开发的 OVS（ Open vSwitch）进行连接的， NSX-MH 中的逻辑交换机、分布式逻辑路由器、安 全组件等功能是建立在 OVS 的基础之上的。此外， NSX-V 中的 NSX Edge，在 NSX-MH 中替换为二层/三层网关，实现了类似的功能。 NSX-MH 解决方案的整体拓扑架构如图 9.3 所示，可以看到，与 NSX-V 相比，最大的区别 就是在 NSX-MH 中，服务器虚拟化平台可能会由 Xen 或 KVM 中的一种进行搭建，或混合搭建。 有时 ESXi 也会出现在架构中。 这样一来，数据中心中的虚拟化软件可能同时有 Xen、 KVM 和 ESXi。而逻辑交换机建立在 OVS（其中对于 ESXi 上使用的 OVS，在 NSX 环境中有个专门的名 称，叫 NSX vSwitch[NVS]）之上，而不是 vSphere 分布式交换机。

        NSX-MH 的整体拓扑中，管理平面和控制平面的架构与其主要的组件与 NSX-V 仅有 一些细微的差别。而数据平面的架构和 NSX-V 相比有很大区别。本章后面会进行概述。

9.2.2 NSX-MH 的管理平面

        NSX-MH 的管理平面与 NSX-V 一样。 NSX-MH 中，管理平面的主要组件是 NSX Manager，如图 9.4 所示，它提供了一个基于网页的友好 UI 页面。 NSX Manager 被用于 NSX 的 API 与 NSX Controller 集群之间的交互， 并可以对传输网络和逻辑交换机（OVS）进行配置，将虚拟设备连接至逻辑网络。 NSX Manager 也能提供基本的故障诊断、 Syslog、数 据采集、监控等功能。 NSX Manager 同时希望在非纯 vSphere 环境下部署和管理逻辑网络 时，可以通过云管理平台（如 OpenStack）进行自动的配置和管理，这样它就能更有效地专 注于与 NSX Controller 集群的交互，而不是专注于配置和故障诊断。换句话说，由于在多 虚拟化环境中，很可能存在用户定制开发的云管理平台，因此在 NSX-MH 架构下， NSX Manager 可以不用进行日常的配置和维护。

        NSX-MH 中，各种服务可以使用 Cloud Management Platform（CMP）进行运维和管理。 CMP 是一种云管理的平台，它可以是 OpenStack、 CloudStack 或其他第三方的云管理平台。 CMP 用来进行应用的自动化部署和配置，或将应用连接至所在的逻辑网络，它提供了现代 数据中心所需的重要特征—敏捷性。 CMP 向终端用户和租户提供管理员服务，而对于应 用服务，则可以通过允许用户利用授权的模板、使用 scratch 等工具进行部署。

        OpenStack 作为一种开源的公有云和私有云管理平台（也是一种 CMP），经常被集成部署 在 NSX-MH 环境中。由于 NSX 是网络虚拟化平台，因此 OpenStack 与 NSX 集成最多的是其 网络组件—Neutron。 这样的集成不局限于 NSX-MH 环境，在 NSX-V 环境同样适用。 Neutron 允许借助第三方解决方案来丰富 OpenStack 的网络功能，而 NSX 网络虚拟化平台正可以提供 诸多丰富的网络功能。 VMware 提供的 Neutron Plugin 叫作 NSX Plugin，它允许 OpenStack 使 用所有的 NSX-MH 中的网络服务，这些服务包括且不局限于：  二层 Overlay 网络；  跨越逻辑和物理网络之间的二层网络；

 使用集中式或分布式路由的三层网络；
 安全的 Profile；
 访问控制，如 ACL 等；
 QoS。
图 9.5 所示为给定的租户通过 OpenStack 管理界面为 NSX-MH 创建的逻辑网络示意图，它来自于 OpenStack 仪表板组件 Horizon 自动生成的网络拓扑图。

9.2.3 NSX-MH 的控制平面

        在 NSX-MH 中， NSX Controller 集群将逻辑网络的配置从管理平面发布至各个租户（通 过 NSX API 服务）。它同时会从 Hypervisor 侧学习不同虚拟机的虚拟网络接口信息。通过 这些信息，控制平面可以收集整个虚拟网络空间的所需流量信息，并将信息通过 OpenFlow 协议通告给运行在各个物理和虚拟传输节点（Transport Node）的 OVS 的所有接口。 为了使得 NSX Controller 获得弹性的架构与更高的性能，可以将 NSX Controller 部署 为集群模式，这点与 NSX-V 中的部署一样，是一种可扩展的分布式部署。

        在 NSX Controller 集群中，每一个 NSX Controller 节点都分配了一个角色，用来定义工作任务的类型，图 9.6 为各个工作任务在各节点上的分布示意图。由于 NSX-MH 中的工作任务与 NSX-V 中的稍 有不同， 下面解释一下这些工作任务。  传输节点管理（Transport Node Management）：维持 OVS 与不同传输节点的连接性。  逻辑网络管理（Logical Network Management）：对工作流抵达或离开传输节点进行 监控，并且配置 OVS 的转发状态，以部署逻辑网络的策略。  数据的持久性与复制（Data Persistence and Replication）：将所有的信息从 NSX API和 OVS 那里复制到 NSX Controller 集群中的所有节点，这样一来就不用担心某一 个节点失效了，因为其他节点都会知晓其信息，并在该节点失效后自动选择其他 节点接管其工作任务。  Web 服务的 API：从外部的客户那里处理 HTTP Web 服务请求，并处理 NSX Controller 节点的任务。

        NSX-MH 的 NSX Controller 集群节点之间同样引入了“切片” 的概念，通过切片实现的 集群之间的节点资源分配、节点失效后的重新分配与 NSX-V 中完全相同。 这些内容不再赘 述，当然同样建议将节点配置为至少 3 个，或其他奇数个节点数量。 在 NSX-MH 中， NSX Controller 集群同样通过分布式的架构部署在 x86 服务器上，提供了以下两个重要功能。  高可用性（HA）：集群式的部署， 确保在单个或多个 NSX Controller 节点故障时， 整个 NSX Controller 依旧存活，并可以在故障恢复时，自动重新加入集群。  可扩展性（Scale-out）：可以轻松增加控制平面控制的终端节点数量，也可以将更 多 NSX Controller 节点加入 NSX Controller 集群。 NSX Controller 集群在逻辑网络和物理网络方面的视角方面保持了一致性。

        一旦物理网 络发生变化，比如虚拟机开机导致物理网络端口开启或更多子网流量经过一个 Trunk，或 虚拟机发生迁移， NSX Controller 集群就会动态、智能地更新转发规则，并告知逻辑网络。 这样一来， 逻辑网络配置同时就会因为来自 API 的请求而发生变化，而 NSX Controller 集 群会将变化后的最终结果同步到所有相关的传输节点。 下面通过图 9.7 详细说明在 NSX-MH 中， NSX Controller 集群是如何工作的。在每个传输节 点（图中为 Hypervisor）与 NSX Controller 集群之间，控制平面的通道都有两个，一个是管理通 道，它使用 OVSDB 协议（TCP 的 6632 端口），另一个是 OpenFlow 通道（TCP 的6633 端口）。

        管理通道用于 NSX Controller 集群与传输节点的通信，可以携带丰富的配置信息并将信息 推送至 OVS，这些信息包括逻辑路由、逻辑交换的各种信息。同时， Hypervisor 也会使用 OVSDB 管理通道，向 NSX Controller 集群提供本地连接以及部署的虚拟机的 MAC 地址和 VIF-ID。这样一来， NSX Controller 集群就可以学习到所有虚拟机的位置信息，知晓全网物 理拓扑结构，最终精确计算物理网络的路由、交换策略，这样就可以更好地部署逻辑网络。 NSX Controller 集群之后会使用 OpenFlow 协议，使得各种网络流量在各个逻辑网络的传输 节点直接进行传递。

        每个传输节点只会从NSX Controller 集群中接收流量中关联了逻辑交换机本地活跃（Active） 的子网信息。换句话说，至少需要有一个活跃的虚拟机连接到了这个逻辑交换机的逻辑网段，传 输节点才会收到逻辑交换机上建立连接的信息。这样的架构降低了逻辑网络中的资源消耗。 每一个节点和 NSX Controller 集群之间的通信通道在相互认证后，就可以成功建立连 接。它们一般通过 SSL 进行认证。认证过程如下。

        1．每一个传输节点在向 NSX Controller 集群注册时，可以提供一个证书。而 NSX Controller 集群必须在此之前就将这个证书注册到自己的系统中，然后才可以允许 OVS 连 接各个传输节点。

        2．同一时间， NSX Controller 集群使用这个 SSL 证书，与各个传输节点建立 OVS 的 管理连接。这些传输节点也需要通过证书进行预配置， 除非它收到的第一个证书是可信的 （默认配置可信，可以进行修改）。

        NSX Controller 集群还提供了通配符的功能。网络流量，是通过五元组的数据包关联起 来并执行转发的。 在一些情况下，五元组可以使用通配符来代替，这消除了传统 TCP/IP 协 议的复杂性。 下面通过两个例子来看一看 NSX Controller 集群是如何将 NSX-MH 环境下的 五元组 TCP/IP 数据替换为通配符的。

        这种功能代替了繁琐的基于五元组的 TCP/IP 协议， 使得流量的策略执行更加便捷、迅速。  如果所有从虚拟机 1 （运行在 Hypervisor1 主机上）去往虚拟机 2 （运行在 Hypervisor2 上）的流量被允许，那么 NSX Controller 集群就会在 Hypervisor1 的 OVS 推送一条 流量规则： from L2-mac@VM 1 to L2-mac@VM 2 any IP / any protocol -> encapsulate the traffic and send it to hypervisor2。 意思是从虚拟机 1 去往虚拟机 2 的任何 IP、任何协议的流量都可以进行封装并发送到 Hypervisor2 的 ESXi 主机。  如果只有一个协议的流量可以被放行，比如只有虚拟机 1（运行在 Hypervisor1 主 机上）去往虚拟机 2（运行在 Hypervisor2 上）的 HTTP 流量被允许，那么 NSX Controller 集群同样会在 Hypervisor1 的 OVS 推送一条流量规则，这个流量规则可 以被 OVS 识别并读取： from L2-mac@VM 1 / L3-IP@VM 1 to L2-mac@VM 2 / L3-IP@VM 2 on TCP:80 -> Encapsulate the traffic and send it to hypervisor2。

        意思是 仅有从虚拟机 1 去往虚拟机 2 的三层 IP 流量，且端口号为 TCP 80， 才可以进行封 装并发送到 Hypervisor2 的 ESXi 主机。 当 OVS 遇到一个 BUM（广播、不知道目的的单播、组播）流量时，无论是从源 Hypervisor 去往 OVS 逻辑交换机接口连接的所有传输节点（如果在 NSX 中选择源节点复制模式），还 是通过一个 NSX 服务节点（默认推荐的服务节点复制模式）， OVS 都会将流量泛洪到自身 OVS 逻辑交换机来处理。 对于北向接口， NSX Controller 集群提供了 NSX API。可以使用 NSX Manager、 OpenStack 这些 CMP，通过 NSX API 接收到的管理平面信息来创建逻辑接口、逻辑网络、将虚拟机与逻 辑网络连接。