OpenStack OVS GRE/VXLAN网络

322e

OpenStack OVS GRE/VXLAN网络
(2014-04-17 13:55:11)

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

http://blog.sina.com.cn/s/blog_6de3aa8a0101pfgz.html转载▼

标签： gre vxlan neutron openstack-ovs网络 云计算

分类： OpenStack

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

主要参考：
RDO官网对GRE网络的分析：
http://openstack.redhat.com/Networking_in_too_much_detail
OpenStack网络出错处理的一般步骤：
http://docs.openstack.org/trunk/openstack-ops/content/network_troubleshooting.html
OpenStack的主要网络部署场景：
http://docs.openstack.org/admin-guide-cloud/content/section_networking-scenarios.html
==
OpenStack整体系统架构：
http://docs.openstack.org/trunk/openstack-ops/content/architecture.html
OpenStack网络设计：
http://docs.openstack.org/trunk/openstack-ops/content/network_design.html
OpenStack网络组件详细介绍：
http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html

下图是OpenStack软件架构，可以看出主要的组件：
OpenStack Dashboard [Horizon]：提供web管理接口；
OpenStack Object Store [swift]：提供对象存储服务；
OpenStack Image Service [glance]：提供镜像管理服务；
OpenStack Computer [nova]:提供计算和简单的网络服务；
OpenStack Block Storage [cinder]：提供块存储服务；
OpenStack Networking [Neutron]：提供网络服务；
OpenStack Identity Service [keystone]：提供认证服务。
各个组件详细介绍请参考：
http://docs.openstack.org/admin-guide-cloud/content/ch_install-dashboard.html



    典型的系统架构有两种，第一种如下图，是传统的nova-network架构，它也可以有多种网络拓扑模式，包括Flat，FlatDHCP，VlanManager。
请参考：
http://docs.openstack.org/trunk/openstack-ops/content/example_architecture.html#example_architecture-nova
http://docs.openstack.org/trunk/openstack-ops/content/network_design.html#network_topology
http://blog.csdn.net/lynn_kong/article/details/8083924

第二种是OpenStack Networking架构（先不理会HA），此种架构常用的网络拓扑模式包括：VlanManager，GRE和VXLAN。
http://docs.openstack.org/trunk/openstack-ops/content/example_architecture.html#example_architecture-neutron






接下来是OpenStack Networking 组件Neutron的软件架构图，它作为OpenStack的一个独立组件，因此既可以独立部署在单独的主机上，也能与其它组件组合部署在同一主机上。但大多数情况下，Neutron组件在OpenStack架构中常以单独的host形式提供网络服务，作为网络节点，这也是我们下面将重点介绍的架构。
Neutron提供多种服务，具体而言：
neutron-server服务：
neutron-server是一个守护进程，用来提供外部调用的API和与其它组件交互的接口。从图中可看出，其中包括horizon组件，nova-compute服务和keystone认证服务。
neutron agent服务：
(1)插件代理，需要部署在每一个运行hypervisor的主机上，它提供本地的vSwitch配置，更多的时候得依赖你具体所使用的插件类型。（常用的插件是OpenvSwitch，还包括Big Switch，Floodinght REST Proxy，Brocade， NSX， PLUMgrid， Ryu）
http://docs.openstack.org/admin-guide-cloud/content/section_plugin-arch.html
(2)DHCP代理，给租户网络提供动态主机配置服务，主要用途是为租户网络内的虚拟机动态地分配IP地址。
(3)L3代理，提供三层网络功能和网络地址转换(NAT)功能，来让租户的虚拟机可以与外部网络通信。
(4)计量代理，为租户网络提供三层网络流量数据计量服务。

查看方式：
[iyunv@rdo-allinone ~(keystone_admin)]# cd /etc/init.d/
[iyunv@rdo-allinone init.d(keystone_admin)]# ll neutron-*
-rwxr-xr-x. 1 root root 1778 Feb 19 11:10 neutron-dhcp-agent
-rwxr-xr-x. 1 root root 1814 Feb 19 11:10 neutron-l3-agent
-rwxr-xr-x. 1 root root 1783 Feb 19 11:10 neutron-lbaas-agent
-rwxr-xr-x. 1 root root 1798 Feb 19 11:10 neutron-metadata-agent
-rwxr-xr-x. 1 root root 1836 Feb 19 11:10 neutron-openvswitch-agent
-rwxr-xr-x. 1 root root 1160 Feb 19 11:10 neutron-ovs-cleanup
-rwxr-xr-x. 1 root root 1820 Feb 19 11:10 neutron-server

