openstack 网络架构 nova-network + neutron，openstackneutron

openstack网络架构（nova-network/neutron）

openstack网络体系中，网络技术没有创新，但用到的技术点非常庞杂，包括bridge、vlan、gre、vxlan、ovs、openflow、sdn、iptables等，当然这里不会做具体技术介绍，概述技术，主要将其与openstack的结合点做详细分析。

nova-network网络架构

在nova-network中，其网络模型包括flat、dhcp flat、vlan，用到的技术主要有bridge、vlan，

dhcp flat多网络节点架构图如下所示：

优点：结构简单，稳定

缺点：所有租户都在一个水平面上，租户之间没有隔离，由于所有租户都在一个子网内，当大规模部署后，其广播风暴将会是不小的负面因素，至于这种模型其vm的上限，笔者还没有条件测试。

vlan架构如下所示：

• 为租户创建独占的bridge
• 创建vlan接口vlan100，依据802.1q协议打vlanid
• Dnsmasq监听网桥网关，负责fixedip的分配
• switch port设定为chunk mode
• eth0负责vm之间的数据通信，eth1负责外网访问

vlan模型：

优点：租户有隔离

缺点：需要物理交换机chunk口的支持，实际部署时比较复杂，vlan id个数为4094个，也就是最多4094个子网租户，不适用于公有云。

结论：相比于neutron网络，虽说没有neutron那么多的功能插件，仅有bridge，但是其稳定性已得到大多数用户的验证，对于小规模的私有云(1千台虚机的规模)，nova-network是可以考虑的，目前线上部署的环境也是nova-network。

参考资料：

https://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/

https://www.mirantis.com/blog/vlanmanager-network-flow-analysis/

https://www.mirantis.com/blog/openstack-networking-vlanmanager/

http://blog.csdn.net/hilyoo/article/details/7721401

http://blog.csdn.net/beginning1126/article/details/39371757

neutron网络架构

neutron网络体系相比于nova-network要复杂的多，用到的技术点也非常庞杂，在介绍网络架构之前，有必要概述下gre、vxlan、ovs、openflow、sdn技术点。

上面阐述过，vlan技术存在vlan id个数限制4094，公有云租户肯定不止4094，二层技术，只能部署在一个局域网内，无法实现跨机房部署。为了突破这俩个限制，增加了gre和vxlan隧道技术。

GRE：

跨机房部署：3层隧道技术，在原来小网ip头前面加入大网ip头和gre头，大网ip头里面的ip是公网ip；

segment id：而gre头里面最重要的字段应该是4字节key值（segment id），充当了vlan技术里面的vlan id，隔离租户的作用，由于是4个字节，已经不受4094 vlan id限制。下图是gre典型应用vpn。

当然gre也有其缺点，

VXLAN：

针对vlan和gre的第一个缺点，业界提出了vxlan技术，下图分别是vxlan头结构和通信流程。

结论：

参考资料：

http://blog.csdn.net/freezgw1985/article/details/16354897

http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-729383.html

openflow

openflow主要分为controller和flow table，并且其通信遵循openflow协议。增加了controller点，openflow switch仅仅根据flow table设定好的规则对数据做路由或丢弃等操作，而整个系统的大脑部分在controller，所有flow table的路由规则、处理方法都是从controller得到。

Openflow的优点：

Openflow问题：

实验室截取的流表实例：

参考资料：

http://www.ibm.com/developerworks/cn/cloud/library/1303_silei_openflow/

http://mytrix.me/2014/04/dive-into-openstack-neutron-on-compute-node/

http://www.kankanews.com/ICkengine/archives/101651.shtml

OVS：

相比于Linux bridge，ovs有以下好处

参考资料：

http://blog.csdn.net/canxinghen/article/details/39344797

http://bengo.blog.51cto.com/4504843/791213                    

http://www.cloudstack-china.org/2013/09/2484.html

到此为止，关于gre、vxlan、openflow、ovs基本情况基本介绍完了，下面将是应用这些技术介绍neutron网络架构体系。

neutron体系结构组成

Control node：neutronserver(api/neutron-*-plugin)

Network node：neutron-*-plugin-agent/l3-agent/dhcp-agent

Computer node：neutron-*-plugin-agent

