OpenStack Neutron中的DVR简介与OVS流表分析

本文主要介绍DVR的概念,比较了DVR和非DVR情况下,数据在network节点上的流量变化。同时也介绍了在OpenStack里面如何配置DVR,比较详细地介绍了在DVR激活的情况下,数据包的流表情况。



DVR 简介DVR 提出的背景

在Neutron的网络环境中,跨子网的虚机通信是需要通过Neutron的路由器。这既包括不同子网的虚拟机之间的通信,又包括虚拟机与外网之间的通信。在DVR被提出之前,由于Neutron的legacy router只会部署在网络节点上,因此会造成网络节点的流量过大,从而产生了两个问题,其一是网络节点将成为整个Neutron网络的瓶颈,其二是网络节点单点失败的问题。在这样的背景下,OpenStack社区在Juno版本里正式引入了DVR(Distributed Virtual Router)。DVR,顾名思义就是Neutron的router将不单单部署在网络节点上,所有启动了Neutron L3 Agent的节点,都会在必要时在节点上创建Neutron router对应的 namepsace,并更新与DVR router相关的Openflow规则,从而完成DVR router在该节点上的部署。在计算节点上部署了DVR router后,E-W方向上的流量不再需要将数据包发送到网络节点后再转发,而是有本地的DVR router直接进行跨子网的转发;N-S方向上,对于绑定了floating IP的虚机,其与外网通信时的数据包也将直接通过本地的DVR router进行转发。从而,Neutron网络上的一些流量被分摊开,有效地减少了网络节点上的流量;通信不再必须通过网络节点,也提升了Neutron网络的抗单点失败的能力。

本文主要讲解的是E-W方向上的虚拟机通信情况。

非DVR和DVR情况下,网络节点流量对比

这是在有相同数量的虚机的情况下的对比。

非DVR的情况,网络节点的流量情况

[root@test114 openvswitch]# ifstat

#kernel

Interface RX Pkts/Rate TX Pkts/Rate RX Data/Rate TX Data/Rate

RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate

lo 19090K 0 19090K 0 18446744071513M 0 18446744071513M 0

0 0 0 0 0 0 0 0

eth0 116688K 0 1737K 0 674575K 0 555880K 0

0 0 0 0 0 0 0 0

eth1 118480K 0 286 0 18446744070647M 0 71696 0

0 0 0 0 0 0 0 0

br-eth1 8650K 0 80 0 1580M 0 3360 0

0 1127 0 0 0 0 0 0

br-ex 10276K 0 1737K 0 18446744071533M 0 555877K 0

0 1127 0 0 0 0 0 0

在DVR enabled的情况下,网络节点的流量情况

[root@test114 ~]# ifstat

#kernel

Interface RX Pkts/Rate TX Pkts/Rate RX Data/Rate TX Data/Rate

RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate

lo 2155 0 2155 0 790717 0 790717 0

0 0 0 0 0 0 0 0

eth0 10461 0 213 0 2310K 0 88001 0

0 0 0 0 0 0 0 0

eth1 10683 0 0 0 2399K 0 0 0

0 0 0 0 0 0 0 0

br-eth1 528 0 0 0 90626 0 0 0

0 0 0 0 0 0 0 0

br-ex 800 0 213 0 173756 0 88001 0

0 0 0 0 0 0 0 0

在非DVR和DVR的情况下,数据包流经各节点的对比

DVR支持VLAN、GRE、VXLAN这几种网络类型,但因为方便起见(VLAN需要开启路由器的Trunk口),所以本文中,我们这就用 GRE作为环境的网络类型。我们这里的环境情况如下:

网络节点是test114.sce.ibm.com, 两个计算节点分别是test115.sce.ibm.com和test116.sce.ibm.com,两个私有网络分别是gre(192.168.11.0/24),gre1(192.168.12.0/24),都是GRE类型的,它们通过router相连,在两个计算节点上面分别有一台虚拟机,它们分属不同的网络。这里面VM1在test115.sce.ibm.com上,ip地址是192.168.11.3,VM2在 test116.sce.ibm.com 上,ip地址是192.168.12.4。