[iyunv@rdo-allinone ~(keystone_admin)]# neutron agent-list
+--------------------------------------+--------------------+--------------+-------+----------------+
| id                     | agent_type         | host      | alive | admin_state_up |
+--------------------------------------+--------------------+--------------+-------+--------------
| 16436773-3170-46fa-8558-902d4d9c05de | DHCP agent      | rdo-allinone | :-)  | True|
| 7dbebfde-128c-43a8-9c70-fdbe8e49a89e | L3 agent          | rdo-allinone | :-)  | True |         
| 98cb47b5-bc50-4cd2-be24-913bf8111c57 | Open vSwitch agent | rdo-computer | :-) |True |         
| ad9a4799-94a0-4541-be6a-5cab1fcb3dbf | Open vSwitch agent | rdo-allinone | :-)  | True|         
+--------------------------------------+--------------------+--------------+-------+--------------
从图中也能看出Neutron不可避免与消息系统Queue和数据库neutron database交互。
            
前面提到了OpenStack系统架构，接下来介绍的GRE网络使用的是上面提到的第二种架构，图上的HA可以暂不理会。概括来说这种系统架构有着独立的控制节点运行horizon，glance，cinder，keystone组件服务，还包括数据库，消息系统等；独立的网络节点运行neutron组件服务；一个或多个独立的计算节点运行nova组件服务。
为了安全和有机的让各个组件稳定的运行，划分网络是很重要的工作。OpenStack的网络主要有两类，内部网络和外部网络；再细分内部网络包括管理网络和虚拟机之间的数据网络，外部网络包括互联internet网络和API管控网络。其中：管理网络主要是来管理OpenStack中各个组件的，在安装部署时，很多配置文件项相关的网络IP就属于管理网络范畴；数据网络主要用于虚拟机之间的通信，虚拟网络划分，Network as a Service等，它由OpenStack的网络组件Neutron和网络插件管理并操作；外部网络就是指可以访问互联网和被cloud之外主机访问或接入的通道；API网络是对cloud之外提供的可以管理的通道，一般不与外部网络区分开来。
具体网络划分如下：
管理网络：192.168.10.0/24（配置在eth0上），部署OpenStack环境时，各种服务的配置文件均会使用这个网卡上的IP。
数据网络：192.168.100.0/24（配置在eth1上），用来连通各个节点上的br-tun网桥，构造通信平面，这个通信层可以构建隧道[GRE]，也可以构建L3通信协议层[VXLAN]。同时它也负责连通租户虚拟网络内的网络设备，使虚拟机之间进行网络通信。
Public/API网络：10.1.101.0/24（配置在eth2上）外部网关是10.1.101.254，一般用在控制节点和网络节点上，需要和外部通信。
租户网络：是用软件定义出来的虚拟网络[10.0.0.0/24]，参考如下


可以参考RDO官方文档http://openstack.redhat.com/GettingStartedHavana_w_GRE使用RDO部署多节点的OpenStack-Neutron-OVS-GRE环境。按照以上网络划分和网卡地址分配，你将更容易的修改RDO的配置文件，部署你所需要的网络环境。
CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=gre
CONFIG_NEUTRON_OVS_TUNNEL_RANGES=1:1000
CONFIG_NEUTRON_OVS_TUNNEL_IF=eth1
安装完成后在安装了neutron组/插件的主机上可以看到vim /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini +157 配置项local_ip为eth1地址。

先了解一下这些网络设备命名的规律：
（1）TenantA的router和Linux网络命名空间qrouter名称
# neutron --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 router-list --field id
| 165f931b-4e08-46eb-a048-f8c62b72b48e |
# ip netns
qrouter-165f931b-4e08-46eb-a048-f8c62b72b48e
即租户虚拟路由器的ID号，与qrouter命名相对应。

