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

9.2.4 NSX-MH 的数据平面

        在 NSX-MH 中，数据平面是由 OVS 和其他组件（如 NSX 服务、 NSX 网关、第三方 二层网关设备）组成的， 它们都由 NSX Controller 集群所控制。 在 NSX-MH 中，这些接入 层的虚拟和物理设备统称传输节点（Transport Node），可以将其理解成在物理网络中，机 框式交换机的“线卡” 应用在了逻辑网络。 传统的网络硬件设备（可以不由 NSX 控制，也可以通过开放的可编程 API、 OpenFlow 协议交给 NSX 控制）为 NSX-MH 环境提供了底层 Underlay 网络平台，并连接 NSX-MH 中 的各个传输节点。

         NSX 则创建了 Overlay，在 Underlay 之上部署了逻辑网络。 传输节点支持 OVS 管理接口，这是一种开放式的协议，对进入 OVS 的流量的转发提 供细颗粒度的控制和可视性。 数据平面的终端主要有两种类型。  Hypervisor：内嵌了 OVS 功能的虚拟交换机会被安装在每一个 Hypervisor 之上，它允 许在 Hypervisor 之上运行的虚拟机终端连接逻辑网络。目前， NSX 网络虚拟化平台支 持的Hypervisor包括ESXi、KVM和Xen。在不久的将来发布的版本可能会支持Hyper-V。  NSX 网关服务： NSX 网关服务可以将一个或多个 NSX 网关从虚拟网络连接到不 受 NSX 管控的物理网络。在 NSX-MH 中，每一个网关都运行着一个二层网关服务， 可以将流量发送到物理设备的二层子网，或运行一个三层网关服务，并将它和物理路由器的端口进行关联。 在数据平面中，逻辑网络的部署方式有如下两种。

         基于 Overlay 的逻辑网络： Overlay 网络可以通过从二层到三层网络的隧道将流量进 行封装，与 NSX-V 一样，这样就意味着逻辑网络拓扑可以实现与物理网络拓扑的完 全解耦。在 NSX-MH 中，流量的封装类型可以是 STT、 GRE、 VXLAN、 IPSEC-STT 和 IPSEC-GRE，而默认的是 STT，这和 NSX-V 是有区别的（默认是 VXLAN），这是 因为STT是Nicira早先开发的专为KVM 和Xen的虚拟化环境搭建虚拟网络的私有封 装协议，它在多 Hypervisor 的环境中，有最佳的传输效果。  桥接的逻辑网络：这种模式下，不进行封装工作。与建立在 Hypervisor 之上的传 统网络一样，虚拟机的流量可以直接发送至物理网络。这种模式其实很少会用到， 因为它需要在相应的 Hypervisor 之间建立二层连接关系，没有实现物理网络和逻 辑网络的解耦，也缺少先前介绍的 Overlay 的任何优势。

        因此， 后文只会讨论如何 在 NSX-MH 环境下部署 Overlay 网络。 NSX 服务节点是一种可选择的传输节点，它可以使用双活的集群模式工作。 NSX 服务 节点有如下作用。  处理 BUM 流量时， Hypervisor 将流量发送到了 NSX 的服务节点，服务节点会将 其复制到其他 OVS 下属的传输节点。  改变封装方式。比如，在 Hypervisor 和服务节点中使用 STT 的封装方式，但是服 务节点和远端 NSX 网关之间使用 IPSEC-STT 的封装方式。 值得注意的是，在物理网络设备上，都无需提供 OVS 或 OpenFlow 的支持。物理网络 设备只需要支持单播 IP 流量的可达性，以为传输节点提供连接即可，这是 NSX 平台的一 大优势。当然，如果底层物理网络支持 OpenFlow， 则可以通过在其开放的 API 上再编程， 让 NSX 直接管理和控制底层物理网络。

