支持高效管理的软件定义DCN控制架构
毛健彪, 韩彪, 孙志刚, 卢锡城    
国防科技大学 计算机学院, 长沙 410073
摘要

提出了支持高效管理的软件定义数据中心网络控制架构(FRINGE),采用分布式和集中式相结合的控制,特点是在网络边缘构建软件定义的集中管理域,利用边缘网络设备的可编程配置能力提高网络管理效率. 通过分析发现,FRINGE具有较好的实现可行性,仅需对现有数据中心柜顶交换机进行OpenFlow软件升级. 以数据中心网络管理功能中的故障诊断为例,说明了FRINGE可提升网络管理的性能,诊断探测开销比原有方法可降低至少2个数量级.

关键词: 网络控制    数据中心网络    软件定义网络         
中图分类号:TN929.53 文献标志码:A 文章编号:1007-5321-38-5-109 DOI:10.13190/j.jbupt.2015.05.021
Software-Defined DCN Control Framework Supporting Efficient Network Management
MAO Jian-biao, HAN Biao, SUN Zhi-gang, LU Xi-cheng    
School of Computer, National University of Defense Technology, Changsha 410073, China
Abstract

The target of network control in datacenter is to satisfy the requirement of network resources of tenants and meet the demand of network management. A method of edge software-defined control framework supporting efficient management in data center network(DCN) was proposed named FRINGE. FRINGE builds up a software-defined networking(SDN) management domain at the edge of datacenter networks, exploiting configurable network devices to improve the efficiency of network management. The article analyzed the feasibility of implementation of FRINGE by updating the software of top-of-rack switches to support OpenFlow. It illustrates the troubleshooting in network management to present the enhanced effectiveness of the framework. The probing overhead of FRINGE is two orders of magnitude less than the previous method.

Key words: network control    data center network    software-defined networking    

数据中心已经成为信息化建设的关键基础设施. 数据中心的网络控制是为了满足租户对网络资源的需求以及满足对网络本身管理的需求. 租户对网络资源的需求包括租户构建自定义的网络拓扑,保证多租户带宽、流量隔离等租户需求;网络本身管理的需求包括实现流量工程、故障诊断等相应的网络管理功能.

现有数据中心网络(DCN,data center network)主要存在3种控制架构:一是传统DCN采用的分布式控制架构,通常采用逐个设备的人工配置方法. 其不足是配置失误率高,占所有DCN错误事件的50%~80%[1]. 二是利用软件定义网络(SDN,software-defined networking)思想实现集中的控制. 例如CloudNaaS[2],其缺点是受到网络规模的限制,网络控制器无法对海量、高频变化的网络事件做出及时响应,使得管理效率降低. 三是分布与集中相结合的控制架构. 其代表为基于软件交换机Open vSwitch构建的网络虚拟化平台NVP[3]. 但受到原有网络设备的限制,NVP并没有针对网络本身的管理进行优化.

笔者对高效提升DCN管理的性能进行了研究,利用SDN集中控制和可编程的特点,提出了一种支持高效管理的边缘软件定义DCN控制架构FRINGE. FRINGE采用分布与集中结合的控制架构,在DCN边缘构建SDN管理域,利用柜顶交换机(ToR,top-of-rack)的可编程配置能力提高网络管理效率. 笔者对FRINGE的实现可行性进行了分析,并以DCN管理功能中的故障诊断为例,对该架构提升管理的高效性进行阐述和验证.

1 边缘软件定义控制架构FRINGE

笔者针对现有3种网络控制架构的不足,提出了支持高效管理的边缘软件定义控制架构FRINGE,如图 1所示. 与NVP类似,FRINGE也采用分布式和集中式相结合的控制. 不同的是,除了基于虚拟交换机实现的集中控制,FRINGE还在DCN边缘构建SDN集中管理域,利用DCN接入层设备的可编程配置能力提高网络管理效率. 汇聚层和核心层由于网络管理策略相对比较简单,因此仍采用分布式的人为配置方式. 新定义的SDN域称为SDN边缘管理层,内部的ToR交换机称为OFToR交换机,受网络管理器集中控制. 网络管理功能通过网络管理器之上的各种网络管理应用实现. 这些应用接受相应的网络管理策略作为其输入,通过网络管理器收集网络状态,实时地以下发网络规则的形式OFToR,优化网络运行状态,实现网络管理的目的,例如故障诊断、流量工程等. FRING架构可通过对现有的ToR交换机进行OpenFlow软件升级得以实现. 其可行性将在第2节进行详细分析.

图1 FRINGE控制架构

相比于其他3种控制架构,FRINGE主要有以下几个优点. 首先,该架构的实现可基于原有通用的商用设备,无须替换硬件,只需要对现有ToR交换机的软件进行升级,支持OpenFlow. 因此易部署,对现有网络设备改动少,升级成本低. 其次,由于仅在网络边缘部署SDN,因此对逻辑集中的网络控制平面(网络管理器)的压力相对较小. 最后,FRINGE为不同的网络管理应用提供了快速灵活部署的平台. 网络管理器为应用提供了底层网络的状态和配置OFToR的接口,便于应用实现管理功能. 第3节将以故障诊断为例,详细说明利用FRINGE实现网络管理的优势. 4种架构的对比如表1所示.

