feisky

云计算、虚拟化与Linux技术笔记
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

[转]UOS 中的虚拟网络设备

Posted on 2014-07-17 11:02  feisky  阅读(1121)  评论(0编辑  收藏  举报

随着网络技术,虚拟化技术的发展,越来越多的高级网络设备被加入了到了 Linux 中,这些设备在 UOS 中起到了广泛而关键的作用,包括 Open vSwitch、TAP 设备、Veth 设备等等,梳理这些设备的关系和如何发挥作用无疑将对我们维护、理解 UOS 系统有重要的作用。

下面我们以这样一个场景来解释下在 UOS 中数据包的流向(假定读者对 OpenStack/UOS 有一定认识,最好实践过官方 OpenStack 安装手册的内容或阅读过 UOS 用户手册):一个租户,两个网络,一个路由,内部网络使用GRE,Libvirt VIF Driver 使用 LibvirtHybridOVSBridgeDriver。

VirtualNetworkTopology-UOS

如图我们有一个外网(External Network),IP段为 42.62.73.52/16(UOS 给我们分配的公网 IP),两个内网,分别是 TestSubnet:192.168.0.0/24,和 ProductiveSubnet:10.10.0.0/16,值得注意的是这是两个子网(subnet)。

在这个场景下,计算节点的内部模型应当是这样的:

 

计算节点模型

下面我将解释如何得到这幅图。首先我们看下我们的虚拟机在 libvirt 的名称,通过 nova show 命令我们大概可以获得像这样输出(截取部分):

+--------------------------------------+-------------------------------
| Property                             | Value                         |
+--------------------------------------+-------------------------------
| Internal network                     | 10.18.0.3, 172.16.19.232      |
| OS-DCF:diskConfig                    | MANUAL                        |
| OS-EXT-AZ:availability_zone          | nova                          |
| OS-EXT-SRV-ATTR:host                 | compute1                      |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute1                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-0000001e             |

我们看到这台虚拟机被部署在compute1节点上,instance_name 为 instance-0000001e,我们上compute1节点使用 virsh dumpxml 将 instance-0000001e 的信息打印出来(截取网络相关):

+--------------------------------------+-------------------------------
| Property                             | Value                         |
+--------------------------------------+-------------------------------
| Internal network                     | 10.18.0.3, 172.16.19.232      |
| OS-DCF:diskConfig                    | MANUAL                        |
| OS-EXT-AZ:availability_zone          | nova                          |
| OS-EXT-SRV-ATTR:host                 | compute1                      |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute1                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-0000001e             |

在这里我们看到这台虚拟机的网络设备是 tap48e06cd2-60,而且似乎连到了 qbr48e06cd2-60 上,让我们用 brctl show 再看下(截取相关部分):

bridge name        bridge id            STP enabled     interfaces
qbr48e06cd2-60     8000.bed5536ff312	no              qvb48e06cd2-60
                                                        tap48e06cd2-60

看到这里网桥 qbr48e06cd2-60 上接了两个接口,qvb48e06cd2-60和tap48e06cd2-60,其中的tap设备是我们虚拟机使用的虚拟网络设备,那 qvb48e06cd2-60 是什么?我们先用 lshw –class network 把所有网络设备打印出来(截取相关部分):

*-network:5
       description: Ethernet interface
       physical id: 7
       logical name: qvb48e06cd2-60
       serial: be:d5:53:6f:f3:12
       size: 10Gbit/s
       capabilities: ethernet physical
       configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full firmware=N/A link=yes multicast=yes port=twisted pair promiscuous=yes speed=10Gbit/s

我们注意到这里显示这个设备的 driver 是 veth,而 veth 总是成对出现的,我们用 ethtool -S 看下这个 veth 的另一端连到了那里:

# ethtool -S qvb48e06cd2-60
NIC statistics:
     peer_ifindex: 16

OK,看下16号是哪个设备,ip link(截取相关部分):

16: qvo48e06cd2-60: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether aa:c0:0f:d2:e2:43 brd ff:ff:ff:ff:ff:ff

通过上面两个步骤我们已经知道了这对从虚拟机的网络设备到 veth pair 这个流程,这个过程在官方文档中针对不同的 Libvirt VIF Driver 有不同的简单的描述,见https://wiki.openstack.org/wiki/LibvirtVIFDrivers。 下面应该是连到 Open vSwitch 上吧,让我们验证下:

# ovs-vsctl show
1910d375-2692-4214-acdf-d364382c25a4
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port "qvo48e06cd2-60"
            tag: 1
            Interface "qvo48e06cd2-60"
        Port "qvodfdc29e2-9a"
            tag: 2
            Interface "qvodfdc29e2-9a"
        Port "qvo18cec000-80"
            tag: 2
            Interface "qvo18cec000-80"
        Port "qvob86d15f1-8f"
            tag: 1
            Interface "qvob86d15f1-8f"
    Bridge br-tun
        Port br-tun
            Interface br-tun
                type: internal
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "gre-1"
            Interface "gre-1"
                type: gre
                options: {in_key=flow, local_ip="192.168.10.11", out_key=flow, remote_ip="192.168.10.10"}
    ovs_version: "1.11.0"

果然 qvo48e06cd2-60 是连到了 br-int 上, OpenStack 采用这么复杂的机制,而不是把 tap 设备直接连到 Open vSwitch 上,这与安全组有关,可以查看官方的文档。

在研究到OVS内部前,我们先注意下在 port “qvo48e06cd2-60” 下有一个“tag: 1”,这个 tag 是Open vSwitch 用来区分不同子网的。在这里,tag1 表示我们的10.18.0.0/24子网,tag2表示10.22.22.0/24子网。

br-int和br-tun通过patch连接,在官方文档上patch的介绍并不多,但一旦两个OVS网桥通过网桥连接,这两个网桥将近乎为同一个网桥,参考资料见:Open vSwitch FAQConnecting OVS Bridges with Patch Ports

首先看下bt-int的流表规则:

16: qvo48e06cd2-60: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether aa:c0:0f:d2:e2:43 brd ff:ff:ff:ff:ff:ff

只有一个NORMAL的动作,在Open vSwitch的官方文档里解释为将包以传统的,非OpenFlow的方式进行交换,也就是说效果和没设置OpenFlow规则一样(见Open vSwitch Advanced Features Tutorial)。那么我们分析br-tun的流表规则,首先在计算节点上用ovs-ofctl dump-ports-desc查看br-tun上所有接口:

OFPST_PORT_DESC reply (xid=0x2):
 1(patch-int): addr:ea:a2:71:f5:9f:ad
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 2(gre-1): addr:d6:89:b0:03:d2:72
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-tun): addr:9a:49:9a:35:d1:4e
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

