云计算网络极速入门-虚拟机网络

本文是《云计算网络极速入门》三部曲：

《云计算网络极速入门-虚拟机网络》
《云计算网络极速入门-容器网络》
《云计算网络极速入门-混合云网络》

的第一篇。

1、网络基础

所谓的“云计算”就是通过网络将一个个计算单元、存储单元聚合成巨大的资源池，并按需对外提供计算、存储服务。同时，网络本身也是一项云资源，可以说，没有网络就不存在云计算，网络是云计算基础资源中的基础资源。

云计算中的任何资源为了实现按需分配，首先要先将其“池化”，并按统一的标准对外提供资源服务，这势必要淡化资源的硬件属性，将其“虚拟化”。网络作为云计算基础资源中的基础资源，同样需要遵循此规律，淡化硬件区别以提供更好的“云化”亲和性，也就是更好的控制转发能力；此外，网络也要更高效，提供更高的传输速率，以满足不断增长的云上及跨云的资源传输的需要。一个合格的云网络必须支持如下能力：

允许应用在任意（拥有空闲计算资源的）服务器上灵活部署而不受物理网络的限制，从而提升业务的敏捷性。支持包括站点灾难恢复、业务迁移在内的场景。
跨集群甚至跨多个计算中心的可迁移性。
按需进行虚拟网络部署，而无须重新配置物理网络；支持多租户环境下的大规模网络部署。

可见，云网络和传统经典网络存在较大的区别，我们首先来看看传统经典网络的典型架构，如图1所示：

图1

从图上可以看到，构成网络的最基本元素是主机上的网卡、局域网中的交换机以及连接不同局域网的路由器，另外就是传输介质（网线）。

传统物理网络的组网工作包含了工程勘探、选址、布线施工等等操作，但是，对于云计算来说，这明显和“按需申请、随需调配”的原则相违背。在云计算中，往往需要根据租户的需要随时创建针对租户可见的私有局域网，一切都通过云计算管理控制台上点击几下鼠标，输入一些必要参数即能秒级开通。因此，在云计算中，必须将最底层的物理网络硬件再包装一层，封装成虚拟的逻辑组件，从而淡化硬件的特性。只有这样，才能在软件层面实现对网络资源的随意编排。云计算之所以能做到这一点，依赖的两大“杀器”是SDN和NFV，它们也是一切云计算网络的基础，下面，我们首先介绍这两种技术。

2、SDN

SDN是英文“Software Defined Network”的简写，翻译成中文就是“软件定义网络”，实际上，SDN并不是一个具体的技术与协议，而是一个思想、一个框架，只要网络硬件可以通过软件被集中式的管理、可编程，并实现控制与转发分离，就可以认为这是一个SDN网络。为了实现这一点，一个SDN网络必须具备如下几项能力：

● 集中控制：逻辑上的集中控制能够支持获得网络资源的全局信息。

● 开放接口：南向接口和网络硬件打交道、北向接口则是和管理控制台打交道。

● 网络虚拟化：即NFV，这点非常重要，通过南向接口的统一和开放，屏蔽底层硬件差异，实现底层网络对上层应用的透明化。

SDN的主要落地形式是OpenFlow协议，可以说，OpenFlow发展史就是SDN的发展史，对整个SDN的发展起着重大的推动作用。OpenFlow协议一直由开放网络基金会（ONF）管理，它的核心思路是在网络设备中维护一个流表，并且只通过流表对传输报文进行处理，流表本身的生成、维护和下发完全由外置的控制器实现，从而实现报文转发和路由控制的分离。外置控制器通过事先规定好的接口操作OpenFlow交换机中的流表，从而达到数据转发的目的。

为了促进SDN的标准化发展，一些行业组织也推出了相应的SDN指导架构。图2就是由设备商和软件商主导创建的SDN组织ODL所推出的SDN指导架构。

图2

图2中的各架构分层说明如下（自底向上）：

