Openstack中间DVR Part1 -- 东西走向的交通处理

作者:Liping Mao  发表于:2014-07-04

版权声明:能够随意转载。转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明

在Openstack中L3router会造成流量集中的问题。不论东西向还是南北向的流量都须要流过网络节点的虚拟路由器。为了解决流量集中的问题,社区正在开打分布式虚拟路由器(DVR)的feature。

本文focus在DVR中东西向流量的处理流程。

南北向的处理不在本文范围内。

首先看一下东西向流量存在的问题。 一个用户创建了一个VRoute1(在Network Node上)和两个虚拟网络Net1、Net2,然后在两个网络中分别起了一个虚机,如果这两个虚机分别在Compute Node1和Compute Node2上。能够看到当VM1想要和VM2通信时。数据须要集中到Network Node,因而产生了东西向流量集中的问题。例如以下图所看到的:

为了解决问题引入了DVR,将东西向流量分布在各个计算节点上做到了真正的Multi-Host。

为了分析packet flow做下面如果:

1. VM1 和 VM2如上图所看到的。是属于Net1和Net2的两个虚机,他们分别在Compute Node1 和Compute Node2上。

2. Net1和Net2连接到了VRouter上。

3. Compute Node1和Compute Node2的连接方式是Vlan。

4. VM1和VM2使用fixed ip通信,不涉及floating ip。

5. 使用DVR时,会在每个计算节点上建立IR(Internal Router),如果连接Net1和Net2的接口是qr-net1和qr-net2。

拓扑例如以下图:

启用DVR须要在compute node上安装neutron-l3-agent。而且要打开DVR mode。同一时候须要改动neutron-openvswitch-agent为DVR mode:

就以从VM1发一个包到VM2为例分析东西向包的数据流。

包从VM1发出时。因为默认网关是qr-net1,就会发出下面格式的包:

当包流到br-int会转发到qr-net1,这样就进入了Compute Node1的Internal Router1。

在IR1中查找路由,发现目标地址是属于Net2。而在IR1的ARP表中有全部VM的Static ARP Entry。因此目标地址为VM2就会已经存在ARP Entry,不会发出ARP Request。ARP表是在neutron-l3-agent中维护的。

当有新增/删除虚机时,都会改动此ARP表。

包就会从qr-net2接口转发出。格式例如以下:

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbWF0dF9tYW8=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

当包流入br-int后,会将其转发到br-eth0。br-eth0会将包的Vlan改为外部Vlan,同一时候通过openflow rule会将Source MAC改为一个唯一且与ComputeNode绑定的MAC地址。

这个唯一MAC地址是由DVR生成的。

同一时候在br-eth0上也有阻止对qr-net1和qr-net2的ARP请求的rule,这样就能保证本机的VM使用本机的Internal
Router。

Notes:

为什么要这个与Compute Node绑定的唯一MAC呢?主要原因是每一个Compute Node上都有IR1。同一时候qr-net1和qr-net2接口IP地址和MAC地址都是同样的。

如果不改动Source MAC。那各个计算节点上的OVS以及外部物理交换机会从不同的port收到同样源MAC地址的包。这会造成交换机MAC地址表thrashing。

尽管即使使用了唯一MAC还是会出现不同Vlan
id但MAC地址同样的情况,但这样的情况影响要小的多。

当包从Compute Node1上发出后,Phy Switch将其转发到Compute Node2。在br-eth0上将外部Vlan转为内部Vlan,之后转发到br-int,在br-int上会採用OpenVSwitch2.1的新feature,利用“Group Tables”将源MAC地址改动为qr-net2的MAC地址,并转发到Net2的全部port,VM2就能收到请求包了。

Openflow Rule 应该类似例如以下:

dl_vlan = net2LocalVlanID, nw_dst = net2IPRange, actions : strip_vlan, mod_dl_src = qr-net2 MAC, output->all the port in Net2

Refer:

https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr

https://wiki.openstack.org/wiki/Neutron/DVR_L2_Agent

