一、概述

想必接触过Open stack的人都知道,Opens stack中最复杂的是网络部份,在实际的生产环境中更是如此,实际场景下往往不仅有Open stack网络,还有外部网络(Open stack将其无法管理的网络统称为外部网络),即便在Open stack内部,客户也有不同的网络诉求,本文选取2个案例对常见的网络模型进行说明。

二、案例说明

1.运营商网络和租户网络
Open stack是面向众多租户提供服务的云操作系统,由租户自行创建的网络称为租户网络,但有时候会出现以下这种情况:
Open stack生产环境中几种常见的网络结构
上图是一个租户的VLAN网络,其VID为100,这个网络的计算机并不是虚拟机,即不受Open stack管理,此时该租户需要增加一批虚拟机,而虚拟机VID也必须是100(br-XX转换后的VID),这时Open stack就需要创建一个网络来映射外部网络,创建的这个网络就称为运营商网络。运营商网络可以看成是Open stack网络的外部延展,但其生命周期并不受Neutron组件管理,需要注意的是,创建的网络类型和VID号要和待映射的网络完全一致。运营上网络和租户网络的区别主要表现在以下2点:
(1)管理的权限与角色不同。租户网络由租户自行创建,而运营商网络是由管理员通过administrator账户创建。
(2)创建网络时,传递的参数不同。创建运营商网络时需要传递provider:network_type、provider:physical_network、provider:network_id这3个参数,Open stack认为用户只需要关心服务,所以租户创建网络时不需要传递这3个参数,这3个参数实际上是通过配置文件间接获取。
上文中提到的provider:network_type、provider:network_id好理解,就是对应的网络类型(VLAN或VXLAN)和VID值,但provider:physical_network又起到什么作用?通过上图可以知道,对于非隧道型网络(VLAN)VM在经过br-XX2之后需要转换成待映射网络的VID后就可与外部网络中的物理节点进行通信,但问题是Neutron怎么知br-int必须要将报文发送给br-XX2,此时就需要用到provider:physical_network参数了,因为在配置文件中定义了每个physical_network所对应的物理网卡。对于隧道型网络(VXLAN)这个参数没有什么意义,因为有了目的IP,主机的IP协议栈自己会找到合适的网卡发送出去。
2.VLAN aware VM
在之前的介绍中,VM接受和发送的都是Untag报文,如果这个VM(实际上是VM的vNIC)需要接入多个Vlan中,由于Neutron的资源模型是1个Port只能隶属于1个Network,所以让这1个Port属于多个Network的方法就行不通,而给1个VM配置多个vNIC的方法在VM要接入多个Network的时候(比如1000个Network)就显得不可取,此时就需要VM可以接受和发送带有tag的报文。而根据先前的模型,br-int上的VID是由Open stack自行维护,所有报文必须经过br-int,且VM与br-int之间都是Access接口,一旦将VM与br-int之间的接口改为Trunk,当VM发出带有tag的报文和br-int中的一致时就会造成撞车
Open stack生产环境中几种常见的网络结构
为了解决上述问题,Open stack在N版本之后,就引入了VLAN aware VM模型,它采用1个父端口+多个子端口的方式,将原有的模型改为以下所示:
Open stack生产环境中几种常见的网络结构
图中VM1-1是普通的虚拟机,VM2-1是VLAN aware VM的虚拟机,它是通过在VM和br-int之间加入了1个br-trunk来解决了VID在br-int上撞车的问题,同时Untag的报文走父端口,Tag报文走子接口,有多少个VLAN就有多少个子接口,这样也没有改变Neutron中1个Port属于1个Network的模型,需要注意的是:有多少个VLAN aware VM的虚拟机就有多少个br-trunk虚拟交换机。