在neutron体系中，应用最多的两个插件就是Linux bridge和ovs，笔者在实验室分别搭建过Linux bridge+vxlan和ovs+vxlan。下面分别是从官网上截取的网络结构图，官网给出的是vlan的情况，其实和vxlan区别不大。

ovs+vxlan computer node and network node

网络架构图

是不是看到这2张图就有些晕了，这么多个bridge、tap设备都是做什么用的，理解这些设备其实并不难，redhat有篇文章写的非常详细，大家看看就非常明白了，https://openstack.redhat.com/Networking_in_too_much_detail，官方给出的图是vlan拓扑，其实只要将图中的vlan device改成vxlan device就可以，不妨碍表述结构。

在ovs结构中，如果网络拓扑是vxlan或gre，则有两个bridge，分别是br-int和br-tun(上图由于是vlan环境，没有br-tun，而是br-eth1)，br-int叫集成网桥，用于连接起上方的各个设备（包括vm、dhcp-agent、l3-agent），br-tun叫隧道网桥，隧道既可以是gre，也可以是vxlan，br-tun负责在原始报文中加入gre或vxlan报文头。相当于软件实现了vtep设备(对于vxlan而言)，

flow table

这里值得一提的是network node br-tun中的flow table，如下图所示，对于flow table的各个表项大家可以参考文章http://mytrix.me/2014/04/dive-into-openstack-neutron-on-compute-node/，这里不做过多阐述。

作者实验室搭建了1个network node和2个computer node，port 1对应网络节点的br-int，port 2、3对应2个computer node，可以看出，当由computer node来的数据包（port 2、3），改完vlan标签之后，要先通过自学习的过程（对应table 10），然后输出给port 1，学习的结果就是table 20，table 20将vlan id和目标vm的mac地址作为匹配项，匹配上之后。输出给port 2、3。

通信流程

同一租户不同host vm fixed ip通信流程如下图所示，如果通过fixed ip通信，不需要经过network node，通过br-tun加上vxlan标签则可以实现不同host上的vm通信。

不同租户不同host vm floating ip通信流程如下图所示，如果是通过floating ip进行通信，需要经过network node做dnat、snat、路由，为什么要通过network node呢？原因是目标ip地址是floating ip，和vm2 fixed ip不在一个网段，所以其对ip包的处理需要将包传递给租户2的默认网关mac4/ip4，传给给默认网关后需要做dnat转换，然后路由给租户1的默认网关mac3/ip3，再做snat转换，最后将包传递给vm1，注意包传递过程中，其内外层mac地址和ip地址的转换。

Linux bridge + vxlan computer node and network node

有了ovs的基础，理解bridge的结构就简单多了，但是作者在用rdo搭建bridge + vxlan的环境时，遇到很多问题：

======================华丽的分割线==========================================

结论

nova-network和neutron的选择：flat模式有广播风暴的风险，不适于大规模部署（一千台vm），vlan需要配置物理交换机chunk，neutron由于gre和vxlan的引入，可以解决广播风暴，又不需要配置物理交换机chunk口，但是neutron目前最大的问题是稳定性，而且iec house版本不支持network muti-host部署（据说juno版本支持，接下来搭建个环境研究一下），所以在解决其稳定性和network node ha问题之前也不适用于线上环境。

网络拓扑flat、vlan、gre、vxlan的选择：vxlan解决了vlan id个数限制和跨机房互通问题，同时解决了gre点对点隧道个数过多问题，同时实现了大2层网络，可用于vm在机房之间的的无缝迁移，所以vxlan的选择上没有太多质疑，唯一的缺点就是vxlan增加了ip头部大小，需要降低vm的mtu值，传输效率上会略有下降。

Linux bridge和ovs的选择：这两种插件是目前业界使用最多的，非官方统计（摘自http://wenku.it168.com/d_001350820.shtml）二者在众多插件使用份额是，Linux bridge31%、ovs 39%，ovs的优点就是可以针对每个vm做流量限制、流量监控、数据包分析，但是业界普遍认为其性能是个大问题（这点作者正在实验室搭建环境，测试二者性能，希望后续能给出量化指标），所以二者的选择上，还需大量测试才能决定。

目前SDN虽说很火，并且很多公司提供了SND物理交换机，但是其仍处于研究阶段，于大规模部署还很长的路要走，neutron的稳定性还需要大量测试和修改，也有很长的路要走。