9.3 NSX-MH 环境下的 OVS

        本章已经不止一次提到了 OVS 这个名词，它是 Open vSwitch 的简称， 最早是由 Nicira 公司的创始人卡萨多先生主持开发，并在之后公有化、标准化， 主要用于在 KVM 和 Xen 虚拟化环境中构建虚拟逻辑网络， OVS 现在几乎已经垄断了基于开源系统的数据中心解决 方案中的逻辑网络基础架构。 本节从 OVS 的起源和发展谈起，进而阐述其核心技术，再讲解它与 NSX-MH 转发平 面的各个组件进行交互的方式，旨在帮助读者更好地理解基于 OVS 部署的 NSX-MH 逻辑 交换、逻辑路由和安全。

9.3.1 OVS 的起源和发展历程

        追溯 OVS 的诞生，还得从头说起。进入 21 世纪，随着以 Intel VT-x 和 AMD-V 为核心 的服务器虚拟化技术取得了突飞猛进的发展， x86 服务器逐渐取代小型机， 统治了数据中 心。 这种变化带来了另一个深远的影响—有可能成为人类历史上最伟大的商业和技术创 新的“云计算” 登上了历史舞台，并迅速得到了全球所有 IT 巨头的青睐， 它们不约而同地 都将云计算视作关键战略。但是，只有服务器虚拟化是远远不够的，云计算的隔离、弹 性、动态迁移等特性都需要网络的紧密支持， 这就需要网络的策略可以动态跟随虚拟机， 但物理网络因其端口、位置的局限性，很难做到这一点。 于是，人们想到了可以使用网 络虚拟化技术。

        但是，虚拟网络与物理网络之间的“最后一公里” 问题一直没有得到有效 解决—这是因为物理网络和虚拟网络在之前没有实现完全解耦。 2007 年 8 月，卡萨多先 生提交了第一个开源网络虚拟交换机的项目提案，这个项目在 2009 年 5 月被正式称之为 Open vSwitch，简称 OVS，并在 2009 年 6 月 29 日正式推出，向世人揭开了面纱。之后几 年，随着该技术越来越成熟，终于在 2012 年正式绑定到 Linux 内核中，成为 Linux 的标准 功能之一。

        在那段时间，技术标准难以统一、利益冲突等问题的存在，促使各个厂商纷纷 推出了自己的虚拟交换机，例如 Cisco 公司的 Nexus 1000V、 VMware 公司的分布式交换机 （VDS）、 IBM 公司的 DOVE 等。 与此同时， Linux 中的桥接（bridge） 技术还有很多限制， 不能称之为真正意义上的虚拟交换机。这些问题和现状，使得 OVS 一经推出就获取了业内 的高度关注， 如今， OVS 几乎成为开源虚拟化环境中虚拟交换机的标准。 人类信息科技史上不止一次出现过颠覆性的技术，然而，这些技术在解决某些领域的 问题的同时，往往也会带来其他新的问题。而且新技术在推出的初期，往往会因为其不 成熟、存在 bug、技术细节不被大众熟知而饱受质疑。

        因此， OVS 这种纯粹基于 x86 的虚拟交换机的方案，一经推出就被推到了风口浪尖上，尤其是网络硬件厂商都一致 不看好它， 它们不希望网络虚拟化技术完全基于 x86 或完全开源， 而是希望在物理网 络之上保留一些自己的功能。因此，网络硬件厂商都希望自行研发网络虚拟化系统， 或通过收购来获得这一技术优势。然而几年过去了，就像 IBM 公司无法抗拒 x86 服务 器不断取代其小型机， 不得以推出自己的刀片式和机架式的 x86 服务器一样，那些网 络巨头公司，如 Cisco 和 Juniper，也在不断认可 OVS、认可开源，因为开源已经成为 不可逆转的潮流。

9.3.2 OVS 技术详解

        OVS（Open vSwitch）是一个开源的、多层的虚拟交换机，它是基于开源 Apache 2.0 软件并使用 C 语言开发的，目的是让大规模的虚拟网络可以通过编程方式进行扩展，从而实现自动化。 OVS 支持多种 Linux 虚拟化技术，包括 Xen、 KVM 和 VirtualBox。 OVS 可以 在跨越多个物理服务器的分布式环境中进行部署，这与 VMware 的分布式交换机、 Cisco Nexus 1000v 非常类似。图 9.8 所示为 OVS 在多物理服务器上跨越 Hypervisor 的分布式部 署的逻辑示意图。

