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负责外网訪问

长处：租户有隔离

缺点：须要物理交换机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也有其缺点，

gre是点对点技术，每两个点之间都须要有一个隧道，对于4层的port资源是一种浪费；
添加ip头，势必降低vm的mtu值，相同大小的数据，须要很多其它的ip包来传，传输效率有影响。

VXLAN：

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

24bit的VNID：vxlan技术在原有mac帧基础上添加了新的mac头、ip头、vxlan header，在vxlan header中，VNID相当于vlan id，24bit，16M的大小，远大于4094.
大二层网络，实现跨机房部署：在通信两端添加了VTEP设备，能够硬件设备，也能够软件实现，当然在neutron网络中，其是由软件实现的。该设备记录vlan id、vm mac、vtep ip的相应关系，这个关系是由vm发起arp请求获取到的。在vxlan网络中有个组播地址，全部vtep设备都须要添加该组播地址，vtep将arp的广播请求添加组播ip头转变为组播请求，一旦一个vm发起arp请求，全部vtep都能收到，vtep在将组播ip头去掉，将原始广播包发给vm，这样不同vm之间将建立起arp表。vxlan网络为全部vm建立一个大2层网络。
能让遗留子网不改变 IP 地址的情况下无缝的迁移到云上来；也能够让虚机跨数据中心进行迁移（曾经顶多仅仅能在同一个 VLAN 里迁移）
关于跨机房vxlan互通：前述通过组播消息实现arp的传输，可是在广域网上，组播包传输是受限制的，眼下业界通常的解决方式是通过SDN controller，SDN controller兼做arp代理，并获取vm内层mac和外层VTEP ip相应关系，不同controller之间交换这些信息。

结论：

gre攻克了vlan id个数限制和跨机房互通问题；
vxlan攻克了vlan id个数限制和跨机房互通问题，同一时候攻克了gre点对点隧道个数过多问题，同一时候实现了大2层网络，可用于vm在机房之间的的无缝迁移。

參考资料：

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有下面优点

Qos配置，能够为每台vm配置不同的速度和带宽
流量监控
数据包分析
将openflow引入到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体系结构组成

Neutron Server：这一部分包括守护进程neutron-server和各种插件neutron-*-plugin，它们既能够安装在控制节点也能够安装在网络节点。 neutron-server提供API接口，并把对API的调用请求传给已经配置好的插件进行兴许处理。插件须要訪问数据库来维护各种配置数据和相应关系，比如路由器、网络、子网、port、浮动IP、安全组等等。
插件代理（Plugin Agent）：虚拟网络上的数据包的处理则是由这些插件代理来完毕的。名字为neutron-*-agent。在每一个计算节点和网络节点上执行。一般来说你选择了什么插件，就须要选择对应的代理。代理与Neutron Server及其插件的交互就通过消息队列来支持。
DHCP代理（DHCP Agent）：名字为neutron-dhcp-agent，为各个租户网络提供DHCP服务，部署在网络节点上，各个插件也是使用这一个代理。
3层代理（L3 Agent）：名字为neutron-l3-agent，为客户机訪问外部网络提供3层转发服务。也部署在网络节点上。

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的环境时，遇到非常多问题：

rdo安装linuxbridge，需改动neutron_350.py create_l3_manifests函数；
配置Linuxbridge + vxlan环境，computer node network node，其linuxbridge_conf.ini配置项enable_vxlan、vxlan_group、local_ip一定要加以配置，否则bridge、vxlan设备则不能正确创建，虚拟机也无法创建；
对于Linuxbridge + vxlan环境，network node须要2块网卡，一个内网、一个外网，一个用于dhcp，一个用于floating ip外网訪问，这个是必须的，否则二者功能仅仅能取其一，可是在搭建ovs环境时，却没有这个问题，非常奇怪；
network node须要手工创建一个br-ex，用于外网訪问；
最诡异的是，环境搭建完毕初始状态，network node上，各tap设备绑定的bridge全是错误的，须要手动改动；
须要改动vm mtu值，否则vm之间通信效率很差。

组网方式

典型的组网方式包含nova-network的dhcpflat、vlan，neutron的bridge + vlan、bridge + vxlan、ovs + vlan、ovs + vxlan，其选择上能够从3个维度来看，nova-network和neutron的选择、网络拓扑flat、vlan、gre、vxlan的选择、插件Linux bridge和ovs的选择。

nova-network和neutron的选择：

nova-network：稳定，结构简单，但眼下仅支持linux bridge一种插件；
neutron：能够支持bridge、ovs等众多插件，并且通过ml2技术能够实现众多插件混合使用，引入openflow等sdn技术，是控制逻辑和物理网络相隔离。但neutron眼下最大的问题是稳定性（比如创建过多的vm，host会无故重新启动，neutron服务会无故down掉，floating ip无法正常释放等，这些问题眼下都在查找原因，尚未解决），并且iec house版本号不支持network muti-host部署（据说juno版本号支持，接下来搭建个环境研究一下）

结论：未来的openstack，neutron组件会是其趋势，nova-network会渐渐被替换掉，可是在未解决其稳定性和network node ha问题之前还不适用于线上环境。

网络拓扑flat、vlan、gre、vxlan的选择：

flat：模式简单，但有广播风暴的风险，不适于大规模部署（一千台vm？）；
vlan：能够隔离广播风暴，但须要配置物理交换机chunk口；
gre：能够隔离广播风暴，不须要交换机配置chunk口，攻克了vlan id个数限制，3层隧道技术能够实现跨机房部署。但gre是点对点技术，每两个点之间都须要有一个隧道，对于4层的port资源是一种浪费；
vxlan：能够隔离广播风暴，不须要交换机配置chunk口，攻克了vlan id个数限制，攻克了gre点对点隧道个数过多问题，实现了大2层网络，可用于vm在机房之间的的无缝迁移，便于跨机房部署。唯一的缺点就是vxlan添加了ip头部大小，须要减少vm的mtu值，传输效率上会略有下降。

结论：假设不须要通过大二层网络实现跨机房部署，能够选择vlan，假设涉及到跨机房部署，须要大二层的通信方式，选择vxlan。

Linux bridge和ovs的选择：

这两种插件是眼下业界使用最多的，非官方统计（摘自http://wenku.it168.com/d_001350820.shtml）二者在众多插件使用份额是，Linux bridge31%、ovs 39%

Linux bridge：历史悠久，稳定性值得信赖，可是当vm个数过多，二层交换出现故障时，眼下没有特别好的定位手段。
ovs：能够针对每一个vm做流量限制、流量监控、数据包分析，同一时候能够引入openflow，引入sdn controller，使控制逻辑和物理交换相分离，而且sdn controller能够实现vxlan的跨机房大二层通信，可是业界普遍觉得其性能是个大问题。

结论：关于ovs的性能问题，还须要大量线上測试（这部分工作，作者正在做，希望尽快给出量化指标），所以在未确定ovs性能是否达到我们要求之前，建议使用Linux bridge。

官方推荐的组网方式：

通过查阅openstack官方文档，其更倾向于bridge+vlan和ovs+vlan

私有云和公有云的组网差异：

公有云其vm个数巨大，几十万、几百万的数量级，涉及跨机房部署，须要大二层通信机制。私有云其vm个数相对有限，几千、几万的数量级，能够在每一个机房单独部署一套openstack环境，大二层通信的需求相对弱一些。

未完待续。。。。。