OpenStack在这几年风生水起。随着核心模块稳定性的提高，OpenStack已经有了很多大规模商用的案例，所有与云相关的，无论是商用软件还是开源平台都在积极地寻求着与OpenStack的对接，OpenStack正在成为云计算业界事实上的IaaS标准。

在网络这一口，OpenStack经历了由nova-network到Quantum再到Neutron的演进过程。我们首先来简要地看看各个版本网络的特征：

Nova-network是隶属于nova项目的网络实现，它利用了linux-bridge（早期，目前也支持OVS）作为交换机，具备Flat、Flat DHCP、VLAN三种组网模式。优点是性能出色，工作稳定，支持multi-host部署以实现HA；缺点是网络模块不独立，功能不够灵活，组网模式也比较受限。Quantum作为独立的网络管理项目出现在F版本，除了linux-bridge外还支持OVS，以及以及其他商业公司的插件，组网模式上增加了对GRE和VxLAN两个Overlay技术的支持。优点是功能灵活，支持大二层组网；缺点是集中式的网络节点缺乏HA，而且各厂商插件无法同时在底层网络中运行。Neutron出现在H版本，由来是Quantum和一家公司的名称冲突而改名。Neutron对Quantum的插件机制进行了优化，将各个厂商L2插件中独立的数据库实现提取出来，作为公共的ML2插件存储租户的业务需求，使得厂商可以专注于L2设备驱动的实现，而ML2作为总控可以协调多厂商L2设备共同运行。Neutron继承了Quantum对大二层的支持，还支持L2 PoP，DVR，VRRP，HA等关键功能，集成了很多L4-L7的网络服务，一些blueprint也正在积极开发中，如SFC等。优点是开始引入SDN思想，功能上更为丰富，网络兼容性强；缺点是代码结构复杂，工作不够稳定，HA机制仍缺乏大规模商用的检验。

从应用场景来看，Nova-network组网模式过于简单，一些复杂的网络需求无法实现（比如两个公司合并，有大量IP重合的VM要迁移到一个平台，而且要求迁移后都要用原来的IP）。不过由于其简单稳定的特点，仍适合于中小型企业的生产环境；Quantum的实际部署目前基本都跟进到了Neutron；Neutron的大二层组网，适合于云计算规模的生产环境，但是由于分布式和HA机制仍不够成熟，因此目前多见于私有云和小规模共有云的部署，大规模的公有云仍然难以使用Neutron实现。

Nova-network、Quantum、Neutron的对比分析。

	出现 版本	支持组 网模式	优点	缺点	适用场景
Nova-network	早期	FlatFlat DhcpVLAN	性能出色工作稳定支持multi-host部署 以实现HA	网络管理不独立功能不够灵活组网方式受限	对性能和稳定性要求比较高；中小规模网络；网络运维成本有限；私有云环境
Quantum	Folsom	FlatFlat DhcpVLANOverlay	独立的网络管理支持大二层支持多厂商插件	缺乏HA机制各厂商插件无法 共同运行	基本上已经都跟进到了Neutron
Neutron	Havana	FlatFlat DhcpVLANOverlay	继承了Quantum的优点功能上更为丰富网络兼容性强开始引入SDN的思想	代码结构复杂工作不够稳定HA机制仍缺乏大规模商用的检验	对功能要求比较多或希望向SDN演进；大规模网络或对可扩展性要求高；有专业的网络运维团队；公有云环境

说完了基本特征与应用场景，下面开始对上述提到的一些网络问题进行详细的描述。我们抛开技术，结合图例来抽象地看看不同的组网模型。当然，以下模型的实现不仅仅局限于三张图中的方式。