在 2015 年 8 月 21 发布的版本中（2.40）， OVS 支持的标准协议和特性如下所示。
 虚拟机在通信时，可以使用 NetFlow、 sFlow、 IPFIX、 SPAN、 RSPAN、基于 GRE隧道的端口镜像。
 通过 LACP 实现链路聚合。
 标准的基于 802.1Q 的 VLAN 模型，实现网络分区，同时支持 Trunk。
 使用 IGMP（版本 1 至 3）实现组播侦听。
 支持用于实现大二层的协议 SPB（这是一种 MAC in MAC 的封装技术，硬件层面主要由 ALE[Alcatel-Lucent Enterprise]和 Avaya 力推）。
 支持链路发现协议 LLDP。
 支持 BFD、 802.1ag 链路监听。
 支持 STP 和 RSTP。
 支持针对不同的应用、用户和数据流部署 QoS。
 在虚拟机的接口处实现配置和部署流量策略。
 使用针对源 MAC 地址的负载均衡、主备、 4 层哈希的方式绑定 NIC（NetworkInterface Controller）。
 支持 OpenFlow。
 完全支持 IPv6。
 支持多种隧道技术，包括 GRE、 VXLAN、 STT 和 Geneve，并且在封装时都可以
使用 IPSec 技术。
 提供强大的可编程性，目前可以使用 C 和 Python 程序语言进行编程。
 支持在内核空间和用户空间内的数据包转发引擎，这样一来， OVS 就可以在不离开内核空间的情况下，利用内核空间的多线程组件来提高系统的性能，以支持更 好的灵活性和处理转发分组。  使用流量缓存引擎，实现多表转发通道（Multi-table forwarding pipeline）。

 将转发层进行抽象，提供 OVS 端口，使其可以集成新的软件和硬件平台。 这些协议、特性是内嵌在 OVS 上的，而 OVS 又直接连接 Liunx 内核和服务器的网卡， 这样一来，运行在服务器上的虚拟机就可以直接从这些协议和特性中受益，在整个虚拟网 络中实现交换、路由、安全的一些高级功能，如图 9.9 所示。

OVS 的模块和其功能如下。  ovs-vswitchd： OVS 的主要模块，直接附加在 Liunx 内核之上，实现基于流表的交换。  ovsdb-server：轻量级数据库服务器，主要保存整个 OVS 的配置信息，包括接口、 交 换策略、 VLAN 等，而 ovs-vswitchd 会根据数据库中的配置信息进行转发工作。  ovs-brcompatd：使得 OVS 替换在 Linux 内核侧的桥接（bridge）功能，包括获取 bridge ioctls 的 Linux 内核模块。  ovs-dpctl：用来配置 switch 内核模块，可以控制转发规则。

          ovs-vsctl：获取、查询、配置和更新 ovs-vswitchd 的配置，也会更新 ovsdb-server 中的数据库。  ovs-appctl：向 ovs-vswitchd 发送命令消息，运行相关 daemon。  ovsdbmonitor： GUI 工具，用来显示 ovsdb-server 中的数据信息，这样就可以远程 获取 OVS 数据库和 OpenFlow 的流表。 此外， OVS 也提供了支持 OpenFlow 的特性，这些特性如下所示。  ovs-openflowd：一个简单的支持 OpenFlow 的交换机。  ovs-controller：一个简单的 OpenFlow 控制器。  ovs-ofctl：查询、 控制 OpenFlow 交换机和控制器，在使用 OVS 作为 OpenFlow 交换机时，用来控制流表。  ovs-pki： OpenFlow 交换机创建和管理公钥的框架。

          ovs-tcpundump： tcpdump 的补丁，用来解析 OpenFlow 的消息。 下面来看 OVS 是如何工作的。首先， OVS 在 Liunx 的内核模块上实现了多条数据路径 （类似于网桥功能），每条路径都可以有多个 vport（类似于网桥的端口）。每条数据路径也 通过关联流表（flow table）来设置操作，而这些流表中的流都是用户空间对报文和数据进 行映射的关键信息，一般的操作都是将数据包转发到另一个 vport。当一个数据包抵达一个 vport 时，内核模块就会提取这个数据流的关键信息，并在流表中查找这些信息。 如果有一 个匹配的流，它就会执行相应的操作；如果没有，它会将数据包送到用户空间的处理队列 中（作为处理的一部分，用户空间会设置一个流表项， 当以后遇到相同类型的数据包时， 会根据该流表项来处理）。

