讲清楚说明白openstack中vm流量走向之2——DVR模式

一、背景介绍

上一篇文章已经介绍过,在集中式网络节点模式下,所有的计算节点只安装二层代理,所有三层流量无论是南北或东西走向都必须经过网络节点,尽管可以通过HA的方式保证网络节点的高可用,但是基于vrrp的HA方式同一时间点只有一个网络节点处于工作状态,这样在大规模场景下网络节点仍然会成为性能瓶颈,为此openstack社区从Juno版本开始推出的DVR模式来解决上述问题,需要说明的是:在Mitaka版本之前DVR与L3 HA功能不能同时启用,从Mitaka版本之后才支持DVR与L3 HA功能同时开启。

二、DVR介绍

为了解决网络节点的流量瓶颈问题,DVR通过在计算节点部署L3 Agent,让不同subnet之间的东西流量和绑定floating ip的vm的南北流量直接通过计算节点访问外网,只有未绑定floating ip的vm的南北南北流量才需要通过网络节点SNAT访问外网,此时的集群架构如下图所示:

不同于集中式网络节点中所有计算节点只走二层流量,DVR模式下,每个计算节点都可以走3层流量,以此来分摊网络节点的流量压力。

三、网络、计算节点的内部组件

1.网络节点

DVR模式下,网络节点内部组件此时如下图所示:

可以看到,启用DVR模式后的网络节点多了一个SNAT Namespace空间。在在所有计算节点都开启DVR功能时,Router Namespace中的Metadata Agent只负责处理Project网络中的元数据,SNAT Namespace空间负责对只有fix ip的vm通过源地址转换的方式访问外网。如果所有的计算节点将DVR模式关闭,此时vm的流量和集中式网络节点一致,即所有的三层流量都需要经过网络节点的Router Namespace处理。

2.计算节点

当开启DVR功能后,此时计算节点内部组件如下图所示:

启用DVR功能的计算节点因为部署了L3 Agent组建,所以拥有Distribute Router NameSpace,并且当创建vm时,还会自动生成fip名称空间,所有计算节点的Distribute Router NameSpace完全一致,名称空间接口的ip和mac地址也一样(初始化时所有计算节点的名称空间都是源自网络节点的副本),了解网络的都知道,同一时间同一网络中ip与mac地址要一致,否则交换通过反复mac地址学习到的arp表条目会有冲突,为了解决这一问题,DVR结构为每个运行L3 Agent的计算节点指定全局唯一的mac地址(dvr_host_mac)。

四、vm的东西流量分析

相同subnet下vm之间的流量走向与集中式网络节点类似,此处不在赘述,下面以不同subnet之间vm的vxlan流量走向为例进行说明,此时vm间流量走向如下图所示:

1.位于compute1中的vm1向compute2中的vm2发出请求。此时源/目的ip为vm1/2的ip地址,源/目的mac地址为vm1与网关qr-1的mac地址。
2.报文经过linux bridge进行iptables安全检查,然后送往br-int。
3.进入br-int上的报文被打上内部vlan号并送往vm1的网关qr-1,qr-1接口上配置vm1的网关地址,经查表报文从qr-2口流出,qr-2接口设置vm2的网关地址。
4.从qr-2口出来的报文,此时源/目的ip为vm2网关(qr-2)的ip和vm2的ip地址,源/目的mac为qr-2口mac和vm2的mac地址,并将报文进入br-tun。
5.报文在br-tun交换机上将源mac地址(qr-2)换为全局唯一mac地址(dvr_host_mac),然后进行vxlan封装,离开compute1。
6.报文到达compute2后首先vxlan解封装,然后再将源mac地址(dvr_host_mac)换为vm2网关(qr-2)mac地址,送往br-int并在br-int交换机打上内部vlan号。
7.报文脱掉内部vlan号,进入linux bridge,进行安全策略检查。
8.最终数据报文达到vm2。
vm2数据报文返回的过程与数据报文到达vm2的过程一致,不再赘述。

五、vm的南北流量分析

vm南北流量分为floating ip和fix ip两种情况,对这两种情况分别进行说明:

1.fix ip访问外网