基础设施层：由各种网络设备构成，主要承担数据转发功能。
南向接口：SDN控制器对网络基础设施层的控制主要通过OpenFlow、NetConf等南向接口实现，包括链路发现、拓扑管理、策略制定、表项下发等。
控制层：是网络转发的控制管理平面，是整个网络的大脑。
北向接口：是通过控制器向上层应用开放的接口，其目标是使得应用能够便利地调用底层的网络资源和能力，很多采用REST风格协议。
应用层：指商业应用。开发者可以通过SDN控制器提供的北向接口实现应用和网络的联动，例如网络拓扑的可视化、监控等。

3、NFV

上面介绍的SDN提供南向接口对数据平面进行控制，而NFV则主要应用于数据平台，对应图2中数据平面的各网络设备。NFV重点要实现网卡虚拟化、交换机/路由器虚拟化。接下来，我们针对这两点分别进行介绍：

3.1、网卡虚拟化

现代网卡基本上都支持虚拟化功能，也就是说，可以将一个物理网卡的功能（PF）虚拟化为多个虚拟网卡的功能（VF），每个物理功能（PF）最多可支持64000个与其关联的虚拟功能（VF）。而实现PF到VF的虚拟这个过程中，很重要的一项技术就是Intel推出的SR-IOV技术，SR-IOV是虚拟化的一个重要功能，它最初就是应用在网卡上，后来扩展到其它PCI设备。简单来说，就是一个物理网卡可以通过SR-IOV虚拟出来多个轻量化的PCI-e物理设备，从而分配给多个虚拟机使用，具体如图3所示。由于SR-IOV是在网卡上实现的，可以有效降低宿主机的CPU负荷，提高网络性能，降低网络时延等。

图3

那么，有了VF之后，虚拟机是如何通过VF进行通信？这就要依赖相应的虚拟网卡驱动了，在Linux中，虚拟网卡驱动主要由Linux内核实现的一对虚拟网络设备（基于文件）TAP/TUN来实现。当一个TAP设备被创建时，Linux设备文件目录下将会生成一个与之对应的TAP字符设备文件。当对TAP设备文件执行write()操作时，相当于网卡收到数据；read()操作则是发送数据，也就是说，TAP设备可以被当成本机的一个网卡（实际上是网卡的映射），操作TAP设备的应用程序相当于另外一台计算机，它通过read/write系统调用，和本机进行网络通信。TAP/TUN的数据传输过程如图4所示。

图4

3.2、交换机虚拟化

有了虚拟网卡还不够，还需要有对应的虚拟交换机能将虚拟网卡连接起来，才能构建最终的虚拟网络，下面，我们就来看看实现虚拟交换机的两种重要实现，一个是Linux的Bridge，另外一个，则是大名鼎鼎的Open vSwitch。

Linux Bridge

Linux Bridge是工作在二层（所以它不需要IP）的虚拟网络设备，类似物理的交换机。Bridge有多个端口，数据可以从任何端口进来，进来之后去往哪里主要看MAC地址；Bridge可以绑定其它Linux网络设备（比如虚拟网口vNIC）作为从设备，并将这些从设备虚拟化为端口，当一个从设备被绑定到Bridge上时，就相当于真实网络中的交换机端口插入了一个连接有终端的网线。如下图所示，在图上，对于同一个网络中的br0、tap0、tap1，均不需要IP地址，对于上层交换机/路由器而言，因此只需要给br0设置一个IP地址即可。因为具有自己的IP地址，br0可以被加入路由表，并利用它来发送数据，而最终实际的发送过程则由某个从设备（eth0）来完成。如图5所示：

图5

Open vSwitch

Open vSwitch在云环境中的各类虚拟化平台上（KVM、Xen）实现了分布式的虚拟交换机，它比Linux Bridge强大，也是Xen、KVM的默认交换机。它负责连接vNIC与物理网卡，同时也桥接同一物理Server内的各个vNIC。同时，一个物理Server上的vSwitch可以透明地与另一个Server上的vSwitch连接在一起，从而构建真正意义的分布式网络。它的原理是OVS建立网桥，将物理网卡和虚拟机TAP设备进行桥接，像交换机一样进行二层转发，为虚拟机和网络设备建立桥梁。虚拟机之间在学习到对方的ARP信息之后，可以正常通过OVS和物理交换机进行数据转发。如图6所示。