9.3.3 OVS 与 OpenFlow

        OVS 的工作流程和 OpenFlow 有不少相似之处，这是因为 OpenFlow 和 OVS 都是 Nicira 设计和开发的。并且在 OVS 中也会用到 OpenFlow—在 NSX-MH 中， NSX Controller 作 为 OpenFlow 控制器工作，而 OVS 作为 OpenFlow 交换机，它们之间的通信协议正是 OpenFlow。

        第 1 章讲到， OpenFlow 在 SDN 架构中是最重要的南向接口协议。 前文在介绍 NSX-MH 的控制平面时已经介绍了 NSX Controller 和 OVS 的工作模式。 在每个传输节点与 NSX Controller 集群之间，控制平面的通道都有两个： 使用 OVSDB 协 议的管理通道和 OpenFlow 通道。管理通道可以携带丰富的配置信息并将信息推送至 OVS， 之后 OpenFlow 通道就会使用 OpenFlow 协议，使得各种网络流量在各个逻辑网络的传输节 点直接进行传递，而不经过控制平面。 OpenFlow 协议的转发行为非常简单， 它没有任何的状态机，纯粹就是一个匹配→执行 （Match→Action） 的过程。这个过程看不到任何具体的网络二层或三层等功能和协议的相 关描述，也不知道什么叫路由，什么叫网桥，它唯一知道的就是查询哪种流表，匹配哪些 字段组合，执行什么动作。至于这些流表和字段到底能组合成什么样的网络功能，它一概 不关心，从而使得转发行为变得简易、快捷。

         OpenFlow 协议在工作时，有如下两个基本的内容。这也是卡萨多和麦考恩最初提出的 Ethane 网络模型的基本架构。  基于流（Flow）的转发 每个 OpenFlow 交换机可以保存一个流表（Flow Table），它包含了很多条目，每个条 目内容都是一个五元组的 IP 协议包（源端口、目的端口、源 IP 地址、目的 IP 地址、网络 协议类型）。利用这个五元组，可以定义一种类型的网络流量，而一个流表中每个条目都代表着一种流量。 OpenFlow 交换机会查询流表内的这些内容，并依据流表中每个条目对应的 动作，对每种流量做出转发的指令。

         中央控制器（Central Domain Controller） 中央控制器是一个独立的控制平面设备，而且只有它才能够修改 OpenFlow 交换机内 部流表的内容。中央控制器不但决定了数据包转发的路径，还负责制定优先级、 队列、流 量限制等策略。 在 NSX-MH 环境下， OVS 作为 OpenFlow 交换机时， 具有如下特性：  通过流表保存了对每个数据流的定义，以及相应的处理行为。其中，每个流表还 包含如下三个部分。  匹配值：在内部记录数据包头内不同部分的值， 以此定义一组数据流。匹配值是 一个十元组，包含了重要的二层和三层信息， 这些信息如表 9.1 所示。

十元组中，可以通配任意条目。例如某个条目仅仅定义了其 VLAN ID 为 50， TCP 目的端口为 8080，那么所有 VLAN 50 内端口号为 8080 的 HTTP 请求在此交换机 上都被视为一个“数据流”。  行为项：记录交换机对符合条目的数据流采取的执行策略。  计数器： 主要记录转发数据包的数量和比特位，以及条目的空闲时间。如果一 个条目长期没有匹配的数据包，则此条目会被移除，以保证流表中的空间利用率。  提供安全的网络通道。当一个全新的数据包第一次抵达 OpenFlow 交换机时，交换 机通过这个安全的通道，将数据包送往中央控制器进行解析。  提供开放的 OpenFlow 标准，用于读写流表的内容。