ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

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

2021-05-27 16:57:51  阅读:233  来源: 互联网

标签:OVS ibm sce 流表 192.168 br OpenStack 节点 DVR


本文主要介绍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的情况:

图片图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的情况:

图片图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端口转发出来。


标签:OVS,ibm,sce,流表,192.168,br,OpenStack,节点,DVR
来源: https://blog.51cto.com/u_15127681/2823179

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有