（2）TenantA的network和Linux网络命名空间qdhcp名称
# neutron --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 net-list  --field id --field name
| id                                   | name        |
| 4b9ccec6-0d8c-496c-bad3-a26ce01af708 | TenantA-Net |
| 7f70cae2-fd78-486f-ac62-dabadfbb0959 | Ext-Net     |
# ip netns
qdhcp-4b9ccec6-0d8c-496c-bad3-a26ce01af708
即租户虚拟网络的ID号，与qdhcp命名相对应。

（3）TenantA网络端口和其它的网络设备的名称
# neutron --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 port-list
+--------------------------------------+------+-------------------+-------------------------------
| id                                   | name | mac_address       | fixed_ips
+--------------------------------------+------+-------------------+-------------------------------
| 4c2c44d9-4b00-4094-9b21-aeb811d213d9 |      | fa:16:3e:eb:06:2d | {"subnet_id": "cdba0d10-1ef7-485b-b834-3f112feb0b0b", "ip_address": "10.0.0.2"} |
| 6455f9c4-2c63-4c22-abe6-a93bb59130fa |      | fa:16:3e:35:a0:f2 | {"subnet_id": "cdba0d10-1ef7-485b-b834-3f112feb0b0b", "ip_address": "10.0.0.1"} |
| 9e6562b4-6bc8-4e73-b794-55215c1a9d7c |      | fa:16:3e:49:00:b5 | {"subnet_id": "cdba0d10-1ef7-485b-b834-3f112feb0b0b", "ip_address": "10.0.0.4"} |
| f2ce023b-aa4d-4a78-a36f-ae121c4164f7 |      | fa:16:3e:9c:5e:55 | {"subnet_id": "cdba0d10-1ef7-485b-b834-3f112feb0b0b", "ip_address": "10.0.0.3"} |
+--------------------------------------+------+-------------------+-------------------------------
     IP地址为10.0.0.2的虚拟机端口为4c2c44d9-4b00-4094-9b21-aeb811d213d9，那么上图中与之相连的网络设备tap，qbr，qvb，qvo的命名都是加上port ID前缀的11个字符。同理qr加上IP地址为10.0.0.1的端口ID号前缀就是qrouter下的设备名了；qg加上IP地址为外网的10.1.101.xxx端口ID号前缀就是qrouter先的qg设备名了；tap加上IP地址为10.0.0.3的端口ID号前缀就是qdhcp下的设备名了。
可以使用下面这些命令验证：
# neutron port-list
# ifconfig
# ovs-vsctl show
# ip netns exec qrouter-165f931b-4e08-46eb-a048-f8c62b72b48e ifconfig
# ip netns exec qdhcp-4b9ccec6-0d8c-496c-bad3-a26ce01af708 ifconfig

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

    上图是一个典型的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
    意思就是说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网络。

VXLAN介绍：http://blog.sina.com.cn/s/blog_6de3aa8a0101oisp.html
通过上面介绍OVS在neutron中的使用及各个网桥的功能，那么也就能很容易的理解OVS-GRE和OVS-VXLAN的区别了：关键在于各个节点br-tun网桥构成的通道层的连通方式。若br-tun之间两两点对点的连接，通信封包为GRE格式，那么这样的网络环境就是OpenStack-Neutron-OVS-GRE网络模式。同理，若br-tun之间跑三层网络协议，封包方式为VXLAN格式，这样的网络环境就是OpenStack-Neutron-OVS-VXLAN网络模式。对于GRE和VXLAN网络模式而言，可以抽象地将每个br-tun看成隧道端点，有状态的隧道点对点连接即为GRE；无状态的隧道使用UDP协议连接则为VXLAN。这样说的依据是RDO的官方文档（http://openstack.redhat.com/Using_VXLAN_Tenant_Networks）部署VXLAM_Tenant_Networs的过程就可以看出。
接下来不看官方RFC文档也可以大致猜测一下GRE和VXLAN这两种网络模式哪个更好了？答案是VXLAN网络模式！我为什么这么猜测呢，因为OVS-GRE和OVS-VXLAN这两种br-tun之间的连接协议中，显然VXLAN的三层方式要比GRE的点对点方式更高级！当然这样看问题是非常片面的，具体情形还请君视需求而定。
VXLAN：http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-09
GRE：http://tools.ietf.org/html/rfc2784.html

以上是个人的理解和观点，仅供参考，欢迎雅正！！！