图6

同时Open vSwitch也提供了针对OpenFlow的支持。OvS 通过openFlow流表可以实现各种网络功能，并且通过openFlow Protocol可以方便的实现控制+转发分离的SDN方案,图7是OVS内部架构（各组件关系）：

图7

其中ovs-vswitchd是最重要的模块，实现了虚拟机交换机的后台，负责与远程的Controller进行通信，例如通过OpenFlow协议与OpenFlow Controller通信，通过sFlow协议同sFlow Trend通信。此外，ovs-switchd也负责同内核态模块通信，基于netlink机制下发具体的规则和动作到内核态的datapath。datapath负责执行数据交换，也就是把从接收端口收到的数据包在流表（Flow Table）中进行匹配，并执行匹配到的动作。每个datapath都和一个流表关联，当datapath接收数据后，会在流表中查找可以匹配的Flow，执行对应的动作，比如转发数据到另外的端口。ovsdb-server是一个轻量级的数据库服务器，主要用来记录被ovs-switchd配置的信息。

Open vSwitch还包括一系列的命令行工具，主要包括：

ovs-vsctl：网桥、接口等的创建、删除、设置、查询等。
ovs-appctl：发送命令消息到ovs-vswithchd, 查看不同模块状态。
ovs-dpctl：配置vswitch内核模块中的datapath。
ovs-ofctl：下发流表信息。该命令可以配置其他openflow 交换机（采用openflow 协议）。
ovsdb-server：数据库服务程序, 使用目前普遍认可的ovsdb 协议。它的对应客户端工具是ovsdb-client。

Open vSwitch具有产品级的质量，它的引入使得云环境中虚拟网络的管理以及对网络状态和流量的监控变的容易。

4、虚拟网络

4.1、组网基础：LAN和VLAN

有了以上介绍的SDN和NFV的相关知识，尤其是知道了虚拟网卡和虚拟交换机是如何工作的，我们就可以来正式了解云计算中的虚拟网络是如何构建出来的了。

图1的传统物理网络中，连入同一个Switch（交换机）中的计算机构成了一个本地局域网LAN（Local Area Network），一个LAN表示一个广播域，含义就是：LAN中的所有成员都会收到任意一个成员发出的广播包。

现代的物理交换机普遍具有虚拟功能，能在逻辑上分成多个交换机，这样就能构建多个LAN，计算机发出的广播包可以被同一个LAN中的其它计算机收到，但位于其他LAN的计算机则无法收到。这样构建的LAN又称为虚拟局域网（Virtual LAN，VLAN）。VLAN限制了广播的范围，在二层网络中将计算机隔离到不同的VLAN中。这非常适用于租户和业务隔离。因此，基于二层网络的VLAN技术在传统数据中心内部获得了广泛的应用。

但在云计算中，由于租户数量及组网规模远大于传统数据中心，VLAN只支持4096个VLAN ID规模已经无法满足大规模云计算业务及业务组网的需求，而且不断扩展的虚拟机规模容易使TOR交换机的MAC/ARP表项面临溢出的问题，同时难以实现大量跨三层的虚拟机二层互通及迁移的诉求（为了保证虚拟机迁移过程中业务不中断，需要保证虚拟机的IP地址、MAC地址等参数保持不变，这就要求虚拟机迁移必须发生在一个二层网络中）。

4.2、Overlay网络

LAN和VLAN都无法满足云网络的构建诉求，我们前面说了，云网络需要针对物理网络之上再封装一层，也就是说，要在现有的基于IP的三层物理网络基础之上建立叠加逻辑网络（Overlay Logic Network），从而屏蔽底层物理网络差异，实现网络资源的虚拟化，使得多个逻辑上彼此隔离的网络分区，以及多种异构的虚拟网络可以在同一共享的物理网络基础设施上共存。OverLay网络和物理网络的关系如图8所示：