然后用ovs-ofctl dump-flows或者EasyOVS查看br-tun的流表规则(这里使用EasyOVS使排版相对好看):

ID TAB PKT       PRI   MATCH                                                       ACT
0  0   339       1     in=1                                                        resubmit(,1)
1  0   285       1     in=2                                                        resubmit(,2)
2  0   3         0     *                                                           drop
3  1   216       0     dl_dst=00:00:00:00:00:00/01:00:00:00:00:00              resubmit(,20)
4  1   123       0     dl_dst=01:00:00:00:00:00/01:00:00:00:00:00              resubmit(,21)
5  10  363       1     *                                                           learn(table=20,hard_timeout=300,priority=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1
6  2   341       1     tun_id=0x2                                             mod_vlan_vid:1,resubmit(,10)
7  2   17        1     tun_id=0x3                                             mod_vlan_vid:2,resubmit(,10)
8  2   3         0     *                                                           drop
9  20  0         0     *                                                           resubmit(,21)
10 21  3         1     vlan=2                                          strip_vlan,set_tunnel:0x3,output:2
11 21  16        1     vlan=1                                          strip_vlan,set_tunnel:0x2,output:2
12 21  4         0     *                                                            drop
13 3   0         0     *                                                            drop

这里为了看去来清楚只显示了ID、表名、计数器、匹配规则和行为。先看这几条流:0、3、4、9、10、11、12,这些流定义了从br-int进入的包的行为,逐条从上往下看:

0. 表0:当匹配到从port 1(patch-int)进入的包时,提交给表1继续匹配;3. 表1:当目标MAC地址为单播地址时,提交给表20继续匹配;4. 表1:当目标MAC地址为多播/广播地址时,提交给表21继续匹配;、9. 表20:提交给21继续匹配(这个表并非只是转发,当OVS根据表10动态建立自动学习的规则时,会添加到表20,比如下面这条流表规则是自动建立的目标 MAC地址为路由的规则:“cookie = 0×0, duration = 11.099s, table = 20, n_packets = 45, n_bytes = 6132, hard_timeout = 300, idle_age = 3, hard_age = 2, priority = 1,vlan_tci = 0×0001/0x0fff,dl_dst = fa:16:3e:a1:3f:19 actions = load:0 -> NXM_OF_VLAN_TCI[], load:0×2 -> NXM_NX_TUN_ID[], output:2”);10. 表21:当目标VLan标签为2时,剥去VLan标签,然后将Tunnel Key设置为3(GRE通道的Key,详见rfc2890的相关描述)并从port 2(gre-1)发出去;11. 表21:当目标VLan标签为1时,剥去VLan标签,然后将Tunnel Key设置为2并从port 2(gre-1)发出去;12. 表21:对没成功匹配的包,丢弃。

再看1、6、7、5,这几个流定义了来自GRE通道(Network节点)的包的行为:

1. 表0:当匹配到从port 2(gre-1)进入的包时,提交给表2继续匹配;6. 表2:当Tunnel Key为2时,添加VLan tag 1,提交给表10继续匹配;7. 表2:当Tunnel Key为3时,添加VLan tag 2,提交给表10继续匹配;5. 表10:首先从报文中学习VLan、MAC等信息并把规则添加表20,然后再从port 1(patch-int)发出去。

至此,虚拟机的数据路径分析已基本完成。

42.62.73.52
 
本文转自https://www.ustack.com/2014/06/17/virtual-device-in-uos/
无觅相关文章插件,快速提升流量