接下来是OpenStack Networking 组件Neutron的软件架构图，它作为OpenStack的一个独立组件，因此既可以独立部署在单独的主机上，也能与其它组件组合部署在同一主机上。但大多数情况下，Neutron组件在OpenStack架构中常以单独的host形式提供网络服务，作为网络节点，这也是我们下面将重点介绍的架构。

Neutron提供多种服务，具体而言：

neutron-server服务：

neutron-server是一个守护进程，用来提供外部调用的API和与其它组件交互的接口。从图中可看出，其中包括horizon组件，nova-compute服务和keystone认证服务。

neutron agent服务：

(1) plug-in agent(neutron-*-agent)

插件代理，需要部署在每一个运行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 agent(neutron-dhcp-agent)

DHCP代理，给租户网络提供动态主机配置服务，主要用途是为租户网络内的虚拟机动态地分配IP地址。

(3) l3 agent(neutron-l3-agent)

L3代理，提供三层网络功能和网络地址转换(NAT)功能，来让租户的虚拟机可以与外部网络通信。

(4) metering agent(neutron-metering-agent)

计量代理，为租户网络提供三层网络流量数据计量服务。

查看方式：

[root@rdo-allinone ~(keystone_admin)]# cd /etc/init.d/

[root@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

[root@rdo-allinone ~(keystone_admin)]# neutron agent-list

+--------------------------------------+--------------------+--------------+-------+----------------+

+--------------------------------------+--------------------+--------------+-------+--------------

+--------------------------------------+--------------------+--------------+-------+--------------

从图中也能看出Neutron不可避免与消息系统Queue和数据库neutron database交互。

四 OpenStack-Neutron-OVS-GRE部署

前面提到了OpenStack系统架构，接下来介绍的GRE网络使用的是上面提到的第二种架构，图上的HA可以暂不理会。概括来说这种系统架构有着独立的控制节点运行horizon，glance，cinder，keystone组件服务，还包括数据库，消息系统等；独立的网络节点运行neutron组件服务；一个或多个独立的计算节点运行nova组件服务。

· The Controller Node. Provides all functionality of the cloud except actually hosting virtual machines or providing network services. See the "Compute Node" and "Network Controller" for details about those roles. This server will host the OpenStack Image Service, the OpenStack Block Storage Service, the OpenStack Identity Service, and the OpenStack Dashboard. It will also run portions of the OpenStack Compute service such as the API server, the scheduler, conductor, console authenticator, and VNC service. Finally, it hosts the API endpoint for the OpenStack Network service.

· The Network Node. Provides the bulk of the OpenStack Network services such as DHCP, layer 2 switching, layer 3 routing, floating IPs (which this guide does not configure), and metadata connectivity.

· The Compute Node. Runs the OpenStack Compute service as well as the OpenStack Network service agent (in this case, the Open vSwitch plugin agent). This server also manages an OpenStack-compatible hypervisor such as KVM or Xen. This server will host the actual virtual machines (instances).

为了安全和有机的让各个组件稳定的运行，划分网络是很重要的工作。OpenStack的网络主要有两类，内部网络和外部网络；再细分内部网络包括管理网络和虚拟机之间的数据网络，外部网络包括互联internet网络和API管控网络。其中：管理网络主要是来管理OpenStack中各个组件的，在安装部署时，很多配置文件项相关的网络IP就属于管理网络范畴；数据网络主要用于虚拟机之间的通信，虚拟网络划分，Network as a Service等，它由OpenStack的网络组件Neutron和网络插件管理并操作；外部网络就是指可以访问互联网和被cloud之外主机访问或接入的通道；API网络是对cloud之外提供的可以管理的通道，一般不与外部网络区分开来。

· Management network. Used for internal communication between OpenStack components. The IP addresses on this network should be reachable only within the data center.

· Data network. Used for VM data communication within the cloud deployment. The IP addressing requirements of this network depend on the OpenStack Networking plugin in use.

· External network. Provides VMs with Internet access in some deployment scenarios. The IP addresses on this network should be reachable by anyone on the Internet.

· API network. Exposes all OpenStack APIs, including the OpenStack Networking API, to tenants. The IP addresses on this network should be reachable by anyone on the Internet. This may be the same network as the external network, as it is possible to create a quantum subnet for the external network that uses IP allocation ranges to use only less than the full range of IP addresses in an IP block.

具体网络划分如下：（网络使用情况会直接反应在 keystone endpoint-list 的内容）

管理网络：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]，参考如下

neutron net-create Ext-Net --provider:network_type gre/vxlan --provider:segmentation_id 1 --router:external true

neutron subnet-create --allocation-pool start=10.1.101.240,end=10.1.101.252 --gateway 10.1.101.254 Ext-Net 10.1.101.0/24 --enable_dhcp=False

vim A_prepare.sh

#!/bin/bash

# Create Tenant and User #

tenant=TenantA

user=UserA

usermail=usera@stackinsider.com

role=Member

if keystone tenant-list | grep -q $tenant;then

echo "Tenant $tenant existed!"

else

tenant_id=`keystone tenant-create --name $tenant | awk '/id/{print $4}'`

if keystone user-list | grep -q $user;then

echo "User $user existed!"

else

keystone user-create --name=$user --pass=password --tenant-id $tenant_id --email=$usermail

keystone user-role-add --tenant $tenant --user $user --role $role

neutron --os-tenant-name $tenant --os-username $user --os-password password --os-auth-url=http://localhost:5000/v2.0 net-create $tenant-Net