图8

从图上可以看到，由于Overlay是在传统物理网络上虚拟出的一个虚拟网络，因此传统网络不需要再做任何适配,这样物理层网络只对应物理层的计算（物理机、虚拟化层管理网），虚拟的网络只对应虚拟计算（虚拟机的业务IP）

Overlay的技术路线，其实是从架构上对数据中心的建设模式进行了颠覆，对物理设备的要求降至最低，业务完全定义在层叠网络上。而这正是构建云网络的基础。当前，实现OverLay标准的技术方案主要由各虚拟化技术厂商主导，主要有VxLAN、NVGRE、NVP等，而由VMware推出的VxLAN则在目前的云数据中心的构建中占据了主导地位。下面，我们重点介绍VxLAN。

4.3、王者：VxLAN

VxLAN全称是Virtual Extensible Local Area Network，翻译成中文就是虚拟可扩展局域网，它是一种Overlay网络技术，将二层数据帧封装至UDP报文进行转发，可以跨物理三层网络来创建一个完全虚拟化的基础二层云（虚拟）网络，从而充分满足云业务对网络承载的需求。

上面这段定义中的“物理三层”和“二层云（虚拟）”的字样完全体现了图8中的架构的精髓。

VxLAN是基于隧道（Tunnel）的一种网络虚拟化技术。所谓的“隧道”是一个虚拟的点对点的连接（需要注意，这个虚拟的点对点通路，在物理网络中可能通过了多个物理网络节点，甚至跨LAN），提供了一条通路使封装的数据报文能够在这个通路上传输，并且在通路的两端分别对数据报文进行封装及解封装。所谓的封装就是将二层（MAC地址）报文用三层（IP地址）协议进行封装，这样，就达到了对二层网络在三层范围内进行扩展，从而把二层网络的整个数据帧封装在UDP报文中，送到VxLAN隧道对端。隧道对端的虚拟或者物理网络设备再将其解封装，去除里面的二层网络数据帧，发送给真正的目的节点。

图9 VxLAN协议头

如图9所示，由于VxLAN协议头使用了24bit表示VLAN ID(VNI)，所以最多可以支持1600多万个VLAN ID，这样就可以支持足够多的租户子网络的构建，从而解决了大规模云计算业务及业务组网的需求。将VxLAN技术应用于数据中心内部，使虚拟机可以在互相连通的三层网络范围内迁移，而不需要改变IP地址和MAC地址，从而保证业务的连续性。

目前很多云运营商所提供的VPC（虚拟专有网络）也是采用VxLAN来构建的，每个VPC都有一个独立的VNI，一个VNI对应着一个虚拟网络。一个VPC内的虚拟机实例之间的数据包传输都会加上隧道封装，带着唯一的VNI，然后送到物理网络上进行传输。不同VPC之间的虚拟机实例因为所在的VNI不同，本身处于两个不同的路由平面，所以它们之间无法进行通信，天然地进行了隔离。

5、网络加速

当把网络分成数据平面和控制平面之后，网络性能集中体现在了数据平面上，而网络IO的性能又受如下4大因素的影响：

网卡中断：主流操作系统都会采用中断的方式来处理网络的请求，然而每次中断都会引起一次上下文切换（从当前正在运行的进程切换到因等待网络数据而阻塞的进程），造成操作系统额外的性能损耗，造成较高的时延，并导致吞吐量下降。
内存拷贝：一般进入网卡的数据流量会先进入操作系统的内核空间，再从内核空间拷贝到用户空间，这样用户空间中的应用程序才能处理网络数据，而内核空间和用户空间之间的双向拷贝同步会占用大量的CPU及内存、带宽等资源。
锁：为共享资源上锁或者去锁的过程中通常需要几十纳秒。锁的存在也降低了整个系统的并发性能。
缓存未命中：如果因为不合理的设计导致频繁的跨核（CPU）调用，会导致缓存未命中，从而造成严重的数据读写时延，降低系统的整体性能。