https://review.openstack.org/#/q/topic:bp/neutron-ovs-dvr,n,z

Note:

本文计算节点之间进行vlan连接的,现在实际提交patch如果只支持vxlan。未来将支持vlan。

时间: 2024-08-06 17:14:48

Openstack中间DVR Part1 -- 东西走向的交通处理的相关文章

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

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

OpenStack Neutron DVR L2 Agent的初步解析(二)

声明: 本博客欢迎转载,但请保留原作者信息! 作者:林凯 团队:华为杭州OpenStack团队 OpenStack Juno版本已正式发布,这是这个开源云平台的10个版本,在Juno版的Neutron模块中真正引入了分布式路由(DVR)的实现,现在就让我们来初步看下分布式路由是怎么样工作的. 在OpenStack Neutron DVR L2 Agent的初步解析 (一)中我们已经知道DVR是怎么样工作的,现在就我们就来看下具体DVR是怎么样创建起来并且生效进行工作的. L2用Plugin与L3

OpenStack Neutron DVR L2 Agent的初步解析 (一)

声明: 本博客欢迎转载,但请保留原作者信息! 作者:林凯 团队:华为杭州OpenStack团队 OpenStack Juno版本已正式发布,这是这个开源云平台的10个版本,在Juno版的Neutron模块中真正引入了分布式路由(DVR)的实现,现在就让我们来初步看下分布式路由是怎么样工作的. 分布式路由怎么工作? 为了实现分布式路由,L3和L2 agent将需要工作在计算节点内.今天,L3 agent运行在网络节点,但DVR提议,L3agent会在计算节点上运行.L2 agent将继续工作在计算

初探Openstack Neutron DVR

目前在Juno版本的trunk中已经合入了DVR相关的代码,我的理解是在Juno版本中DVR是一个experimental feature.最好需要稳定一个版本以后再上生产环境.之前写过一篇博文是DVR相关的,当时代码还没有实现,与实际的实现有一些出入.当前的DVR的实现是基于VXLAN的.关于VXLAN的优势,有时间会写一些体会,今天暂且不谈. 建议先看一下以下文档,对DVR有一些了解: https://docs.google.com/presentation/d/1ktCLAdglpKdsC

Openstack Neutron DVR workflow

目前在Juno版本的trunk中已经合入了DVR相关的代码,我的理解是在Juno版本中DVR是一个experimental feature.最好需要稳定一个版本以后再上生产环境.之前写过一篇博文是DVR相关的,当时代码还没有实现,与实际的实现有一些出入.当前的DVR的实现是基于VXLAN的.关于VXLAN的优势,有时间会写一些体会,今天暂且不谈. 建议先看一下以下文档,对DVR有一些了解: https://docs.google.com/presentation/d/1ktCLAdglpKdsC

Openstack Neutron DVR

https://blog.csdn.net/matt_mao/article/details/39180135首先看一下,没有使用DVR的问题在哪里: 从图中可以明显看到东西向和南北向的流量会集中到网络节点,这会使网络节点成为瓶颈. 那如果启用的DVR,情况会变成如下: 对于东西向的流量, 流量会直接在计算节点之间传递.对于南北向的流量,如果有floating ip,流量就直接走计算节点.如果没有floating ip,则会走网络节点. 实验环境如下: 然后起了两个私有网络和一个DVR 路由器,

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

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

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

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

openstack公有云需要放通的网络平面

一.前言 openstack当下已成为各大公有云厂商的首选,作者也在一个公有云厂商做外协(对,就是那个出折叠屏手机的厂商),他家的网络设备默认是做白名单(deny any),只允许指定放通的流量经过,生产环境中出于网络安全的因素也不允许permit any any,本文就详细说明他家的openstack公有云场放通哪些网络平面及为什么要放通这些平面.我们假设每个服务器有4张网卡,管理和业务流量分开,eth0/eth1走管理流量,eth4/eth5走业务流量进行说明. 二.openstack的构成