openstack网络(neutron)模式之GRE的基本原理

原文链接:http://www.uml.org.cn/yunjisuan/201501124.asp

neutron网络目的是为OpenStack云更灵活的划分网络,在多租户的环境下提供给每个租户独立的网络环境。

neutron混合实施了第二层的VLAN和第三层的路由服务,它可为支持的网络提供防火墙,负载均衡以及IPSec VPN等扩展功能。

neutron是openstack中一个重要模块,也是比较难理解和debug的模块之一。

一、分析经典的三个节点的Havana的OpenStack中网络

openstack网络(neutron)模式之GRE的基本原理_第1张图片

图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创建一个网络。

openstack网络(neutron)模式之GRE的基本原理_第2张图片

图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:  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:  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:  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:  mtu 1500 qdisc noqueue state UNKNOWN     
    link/ether d6:2a:96:12:4a:49 brd ff:ff:ff:ff:ff:ff    
5: br-tun:  mtu 1500 qdisc noqueue state UNKNOWN     
    link/ether a2:ee:75:bd:af:4a brd ff:ff:ff:ff:ff:ff    
6: qvof5da998c-82:  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:  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:  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:  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:  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:  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:  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:  mtu 1500 qdisc noqueue state UNKNOWN     
    link/ether 22:fe:f1:9b:29:4b brd ff:ff:ff:ff:ff:ff    
7: br-tun:  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:  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:  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:  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:  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:  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:  mtu 1500 qdisc noqueue state UP     
    link/ether f2:d9:f0:d5:48:c8 brd ff:ff:ff:ff:ff:ff    
16: qvo591d8cc4-df:  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:  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:  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的网卡桥接关系,便可以画出下面的图

openstack网络(neutron)模式之GRE的基本原理_第3张图片

图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。

openstack网络(neutron)模式之GRE的基本原理_第4张图片

图4

现在我们想象一个寝室变成了一台Hypervisor,所有的电脑都变成了虚拟机,就变成了下面的样子:

openstack网络(neutron)模式之GRE的基本原理_第5张图片

图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上实现。


你可能感兴趣的:(OpenStack)