没有绑定floating ip的vm在访问外网时需要通过网络节点的SNAT Router NameSpace进行地址转换,其流量走向如下图所示:

1.vm向外网发起请求,数据报文送往linux bridge。
2.进入linux bridge的数据报文经过iptables安全策略检查后将报文送往br-int,此时打上内部vlan号。
3.数据报文从br-int送往Router NameSpace的qr口,该接口配置了vm的网关地址,在Router NameSpace内对Snet NameSpace的sg口的mac地址进行解析,sg接口为vm所在子网的接口,该接口上的ip地址与vm在同一网段。然后将报文送往br-tun。
4.数据报文进入br-tun后脱掉内部vlan号,进行vxlan封装,打上vni号,离开conpute1.
5.数据报文进入Network节点,脱掉vni号,进行vxlan解封装,送往br-int交换机,进入br-int交换机后打上内部vlan号。
6.数据报文进入sg后,进行路由查表,将数据发往fg口,fg口上配置的是可被路由的公网ip。
7.数据报文在fg口上进行SNAT地址转换,转换后的源ip地址为fg口上配置的公网ip访问公网。

2.floati ip访问外网

启用DVR功能后每台计算节点主机都安装了L3 Agent,绑定了floating ip的vm不再需要绕行到网络节点,直接由计算节点主机访问呢公网,其流量走向如下图所示:

1.vm向外网发起访问,由于vm是provider类型的私网地址,所以首先要去找vm地址所在的网关。
2.数据报文经过linux bridge和br-int后进入Distribute NameSpace的qr口,该接口配置的ip地址为vm的网关地址。
3.数据报文从qr口流出,进入rfp口,该接口上配置有2个ip地址,其中3为vm绑定的floating ip地址,在此处进行SNAT地址转换,外网流量访问vm时在此名称空间利用iptables做DNAT地址转换。
4.通过qrouter与fip内部通信的直连接口(4),接口地址由L3 Agent自行维护,ip为169.254.x.x/31格式,将数据包发往fip名称空间。
5.fip空间的直连接口fpr接收到数据包后,转发给外网网关fg口。
6.fip名称空间外网网关接口将数据包发到br-ex交换机最后通过物理网卡访问internet,外网访问vm的数据流向为该过程的逆方向,此处不再赘述。

3.注意事项

针对使用floating ip的数据包进出时需要注意的地方是:
1.fg接口上会额外配置一个外网ip地址,这也是为什么公有云场景下不会将vm外网ip直接设置成公网ip地址的原因,因为每个vm都需要一个额外的地址作为fg网关地址。
2.当外部网络访问vm时,请求的ip地址是qrouter名称空间中rfp接口上做SNAT的ip地址,但此时fg接口会响应rfp接口上外网ip的arp地址解析请求,所以通常认为fg接口是floating ip的arp代理接口。

六、网络节点HA

通过前文得知,开启DVR模式下的网络节点只是针对没有绑定floating ip的vm进行SNAT地址转换,并且qrouter名称空间只处理元数据,所以不同于传统L3 HA对Router NameSpace的高可用,DVR下的L3 HA是对SNAT NameSpace进行的高可用,仍采用vrrp实现,如下图所示:

从部署结构来看,分别要对SNAT外网ip地址和子网接口ip地址做高可用,所以当使用keepalive时,此时架构如下图所示:

原文地址:https://blog.51cto.com/arkling/2409789

时间: 2024-11-09 14:21:25

讲清楚说明白openstack中vm流量走向之2——DVR模式的相关文章

讲清楚说明白openstack中vm流量走向之1——集中式网络节点

一.背景介绍 openstack被广大公有云厂商所采用,对于公有云场景来讲Newtron组件所提供的网络功能,一直是较难理解的部分,本文详细介绍在openstack集中网络节点架构下,vm的南北向与东西向流量实现. 二.网络节点功能 由于openstack默认部署模式下,计算节点通过ml2插件实现二层互通,所有三层流量都要经过网络节点,如下图所示: 图中同一tenant下有2个不同子网,vm1/2和vm3/4分别属于不同的subnet,通过上图可以看出不同子网之间通信,以及未绑定fip的vm与公

Openstack中的DVR Part1 -- 东西向流量处理