为了解决上述影响数据平面的问题，业界做了很多尝试，归纳起来，主要采用两大手段，一种是内核旁路技术，简单说，就是应用程序不通过内核，而是直接操作硬件，从而避免了内核空间和用户空间之间的切换，提高了效率；另一种就是针对硬件处理器做多核及CPU亲和性优化，让一个特定任务在指定的核上尽量长时间地运行，以减少CPU切换的性能损耗，从而提高吞吐量和降低延时，同时采用大页技术，将物理内存分页块加大（从4KB提高到2M或者1G），减少页表级数和TLB不命中的情况，让地址转换时访问内存的次数减少，此外，新的NUMA并行架构也可以减少CPU之间的资源共享，通过独立资源提高处理器的并行处理效率。

DPDK是目前普遍采用的网络加速方案，它充分使用了以上相关技术以提高网络数据的处理性能，为高性能数据面的处理提供了可能。DPDK的全称是Intel Data Plane Development Kit，是Intel提供的数据平面开发工具集，为Intel Architecture（IA）处理器架构下用户空间高效的数据包处理提供库函数和驱动的支持。通俗地说，就是一个用来进行包数据处理加速的软件库。DPDK已作为NFV（网络功能虚拟化）和NFC（网络功能容器化）的重要组件，参与到NFV和NFC的基础设施建设中。其核心思想可以归纳成以下几点：

轮询模式：DPDK轮询网卡是否有网络报文的接收或放送，这样避免了传统网卡驱动的中断上下文开销，对性能的改善十分明显。
用户态驱动：通过用户态驱动的开发框架（旁路技术）避免了不必要的用户态和内核态之间的数据拷贝和系统调用。
降低访问存储开销：使用大页提高缓存命中率。
亲和性和独占：将特定线程指定在固定的CPU核上工作，避免线程在不同核之间频繁切换带来的开销。
批处理：一次处理多个包，降低了一个包处理的平均开销。
利用IA新硬件技术。
软件调优。
充分挖掘外部设备潜能。

相比原生 Linux（Native Linux），采用Intel DPDK技术后能够大幅提升IPV4的转发性能，因此被广泛应用于数据平面控制软件中。Open vSwitch在2.2版本开始支持DPDK，从2.4版本开始可以使用DPDK优化的vHost路径。目前有多个OpenStack子项目使用DPDK实现数据平面用户态转发，包括使用DPDK在用户态实现了netdev datapath：使用轮询driver绕过内核协议栈来直接处理物理网卡上的数据包，使用vHost and IVSHEM库作为宿主机到guest OS的控制和数据通道。当使用IVSHEM时，可以在guest OS中运行DPDK应用，这种场景下DPDK中的应用使用宿主机上的共享内存大页。对于vHost的实现，Open vSwith通过socket实现控制消息的处理，通过共享的内存大页实现真正数据包的处理。

6、云计算网络：OpenStack网络

有了上面的知识后，我们就可以进入本文最核心的部分，真正一窥云计算网络的真面目了。目前最有代表性的云平台非OpenStack莫属，同时OpenStack基金会也是云计算3大基金会之一（另外两大基金会分别是Linux基金会和Apache基金会）。可以毫不夸张的说，OpenStack一手推动了全球云计算技术的发展。

下面，我们就通过OpenStack 来介绍云计算网络的基本构成。OpenStack是构建云计算的综合操作系统，它包含了很多部件，用以解决构建云计算所需的计算、存储、网络、安全、编排等一系列能力，其核心组件包括：

Computer：Nova-提供虚拟机服务，创建或者迁移虚拟机镜像及其快照（类似EC2）
Object Storage：Swift-存储和检索对象（类似S3）
Identity：Keystone-为所有OpenStack提供身份验证及授权
Dashboard：Horizon-为所有服务提供一个模块化的，基于Django的界面。
Block Storage：Cinder-提供块存储服务（类似 AWS EBS服务）。
Network：Neutron-提供网络连接服务，允许用户创建自己的虚拟网络并连接各种网络设备接口，通过插件的方式对众多的网络设备商进行支持。
Image Service：Glance-镜像服务组件，提供镜像的存储、查询和检索服务。