表1 4种架构特点对比

此外,尽管FRINGE用于实现网络管理的OFToR交换机相对较少,但是控制平面可扩展性和可靠性的问题仍然存在,只是减少了问题的数量级. 网络管理器的具体实现可采用分布式[4]或集群的方式. 网络管理器与OFToR之间的OpenFlow通道既可选取带外管理的方式,也可采用带内管理的方式. 带外管理即构建独立的一套管理网络控制OpenFlow设备. 带内管理即在已有的DCN数据通路上划出一个单独的VLAN构建OpenFlow通道. 这2种不同的部署会影响控制报文的传输路径,因此网络管理员必须了解网络管理器的部署方式,以实现正确灵活的控制.

2 可行性分析

从两方面分析FRINGE架构实现的可行性:论证现有ToR交换机仍有部分可利用的计算资源,为OpenFlow升级提供支撑;给出将现有ToR交换机进行软件升级的方案.

2.1 ToR软件升级可行性分析

支持OpenFlow的交换机定会比普通的交换机更多地占用交换机CPU的资源. 如果现有数据中心的ToR交换机CPU利用率已达到比较高的水平,那么再将其改进支持OpenFlow,会加重交换机CPU的负载,在报文处理时极易造成丢包、延迟等网络故障. 因此,必须确认当前DCN的ToR交换机是否仍有足够的空闲计算资源. 笔者在国家广州超算中心的大规模DCN测得2个小时内某个ToR交换机上CPU的空闲率,如图 2所示. 在测试时间内,该网络内运行广州教育网的业务且保持稳定. 测试方法为每隔5min记录1次交换机CPU的空闲率.

图2 ToR交换机CPU空闲率

图 2(a)中横轴表示时间刻度,纵轴表示在该时间刻度的前5min内,CPU平均空闲的比率. 此外,从图 2(b)中看到,所有ToR交换机在一段时间内CPU的空闲率基本维持在61%左右,且保持稳定. 从测试可知,在真实数据中心运行环境下,ToR交换机的CPU利用率不是很高. 这就表明现有的ToR交换机仍有部分可利用的计算资源,这也就为笔者改进ToR交换机实现OpenFlow的想法提供了支撑.

2.2 OpenFlow软件升级方案

现有的商用交换机通过开放ACL,升级软件后可支持OpenFlow,这项技术近年来越渐成熟. BigSwitch公司推出了在特定交换芯片上支持OpenFlow1.0的开源软件包indigo,为部分商用设备OpenFlow软件升级提供支撑. 笔者以广州超算大规模DCN的ToR交换机为例,简要描述基于该交换机的升级方案.

广州超算中心的DCN ToR交换机中交换芯片采用BCM56624,CPU为PowePC440嵌入式处理器. OpenFlow升级后的交换机软件与原有的架构基本保持一致,不同的是在应用层增加了一个OpenFlow协议模块,负责OpenFlow消息的产生、解析和处理;在中间层对交换芯片支持包进行了修改,实现对交换芯片的重新管理配置,符合OpenFlow的硬件处理流程. 基础支撑层保持不变,是软硬件之间的接口,实现硬件操作的基本原语. 由于OpenFlow升级只是改动了现有交换机的软件部分,因此该方案易实现.

此外,各大网络设备厂商竞相推出支持OpenFlow的交换机,如NEC 5820、HP 3500、Juniper MX系列等. 因此,通过升级现有的ToR支持OpenFlow的功能或购买现有的OpenFlow交换机,构建DCN的边缘是可行的.

3 FRINGE架构下的故障诊断优化

本节以网络管理功能中的故障诊断为例,阐述和验证FRINGE架构可提升网络管理效率. 故障诊断是网络管理的核心,是数据中心长期正常运行的保证. 现有的基于端到端的测量方法探测开销较大,且易受服务器虚拟化的影响,误差较大.

为此,笔者提出了基于OFToR的集中网络测量方法,减少探测开销,避免服务器虚拟化对端到端测量的严重干扰,提高故障诊断效率. 笔者假设ToR交换机与服务器的连接是可靠的,因此在进行故障诊断时,将DCN分为可靠域和诊断域. 可靠域由服务器以及服务器和ToR交换机之间的连接组成,而网络核心层和汇聚层构成了诊断域. 该假设可从关于数据中心失效的研究中证明是合理[1],即ToR交换机与服务器的连接的故障率低. 而且在某些数据中心中(例如广州超算中心),ToR交换机和服务器通过背板互连,2者之间的连接失效率更低. 在对可靠域进行测量时,控制器可直接利用OpenFlow控制通路,读取OFToR交换机端口状态. 诊断域的测量过程描述如下,如图 3所示.

图3 基于OFToR的集中网络测量

