上一节创建了 OVS 本地网络 first_local_net,今天我们会部署一个 instance 到该网络并分析网络结构。
launch 一个 instance,选择 first_local_net 网络:
instance 部署成功,分配的 IP 地址为 172.16.1.3
底层网络发生了什么变化?
对于 instance “cirros-vm1”,Neutron 会在 subnet 中创建一个 port,分配 IP 和 MAC 地址,并将 port 分配给 cirros-vm1。
如上图所示,port 列表中增加了一个 port “(fc1c6ebb-719d)”,IP 为 172.16.1.3,点击 port 名称查看 MAC 信息。
我们可以先按照在 linux bridge driver 章节学到的知识推测一下:Open vSwitch driver 会如何将 cirros-vm1 连接到 first_local_net?
如果采用类似的实现方法,neutron-openvswitch-agent 会根据 port 信息创建 tap 设备 tapfc1c6ebb-71,并将其连接到 br-int 网桥,tapfc1c6ebb-71 就是 cirros-vm1 的虚拟网卡。
下面我们验证一下事实是否如此。
cirros-vm1 部署到了控制节点,通过 ovs-vsctl show 查看 bridge 的配置:
非常遗憾,在 br-int 上并没有看到 tapfc1c6ebb-71,而是多了一个 qvofc1c6ebb-71。目前我们并不知道 qvofc1c6ebb-71 是什么,我们再用 brctl show 查看一下 linux bridge 的配置:
这里我们看到有一个新建的网桥 qbrfc1c6ebb-71,上面连接了两个设备 qvbfc1c6ebb-71 和 tapfc1c6ebb-71。从命名上看,他们都应该与 cirros-vm1 的虚拟网卡有关。
通过 virsh edit 查看 cirros-vm1 的配置:
确实 tapfc1c6ebb-71 是 cirros-vm1 的虚拟网卡。那么 linux bridge qbrfc1c6ebb-71 上的 qvbfc1c6ebb-71 设备与 Open vSwitch br-int 上的 qvofc1c6ebb-71 是什么关系呢?
下面的内容稍微需要一些技巧了。
我们用 ethtool -S 分别查看 qvbfc1c6ebb-71 和 qvofc1c6ebb-71 的 statistics。
原来 qvbfc1c6ebb-71 和 qvofc1c6ebb-71 都是 veth 设备,它们对应的另一端 veth 设备 的 index 分别是 12 和 13。通过 ip a 命令找到 index 12 和 13 的设备。
到这里,相信有同学已经看出来了:qvbfc1c6ebb-71 和 qvofc1c6ebb-71 组成了一个 veth pair。我们之前介绍过,veth pair 是一种成对出现的特殊网络设备,它们象一根虚拟的网线连接两个网络设备。这里 qvbfc1c6ebb-71 和 qvofc1c6ebb-71 的作用就是连接网桥 qbrfc1c6ebb-71 和 br-int。
文字描述往往是不够直观的,下面我们将前面梳理好的信息通过图片展示出来。
由图所示,tapfc1c6ebb-71 通过 qbrfc1c6ebb-71 间接连接到 br-int。
那问题来了,为什么 tapfc1c6ebb-71 不能像左边的 DHCP 设备 tap7970bdcd-f2 那样直接连接到 br-int 呢?
其原因是: Open vSwitch 目前还不支持将 iptables 规则放在与它直接相连的 tap 设备上。
如果做不到这一点,就无法实现 Security Group 功能。为了支持 Security Group,不得不多引入一个 Linux Bridge 支持 iptables。
这样的后果就是网络结构更复杂了,路径上多了一个 linux bridge 和 一对 veth pair 设备。
下节我们再部署一个 instance 到 first_local_network 并验证两个 instance 的连通性。
8秒钟小调查
《5分钟》教程已经伴随大家快一年了,目前也到了最后一部分。CloudMan 想做个小小的问卷,了解一下大家学习 OpenStack 的情况,并为后续教程提供参考,谢谢。