Flat模型最为简单，所有的虚拟机共用一个私有IP网段，IP地址在虚拟机启动时完成注入，虚拟机间的通信直接通过HyperVisor中的网桥转发，公网流量在该网段的网关上进行NAT（Nova-network实现为开启nova-network主机内核的iptables，Neutron实现为网络节点上的l3-agent）。Flat DHCP模型与Flat区别在于网桥中开启了DHCP进程，虚拟机通过DHCP消息获得IP地址（Nova-network实现为nova-network主机中的dnsmaq，Neutron实现为网络节点上的dhcp-agent）。VLAN模型引入了多租户机制，虚拟机可以使用不同的私有IP网段，一个租户可以拥有多个IP网段。虚拟机IP通过DHCP消息获取IP地址（Nova-network实现为nova-network主机中的dnsmaq，Neutron实现为网络节点上的dhcp-agent）。网段内部虚拟机间的通信直接通过HyperVisor中的网桥转发，同一租户跨网段通信通过网关路由，不同租户通过网关上的ACL进行隔离，公网流量在该网段的网关上进行NAT（Nova-network实现为开启nova-network主机内核的iptables，Neutron实现为网络节点上的l3-agent）。如果不同租户逻辑上共用一个网关，则无法实现租户间IP地址的复用。Overlay模型（包括GRE和VxlAN隧道技术），相比于VLAN模型有以下改进。1）租户数量从4K增加到16million；2）租户内部通信可以跨越任意IP网络，支持虚拟机任意迁移；3）一般来说每个租户逻辑上都有一个网关实例，IP地址可以在租户间进行复用；4）能够结合SDN技术对流量进行优化。

看过抽象的组网模型，下面我们来介绍组网具体的实现技术。由于本章的重点是SDN与云，因此下面的介绍都是针对Neutron的，对nova-network和Quantum将不做讨论。

首先，我们需要对Neutron的3类节点和3种网络有所认识。

3类节点——管理节点：实现镜像、块存储、身份认证、前端等服务，运行nova-compute的调度模块以及nova api-server；计算节点：实现nova-compute，以及neutron的各种agent（一般不包括l3-agent，DVR除外）；网络节点，：实现neutron各种agent。注意，由于OpenStack为分布式架构实现，因此neutron-server既可以运行在控制节点，也可以运行在网络节点。3种网络——OpenStack内部模块之间的交互发生在管理网络，虚拟机之间的通信发生在数据网络，而External Network/API Network网络是连接外网的，无论是用户调用Openstack API，还是虚拟机与外网间的互通都需要经过这个网络。目前OpenStack通常采用out-of-bound方式进行部署，管理网络与另外两个网络是独立的，也并不涉及复杂的组网需求，下面的分析只针对数据网络与External Network/API Network网络。

有了以上知识作为基础，就可以来分析虚拟机的通信过程了。由于OpenStack中容器的通信机制目前尚不成熟，并且有专门的项目Kuryr去实现容器相关网络技术，以下内容将不涉及OpenStack中的容器通信。

以下将通过三张图来分析Neutron中的VLAN组网模型，HyperVisor中的网络设备以OpenvSwitch为例。这三张图中每一个信息都是有用的，把这些信息完全弄懂了，Neutron的组网也就能基本掌握了，Overlay模型与VLAN模型的区别只在于将图中的br-eth1替换成br-tun即可，具体隧道如何进行封装，后面的文章中我们会详细介绍。

第一张图是计算节点上的网络实现。以虚拟机发出流量方向为例，从虚拟机处开始分析：
1)流量经由虚拟机IP内核交给虚拟网卡处理，虚拟网卡由TAP软件实现，TAP允许用户态程序向内核协议栈注入数据，它可以运行于虚拟机操作系统之上，能够提供与硬件以太网卡完全相同的功能。

2)TAP设备并不是直接连接到OVS上的，而是通过linux bridge中继到ovs br-int上，其原因在于ovs无法实现linux bridge中一些带状态的iptables规则，而这些规则往往用于以虚拟机为单位的安全组（security group）功能的实现。qbr是quantum bridge的缩写，Neutron中沿用了Quantum的叫法。

3)linux bridge与ovs br int间的连接通过veth-pair技术实现，qvb代表quantum veth bridge，qvo代表quantum veth ovs。veth-pair用于连接两个虚拟网络设备，总是成对出现以模拟虚拟设备间的数据收发，其原理是反转通讯数据的方向，需要发送的数据会被转换成需要收到的数据重新送入内核网络层进行处理。veth-pair与tap的区别可以简单理解为veth-pair是软件模拟的网线，而tap是软件模拟的网卡。