以上这些组件中，真正用于云网络构建的是Neutron，我们后续的内容将会详细介绍Neutron的网络实现。

6.1、早期的OpenStack网络

很多人不知道的是，OpenStack最早期用于构建网络的并不是Neutron这个独立组件，而是Nova中的一个叫nova-network的模块，它简单、稳定，但支持的网络类型有限，主要功能如下：

基于网桥的二层网络配置（目前也支持Open-vSwitch）
基于数据库进行IP地址的管理和分配
组网模式仅支持Flat、Flat/DHCP及VLAN/DHCP等简单网络模型。
DHCP及DNS服务。
基于IPTables的防火墙策略及NAT（网络地址转换）功能。

时至今日，nova-network依然存在于Nova项目中，并可替代Neutron为OpenStack提供基础的网络服务。

6.2、进化后的OpenStack网络

为了应对更复杂的应用场景，实现更完善的云网络支持，Neutron项目被创建用来取代nova-network。Neutron优化了插件机制，引入SDN思想，支持更多的网络特性，在网络L2~L7的各个方面都提供了完善的支持，包括：

L2~L3层的服务（全量）。L2，L3层是构建云网络的基础，我们前面也介绍了，Overlay就是在物理L3层网络上构建虚拟L2层网络。其中L2的抽象network/subnet/port又被认为是Neutron的核心资源，这个我们在下一节中会详细介绍。
L4~L7层的服务

负载均衡即服务（Lbaas）：可以基于VIP实现
防火墙即服务（Fwaas）：主要基于IpTables
VPNaaS（虚拟专用网络即服务）
DNS
Metering（网络计量服务）

此外，Neutron还支持网桥（Linux Bridge）、Networking OVN、Open vSwitch等众多驱动。

在利用Neutron创建云网络时，首先应由管理员创建一个或多个外部网络对象来负责OpenStack环境和Internet的连接；然后租户就可以创建自己的私有内部网络，并在其中创建虚拟机，如果虚拟机需要访问Internet的话，还必须创建一个路由器将内部网络连接到外部网络，这就是一个典型的Neutron网络结构，如图10所示。

图10

这一切，都可以在OpenStack提供的Horizon控制面板中实现（Horizon不是本文的介绍重点，如想了解请读者自行查阅文献）。在图10中，Neutron提供了一个L3层的抽象Router与一个L2层的抽象Network，Router对应真实网络环境中的路由器，为用户提供路由、NAT等服务，Network则对应于一个真实物理网络中的二层局域网（LAN），从租户的角度看，它为租户所私有。

6.3、Neutron的网络资源模型

从图10可见，一个Neutron网络包含了如下3项核心资源：

Network（网络）：Neutron中最基础的资源，是一个隔离的L2广播域。Network除了租户网络外，还包含运营商网络，一个Network中包含多个子网（Subnet），子网和端口（Port）都需要关联到网络上。目前很多云运营商提供的VPC（虚拟专有网络）实际上就是一个个这样的Network。如果是采用VxLAN构建的Network，如前面所介绍的，每个Network都拥有唯一的VNI。
Subnet（子网）：逻辑上隔离的L3域（网络中的3层概念），代表了一组IP地址的集合，即背后分配了IP的虚拟机。每个子网必须有一个CIDR（具体解释见下面的小贴士），并关联到一个网络（Network）中，不同子网之间L3并不通，必须通过一个路由器（Router）进行通信。
Port（端口）：虚拟网口是MAC地址和IP地址的承载体，也是数据流量的出入口。虚拟机、路由器均需要绑定Port。一个Network可以有多个Port，一个Port也可以与一个Nework中的一个或者多个Subnet关联。

Neutron通过L2的抽象Network/Subnet完成对真实二层网络的映射，并且Network有Linux Bridge、Open vSwitch等不同的实现方式。我们用一个实际的云运营商提供的VPC来理解上面的Network和Subnet的关系，如图11所示：

