openstack neutron(tap、qvb、qvo详解)（转）

2019独角兽企业重金招聘Python工程师标准>>>

openstack neutron

Linux Host 侧使用的网络元素简介
Linux 主要使用以下三种设备模型：Bridge、TAP、VETH、VLAN。Bridge 设备是基于内核实现的二层数据交换设备，其作用类似于现实世界中的二级交换机。TAP 设备是一种工作在二层协议的点对点网络设备，每一个 TAP 设备都有一个对应的 Linux 字符设备，用户程序可以通过对字符设备的读写操作，完成与 Linux 内核网络协议栈的数据交换工作，在虚拟化环境中经常被模拟器使用。VETH 设备是一种成对出现的点对点网络设备，从一段输入的数据会从另一端改变方向输出，通常用于改变数据方向，或连接其它网络设备。VLAN 设备是以母子关系出现的一组设备，是 Linux 里对 802.1.Q VLAN 技术的部分实现，主要完成对 802.1.Q VLAN Tag 的处理。

上半部分原文出处(http://panpei.net.cn/2013/12/04/openstack-neutron-mechanism-introduce/)
借用原资料上的一张架构图为开篇：

openstack neutron

从这张架构图中，我们可以明显的看到有两个物理主机，计算节点和网络节点，这是因为采用了网络节点集中式的部署方式。至于为什么采用这种部署方式，那是因为自从E版之后，OpenStack开始把network功能从Nova中分离出来，使之成为独立的Neutron组件。而坑爹的是，分离后的版本，反而不支持网络分布式部署的特性了，所以目前的Grizzly和Havana版本都是只能使用网络集中式部署方案的，或者说，集群中只能存在一个部署网络功能的节点。

计算节点：虚拟机实例的网络
从图中看，这段网络包含了A、B、C这三段的流程。A就是虚拟机test0的虚拟网卡，这块没什么好讲的。和它相连的B倒是值得好好讲一下。B是一个TAP设备，通常是以tap开头的一段名称，它挂载在Linux Bridge qbr上面。那什么又是TAP设备呢？Linux 中的虚拟网络中给出了这样的解释：
TAP是一个虚拟网络内核驱动，该驱动实现Ethernet设备，并在Ethernet框架级别操作。TAP驱动提供了Ethernet “tap”，访问Ethernet框架能够通过它进行通信。
总而言之，TAP设备其实就是一个Linux内核虚拟化出来的一个网络接口。OK，我们明白了TAP设备了，如果还是不明白可以查看TAP的具体定义。接下来就是qbr，这之前就说了，是一个Linux Bridge，很是奇怪，我们在这个架构中，使用的OpenvSwitch实现虚拟交换设备的，为什么会出现Linux Bridge呢？OpenStack Networking Administration Guide给出了这样的解释：
Ideally, the TAP device vnet0 would be connected directly to the integration bridge, br-int. Unfortunately, this isn’t possible because of how OpenStack security groups are currently implemented. OpenStack uses iptables rules on the TAP devices such as vnet0 to implement security groups, and Open vSwitch is not compatible with iptables rules that are applied directly on TAP devices that are connected to an Open vSwitch port.
其实就是说，OpenvSwitch不支持现在的OpenStack的实现方式，因为OpenStack是把iptables规则丢在TAP设备中，以此实现了安全组功能。没办法，所以用了一个折衷的方式，在中间加一层，用Linux Bridge来实现吧，这样，就莫名其妙了多了一个qbr网桥。在qbr上面还存在另一个设备C，这也是一个TAP设备。C通常以qvb开头，C和br-int上的D连接在一起，形成一个连接通道，使得qbr和br-int之间顺畅通信。

计算节点：集成网桥(br-int)的网络
刚才说到D(这也是一个TAP设备)在br-int上面，现在轮到br-int出场了，br-int是由OpenvSwitch虚拟化出来的网桥，但事实上它已经充当了一个虚拟交换机的功能了。br-int的主要职责就是把它所在的计算节点上的VM都连接到它这个虚拟交换机上面，然后利用下面要介绍的br-tun的穿透功能，实现了不同计算节点上的VM连接在同一个逻辑上的虚拟交换机上面的功能。这个似乎有点拗口，其实就是在管理员看来，所有的VM都是连接在一个虚拟交换机上面的，但事实上这些VM又都是分布在不同的物理主机上面。OK，回到D上面，D通常以qvo开头。在上面还有另一个端口E，它总是以patch-tun的形式出现，从字面就可以看出它是用来连接br-tun的。

计算节点：通道网桥(br-tun)的网络
br-tun在上面已经提及了，这同样是OpenvSwitch虚拟化出来的网桥，但是它不是用来充当虚拟交换机的，它的存在只是用来充当一个通道层，通过它上面的设备G与其他物理机上的br-tun通信，构成一个统一的通信层。这样的话，网络节点和计算节点、计算节点和计算节点这样就会点对点的形成一个以GRE为基础的通信网络，互相之间通过这个网络进行大量的数据交换。这样，网络节点和计算节点之间的通信就此打通了。而图中的G、H正是描画这一通信。

网络节点：通道网桥（br-tun）的网络
正如前面所说，网络节点上也是存在一个br-tun，它的作用同计算节点上的br-tun如出一辙，都是为了在整个系统中构建一个统一的通信层而存在的。所以，这一部分的网络同计算节点上的网络的功能是一致的，因此，也就没有必要多说了。

网络节点：集成网桥（br-int）的网络
网络节点上的br-int也是起了交换机的作用，它通过I、J与br-tun连接在一起。最终的要的是，在这个虚拟交换机上，还有其他两个重要的tap设备M、O，它们分别同N、P相连，而N、P作为tap设备则是分别归属两个namespacerouter和dhcp，没错，正如这两个namespace的名称所示，它们承担的就是router和dhcp的功能。这个router是由l3-agent根据网络管理的需要而创建的，然后，该router就与特定一个子网绑定到一起，管理这个子网的路由功能。router实现路由功能，则是依靠在该namespace中的iptables实现的。dhcp则也是l3-agent根据需要针对特定的子网创建的，在这个namespace中，l3-agent会启动一个dnsmasq的进程，由它来实际掌管该子网的dhcp功能。由于这个两个namespace都是针对特定的子网创建的，因而在现有的OpenStack系统中，它们常常是成对出现的。

网络节点：外部网桥（br-ex）的网络
当数据从router中路由出来后，就会通过L、K传送到br-ex这个虚拟网桥上，而br-ex实际上是混杂模式加载在物理网卡上，实时接收着网络上的数据包。至此，我们的计算节点上的VM就可以与外部的网络进行自由的通信了。当然，前提是我们要给这个VM已经分配了float-ip。

转载于:https://my.oschina.net/tantexian/blog/648970