4)ovs br-int是计算节点本地的虚拟交换设备，根据neutron-server中OVS Plugin的指导，完成流量在本地的处理：本地虚拟机送入的流量被标记本地VLAN tag，送到本地虚拟机的流量被去掉本地VLAN tag，本地虚拟机间的2层流量直接在本地转发，本地虚拟机到远端虚拟机、网关的流量由int-br-eth1送到ovs br-eth1上（在Overlay模型中送到ovs br-tun上）。无论是VLAN模型还是Overlay模型，由于br-int上VLAN数量的限制，计算节点本地最多支持4K的租户。

5)ovs br-int与ovs br-eth1间的连接通过veth-pair技术实现。

6)ovs br-eth1将该计算节点与其他计算节点、网络节点连接起来，根据neutron-server中OVS Plugin的指导，完成流量送出、送入本地前的处理：根据底层物理网络租户VLAN与本地租户VLAN间的映射关系进行VLAN ID的转换（Overlay模型中此处进行隧道封装，并进行VNI与本地租户VLAN ID间的映射）。由于底层物理网络中VLAN数量的限制，VLAN模型最多支持4K的租户，而Overlay模型中，24位的VNI最多支持16million的租户。

7)ovs br-eth1直接关联物理宿主机的硬件网卡eth1，通过eth1将数据包送到物理网络中。Overlay模型中ovs br-tun通过TUN设备对数据包进行外层隧道封装并送到HyperVisor内核中，内核根据外层IP地址进行选路，从硬件网卡eth1将数据包送到物理网络中。TUN与TAP的实现机制类似，区别在于TAP工作在二层，而TUN工作在三层。

第二张图和第三张图是网络节点上的网络实现，需要结合在一起来看。以流量流入网络节点方向为例，从底层物理网络流量通过eth1进入ovs br-eth1（Overlay模型中为ovs br-tun）开始分析：

1)ovs br-eth1将网络节点与计算节点连接起来，根据neutron-server中OVS Plugin的指导，完成流量送入网络节点前的处理：根据底层物理网络租户VLAN与本地租户VLAN间的映射关系进行VLAN ID的转换（Overlay模型中此处进行解封装，并进行VNI与本地租户VLAN ID间的映射）。注意，虽然同一租户在底层物理网络上的VLAN ID（Overlay模型中为VNI）唯一，但是在网络节点与计算节点，不同计算节点中同一租户对应的本地VLAN ID可能有所不同。另外由于网络节点也要在ovs br-int上使用本地VLAN，而租户跨网段流量与公网流量都要经过网络节点，因此使用单个网络节点时，Neutron最多能支持4K租户，可采用部署多个网络节点的方式来解决这一问题。

2)送入网络节点的流量，由ovs br-eth1（ovs br-tun）通过veth-pair送给ovs br-int，ovs br-int连接了本地不同的namespace，包括实现dhcp功能的dhcp-agent——dnsmasq，以及实现路由功能的l3-agent——router。Dnsmasq负责给对应租户的虚拟机分配IP地址，而router负责处理租户内跨网段流量以及公网流量。不同的租户有不同的dnsmasq和router实例，因此不同租户间可以实现IP地址的复用。

3)Router namesapce通过qr接口（Quantum Router）接收到租户内跨网段流量以及公网流量，在ns的IP内核中对跨网段流量进行路由，改写MAC地址并通过相应的qr接口向ovs br-int送出数据包。在ns的IP内核中对公网流量进行NAT，并通过qg接口（Quantum Gateway）发送给ovs br-ex。

4)Ovs br-ex通过关物理联宿主机的硬件网卡eth1将流量送至Internet路由器。

5)上述两幅图中，ovs br-int与ovs br-ex间有直连，据说主要是防止l3-agent出现问题时能够保证流量不中断，但实际上看来很少出现此问题。

上图是在网上看过的更加细致，更为全面的一张图，图中清晰地展示了Neutron对多种L2技术（VLAN、VxLAN、GRE）共同运行的支持。图中的82599/i350/mellonax是硬件厂商搞出的具备转发功能的网卡，能够避免虚拟交换机带来的资源消耗，并能够加快转发速率。一块这样的网卡能虚拟出63个VF，每个VF就好像一个独立的物理网卡一样，通过将VF直接挂到虚拟机上，能够实现转发性能的大幅度提高。

以上介绍了OpenStack中网络组件的演进，以及Neutron组网的基本原理。下一节我们将对Neutron的软件实现进行简单的介绍。

本文转自d1net（转载）