图11

图上的VPC就是一个Network，每个可用区都是一个Subnet，所使用的网段都是采用CIDR标准表示，每个VPC都由一个路由器，至少一个私网网段和至少一个交换机组成。

小贴士：CIDR(无类域间路由)

将子网掩码转换为二进制，就会发现网络ID部分全部是1、主机ID部分全部是0。

CIDR（Classless Inter-Domain Routing，无类域间路由选择）它消除了传统的A类、B类和C类地址以及划分子网的概念，因而可以更加有效地分配IPv4的地址空间。它可以将好几个IP网络结合在一起，使用一种无类别的域际路由选择算法，使它们合并成一条路由从而较少路由表中的路由条目减轻Internet路由器的负担。

CIDR技术用子网掩码中连续的1部份表示网络ID，连续的0部份表示主机ID。比如，网络中包含2000台计算机，只需要用11位表示主机ID，用21位表网络ID，则子网掩码表示为11111111.11111111.11100000.00000000，转换为十进制则为 255.255.224.0。此时，该网络将包含2046台计算机，既不会造成IP地址的浪费，也不会利用路由器连接网络，增加额外的管理维护量。

CIDR 还使用“斜线记法”，即在IP地址后面加上一个斜线“/”，比如192.168.23.35/21，其中用21位表示网络ID。

Neutron内部的网络都是一个个的租户网络（Tenant Network），由租户自行创建，但这些租户网络要连接外部网络的话，必须由管理员创建一个特殊的Network：运营商网络（Provider Network），来映射外部网络，运营商网络并不在Neutron的管理之中。如图12所示：

图12

租户网络和运营商网络都是比较粗粒度的概念，接下来我们再从更细节层面来看看内部虚拟机究竟是如何和外部网络通信的。

Neutron通过L3的抽象Router提供路由器的功能，此外，在L2中还提供一个重要的抽象Port，代表了虚拟交换机上的一个虚拟交换端口，并记录其属于哪个网络及对应的IP信息等。可以说，端口是Neutron资源模型的“灵魂”，Router则是Neutron资源模型的“发动机”，它承担着路由转发功能。这么解释还比较抽象，为了更好理解，我们来看一个实际的例子，如图13所示：

图13

上图中，位于Neutron管理网络的内部虚拟机VM，IP地址为10.10.10.10，它要访问位于公网的网站www.openstack.org，IP地址为104.20.110.33，需要经过公网的路由器RouterB才能到达。RouterB的Port2端口直接与Neutron网络节点的RouterA的Port1端口相连（中间经过Bridge相连），RouterA属于Neutron管理，RouterB是真正意义上的外部网关，RouterB的接口Port2的IP地址120.192.0.1是Neutron网络的外部网关IP。但RouterB根本不在Neutron的管理范围内，而且Neutron也不需要管理它。从路由转发的角度来说，只需要在RouterA中建一个路由表项即可(Router最关键的两个概念就是端口和路由表)，如下表：

destination next_hop out interface

104.20.110.0/24 120.192.0.6 Port2(120.192.0.1)

因此，可以理解如下：

Neutron只能管理自己的网络。
Neutron不需要管理外部网络，只需要知道外部网络网关IP即可。而它获取外部网关IP的方式就是通过subnet_id间接获取其gateway_ip得到。

目前Neutron支持如下类型的网络：

Flat：不支持VLAN，因此不支持二层隔离，所有虚拟机都在同一个广播域。
VLAN
NVGRE/GRE：点对点的IP隧道技术，可以支持虚拟网络互联。
VxLAN：VxLAN是UDP隧道，可以穿越IP网络，使得两个虚拟VLAN可以实现二层联通。
GENEVE：类似VxLAN。

基于上述的L2和L3抽象，提供更高层次的FWaas、LBaaS、VPNaaS等服务。

6.4、Neutron的网络实现模型

在实际组网中，Neutron有三类节点：

