OpenStack OVS GRE/VXLAN网络

http://blog.sina.com.cn/s/blog_6de3aa8a0101pfgz.html

 

学习或者使用OpenStack普遍有这样的现象：50%的时间花费在了网络部分；30%的时间花费在了存储方面；20%的时间花费在了计算方面。OpenStack网络是不得不逾越的鸿沟，接下来我们一起尝试努力穿越这个沟壑吧……J

虚拟机中数据包传递路径：

    上图是一个典型的Neutron-OVS-GRE网络模式，有两个计算节点Computer-01和Computer-02；一个网络节点Network-node。

    假设物理计算节点Computer-02上面的虚拟机VM-003网卡eth0上有网络数据包向外部物理路由器网关10.1.101.254发出：那么数据会依次经过tap设备；qbr Linux Bridge设备；qvb和qvo虚拟网络设备；到达物理计算节点的OVS网桥br-int上；br-int将数据包attach到计算节点Computer-02的OVS网桥br-tun上；数据包再从计算节点Computer-02上的OVS网桥br-tun与网络节点Network-node上的OVS网桥br-tun构成的网络隧道穿过，交付到网络节点的OVS网桥br-int上；网络节点上的br-int通过qr设备借助Linux网络命名空间qrouter连通br-ex上的qg设备，将数据包交付到OVS网桥br-ex上；最后br-ex通过网络节点的外部物理网口eth2把数据包送达到外部路由器网关。

 

分别介绍数据包途径的网络设备：

计算节点：

 （1）与虚拟机相连的TAP设备

从上图中可以看出，Computer-02上面的虚拟机VM-003的eth0网口与一个tap设备相连。但这个tap设备并没有像图上Computer-02画的那样与qbr设备直接相连，用ovs-vsctl show命令查看，发现这个tap设备是OVS网桥br-int上面的一个端口。所以实际上的连接情况是Computer-01所表示的那样。

于是这样看来那些Linux bridge qbr设备，qvb设备，qvo设备（Computer-01黄色框中的内容）就显得多余了。没办法，哲学上说存在即合理，qbr的存在当然另有它用，官网文档有这样的一句话：

http://docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html#under_the_hood_openvswitch_scenario1

Security groups: iptables and Linux bridges

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.

Networking uses an extra Linux bridge and a veth pair as a workaround for this issue. Instead of connecting vnet0 to an Open vSwitch bridge, it is connected to a Linux bridge, qbrXXX. This bridge is connected to the integration bridge,br-int, through the (qvbXXX, qvoXXX) veth pair.

    意思就是说OVS插件没有设置iptables规则的功能，但OpenStack又想要(或必须)提供安全组服务，那么就借助了Linux Bridge的功能。

   个人观点：Linux Bridge这种拿来主义的做法大大简化了组件的开发，但是这样无疑增加了其复杂性和冗余度，并且从实践中发现这种做法带来了不少问题。比如http://blog.sina.com.cn/s/blog_6de3aa8a0101lnar.html最后提到的问题，就是OVS网桥和Linux网桥混用造成的。  因此，另寻别的途径来简化实现OpenStack安全组是一件有意义的事，今后将对此深入调研。

（2）OVS一体化网桥br-int

br-int是OpenvSwitch创建的虚拟网桥，但在实际运行中它充当着虚拟交换机的角色，br-int上的端口tap设备将宿主机上的虚拟机实例连接到同一网络交换层上。再透过本机OVS网桥br-tun的互联协议可以将OpenStack系统架构中所有节点的br-int组织成一个更大的虚拟交换机BR-INT{compuer-01-br-int + compuer-02-br-int….}。这是一种很重要的抽象思想，如此一来就好像OpenStack环境中所有的虚拟机实例都连接到了一个巨型的虚拟机交换机上。遗憾的是这个虚拟机交换机的功能有限，不能设定iptables规则实现安全组服务，因此通过qvo，qvb去连接qbr借助linux网桥完成这个工作。所以在计算节点ovs-vsctl show中的br-int网桥看到tap设备和qvo设备共存也就不足为奇了。

 （3）OVS通道网桥br-tun

    br-tun是OVS创建的虚拟网桥，它的作用是向下直接与br-int连接作为网络数据的进出口；对上通过特定的通信协议与各个节点上的br-tun相连构成一个扁平的通信/通道层。如果把所有的br-int构成的抽象层次定义为虚拟二层网络，那么所有的br-tun构成的抽象层次便是虚拟三层网络了。如此说来似乎有点网络虚拟化的味道了。

网络节点：

 （1）OVS通道网桥br-tun

   它与计算节点上的br-tun作用相同，只是作为通道层用于连接别的物理节点。唯一不同的是这个br-tun连接的是网络节点的br-int，网络节点br-int与计算节点的br-int区别较大。

 （2）OVS一体化网桥br-int

br-int是OpenvSwitch创建的虚拟网桥，也起到了虚拟交换机作用。上面主要有两类设备：一类是tap设备；另一类是qr设备。linux网络命名空间namespace  qdhcp和qrouter均由l3-agent所创建，用来隔离管理租户的虚拟网络和路由。br-int上的tap 设备，ip地址一般为xxx.xxx.xxx.3与dnsmasq进程构成qdhcp，为新创建的虚拟机动态分配私有IP地址。qr-int上的qr设备，IP地址一般为xxx.xxx.xxx.1与br-ex 的qg设备构成qrouter，为租户网络做路由转发，通过qg打通租户内部的虚拟网络和外部的物理网络。

 （3）OVS外部网桥br-ex

    br-ex是OpenvSwitch创建的虚拟网桥，网桥上有qg设备端口，它是打通租户网络和外部网络的重要通道。另外br-ex与物理网卡（图中是eth2）相连，通往internet网络。