作者:Liping Mao  发表于:2014-07-04 版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明 在Openstack中L3router会造成流量集中的问题.不论东西向还是南北向的流量都需要流过网络节点的虚拟路由器.为了解决流量集中的问题,社区正在开打分布式虚拟路由器(DVR)的feature.本文focus在DVR中东西向流量的处理流程.南北向的处理不在本文范围内. 首先看一下东西向流量存在的问题. 一个用户创建了一个VRoute1(在Netw

在OpenStack中绕过或停用security group (iptables)

眼下.OpenStack中默认採用了security group的方式.用系统的iptables来过滤进入vm的流量.这个本意是为了安全,可是往往给调试和开发带来一些困扰. 因此,暂时性的禁用它能够排除由于iptables规则错误问题带来的网络不通等情况. 在H版本号中,能够通过改动neutron plugin.ini中的firewall配置来禁用security group. 但在I版本号中.类似的操作仅仅会让vm出来的流量都无法通过安全网桥. 因此,在正常配置启用security group

合约广告中的流量分配算法

简介 合约广告是一种基于合约的广告模式,在线广告中的一种主流方式是担保式投放(Guaranteed Delivery,GD).GD是一种量优于质的广告投放方式,需要保证广告主能够获得在合约中约定的受众用户的流量.GD中,媒体的流量按照属性划分,媒体要给不同的广告主按照合同分配约定好的流量.Ad Server的准则是希望在每一次展现满足多个合约时,选择合适的广告主,以使得每个广告主效果最好,同时能够更有效的分配流量.如下图所示,supply为媒体方,提供流量,媒体的流量可以按照性别.年龄.地域划分

也谈OpenStack中的虚拟机HA

OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目.它的社区拥有超过130家企业及1350位开发者,这些机构与个人都将OpenStack作为基础设施即服务(IaaS)资源的通用前端.OpenStack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性.做为云计算IAAS层事实标准,OpenStack广泛的应用与各行各业.到目前为止OpenStack社区并没有一个完整的虚拟机HA解决方案.起初社区认为虚拟机的HA不是云平台层次的特性,不应该在云平台层面来实现,虚拟机的H

openstack中创建一个虚拟机经过的51步

一.前言 本文在林海峰老师"openstack创建一个VM所需的29步"基础上进行了补充和修改,文中只用到了openstack六个核心组件,为了便于理解,架构中不同组件内的rabbit mq和db为同一个(可以为每个组件配置单独的db和rabbit mq).openstack组件之间通过REST调用,组件内通过RPC协议通信,RPC协议又是基于AMQP模型实现的,rabbit mq就是运用该模型的一款软件. 二.概述 以现实中的PC举例来说明openstack创建的VM,一个PC要能正

openstack中eventlet使用

openstack中使用eventlet的协程来实现并发. 第一种,使用eventlet.GreenPool来管理绿色线程 如l3-agent在开启了8个绿色线程来处理router消息 def _process_routers_loop(self): pool = eventlet.GreenPool(size=8) while True: pool.spawn_n(self._process_router_update) 第二种是在oslo.messaging中创建接消息的进程直接创建绿色线程

部署OpenStack问题汇总(四)--openstack中nova-compute状态status显示为'XXX'的问题

第一次部署openstack的时候就遇见了这个问题,当时的版本是havana, 现在部署essex的时候又遇到了这个问题,经过一番折腾,解决了这个问题,记录下来,以免以后忘记. =========================================================== 1.查看/var/log/nova/nova-compute.log文件其中出现了这样的情况: Domain not found: no domain with matching name 'insta

Openstack中给windows加载virtion驱动

通过qemu-img将windows虚拟机的vmdk文件转换成qcow2,并将文件上传至openstack中时,发现虚拟机无法启动. 经过分析,原因是openstack默认使用的是virtio驱动,而windows虚拟机未安装virtion驱动. 解决办法:安装VirtIO驱动 1.通过virt-manager打开windows虚拟机 2.磁盘.网卡使用默认驱动,即磁盘使用ide.网卡使用rt 3.添加一块floopy设备 4.添加一块临时硬盘,设置为virtio模式 5.启动虚拟机,为新磁盘.