subnet_id=`neutron --os-tenant-name $tenant --os-username $user --os-password password --os-auth-url=http://localhost:5000/v2.0 subnet-create $tenant-Net 10.0.0.0/24 | awk '$2~/^id/{print $4}'`

neutron --os-tenant-name $tenant --os-username $user --os-password password --os-auth-url=http://localhost:5000/v2.0 router-create $tenant-R1

neutron --os-tenant-name $tenant --os-username $user --os-password password --os-auth-url=http://localhost:5000/v2.0 router-interface-add $tenant-R1 ${subnet_id}

neutron router-gateway-set $tenant-R1 Ext-Net

可以参考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地址。

五 OpenStack-Neutron-OVS网络

先了解一下这些网络设备命名的规律：

（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

举例说明：

系统中的网络设备：

一个外部网络Ext-Net(8583f2ba-37da-4fa0-b312-f9b0979a4fea)；它的子网是ef11b954-d328-4851-a31e-f4bcaefba42b，网段为10.1.101.0/24，但是分配的地址池是从10.1.101.240到10.1.101.252。

还有一个租户网络TenantA-Net（TenantA的网络，ID号为84191af8-269f-485a-b394-85d79e53a39a，对应着qdhcp-84191af8-269f-485a-b394-85d79e53a39a）；它的子网是b2bc3ba5-667c-4df1-a74f-448ce8261fff，网段为10.0.0.0/24，地址池是10.0.0.2到10.0.0.254。TenantA还有一个私有的路由器TenantA-R1（ID号为45765633-1bd6-41c7-bdfc-7d425818135a，对应着qrouter-45765633-1bd6-41c7-bdfc-7d425818135a）。

系统中的网络端口：

neuron port-list出来一共有6个端口：

显然端口974a43e3-90a5-4066-83b1-ac819b29966b（10.0.0.2）和端口0f474d5d-519d-4aef-a633-e4d910cc1b1a（10.0.0.4）是虚拟机cirros-0001和cirros-0002的私有IP地址端口（虚拟机tap网络设备端口）。[并且虚拟机cirros-0001位于computer-02上，cirros-0002位于computer-01上]

端口beabcafe-044d-43f2-bed9-7597d9dfe051（10.1.101.241）是一个浮点IP端口，它绑定在了虚拟机cirros-0001（0aaecb00-0ca2-4c60-bf7c-869eb0570ba8）上。

端口6defad4c-b22c-4216-8de6-8eba533f6c5b（10.0.0.1）和端口d7e5d255-6247-4483-841b-19860161392f（10.1.101.240）是qrouter上面的网络端口。分别作TenantA的网络环境中，子网是b2bc3ba5-667c-4df1-a74f-448ce8261fff（网段为10.0.0.0/24）的网关qr-6defad4c-b2和外网通道qg-d7e5d255-62。[多个网络对应多个qrouter，即qr和qg设备]

端口ae8517df-a628-4252-ad0c-38806d8549d8（10.0.0.3）是qdhcp上面的网络端口tapae8517df-a6，为TenantA的网络环境中，子网是b2bc3ba5-667c-4df1-a74f-448ce8261fff（网段为10.0.0.0/24）的网段动态分配私有IP地址，提供子网dhcp服务。[多个子网对应多个qdhcp，即tap设备]

网络节点上的Linux网桥和OVS网桥：

由上图可以看出网络节点没有运行虚拟机，所以Linux网桥为空。 OVS网桥br-int上面有qrouter的qr端口和qdhcp的tap端口；OVS网桥br-ex上面有qrouter的qg端口，并且br-ex与物理网卡eth2相连；OVS网桥br-tun只是patch网桥br-int和构建隧道平面。

computer-01节点上的Linux网桥和OVS网桥：

由上图可以看出计算节点computer-01节点上面运行虚拟机cirros-0002（3a0ad0d1-ae47-486b-98b2-6e56181fda9e）网络端口为0f474d5d-519d-4aef-a633-e4d910cc1b1a（10.0.0.4）。可以看到qvb0f474d5d-51端口qbr0f474d5d-51端口和tap0f474d5d-51端口。 OVS网桥br-int上面有qvo0f474d5d-51端口；OVS网桥br-tun只是patch网桥br-int和构建隧道平面。

computer-02节点上的Linux网桥和OVS网桥：

由上图可以看出计算节点computer-02节点上面运行虚拟机cirros-0001（0aaecb00-0ca2-4c60-bf7c-869eb0570ba8）网络端口为974a43e3-90a5-4066-83b1-ac819b29966b（10.0.0.2）。可以看到qvb974a43e3-90端口qbr974a43e3-90端口和tap974a43e3-90端口。 OVS网桥br-int上面有qvo974a43e3-90端口；OVS网桥br-tun只是patch网桥br-int和构建隧道平面。

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

上图是一个典型的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设备为什么不直接与计算节点上的br-int网桥相连，而是上图黄色框中所展现的连接情况呢？理想的情况应该是Computer-01上面的绿色框所示。

既然br-int也是网桥，为什么还要穿过Linux bridge qbr设备，这样qbr设备，qvb设备，qvo设备岂不是就显得多余了。没办法，哲学上说存在即合理，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的网桥br-int没有设置iptables规则的功能，但OpenStack又想要(或必须)提供安全组服务，那么就借助了Linux Bridge的功能。虽说OVS的br-int网桥和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网络。

六 OpenStack Neutron OVS-GRE和OVS-VXLAN网络

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

转自：转载链接忘记，请见谅！

码农公寓

相关文章