非DVR的情况:

OpenStack Neutron中的DVR简介与OVS流表分析图1 非DVR

[root@test115 ~] tcpdump |grep -i "gre"

18:14:11.794450 IP test115.sce.ibm.com > test114.sce.ibm.com: GREv0, key=0x1, length 106:

IP 192.168.11.3 > 192.168.12.4: ICMP echo request, id 16641, seq 23588, length 64

18:14:11.794550 IP test114.sce.ibm.com > test116.sce.ibm.com: GREv0, key=0x2, length 106:

IP 192.168.11.3 > 192.168.12.4: ICMP echo request, id 16641, seq 23588, length 64

18:14:11.796136 IP test116.sce.ibm.com > test114.sce.ibm.com: GREv0, key=0x2, length 106:

IP 192.168.12.4 > 192.168.11.3: ICMP echo reply, id 16641, seq 23588, length 64

18:14:11.796198 IP test114.sce.ibm.com > test115.sce.ibm.com: GREv0, key=0x1, length 106:

IP 192.168.12.4 > 192.168.11.3: ICMP echo reply, id 16641, seq 23588, length 64

DVR的情况:

OpenStack Neutron中的DVR简介与OVS流表分析图2 DVR

16:34:02.479531 IP test115.sce.ibm.com > test116.sce.ibm.com: GREv0, key=0x2, length 106:

IP 192.168.11.3 > 192.168.12.4: ICMP echo request, id 10241, seq 19852, length 64

16:34:02.482082 IP test116.sce.ibm.com > test115.sce.ibm.com: GREv0, key=0x1, length 106:

IP 192.168.12.4 > 192.168.11.3: ICMP echo reply, id 10241, seq 19852, length 64

在非 DVR 的情况,数据是要通过网络节点才能相互传递数据包;在 DVR 的情况,数据包是直接在两个计算节点上传递。

配置DVR配置文件

在网络节点和计算节点配置DVR:

网络节点:因为 DVR 是属于 l3-agent 的功能,并依赖于 l3-agent,所以我们在这里的改动应该默认为环境上的 l3-agent 是可以工作的。具体配置如下:

修改对应文件:

neutron.conf : router_distributed = True

l3_agent.ini : agent_mode = dvr_snat

ovs_neutron_plugin.ini : l2_population = True and enable_distributed_routing = True

ml2_conf.ini : mechanism_drivers = openvswitch,linuxbridge,l2population

重新启动 neutron-openvswitch-agent, netron-l3-agent, neutron-server 服务。

计算节点:考虑到 compute node 上可能在 enable DVR 之前是没有启动/配置 DVR 的,那么参照 network node 上的 l3_agent.ini 去配置 compute node,启动 l3-agent。同时把 l3-agent 配置成 DVR 模式。还需要在节点上配置 br-ex 这个 ovs bridge,如果节点上在 enable DVR 之前没有这个 ovs bridge,并且如果 compute node 上的虚机需要与外网通信,那么 compute node 上的 br-ex 就必须桥接到一个可以连接到外网的网卡上。具体配置如下:

把节点配置成 DVR 模式:

l3_agent.ini : agent_mode = dvr

ovs_neutron_plugin.ini : l2_population = True and enable_distributed_routing = True

重新启动neutron-openvswitch-agent, netron-l3-agent 服务。

建立br-ex网桥,使得eth0上的ip地址转移到br-ex上。具体操作如下:

建立br-ex: ovs-vsctl add-br br-ex

把eth0桥接到br-ex里面:ovs-vsctl add-port br-ex "eth0"

建立ifcfg-br-ex,ifcfg-eth0 is in /etc/sysconfig/network-scripts。

重新启动网络服务。使得配置生效。

迁移到 DVR 模式。使得新添加的 l3-agent 能够管理 router,(如果是先 enabled DVR,再建立网络和 router,忽略这一步),具体操作如下:

在网络节点上执行如下操作:

neutron router-update --admin_state_up=False ROUTER

neutron router-update --distributed=True ROUTER

neutron router-update --admin_state_up=True ROUTER

查看router是否已经和三个l3-agent对应

[root@test114 ~]# neutron  l3-agent-list-hosting-router router2

+--------------------------------------+------------------

| id | host | admin_state_up | alive |

+--------------------------------------+------------------

|26a3a232-888b-4b6d-8f81-5bdd2b988414 | test114.sce.ibm.com | True | :-) |

|818537d8-903a-4ff9-a745-2d562ab82e54 | test115.sce.ibm.com | True | :-) |

|427b251d-b210-4782-9d96-858c30181dbe | test116.sce.ibm.com | True | :-) |

计算节点上的虚拟机的数据流的传递

当在虚拟机VM1(test115.sce.ibm.com)里面去ping VM2的IP的时候,数据包先转到宿主机的网桥br-int上,数据先传到那个和VM1的port匹配的port端口上,转到网关所在的那个端口,再转到namespace里,找到网关所在的端口,再转回br-int,然后通过br-int上面的patch-tun端口传递到br-tun这个网桥上,在br-tun网桥上的对应的端口通过trunk传递数据包到VM2所在的宿主机(test116.sce.ibm.com)的br-tun上的对应端口,再通过patch-int传到br-int上的patch-tun,通过br-int上的与VM2对应的port端口,把数据传递给VM2,完成数据包的传递。简单的可以写成vm1->br-int->namespace->br-int>br-tun->tunnel>br-tun->br-int->vm2。

DVR环境下Openflow规则的分析OVS命令简介

Open VSwitch(OVS)是一个虚拟交换机,可以用来组成虚拟网络。OpenStack Neutron里面也是应用了OVS,Neutrondd的router虽然是工作在网络3层的,看似与2层的OVS无关,但实际上Neutron router在转发不同子网之间的数据流量时,还是需要借助2层Openflow规则,并且Neutron router的namespace中的子网网关的端口设备等都是需要接在OVS的网桥br-int 上才能工作的。DVR作为Neutron router的一种特殊实现,本质上也是依赖于OVS的,这一点与Neutron legacy router并无差异。在前面DVR的配置中我们用到了一些OVS的命令,这里再介绍一下OVS的一些命令:

查看open vswitch的网络状态:ovs-vsctl show

查看网桥br-tun的接口状况:ovs-ofctl show br-tun

查看网桥br-tun的流表:ovs-ofctl dump-flows br-tun

添加网桥:#ovs-vsctl add-br br0

将物理网卡挂接到网桥:#ovs-vsctl add-port br0 eth0

我们这片文章里面主要用到了以上五个个 ovs 命令。我们在提一下其它的一些命令。

列出 open vswitch 中的所有网桥:#ovs-vsctl list-br

判断网桥是否存在:#ovs-vsctl br-exists br0

列出网桥中的所有端口:#ovs-vsctl list-ports br0

列出所有挂接到网卡的网桥:#ovs-vsctl port-to-br eth0

删除网桥上已经挂接的网口:#vs-vsctl del-port br0 eth0

删除网桥:#ovs-vsctl del-br br0

数据包在br-int和br-tun上的流表

在前面的章节,大致描述了一下数据包的流动情况,在这里再来看一下 br-int 和 br-tun 上的流表,具体来看下数据包的传递。

当从VM1(192.168.11.14)去pingVM2(192.168.12.9), 数据包首先流到compute1(10.11.1.115)的br-int上,让我们先看看compute1上的网络状态。

[root@test115 ~]# ovs-vsctl show

1799e6ea-b3b0-4581-b42e-e1bfd8a5d96d

Bridge br-ex

Port "eth0"

Interface "eth0"

Port br-ex

Interface br-ex

type: internal

Bridge br-tun

fail_mode: secure

Port "gre-0a0b0174"

Interface "gre-0a0b0174"

