您可以捐助,支持我们的公益事业。

金额: 1元 10元 50元

姓名:

邮件:

电话:

公司:

说明:

认证码: 验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   专家招募  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
openstack网络架构(nova-network/neutron)
 
作者:zfyouxi 来源:博客园 发布于 2015-8-7
来自于要资料   3271 次浏览     评价:      
 

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。

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也有其缺点,

1.gre是点对点技术,每两个点之间都须要有一个隧道,对于4层的port资源是一种浪费;

2.添加ip头,势必降低vm的mtu值,相同大小的数据,须要很多其它的ip包来传,传输效率有影响。

VXLAN:

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

1.24bit的VNID:vxlan技术在原有mac帧基础上添加了新的mac头、ip头、vxlan header,在vxlan header中,VNID相当于vlan id,24bit,16M的大小,远大于4094.

2.大二层网络,实现跨机房部署:在通信两端添加了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层网络。

3.能让遗留子网不改变 IP 地址的情况下无缝的迁移到云上来;也能够让虚机跨数据中心进行迁移(曾经顶多仅仅能在同一个 VLAN 里迁移)

4.关于跨机房vxlan互通:前述通过组播消息实现arp的传输,可是在广域网上,组播包传输是受限制的,眼下业界通常的解决方式是通过SDN controller,SDN controller兼做arp代理,并获取vm内层mac和外层VTEP ip相应关系,不同controller之间交换这些信息。

结论:

1.gre攻克了vlan id个数限制和跨机房互通问题;

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

openflow

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

Openflow的长处:

1.控制逻辑和物理交换网络相分离;

2.物理网络切割成相互独立的逻辑网络

Openflow问题:

1.和现有物理网络相冲突,非常难实际应用

实验室截取的流表实例:

OVS:

相比于Linux bridge,ovs有下面优点

1.Qos配置,能够为每台vm配置不同的速度和带宽

2.流量监控

3.数据包分析

4.将openflow引入到ovs中,实现控制逻辑和物理交换网络分离。

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

neutron体系结构组成

1.Neutron Server: 这 一部分包括守护进程neutron-server和各种插件neutron-*-plugin,它们既能够安装在控制节点也能够安装在网络节点。 neutron-server提供API接口,并把对API的调用请求传给已经配置好的插件进行兴许处理。插件须要訪问数据库来维护各种配置数据和相应关系,比如路由器、网络、子网、port、浮动IP、安全组等等。

2.插件代理(Plugin Agent):虚拟网络上的数据包的处理则是由这些插件代理来完毕的。名字为neutron-*-agent。在每一个计算节点和网络节点上执行。一般来说你选择了什么插件,就须要选择对应的代理。代理与Neutron Server及其插件的交互就通过消息队列来支持。

3.DHCP代理(DHCP Agent): 名字为neutron-dhcp-agent,为各个租户网络提供DHCP服务,部署在网络节点上,各个插件也是使用这一个代理。

4.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的环境时,遇到非常多问题:

1.rdo安装linuxbridge,需改动neutron_350.py create_l3_manifests函数;

2.配置Linuxbridge + vxlan环境,computer node network node,其linuxbridge_conf.ini配置项enable_vxlan、vxlan_group、local_ip一定要加以配置,否则bridge、vxlan设备则不能正确创建,虚拟机也无法创建;

3.对于Linuxbridge + vxlan环境,network node须要2块网卡,一个内网、一个外网,一个用于dhcp,一个用于floating ip外网訪问,这个是必须的,否则二者功能仅仅能取其一,可是在搭建ovs环境时,却没有这个问题,非常奇怪;

4.network node须要手工创建一个br-ex,用于外网訪问;

5.最诡异的是,环境搭建完毕初始状态,network node上,各tap设备绑定的bridge全是错误的,须要手动改动;

6.须要改动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的选择:

1.nova-network:稳定,结构简单,但眼下仅支持linux bridge一种插件;

2.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的选择:

1.flat: 模式简单,但有广播风暴的风险,不适于大规模部署(一千台vm?);

2.vlan:能够隔离广播风暴,但须要配置物理交换机chunk口;

3.gre:能够隔离广播风暴,不须要交换机配置chunk口, 攻克了vlan id个数限制,3层隧道技术能够实现跨机房部署。但gre是点对点技术,每两个点之间都须要有一个隧道,对于4层的port资源是一种浪费;

4.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%

1.Linux bridge:历史悠久,稳定性值得信赖,可是当vm个数过多,二层交换出现故障时,眼下没有特别好的定位手段。

2.ovs:能够针对每一个vm做流量限制、流量监控、数据包分析,同一时候能够引入openflow,引入sdn controller,使控制逻辑和物理交换相分离,而且sdn controller能够实现vxlan的跨机房大二层通信,可是业界普遍觉得其性能是个大问题。

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

官方推荐的组网方式:

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

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

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

   
 订阅
  捐助
 
相关文章

云计算的架构
对云计算服务模型
云计算核心技术剖析
了解云计算的漏洞
 
相关文档

云计算简介
云计算简介与云安全
下一代网络计算--云计算
软浅析云计算
 
相关课程

云计算原理与应用
云计算应用与开发
CMMI体系与实践
基于CMMI标准的软件质量保证
 

深度解析---云安全
汉周云计算白皮书简版
基于云计算的通讯录产品设计
云计算呼叫中心的应用
中国式的云计算服务模式
云计算技术和体系结构调研
相关培训课程

云计算原理与应用
Windows Azure 云计算应用

摩托罗拉 云平台的构建与应用
通用公司GE Docker原理与实践
某研发中心 Openstack实践
知名电子公司 云平台架构与应用
某电力行业 基于云平台构建云服务
云计算与Windows Azure培训
北京 云计算原理与应用
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号