随着互联网应用的快速发展,数据中心业务上“云”已经成为迫切需求,OpenStack作为最先被广泛认可的云计算产品在生产网络中得到广泛的应用。OpenStack提供的接口可以对接计算、存储、网络等多种资源,本文主要介绍H3C SDN控制器和OpenStack云平台对接的方式,让大家了解一下OpenStack的虚拟网络模型是如何在新华三硬件设备上实现的。
云计算的概念最早由亚马逊公司提出。亚马逊将自己的零售业务迁移到互联网上后,随着公司组织架构的复杂化,单纯的虚拟化技术满足不了业务要求。公司不同部门需要不同的物理服务器,部门内也有不同的业务线。服务器使用完以后也没有一定的回收策略,导致资源利用率低下。后来亚马逊基于虚拟化技术做了二次的研发,开发了一个云计算平台“AWS”也就是亚马逊云。AWS是闭源的,美国宇航局NASA联合了其他公司开发了OpenStack平台,一个开源的云计算架构。
经过不断的版本迭代,OpenStack已经成为当今最具影响力的云计算平台,通过基于Web的可视化控制面板来管理IaaS云端的计算、存储和网络资源池。
通常一个应用程序会有很多底层组件构成,组件之间必须相互配合,才能正常提供服务。这些组件之间的关系就是“耦合”。如果组件之间关联性越强,其中的某一个组件故障了,导致其他的就不能正常工作,这样系统的耦合性就高,或者可称为紧耦合系统。反之,如果组件之间依赖关系低,组件可以自由的进行更新替换,系统耦合性低,可称为松耦合系统。
OpenStack致力于搭建一个分布式松耦合的开放云平台。它由众多功能组件构成,不同的组件提供不同类型的服务,组件之间通过RestAPI接口进行通信。当新的功能被引入,只需要部署新的组件进行对接即可。松耦合模块化的系统为平台服务的横向扩展提供了可行性,增加了平台的灵活度。
图1 OpenStack组件
OpenStack的组件可以分为核心组件和可选组件,核心组件涉及计算、网络、存储、认证等功能,提供了虚拟机运行的最基本环境。但云平台业务往往是多样性的,需要更多的特性组件配合,越来越多的功能正在不断被开发出来。
其中Neutron组件管理网络资源,提供一组应用编程接口,用户可以调用它们来定义网络,并把定义好的网络分配给租户。SDN网络控制器和OpenStack云平台对接主要就是和云平台的Neutron组件进行对接。
图2 OpenStack节点
OpenStack云平台由一系列的服务功能节点组成,上文中提到的各个功能组件分别部署在不同的节点上,这里介绍基本的节点类型。
控制节点:控制节点是OpenStack云平台的集中管理节点,一般会将集群的基础功能部署在控制节点上:如用于组件之间相互认证的Keystone组件、数据库MySQL、实现网络功能的Neutron组件、以及实现计算管理的Nova组件。
计算节点:这里提到的计算节点严格来说可以称为计算代理节点或者Hyper-V节点。这个节点上会真正下发用户创建的虚拟机,这个虚拟机的类型可以是KVM虚拟机,也可以是VMware虚拟机,或者其他支持对接OpenStack的虚拟化类型。控制节点上部署的Novacompute注重的是计算服务,其实它并不关心是通过哪种虚拟化技术实现的。所以这些具体负责虚拟机下发的计算节点是一个代理的角色,但一般为了方便直接称为计算节点。
网络节点:网络节点部署Neutron网络服务,是计算节点上虚拟机和外部网络互通的桥梁。类似的,网络节点可以认为是Neutron网络代理节点,是Neutron维护的逻辑网络的具体执行者。网络节点上有各种Agent来实现网络功能,比如通过dnsmasq来进行地址分配,通过ip tables实现安全组和地址转换等。
从上述的OpenStack节点类型介绍中可以看出,云平台实际上维护的是虚拟的业务模型,各个组件的具体功能都由对应节点上的代理驱动完成,这符合分布式模块化的设计理念,使得云平台可以灵活的对接不同厂商的产品,扩展了OpenStack的生态环境。
图3 Neutron的组成
Neutron由如下组件构成:
组件名称 | 功能 |
Neutron Server | Neutron主要的服务进程,对外提供OpenStack网络API接口,接收请求,并调用Plugin处理请求 |
Plugin | 处理Neutron Server发来的请求,将请求分发到Agent去,维护OpenStack逻辑网络状态 |
Agent | 处理Plugin的请求,负责在Network provIDer上真正实现各种网络功能 |
Network provIDer | 提供网络服务的虚拟或物理网络设备,例如Linux BrIDge,Open vSwitch或者其他支持Neutron的物理交换机 |
Messaging Queue | Neutron Server,Plugin和Agent之间通过消息队列进行通信 |
Database | 存放OpenStack的网络状态信息,包括Network,Subnet,Port,Router等 |
表1 Neutron组件和功能
组件的工作过程:
1. Neutron Server接收到创建Network的请求,通过MessageQueue通知已注册的LinuxBrIDge Plugin。
2. Plugin将要创建的Network的信息(例如名称、VLAN ID等)保存到数据库中,并通过Message Queue通知运行在各节点上的网络Agent。
3. Agent收到消息后会在节点上的物理网卡(比如eth2)上创建VLAN设备(比如eth2.100),并创建brIDge桥接VLAN设备。
Plugin,Agent和Network provIDer是配套使用的,如果Network provIDer是LinuxbrIDge,那么就得使用Linux brIDge的plungin和Agent;相应的如果Network provIDer换成了OVS或者物理交换机,Plugin和Agent也得替换。
Plugin按照功能分为两类:Core Plugin和service Plugin。Core Plugin维护Neutron的Network,subnet和port相关资源的信息,与Core Plugin对应的Agent包括Linux brIDge,OVS等;service Plugin提供routing,firewall,loadbalance等服务,也有相应的Agent。
Plugin的一个主要的职责是在数据库中维护Neutron网络的状态信息,这就造成一个问题:所有Network provIDer的Plugin都要编写一套非常类似的数据库访问代码。
为了解决这个问题,Neutron在Havana版本实现了一个新的Core Plugin:ML2(Modular Layer 2)Plugin,替代原有的Linux brIDge Plugin和open vswitch Plugin,对Plugin的功能进行抽象和封装。有了ML2 Plugin,各种Network provIDer无需开发自己的Plugin,只需要针对ML2开发相应的driver就可以了,工作量和难度都大大减少。
M L 2 对二层网络进行抽象和建模, 引入了typedriver和mechanism driver。这两类driver解耦了Neutron所支持的网络类型(type)与访问这些网络类型的机制(mechanism),其结果就是使得ML2具有非常好的弹性,易于扩展,能够灵活支持多种type和mechanism。
在Neutron网络中可以支持多种网络模型,包括Flat类型、VLAN类型、Overlay类型,通过ML2插件中的type值进行确定。
Flat类型见图4。Flat网络模型最为简单,网络不带有Tag,每个Flat类型的网络独占一个网卡,所有的虚拟机共用一个私有IP网段。
图4 Flat类型网络
VLAN类型见图5。VLAN类型网络带有VLAN Tag,引入了多租户机制,虚拟机可以使用不同的私有IP网段,一个租户可以拥有多个IP网段。VLAN模式下网络地址地址不能有重叠。
图5 VLAN类型网络
Overlay类型见图6。Overlay网络是把二层报文封装在IP报文之上的新的数据格式,只要网络支持IP路由可达就可以部署Overlay网络。而IP路由网络本身已经非常成熟,且在网络结构上没有特殊要求。而且路由网络本身具备良好的扩展能力,很强的的故障自愈能力和负载均衡能力。
图6 Overlay类型网络
Overlay网络模型实现了租户数量的扩充,突破了VLAN网络4K的限制,每个租户可以独立规划自己的虚拟网络和虚拟路由器,并且Overlay模型网络中租户的地址空间允许有重叠。
Overlay技术的选型:
IETF在Overlay技术领域提出三大技术方案。
|
|
VXLAN | VXLAN是将以太网报文封装成UDP报文进行隧道传输,UDP目的端口为已知端口,源端口可按流分配,标准五元组方式有利于在IP网络转发过程中进行负载分担;隔离标识采用24比特来表示 |
NVGRE | NVGRE采用的是RFC 2784和RFC 2890所定义的GRE隧道协议。将以太网报文封装在GRE内进行隧道传输。隔离标识采用24比特来表示;与VXLAN的主要区别在对流量的负载分担上,因为使用了GRE隧道封装,NVGRE使用了GRE扩展字段flowID进行流量负载分担,这就要求物理网络能够识别GRE隧道的扩展信息 |
STT | STT是无状态传输协议,通过将以太网报文封装成TCP报文进行隧道传输,隔离标识采用64比特来表示。与VXLAN和NVGRE的主要区别是在隧道封装格式使用了无状态TCP,需要对传统TCP协议进行修改以适应NVGRE的传输 |
表2 Overlay技术对比
VXLAN技术的优点:
1. 位置无关性:业务可在任意位置灵活部署,缓解了服务器虚拟化后相关的网络扩展问题;
2. 可扩展性:在传统网络架构上规划新的Overlay网络,部署方便,同时避免了大二层的广播风暴,可扩展性极强;
3. 适合云业务:支持千万级别租户隔离,有力支持云业务的大规模部署;
4. 技术成熟度:VXLAN利用了现有通用的UDP传输,成熟性极高。
新华三数据中心组网中使用VXLAN作为底层转发技术。
原生的OpenStack使用纯软组网,全部节点部署在物理服务器上,这种组网模式适用于小规模或者实验性局点。路由器、交换机等硬件网络设备在转发性能上远胜于靠CPU转发的X86服务器,大规模云计算网络中为了满足业务性能需求,均采用硬件Overlay方案。
前面提到了Neutron组件可以通过插件对接Agent实现网络功能,这就为OpenStack对接硬件网络提供了可能,厂家只需要开发网络插件部署在Neutron上就可以。
图7 Neutron对接原理
在硬件Overlay方案中,通常不再使用原生的网络节点,取而代之的SDN控制器和网络设备一起组成的逻辑上的网络节点。原有的网络节点出外网的功能也由SDN Fabric网络来实现。
厂商开发的SDN Neutron插件部署在OpenStack控制节点上,获取Neutron维护的虚拟网络信息,并通过管理网通知给SDN控制器,接着SDN控制器将虚拟网络信息转化成设备配置下发到网络设备上,由此实现了虚拟网络和硬件数据中心架构的对接。
SDN控制器和OpenStack云平台之间互通的网络称为北向网络,SDN控制器从北向网络接受网络创建、更新、删除的请求。同时,SDN控制器和网络设备之间通信的网络称为南向网络,SDN控制器通过南向网络给设备下发业务配置。在控制器上南向网络和北向网络可以使用同一个地址通信,也可以规划不同的地址。
SDN控制器指导设备进行转发有两种方式。一种方式是控制器给设备下发OpenFlow流表指导转发,称为强控方式;一种方式是下发EVPN网络配置,设备进行自学习转发,称为弱控方式。弱控方式由于其网络健壮性高、业务实现灵活、维护难度较低等特点,受到广大硬件厂商的青睐。
本节介绍Neutron基础网络功能在新华三硬件网络中是如何实现的。
图8 Neutron网络模型
project是OpenStack云平台上实现业务分隔的单元,通常对应一个公司组织。OpenStack会基于project分配资源,比如允许创建多少网络、允许创建多少虚拟路由器。SDN控制器上对应project的是租户,在一些场景下也被称为VPC(Virtual Private Cloud)。租户是一个资源分配的逻辑范围,在资源本身,即网络设备上,是没有租户概念的。
vPort是Neutron中虚拟机的概念,OpenStack创建虚拟机的时候首先处理的是Nova,Nova通知Neutron为虚拟机分配网络信息。在Neutron看来分配了网络的虚拟机就是一个vPort。SDN控制器会通过插件获取vPort的信息比如MAC和IP地址。初始状态下,控制器将vPort的状态置为down状态,虚拟机发送DHCP请求或者ARP请求通过OpenFlow通道以PacketIN的方式送到控制器上后,控制器认为该端口已经上线,就将该vPort置为up状态。
Network就是业务网络,根据云平台上租户网络类型的配置,Network一般是VLAN类型的或者是VXLAN类型的。相应的Network ID就是VLAN ID或者VXLAN ID。在Overlay组网中,一个Network就对应这一个VXLAN ID,并且多个VLAN可以映射到一个VXLAN中。控制器上Network的概念和云平台一致,在设备上对应VXLAN的就是vsi(虚拟转发实例)。
subnet就是具体的子网网段,如“192.168.1.0/24”,subnet从属于Network,一个Network中可以配置多个subnet,这些subnet共享这一个Network的广播域。配置subnet的时候可以勾选是否使能DHCP功能,在原生环境下,地址自动分配工作由Neutron-dhcp-Agent来分配,对接SDN控制器之后,该项工作可由SDN控制器集成的DHCP服务器进行分配。
如果一个Network中多个subnet的虚拟机都使能dhcp,那么地址分配的时候会从第一个subnet依次分配。所以在业务环境中通常一个Network只配置一个subnet,也符合传统VLAN网络的使用习惯。
vRouter就是虚拟路由器,和普通硬件路由器一样,虚拟路由器负责在不同Network之间进行三层转发。虚拟机需要访问外部网络也需要经过vRouter的外部网络接口。
OpenStack云平台上vRouter的功能通过Neutron-l3-Agent来实现。虚拟路由器之间通过Linuxnamespace进行隔离。不同的namespace有自己独立的路由表,通过这种方式解决了地址重叠的问题,每个租户都可以独立的地址规划。在SDN控制器对接的场景下,vRouter功能由可以进行三层路由的网络设备实现。相应的,不同虚拟路由器的业务被放在不同的VPNinstance来实现路由隔离。可以理解为一个vRouter就对应着设备上的一个VPN-instance。
OpenStack fwaas功能通过iptables实现,实现用户子网访问的控制,OpenStack lbaas通过haproxy软件来实现业务负载均衡功能。在OpenStack和SDN控制器对接之后,这两项功能均由控制器来实现,控制器纳管物理的防火墙和负载均衡,并将云平台上下发的防火墙和负载均衡业务需求以配置的方式下发到物理设备上。通常情况下,防火墙通过给租户分配不同的虚墙来进行租户间业务的隔离。
每个SDN控制器版本发布的时候都会带有对应插件的版本文件,插件的格式为egg文件。随着OpenStack版本的迭代,控制器也会不断发布对应的插件。
图9 SDN控制器插件
安装插件只需要在Neutron节点部署egg包即可。
[root@localhost ~]# easy_install VCF_CONTROLLER_PLUGIN-D2502P02_pike_2017.10-py2.7
[root@localhost ~]# h3c-vcfPlugin controller install
图10 Neutron插件安装
Neutron配置文件的修改,如图11所示。
[root@localhost ~]# vi /etc/Neutron/Neutron.conf
[DEFAULT]
Core_Plugin = ML2
service_Plugins = h3c_l3_router,firewall,lbaasv2,vpnaas,qos
[service_providers]
service_provIDer=FIREWALL:H3C:Networking_h3c.fw.h3c_fwPlugin_driver.H3CFwaasDriver:default
service_provider=LOADBALANCERV2:H3C:Networking_h3c.lb.h3c_lbPlugin_driver_v2.H3CLbaasv2PluginDriver:default
service_provIDer=VPN:H3C:Networking_h3c.vpn.h3c_vpnPlugin_driver.H3CVpnPluginDriver:default
图11 Neutron配置文件修改
Core_Plugin:核心插件加载入口,即加载核心插件ML2到OpenStack。
Service_Plugins:扩展服务插件加载入口,即加载扩展服务插件到OpenStack。
Service_provider:各种服务插件的路径。
Notification_drivers:QoS消息通知驱动的名称。
原生ML2插件配置文件修改,如图12所示。
[root@localhost ~]# vi /etc/Neutron/Plugins/ML2/ML2_conf.ini
[ML2]
type_drivers = VXLAN,VLAN
tenant_Network_types = VXLAN,VLAN ##租户网络类型
mechanism_drivers = ML2_h3c ##H3C 机制驱动
extension_drivers = ML2_extension_h3c,qos ##H3C扩展驱动
[ML2_type_VLAN]
Network_VLAN_ranges = physicnet1:1000:2999 ##VLAN网络 VLAN范围
[ML2_type_VXLAN]
vni_ranges = 1:500 ##VXLAN网络 VXLAN ID的范围
图12 Neutron ML2配置修改
H3C ML2插件的修改,配置云平台插件和控制器之间的通信方式,如图13所示。
[root@localhost ~]# vi /etc/Neutron/Plugins/ML2/ML2_conf_h3c.ini
[VCFCONTROLLER]
url = https://127.0.0.1:8443
username = sdn
password = skyline123
domain = sdn
timeout = 1800
retry = 10
vnic_type=ovs
hybrID_vnic = True
图13 Neutron H3C配置文件修改
802.1Q协议中规定VLAN ID的字段为12个比特位,这就导致在传统的VLAN数据中心中,虚拟链路层网络的数量最多只有4K个,在大规模业务场景下会出现网络数量不够的情况。
在SDN硬件组网环境中,我们采用VXLAN技术作为底层转发技术,VXLAN VNI的范围有1600万个,可以满足大规模业务场景。但是虚拟机出来还是携带的VLAN标签,而不是VXLAN标签,那么4K个网络的限制是如何被打破的呢?
解决方案就是“层次化端口绑定”。硬件厂商开发硬件交换机的Overlay网络接口,通过接入层交换机VXLAN配置和计算节点上虚拟机标签分配的联动,共同来实现网络规模的突破。
图14 层次化端口绑定原理
1. 租户在Nova中创建一个虚拟机,将其加入网络VXLAN 100;Neutron为VXLAN100创建网络接口,并将请求发送到ML2组件;
2. ML2调用物理交换机(TOR)的Mechanism Driver,设定VXLAN 100;
3. 物理交换机Mechanism Driver再申请一个VLAN 110,通知ML2,当前这个VM的网络接口还需要绑定在VLAN 10;
4. 物理交换机Mechanism Driver通过NETCONF接口设定VLAN 10和VXLAN 100的映射关系;
5. ML2调用OVS的Mechanism Driver,在OVS添加VLAN 10,并将该VLAN配置到VM对应的接口上。
OVS将对VM发出的数据包打上VLAN 10的TAG并转发到物理交换机的接口,物理交换机将带有VLAN 10 TA的数据包封装入VXLAN 100。
我们看到,VM的一个网络接口,既通过OVS的Me c h a n i sm Dr i v e r绑定到了OVS的VL AN接口上,又通过物理交换机的Mechanism Driver绑定到了物理交换机的VLAN/VXLAN接口上。这就是所谓“层次化端口绑定”的含义。
通过这种方式,可以在单独的计算节点上设置VLAN到VXLAN映射的范围,保证全局VXLAN ID不冲突,而不同计算节点上的VLAN可以重叠,这样一个计算节点的网络空间是4K个,N个计算节点的网络空间就是N*4K个,这就实现租户网络规模的突破。
本文简要介绍了原生OpenStack云平台和硬件SDN网络对接的基本原理,以及H3C ADDC数据中心方案中网络Overlay的实现方式,希望能够帮助大家加深对H3C SDN技术方案的理解。