type: gre

options:{df_default="true",in_key=flow, local_ip="10.11.1.115",

out_key= flow, remote_ip="10.11.1.116"}

Port br-tun

Interface br-tun

type: internal

Port patch-int

Interface patch-int

type: patch

options: {peer=patch-tun}

Port "gre-0a0b0172"

Interface "gre-0a0b0172"

type: gre

options:{df_default="true",in_key=flow, local_ip="10.11.1.115",

out_key= flow, remote_ip="10.11.1.114"}

Bridge "br-eth1"

Port "eth1"

Interface "eth1"

Port "phy-br-eth1"

Interface "phy-br-eth1"

type: patch

options: {peer="int-br-eth1"}

Port "br-eth1"

Interface "br-eth1"

type: internal

Bridge br-int

fail_mode: secure

Port "qr-43fad9d6-53"

tag: 1

Interface "qr-43fad9d6-53"

type: internal

Port patch-tun

Interface patch-tun

type: patch

options: {peer=patch-int}

Port "qr-c669122c-11"

tag: 2

Interface "qr-c669122c-11"

type: internal

Port br-int

Interface br-int

type: internal

Port "qvof76ecb29-5d"

tag: 2

Interface "qvof76ecb29-5d"

Port "int-br-eth1"

Interface "int-br-eth1"

type: patch

options: {peer="phy-br-eth1"}

ovs_version: "2.3.0"

[root@test114 neutron]# neutron port-list

+--------------------------------------+------+-------------------+-----------

---------------------------------------------------------------------------+

| id | name | mac_address | fixed_ips |

+--------------------------------------+------+-------------------+----------

----------------------------------------------------------------------------+

| 3086e492-b9b2-416a-9140-f01258c34dda | | fa:16:3e:e5:b9:08 | {"subnet_id":

"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.2"}  |

| ed6b11e8-05ea-4024-8d83-b080984f084e | | fa:16:3e:b4:76:32 | {"subnet_id":

"ffd2c101-35e5-4758-ba75-43409e58adaf", "ip_address": "10.11.2.14"} |

| cf9fa480-7fd4-4e4b-b8cf-7f6c26cffb2d | | fa:16:3e:02:b7:c7 | {"subnet_id":

"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.13"} |

| f76ecb29-5d9d-41fe-ae70-098502fda347 | | fa:16:3e:17:6b:a7 | {"subnet_id":

"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.14"} |

| 2bbd30d4-86d4-4ccb-930a-edb7be55b740 | | fa:16:3e:2a:34:19 | {"subnet_id":

"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.9"}  |

| 43fad9d6-53d3-4664-8fc1-defcfa21d78a | | fa:16:3e:a3:95:c2 | {"subnet_id":

"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.1"}  |

| da445e04-ab74-409b-b5df-1f5e8f7aa955 | | fa:16:3e:42:25:42 | {"subnet_id":

"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.2"}  |

| 76bfd868-976d-4483-8352-89e0522e213d | | fa:16:3e:d4:4d:ff | {"subnet_id":

"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.10"} |

| 20f66057-a825-422c-9dfe-5bfa09292251 | | fa:16:3e:ee:70:14 | {"subnet_id":

"ffd2c101-35e5-4758-ba75-43409e58adaf", "ip_address": "10.11.2.10"} |

| c669122c-115f-42d5-b107-d346193cdb82 | | fa:16:3e:cd:50:8d | {"subnet_id":

"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.1"}  |

+--------------------------------------+------+----------------

从VM1的port信息里面我们得知,数据是从qvof76ecb29-5d口进入br-int的。我们再看看br-int上的数据包,从上面的port信息我们查看到了相应的MAC地址,知道数据包是从VM1的MAC发到它gateway的MAC上的。然后在namespace里面通过VM2的gateway端口转发出来。


上一篇:TSINGSEE青犀视频接入海康解码器SDK解码远程文件流程


下一篇:OpenStack Neutron中的DVR简介与OVS流表分析