以测试网络连通性为例,控制器向某个OFToR交换机以Packet_out报文的形式发出探测报文. 该探测报文将根据Packet_out报文中包含的规则输出到指定端口,并通过汇聚→核心→汇聚→OFToR或汇聚→OFToR的路径达到另一个OFToR交换机. 该OFToR交换机不识别这些探测报文,将它们以Packet_in的形式送至控制器. 控制器端收到探测报文,即可得到路径①→②→③→④→⑤的连通性. 同样可测得其余路径的连通性. 再利用拓扑层析的线性模型,推断出网络中每条链路的通/断,即可定位故障. 需要注意的是,链路①⑤为OpenFlow控制通路. 当控制器以带外的方式进行控制,由于带外控制单独地为OpenFlow控制通路构建网络,仅用于控制器与所有OpenFlow交换机之间交互信息,因此可假设链路①⑤连通性好,无丢包和延迟等. 若控制器以带内的方式控制,则须保证控制路径上的报文在经过所有交换节点时以最高的优先级处理. 为防止对诊断域测量的干扰,链路①⑤的链路参数可单独测得.

记ToR交换机的数量为m,则集中测量的探测开销从O(n2)下降至O(m2)(通常情况下n>>m). 表2给出当等分带宽比(equal bisection bandwidth ratio)为1∶1时,在不同的DCN拓扑下(HyperX,Jellyfish,VL2)服务器数量和ToR交换机的数量之间的关系. 若已知服务器数量,HyperX和Jellyfish2个拓扑中ToR的数量从文献[5]的结果中推算可知. 从表2中可以看出,尽管拓扑不同,但是服务器的数量和ToR数量基本呈正比关系增长,n/m分别约为13.0(HyperX)、17.5(Jellyfish)、20(VL2). 由此可知,测量开销的复杂度可分别减少约169、306、400倍. 以VL2的拓扑为例,考虑在不同等分带宽比下的探测开销,如图 4所示. 基于端到端的探测开销至少为105数量级,随着服务器数量增加,最大开销可达108数量级.

表2 不同拓扑下服务器与ToR数量的对比

图4 VL2拓扑下不同等分带宽比的网络探测开销测量

而基于OFToR的探测开销,当等分带宽比为1∶1时,开销最小为103数量级;当等分带宽比为1∶2时,开销最小为102数量级;当等分带宽比为1∶5时,开销最小为10数量级. 由此可知,基于OFToR的集中测量方法能有效降低探测开销至少2个数量级.

此外,该方法还可以动态的指定要测量的路径,利用图论方法,选取尽量少的测量路径覆盖整个网络,实现链路参数的估计. 所以基于OFToR的测量开销可进一步减少.

基于FRINGE还可更好地实现其他网络管理功能. 2层网络更符合云计算业务对网络的需求,但2层网络规模扩展受到广播数量增多、交换机表项资源有限、生成树协议等的限制,可扩展能力有限. 基于FRINGE控制架构,利用网络控制器上的ARP代理应用,采用交换机MAC作为报文目的MAC的方法,对处于同一OFToR下的MAC地址用该交换机的MAC进行聚合,可有效减少所有网络设备中表项的数量. 此外,由于DCN通常包含多条冗余链路,可基于OFToR实现流量工程,充分利用网络中的多路径.

4 结束语

由于SDN在简化网络管理方面的优势,并且越来越多的商用交换机已经或很容易经过软件升级支持OpenFlow,笔者提出一种支持高效管理的边缘软件定义DCN架构FRINGE. 该架构利用DCN接入层支持SDN的特性提升网络管理效率,为未来数据中心的建设提供了新思路.

笔者仅对该架构的可行性进行了简要的分析,下一步将针对核心架构的设计进行细化,针对管理功能完成具体的模拟实验和实际环境验证,论证该架构的性能与可扩展性.

参考文献
[1] Gill P, Jain N, Nagappan N. Understanding network failures in data centers: measurement, analysis, and implications[C]//In Proceedings of SIGCOMM. Toronto, Canada, 2011: 350-361.[引用本文:2]
[2] Benson T, Akella A, Shaikh A, et al. Cloudnaas: a cloud networking platform for enterprise applications[C]//In Proceedings of ACM SOCC. Cascais, Portugal, 2011: 8-20.[引用本文:1]
[3] Koponen T, Amidon K, Balland P, et al. Network virtualization in multi-tenant datacenters[C]//In Proceedings of USENIX NSDI. Seattle, WA, USA, 2014: 203-214.[引用本文:1]
[4] Berde P, Matteo G, Jonathan H, et al. Onos: towards an open, distributed SDN os[C]//Proceedings of the SIGCOMM Workshop on Hot Topics in SDN. Chicago, USA, 2014: 157-162.[引用本文:1]
[5] Stephens B, Cox A, Felter W, et al. Past: scalable ethernet for data centers[C]//Proceedings of the ACM CoNEXT. Nice, France, 2012: 49-60.[引用本文:1]