控制节点：部署身份认证、镜像服务、Nova，以及Neutron的API Server、Nova的调度器服务；
计算节点：运行Nova-compute及一些Neutron的Agent，为VM的启动和联通服务；
网络节点：通过部署一系列Neutron的Agent，为整个OpenStack网络提供DHCP、DNS、通过Router访问Internet的能力。

这三类节点的关系如图14所示：

图14

在控制层面上，三类节点间均通过管理网络进行控制面的消息传递，同时控制节点通过API网络接收OpenStack用户的管理消息；在数据层面上，计算节点与网络节点间的数据通过数据网络传输，同时访问或接收外部网络的流量需要通过Network节点的External Network（外部网络）。这种根据不同层面和功能使用不同网络进行数据传递的能力，有利于提高Neutron的网络性能及自身的可靠性、可用性及可服务性。

Neutron仅仅只是一个管理系统，本身没有任何网络功能，仅仅通过南向接口利用Linux及Open vSwitch的相关功能做一个配置或者驱动而已。相关细节在前面章节中已有所阐述。Neutron只有一个主要的服务进程neutron-server，它运行在网络控制节点上，提供RESTful API的北向接口并作为访问Neutron的入口，neutron-server接收用户HTTP命令请求，最终由遍布于计算节点和网络节点的各种Agent完成具体的数据流量控制及转发功能。

Neutron提供的众多API资源对应了各种Neutron网络抽象，为了更容易进行扩展，Neutron采用Plugin的方式组织代码，但由于各Core Plugin的实现之间存在很多重复的代码，比如对数据库的访问操作等，因此，从Havana版本开始，Neutron推出一个叫ML2的新的抽象的Core Plugin来替代原有的Core Plugin们。

ML2提供了一个框架，允许在OpenStack网络中同时使用多种Layer2网络技术，很好解耦了网络拓扑类型与底层的虚拟网络实现机制，并分别通过Driver的形式进行扩展。其中，不同的网络拓扑类型对应着Type Driver，由Type Manager管理，不同的网络实现机制对应着Mechanism Driver，由Mechanism Manager管理。目前，Neutron已经实现了Flat、GRE、VLAN、VxLAN等拓扑类型的Type Driver，也实现了Linux Bridge、Open vSwitch及众多厂商的Mechanism Driver，通过这些众多的Driver，ML2 Plugin实现了其他Core Plugin的功能，这就是ML2能替代原有Core Plugin的真正原因。

除了Network/Subnet/Port这三种核心资源和Router等基于ML2的Core Plugin外，Neutron还以Service Plugin的方式提供一些其它的扩展服务API，包括：

防火墙（FWaaS）：FWaaS给租户网络提供虚拟防火墙，主要基于Linux IpTables来实现，以作为Neutron自有安全组策略的补充和扩展。
负载均衡（LBaaS）：使用LoadBalance Plugin在VM Instance之间做负载均衡的能力，除了负载均衡，还可以监控应用和服务的状态、限制链接防止DoS攻击、会话保持等。构建一个LBaaS需要完成三个任务：
1. 首先创建一个计算池，一开始可以为空，然后为计算池添加几个成员；
2. 创建几个health monitor（健康监控），并将其和计算池关联起来；
3. 为计算池配置VIP（Virtual IP）
虚拟专用网络（VPNaaS）：目前只支持IPSecVPN，使用的是IPSec的遂道模式。

在本章最后，使用一张图来展示Neutron的整体架构能力，基本上囊括了前面所讨论的Neutron的所有能力，如图15所示：

图15

云计算网络的第一篇就到此为止，主要介绍了虚拟机网络。提前预告一下，下一篇文章还是和云网络相关，主要介绍容器网络。

附，参考文献：

《Linux开源网络》
《Docker 容器与容器云》
《软件定义网络 SDN与OpenFlow解析》
《混合云架构》
《深度探索Linux系统虚拟化》

最后——

我把十几年的经验总结起来，出了本书，叫做《微服务治理：体系、架构及实践》，大家如果感兴趣可以关注一下。