neutron网络目的是为OpenStack云更灵活的划分网络,在多租户的环境下提供给每个租户独立的网络环境。
neutron混合实施了第二层的VLAN和第三层的路由服务,它可为支持的网络提供防火墙,负载均衡以及IPSec
VPN等扩展功能。
neutron是openstack中一个重要模块,也是比较难理解和debug的模块之一。
一、分析经典的三个节点的Havana的OpenStack中网络
图1:三节点opens网络
分为三个网络:
1、External Network/API Network,这个网络是链接外网的,无论是用户调用OpenStack的API,还是创建出来的虚拟机要访问外网,或者外网要ssh到虚拟机,都需要通过这个网络
2、Data Network,数据网络,虚拟机之间的数据传输通过这个网络来进行,比如一个虚拟机要连接到另一个虚拟机,虚拟机要连接虚拟路由都是通过这个网络来进行
3、Management Network,管理网络,OpenStack各个模块之间的交互,连接数据库,连接Message
Queue都是通过这个网络来进行。
将这三个网络隔离,一方面是安全,在虚拟机里面,无论采用什么手段,干扰的都仅仅是Data Network,都不可能访问到我的数据库。一方面是流量分离,Management
Network的流量不是很大的,而且一般都会比较优雅的使用,而Data Network和External
Network就需要有流量控制策略。
这个网络结构有点奇怪,除了Controlller节点是两张网卡之外,其他的都多了一张网卡连接到External
Network。这个网卡是用来做apt-get的,因为Compute Node按说是没有网卡连接到外网的,为了apt-get添加了eth0;NetWork
Node虽然有一个网卡eth1是连接外网的,而在neutron配置好之前,这个网卡通常是没有IP的,为了apt-get也添加了eth0;有人说可以通过route规则都通过Controller连接到外网,但是对于初学者,这样比较容易操作。
二、neutron三个节点简介
neutron是用来创建虚拟网络的,所谓虚拟网络,就是虚拟机启动的时候会有一个虚拟网卡,虚拟网卡会连接到虚拟switch上,虚拟交换机连接到虚拟router上,虚拟路由器最终和物理网卡联通,从而虚拟网络和物理网络联通起来。
neutron分成多个模块分布在三个节点上。
1.Controller节点:
neutron-server,用于接受API请求创建网络,子网,路由器等,然而创建的这些东西仅仅是一些数据结构在数据库里面
2.Network节点:
neutron-l3-agent,用于创建和管理虚拟路由器,当neutron-server将路由器的数据结构创建好,neutron-l3-agent是做具体事情的,真正的调用命令行将虚拟路由器,路由表,namespace,iptables规则全部创建好。
neutron-dhcp-agent,用于创建和管理虚拟DHCP server,每个虚拟网络都会有一个DHCP
server,这个DHCP server为这个虚拟网络里面的虚拟机提供IP。
neutron-openvswitch-plugin-agent,这个是用于创建L2的switch的,在Network节点上,Router和DHCP
Server都会连接到二层的switch上。
3.Compute节点:
neutron-openstackvswitch-plugin-agent,这个是用于创建L2层switch的,在compute节点上,虚拟机的网卡也是连接到二层的switch上。
三、租户网络创建过程
当我们搭建好了OpenStack,然后创建好了tenant后,我们会为这个tenant创建一个网络。
图2:租户网络创建过程
结合上图说明给一个租户创建网络的流程:
1、为这个Tenant创建一个private network,不同的private network是需要通过VLAN
tagging进行隔离的,互相之间广播(broadcast)不能到达,这里我们我们用的是GRE模式,也需要一个类似VLANID的东西,称为Segment
ID
2、为private network创建一个subnet,subnet才是真正配置IP网段的地方,对于私网,我们常常用192.168.0.0/24这个网段
3、为这个Tenant创建一个Router,才能够访问外网
4、将private network连接到Router上
5、创建一个External Network
6、创建一个External Network的Subnet,这个外网逻辑上代表了我们数据中心的物理网络,通过这个物理网络,我们可以访问外网。因而PUBLIC_GATEWAY应该设为数据中心里面的Gateway,PUBLCI_RANGE也应该和数据中心的物理网络的CIDR一致,否则连不通。之所以设置PUBLIC_START和PUBLIC_END,是因为在数据中心中,不可能所有的IP地址都给OpenStack使用,另外的可能搭建了VMware
Vcenter,可能有物理机,所以仅仅分配一个区间给OpenStack来用。
7、将Router连接到External Network
经过这个流程,从虚拟网络到物理网络即逻辑上联通了。
代码流程如下:
#!/bin/bash
TENANT_NAME="openstack"
TENANT_NETWORK_NAME="openstack-net"
TENANT_SUBNET_NAME="${TENANT_NETWORK_NAME}-subnet"
TENANT_ROUTER_NAME="openstack-router"
FIXED_RANGE="192.168.0.0/24"
NETWORK_GATEWAY="192.168.0.1"
PUBLIC_GATEWAY="172.24.1.1"
PUBLIC_RANGE="172.24.1.0/24"
PUBLIC_START="172.24.1.100"
PUBLIC_END="172.24.1.200"
TENANT_ID=$(keystone tenant-list | grep " $TENANT_NAME " | awk '{print $2}')
(1) TENANT_NET_ID=$(neutron net-create --tenant_id $TENANT_ID
$TENANT_NETWORK_NAME --provider:network_type gre
--provider:segmentation_id 1 | grep " id " | awk '{print $4}')
(2) TENANT_SUBNET_ID=$(neutron subnet-create --tenant_id $TENANT_ID
--ip_version 4 --name $TENANT_SUBNET_NAME $TENANT_NET_ID $FIXED_RANGE
--gateway $NETWORK_GATEWAY --dns_nameservers list=true 8.8.8.8 | grep "
id " | awk '{print $4}')
(3) ROUTER_ID=$(neutron router-create --tenant_id
$TENANT_ID $TENANT_ROUTER_NAME | grep " id " | awk '{print $4}')
(4) neutron router-interface-add $ROUTER_ID $TENANT_SUBNET_ID
(5) neutron net-create public --router:external=True
(6) neutron subnet-create --ip_version 4 --gateway $PUBLIC_GATEWAY
public $PUBLIC_RANGE --allocation-pool
start=$PUBLIC_START,end=$PUBLIC_END --disable-dhcp --name public-subnet
(7) neutron router-gateway-set ${TENANT_ROUTER_NAME} public |
四、GRE模式下网络细节
创建完网络,如果不创建虚拟机,我们发现neutron的agent还是做了很多工作的,创建了很多虚拟网卡和switch。
在compute节点上:
root@ComputeNode:~# ip addr 【显示所有接口的IP信息】
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:49:5c:41 brd ff:ff:ff:ff:ff:ff inet 172.24.1.124/22 brd 16.158.167.255 scope global eth0 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:8e:42:2c brd ff:ff:ff:ff:ff:ff inet 192.168.56.124/24 brd 192.168.56.255 scope global eth2 3: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:68:92:ce brd ff:ff:ff:ff:ff:ff inet 10.10.10.124/24 brd 10.10.10.255 scope global eth3 4: br-int: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether d6:2a:96:12:4a:49 brd ff:ff:ff:ff:ff:ff 5: br-tun: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether a2:ee:75:bd:af:4a brd ff:ff:ff:ff:ff:ff 6: qvof5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether c2:7e:50:de:8c:c5 brd ff:ff:ff:ff:ff:ff 7: qvbf5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether c2:33:73:40:8f:e0 brd ff:ff:ff:ff:ff:ff |
root@ComputeNode:~# ovs-vsctl show 【查看open vswitch网桥】
39f69272-17d4-42bf-9020-eecc9fe8cde6 Bridge br-int Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port br-int Interface br-int type: internal Bridge br-tun Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "gre-1" Interface "gre-1" type: gre options: {in_key=flow, local_ip="10.10.10.124", out_key=flow, remote_ip="10.10.10.121"} Port br-tun Interface br-tun type: internal ovs_version: "1.10.2" |
在Network 节点上:
root@NetworkNode:~# ip addr 【显示所有接口的IP信息】
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:22:8a:7a brd ff:ff:ff:ff:ff:ff inet 172.24.1.121/22 brd 172.24.1.255 scope global eth0 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:f1:31:81 brd ff:ff:ff:ff:ff:ff 3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:56:7b:8a brd ff:ff:ff:ff:ff:ff inet 192.168.56.121/24 brd 192.168.56.255 scope global eth2 4: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:26:bc:84 brd ff:ff:ff:ff:ff:ff inet 10.10.10.121/24 brd 10.10.10.255 scope global eth3 5: br-ex: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 08:00:27:f1:31:81 brd ff:ff:ff:ff:ff:ff inet 172.24.1.8/24 brd 172.24.1.255 scope global br-ex 6: br-int: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 22:fe:f1:9b:29:4b brd ff:ff:ff:ff:ff:ff 7: br-tun: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether c6:ea:94:ff:23:41 brd ff:ff:ff:ff:ff:ff |
oot@NetworkNode:~# ip netns 【列出网络命名空间】
qrouter-b2510953-1ae4-4296-a628-1680735545ac qdhcp-96abd26b-0a2f-448b-b92c-4c98b8df120b |
oot@NetworkNode:~# ip netns exec qrouter-b2510953-1ae4-4296-a628-1680735545ac
ip addr 【利用网络命名空间进行操作】
8: qg-97040ca3-2c: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether fa:16:3e:26:57:e3 brd ff:ff:ff:ff:ff:ff inet 172.24.1.100/24 brd 172.24.1.255 scope global qg-97040ca3-2c 11: qr-e8b97930-ac: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether fa:16:3e:43:ef:16 brd ff:ff:ff:ff:ff:ff inet 192.168.0.1/24 brd 192.168.0.255 scope global qr-e8b97930-ac |
root@NetworkNode:~# ip netns exec qdhcp-96abd26b-0a2f-448b-b92c-4c98b8df120b
ip addr 【利用网络命名空间进行操作】
9: tapde5739e1-95: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether fa:16:3e:19:8c:67 brd ff:ff:ff:ff:ff:ff inet 192.168.0.2/24 brd 192.168.0.255 scope global tapde5739e1-95 inet 169.254.169.254/16 brd 169.254.255.255 scope global tapde5739e1-95 |
root@NetworkNode:~# ovs-vsctl show 【查看open vswitch的网络状态】
d5d5847e-1c9e-4770-a68c-7a695b7b95cd Bridge br-ex Port "qg-97040ca3-2c" Interface "qg-97040ca3-2c" type: internal Port "eth1" Interface "eth1" Port br-ex Interface br-ex type: internal Bridge br-int Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "tapde5739e1-95" tag: 1 Interface "tapde5739e1-95" type: internal Port br-int Interface br-int type: internal Port "qr-e8b97930-ac" tag: 1 Interface "qr-e8b97930-ac" type: internal Bridge br-tun Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "gre-2" Interface "gre-2" type: gre options: {in_key=flow, local_ip="10.10.10.121", out_key=flow, remote_ip="10.10.10.124"} Port br-tun Interface br-tun type: internal ovs_version: "1.10.2" |
这时如果我们在这个网络里创建一个虚拟机,在Compute Node多了下面的网卡:
13: qvof5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether c2:7e:50:de:8c:c5 brd ff:ff:ff:ff:ff:ff 14: qvbf5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether c2:33:73:40:8f:e0 brd ff:ff:ff:ff:ff:ff 15: qbr591d8cc4-df: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether f2:d9:f0:d5:48:c8 brd ff:ff:ff:ff:ff:ff 16: qvo591d8cc4-df: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether e2:58:d4:dc:b5:16 brd ff:ff:ff:ff:ff:ff 17: qvb591d8cc4-df: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbr591d8cc4-df state UP qlen 1000 link/ether f2:d9:f0:d5:48:c8 brd ff:ff:ff:ff:ff:ff 18: tap591d8cc4-df: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbr591d8cc4-df state UNKNOWN qlen 500 link/ether fe:16:3e:6e:ba:d0 brd ff:ff:ff:ff:ff:ff |
如果我们按照ovs-vsctl show的网卡桥接关系,便可以画出下面的图
图3:GRE网络
GRE网络原理:
假设虚拟机VM0网卡eth0有网络数据包向外网发送,那么数据会依次经过qbr Linux Bridge设备,qvb和qvo虚拟网络设备,到达OVS网桥br-int上,br-int将数据包attach到OVS网桥br-tun上,数据包再从compute节点OVS网桥的br-tun和network节点OVS网桥br-tun构成的GRE隧道穿过,交付到Network节点的OVS网桥br-int上;网络节点的br-int通过qr设备借助Linux命名空间qrouter连通到br-ex上的qg设备,将数据包交付到OVS网桥br-ex上,最后br-ex通过网络节点的外部武力端口eth1把数据包传送到外部路由器的网关。
五、通过例子理解GRE网络
openstack为什么要创建这么多的虚拟网卡?
这些网卡看起来复杂,却是各有用处,这种虚拟网络拓扑,正是我们经常使用的物理网络的拓扑结构。
下面通过一个非常容易理解的例子来逐步分析gre网络。
我们先来回到一个最最熟悉不过的场景,我们的大学寝室,当时我们还买不起路由器,所以一般采取的方法如下图所示:
寝室长的机器上弄两张网卡,寝室买一个HUB,其他人的电脑都接到HUB上,寝室长的电脑的两张网卡一张对外连接网络,一张对内连接HUB。寝室长的电脑其实充当的便是路由器的作用。
后来条件好了,路由器也便宜了,所以很多家庭也是类似的拓扑结构,只不过将Computer1和switch合起来,变成了一个路由器,路由器也是有多个口一个连接WLAN,一个连接LAN。
图4
现在我们想象一个寝室变成了一台Hypervisor,所有的电脑都变成了虚拟机,就变成了下面的样子:
图5:单节点的openstack的网络结构
我们先忽略qbr和DHCP Server,以及namespace。
br-int就是寝室里的HUB,所有虚拟机都会连接到这个switch上,虚拟机之间的相互通信就是通过br-int来的。
Router就是寝室长的电脑,一边连接在br-int上,一边连接在对外的网口上,br-ex/eth0外面就是我们的物理网络。
图5其实就是单节点的openstack的网络结构,虽然复杂,但是就是把我们家里的,或者寝室里面的物理机搬到一个Hypervisor上了,其结构就不难理解了。
当然单节点的openstack不过是个测试环境,compute节点和network节点也是要分开的,如图3,每个机器上都有了自己的br-int。
六、GRE网络原理进一步理解
以下内容可对比图3来理解
(1)DHCP
为什么会有个DHCP Server呢,是同一个private network里的虚拟机得到IP都是通过这个DHCP
Server来的,这个DHCP Server也是连接到br-int上和虚拟机进行通信的。
(2)qbr
既然qbr和br-int都是网桥,为什么不直接连到br-int,还要通过qbr,qvb,qvo岂不是多余,为什么会有qbr呢?这是和security
group的概念有关。简单说就是OVS网桥br-int没有设置iptables规则的功能,但openstack又要提供安全组服务,就借助了Linux
bridge(qbr)的功能,虽然OVS的br-int和linux bridge (qbr)都是二层网桥,但是为了功能互补就同时出现了。具体了解,openstack中的security
group开通哪些端口,屏蔽哪些端口是用iptables来实现的,然而br-int这些虚拟bridge都是openvswitch创建的,openstack的Kernel
mode和netfilter的kernel mode不兼容。一个IP包进来要么走iptables规则进行处理,要么走openvswitch的规则进行处理,br-int上有很多openvswitch的规则,比如vlan
tag等,所以iptables必须要另外建立一个linux bridge(qbr)来做,因而就有了qbr,在了解拓扑结构的时候,可以将qbr忽略,看到VM直接连接到br-int上就可以了。
(3)namespace
为什么会有namespace呢,java的namespace是为了在不同namespace下有相同类名,openstack也想做到这一点。不同Tenant都创建自己的router和private
network,彼此不知道别人指定了哪些网段,很有可能两个tenant都指定了192.168.0.0/24,这样不同的private
network的路由表,DHCP Server就需要隔离,不然就乱了,因而就有了namespace。
(4)OVS一体化网桥br-int
每个机器上都有了自己的br-int,但是对于虚拟机和虚拟router来说,它们仍然觉得自己连接到了一个大的L2的br-int上,通过这个br-int相互通信的,它们感受不到br-int下面的虚拟网卡br-tun。所以对于多节点结构,我们可以想象br-int是一个大的,横跨所有compute和network节点的二层switch,虚拟机之间的通信以及虚拟机和Router的通信,就像在一个寝室一样的。这是一种很重要的抽象思维,好像openstack环境中所有虚拟机都连接到了一个巨型的虚拟交换机上。
然而br-int毕竟被物理的割开了,需要有一种方式将他们串联起来,openstack提供了多种方式,可以用GRE
tunnel将不同机器的br-int连接起来,也可以通过VLAN将br-int连接起来,当然还可以使用vxlan。
这就是为什么openstack有了br-int这个bridge,但是不把所有的openvswitch的规则都在它上面实现。就是为了提供这种灵活性,对于虚拟机来讲,看到的是一大整个br-int,不同机器的br-int可以有多种方式连接,这在br-int下面的网卡上面实现。
(5)OVS通道网桥br-tun
br-tun也是OVS创建的虚拟网桥,它是一个中间层,接收br-int的网络数据,然后在通过特定网络协议与各个节点的br-tun相连构成一个通道层。如果所有的br-int构成的抽象层定义为虚拟二层网络,那么所有的br-tun构成的抽象层边上虚拟三层网络了。
(6)网络数据包隔离
如果有不同的Tenant,创建了不同的private network,为了在data network上对包进行隔离,创建private
network的时候,需要指定vlanid或者segmentid。
从ovs-vsctl show我们可以看到,不同的tenant的private network上创建的虚拟机,连接到br-int上的时候是带tag的,所以不同tenant的虚拟机,即便连接到同一个br-int上,因为tag不同,也是不能相互通信的。然而同一个机器上的tag的计数是仅在本机有效的,并不使用我们创建private
network的时候指定的全局唯一的vlanid或者segmentid,一个compute节点上的br-int上的tag
1和另一台compute节点上的br-int的tag1很可能是两码事。全局的vlanid和segmentid仅仅在br-int以下的虚拟网卡和物理网络中使用,虚拟机所有能看到的东西,到br-int为止,看不到打通br-int所要使用的vlanid和segmentid。
从局部有效的taging到全局有效的vlanid或者segmentid的转换,都是通过openvswitch的规则,在br-tun或者br-eth1上实现。
|