source: http://blog.csdn.net/beginning1126/article/details/41172365#comments
OpenStack网络体系中,网络技术没有创新,但用到的技术点非常庞杂,包括bridge、vlan、gre、vxlan、ovs、openflow、sdn、iptables等,当然这里不会做具体技术介绍,概述技术,主要将其与openstack的结合点做详细分析。
在nova-network中,其网络模型包括flat、dhcp flat、vlan,用到的技术主要有bridge、vlan,
优点:结构简单,稳定
缺点:所有租户都在一个水平面上,租户之间没有隔离,由于所有租户都在一个子网内,当大规模部署后,其广播风暴将会是不小的负面因素,至于这种模型其vm的上限,笔者还没有条件测试。
优点:租户有隔离
缺点:需要物理交换机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网络体系相比于nova-network要复杂的多,用到的技术点也非常庞杂,在介绍网络架构之前,有必要概述下gre、vxlan、ovs、openflow、sdn技术点。
上面阐述过,vlan技术存在vlan id个数限制4094,公有云租户肯定不止4094,二层技术,只能部署在一个局域网内,无法实现跨机房部署。为了突破这俩个限制,增加了gre和vxlan隧道技术。
跨机房部署:3层隧道技术,在原来小网ip头前面加入大网ip头和gre头,大网ip头里面的ip是公网ip;
segment id:而gre头里面最重要的字段应该是4字节key值(segment id),充当了vlan技术里面的vlan id,隔离租户的作用,由于是4个字节,已经不受4094 vlan id限制。下图是gre典型应用。
当然gre也有其缺点,
针对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主要分为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相比于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 Server: 这 一部分包含守护进程neutron-server和各种插件neutron-*-plugin,它们既可以安装在控制节点也可以安装在网络节点。 neutron-server提供API接口,并把对API的调用请求传给已经配置好的插件进行后续处理。插件需要访问数据库来维护各种配置数据和对应关系,例如路由器、网络、子网、端口、浮动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区别不大。
是不是看到这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而言),
这里值得一提的是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地址的转换。
有了ovs的基础,理解bridge的结构就简单多了,但是作者在用rdo搭建bridge + vxlan的环境时,遇到很多问题:
rdo安装linuxbridge,需修改neutron_350.py create_l3_manifests函数;
典型的组网方式包括nova-network的dhcpflat、vlan,neutron的bridge + vlan、bridge + vxlan、ovs + vlan、ovs + vxlan,其选择上可以从3个维度来看,nova-network和neutron的选择、网络拓扑flat、vlan、gre、vxlan的选择、插件Linux bridge和ovs的选择。
结论:未来的openstack,neutron组件会是其趋势,nova-network会渐渐被替换掉,但是在未解决其稳定性和network node ha问题之前还不适用于线上环境。
结论:如果不需要通过大二层网络实现跨机房部署,可以选择vlan,如果涉及到跨机房部署,需要大二层的通信方式,选择vxlan。
这两种插件是目前业界使用最多的,非官方统计(摘自http://wenku.it168.com/d_001350820.shtml) 二者在众多插件使用份额是,Linux bridge31%、ovs 39%
实验室测试结果:
不同host上的两个vm,通过ping测试响应时间,如下表所示
组网 |
fixed ip |
floating ip |
备注 |
Linux bridge + vxlan |
1.124ms |
1.509ms |
|
ovs + vxlan |
1.179ms |
1.898ms |
|
关闭安全组 ovs + vxlan |
1.073ms |
在同一个host上的,2个vm互跑流量,如下表所示
组网 |
吞吐量 |
cpu占用情况 |
备注 |
Linux bridge + vxlan |
7.86 Gbits/sec |
23.7%us, 15.7%sy, 52.1%id, 8.5%si |
|
ovs + vxlan |
7.10 Gbits/sec |
23.1%us, 16.5%sy, 46.9%id, 13.5%si |
|
关闭安全组ovs + vxlan |
8.32 Gbits/sec |
28.7%us, 19.4%sy, 46.3%id, 5.6%si |
测试结果说明:
1、cpu占用量记录的是瞬时值,上下会有大约5%的波动。
2、关于响应时间:ovs+ vxlan(关闭安全组)< Linux bridge + vxlan < ovs +vxlan
3、关于吞吐量:ovs+ vxlan(关闭安全组)> Linux bridge + vxlan > ovs +vxlan
4、在ovs组网中,需要为每个vm创建一个bridge(用于安全组的实现),所以关闭安全组,将vm直接桥接到ovs上,其吞吐量响应时间都会有所改善。
5、就本次结果来看,在不采用安全组的情况下,ovs性能要略好于Linux bridge
网上找的一篇测试报告(原文链接: https://docs.google.com/viewer?url=http%3A%2F%2Fwww.ustack.com%2Fwp-content%2Fuploads%2F2013%2F10%2FNeutron-performance-testing.pdf)结论:关于ovs的性能问题,还需要大量线上测试(这部分工作,作者正在做,希望尽快给出量化指标),所以在未确定ovs性能是否达到我们要求之前,建议使用Linux bridge。
通过查阅openstack官方文档,其更倾向于bridge+vlan和ovs+vlan
公有云其vm个数巨大,几十万、几百万的数量级,涉及跨机房部署,需要大二层通信机制。私有云其vm个数相对有限,几千、几万的数量级,可以在每个机房单独部署一套openstack环境,大二层通信的需求相对弱一些。