张 宁,刘 军,张书林,刘 识,唐 佳,王 颖,广泽晶
基于OpenFlow的电力企业数据中心研究
张 宁,刘 军,张书林,刘 识,唐 佳,王 颖,广泽晶
(国家电网公司信息通信分公司,北京 100761)
近年来,随着云计算、大数据技术的不断应用,企业云计算数据中心规模逐渐扩大,计算资源、存储资源的虚拟化技术为云数据中心的建设提供了计算和存储保障。传统网络架构已经成为云数据中心发展的瓶颈,新的网络架构迫在眉睫。本文通过深入研究SDN技术以及OpenFlow技术,并对SDN技术当前发展三种路线进行对比分析,设计了电力企业云数据中心网络。
电力企业;云数据中心;OpenFlow
随着国网信息化水平的不断能提高,数据中心一级部署重要业务系统越来越多。近期,随着更多云业务的上线,对网络的虚拟化、弹性机制和可靠性方面提出了更高的要求。因此,针对SDN技术的数据中心网络研究具有十分重要的意义。
软件定义网络(Software Defined Network,SDN)[1],是Emulex网络一种新型网络创新架构, 是网络虚拟化的一种实现方式,其核心技术OpenFlow通过将网络设备控制面与数据面分离开来,从而实现了网络流量的灵活控制,使网络作为管道变得更加智能。
SDN中没有很好定义的一个方面是控制器信息如何传输到整个网络中的交换机和路由器。图1显示了SDN中信息如何交换。在信息交换的过程中,中央协调控制器将信息传递给开放式存储控制器,开放式虚拟化控制器和SDN控制器。在这里,我们专注于使用OpenFlow等协议的SDN控制器将信息传递给网络中的各种交换机和路由器。
SDN控制器[2]对网络的控制主要是通过南向接口协议实现,包括链路发现、拓扑管理、策略制定等,其中拓扑管理和链路发现主要是控制其利用南向接口的上行通道对底层交换设备所上报的信息进行统一的监控和统计,表项下发和策略制定是控制器利用南向接口的下行通道对网络设备进行统一控制。
图1 SDN信息交换示意图
SDN北向接口是通过控制器向上层业务应用开放的接口,其目标是使得业务应用能够便利地调用底层的网络资源和能力。通过北向接口,网络业务的开发者能以软件编程的形式调用各种网络资源;同时上层的网络资源管理系统可以通过控制器的北向接口全局把控整个网网络的资源状态,并对资源进行统一调度。因为北向接口是直接为业务应用服务的,因此其设计需要密切联系业务应用需求,具有多样化的特征。同时,北向接口的设计是否合理、便捷,以便能被业务应用广泛调用,会直接影响到SDN控制器厂商的市场前景。
与南向接口方面已有OpenFlow等国际标准不同,北向接口方面还缺少业界公认的标准,因此,北向接口的协议制定成为当前SDN领域竞争的焦点,不同的参与者或者从用户角度出发,或者从运营角度出发,或者从产品能力角度出发提出了很多方案。据悉,目前至少有20种控制器,每种控制器会对外提供北向接口用于上层应用开发和资源编排。虽然北向接口标准当前还很难达成共识,但是充分的开放性、便捷性、灵活性将是衡量接口优劣的重要标准,例如REST API就是上层业务应用的开发者比较喜欢的接口形式。部分传统的网络设备厂商在其现有设备上提供了编程接口供业务应用直接调用,也可被视作是北向接口之一,其目的是在不改变其现有设备架构的条件下提升配置管理灵活性,应对开放协议的竞争。
控制器负责整个SDN网络的集中化控制,对于把握全网置资源视图、改善网络资源交付都具有非常重要的作用。但控制能力的集中化,也意味着控制器局的安全性和性能成为全网的瓶颈;另外,单一的控制器也无法应对跨多个地域的SND网络问题,需要多个SDN控制器组成的分布式集群,以避免单一的控制器节点在可靠性、扩展性、性能方面的问题。目前,用于多个控制器之间沟通和联系的东西向接口还没定义标准,但一些非常成熟的集群技术可以被运用到SDN网络中来解决上述难题。
OpenFlow规范的几个版本现在已经发布给业界,并且有几种产品开始在市场上出现[3]。谷歌已经宣布,为了提高效率以及较低能耗比,它已经重新设计了网络在OpenFlow标准下运行。有些学者认为这是OpenFlow的专有实现,因为大部分开发是在最新的OpenFlow规范发布之前完成的。NEC和HP也宣布在他们的网络产品中提供OpenFlow支持。一个名为“Project Floodlight”的开源Open Flow控制器已经由一家名为Big Switch Networks的创业公司发布,并引起了业界的极大兴趣。另外,印第安纳大学还开设了一个SDN互操作性实验室来测试Open Flow产品之间的兼容性。
Open Flow背后的思想是将分布式的网络智能从移动中移走模型转换为使用通用Open Flow控制器的集中模型,如图2所示。传统的数据中心交换机和路由器通过标准的数据交换协议了解自己的环境,并且每个都维护有关整个网络的状态信息,并将其转换为转发表。如果新的交换机或端点被添加到网络中,则该信息被传播到相关网络域中的所有交换机和路由器,并且使用该信息来更新其转发表。这给每个交换机都增加了成本和复杂性。
图2 Open Flow控制器的集中模型
OpenFlow通过使用OpenFlow控制器提供网络的集中视图来改变上述的问题[4]。控制器维护网络的状态,并简单地将转发表填充到网络中的所有交换机和路由器中。网络中的任何变化都会传送给控制器,然后控制器更新其集中状态表。然后它使用此信息来确定如何填充其控制的每台交换机和路由器中的转发表,并使用OpenFlow API将这些信息传递给这些设备。集中式控制平面与分布式数据平面的分离是OpenFlow背后的主要思想之一。
Open Flow的一个关键方面是在图2所示的控制器和网络设备之间使用的开放API。API是一种应用接口,便于Open API允许网络设备供应商与行业标准控制器进行通信,并允许数据中心管理员使用来自多个供应商的设备,从而消除早期OEM设备中的软件锁定问题。图3显示了OpenFlow如何与使用传统的网络操作系统进行比较。
一个传统的网络操作系统被编写来与一个给定的交换芯片供应商的特定API一起工作。一些芯片供应商通过将网络设备OEM厂商锁定在他们在多代硅芯片上使用的特定API来利用这一优势。Open Flow通过使用轻量级的Open Flow API中介层来打破这种锁定,该层简单地将Open Flow API函数调用转换为切换特定的API函数调用但是,开关芯片需要恰当地实现这些功能,以便利用Open Flow功能。目前许多开关芯片供应商正在开发这些垫片层以符Open Flow标准。
图3 与传统网络数据传输进行对比
在SDN技术诞生以来的这十多年发展演变中,根据控制器和网络设备形态的不同组合,出现了三种不同的SDN方案路线,分别是自研控制器+白盒硬件路线,厂商控制器+厂商硬件路线,以及自研控制器+厂商硬件路线[5]。
2.1.1 自研控制器+白盒硬件路线
由用户自行完成SDN网络管理编排层开发、控制器层开发,底层网络设备层的开发可自行完成也可采用ODM厂家自带的硬件操作系统,控制器一般采用行业标准的南北向接口来对接管理编排层及网络设备层。在这个路线中,网络设备的硬件和软件解耦,硬件设备只做报文转发,指导硬件转发的系统软件上收到一个集中的控制器软件中。控制器指导、“命令”硬件转发的方式是给设备下发openflow流表,设备硬件根据流表对报文做无脑转发。
考虑到控制器及白牌交换机的研发成本、人力成本、研发能力、白牌厂商支持能力问题,目前SDN控制器及白牌交换机均采用自研方式的商业案例较少,商用案例主要集中在互联网公司及大型云服务提供商,主要用于数据中心及云计算。这种模式还没有用于大型广域网的案例。Google公司及Facebook在数据中心大量采用白牌交换机,交换机通过ODM厂商根据技术要求进行批量生产,通过公司自研的SDN控制器对白盒交换机进行统一纳管。
2.1.2 厂商控制器+厂商硬件路线
控制器软件和网络硬件都由设备厂商提供,采用厂商经过验证的SDN解决方案。网络硬件在传统的路由器交换机设备上,增加支持了SDN相关的功能协议(例如Netconf配置协议)。控制器给网络设备下发配置或者下发业务流量隧道路径,实现网络配置的自动化和运维的智能化。
这种模式是当前一个主流模式,网络厂商针对局域网SDN及广域网SDN已有较多解决方案及商用案例,在金融、互联网、电信运营商均有实施经验。
2.1.3 自研控制器+厂商硬件路线
基于白盒硬件设备的控制器软件开发难度和工作量太大,为此有些公司企业采用一种折中的路线,网络设备使用传统网络设备厂商的硬件,设备保留了各种路由协议和转发功能,在这种传统网络设备基础上,企业自研控制器软件。
目前已知仅有腾讯公司在有限度的探讨这种模式。
2.2.1 自研控制器+白盒硬件路线
优点:
设备软硬件分离解耦,可以比较方便地给设备和网络添加新功能,SDN架构自行研发,基于管理者对自身网络的深刻理解,可开发出更贴近自身网络业务需求的SDN应用功能。确认业务新需求后,可快速进入开发验证工作,避免了新功能的演进依赖于厂商更新设备。同时,SDN架构体系可根据开发者业务组网需求对整体架构进行灵活调整,避免厂家技术及设备绑定。
硬件白盒化,成本也比传统的网络设备低。另外一方面,所有设备的转发表项都由控制器软件集中下发。对于规模较小、业务简单而且业务变化不大的网络来说,控制器集中计算下发转发流表比较容易实现。
缺点:
网络的集中控制涉及网络拓扑和状态实时感知,路由转发表项动态计算等多方面复杂的挑战和问题。分布在不同设备上运行的各种网络协议和技术——包括路由协议,MPLS转发,二三层VPN,可靠性检测和保护倒换等技术,所有这些技术都集中在一个控制器软件上实现,对自身研发能力要求很高,需对软件开发、业务应用需求、网络功能开发均具备较高研发能力。
对于规模相对较大、业务复杂的网络(例如广域骨干网)来说,控制器集中计算、实时更新网络设备的转发流表,则显得力不从心。同时,商用的白盒机主要为交换机产品均用于数据中心网络,现在业界无用于广域网的路由器白牌设备。
白盒设备采用标准商业芯片,缺乏厂商定制芯片的强大功能特性。白盒厂商,无论是软件厂商还是硬件厂商,他们的能力都会比较聚焦自己的领域,缺乏对设备软硬件整体的认知。同时,软硬件的开发、测试、维护、问题处理需要耗费用户大量的人力成本。
白盒产品线不够齐全,通常不会做核心设备,因核心设备技术门槛高,也不会去做功能要求很复杂的运营商设备,因为功能复杂度高,技术难度高,问题排查难度大,无专业网络厂商对网络功能多年的研发基础。而软件和硬件分离,无法像传统厂商那样提供整体的服务,这将增大问题处理、方案设计的难度。
2.2.2 厂商控制器+厂商硬件路线
优点:
凭借着网络厂商在行业积累大量实际成功项目案例,解决方案非常成熟,可节约用户软硬件的开发、测试、维护的人力成本;高端路由器、交换机技术门槛高,网络厂商设备具备多年的研发积累及市场考验,更加稳定,同时,网络厂商的设备类型丰富,板卡型号丰富,几乎可适用于任何网络场景。
网络厂商提供全面的软、硬件维护服务,故障解决能力更高。
缺点:
采用这种路线,硬件成本比白盒模式高;网络厂商解决方案与厂商设备耦合度较高,容易形成厂商绑定;网络厂商提供的网络功能主要考虑大众用户需求,针对某一用户的定制化需求开发,实现周期相对较长。
2.2.3 自研控制器+厂商硬件路线
优点:
SDN架构的业务应用及控制平面均为自行研发,基于管理者对自身网络的深刻理解,可开发出更贴近自身网络业务需求的SDN应用功能;确认业务新需求后,可快速进入开发验证工作,避免了新功能的演进依赖于厂商更新设备。
缺点:
对自身研发能力要求很高,用户自身需要对软件开发、业务应用需求、网络功能开发均具备较高研发能力;厂家只对自身硬件进行维护,而用户网络的控制软件、及网络整体规划将由用户运维团队自行完成,厂商无法提供专业的技术支持及网络规划支持。
目前主流设备厂商暂未提供此种部署模式,主要原因为此种部署模式与主流网络厂家存在严重利益冲突,等于将自身投入巨额研发成本及经历多年市场考验的网络设备降级为白盒设备,此种模式未来会如何发展,前景还不明朗。
采用此种部署模式时设备保留一部分路由控制平面,控制器只根据业务需求下发路由策略,不下发流表信息。设备根据自身路由转发表完成业务流量转发[7]。交换机实现VxLAN VTEP、VxLAN GW、 VxLAN IP GW的转发封装功能,同时通过标准EVPN完成隧道建立和地址学习。根据控制器制定的路由策略在EVPN隧道中转发业务流量。
控制器只负责业务策略下发,不下发流表[8]。业务转发采用网络设备自身的路由表项。控制器出现故障后,网络设备通过自身路由表象与控制器前期下发的路由策略指导路由转发,对现有业务转发不构成任何应影响。可提供较高的网络可靠性。采用业务策略下发的形式控制交换机转发层面,交换机不必与控制器交互流表信息,减少了传输流表信息、卸载流表及加载流表的网络延迟。因采用策略下发的模式对网络设备进行控制,对网络业务流量转发的控制能力没有采用流表的实行灵活。
图4 弱控制模式
网关部署在Leaf,所有相同VXLAN的网关IP和MAC相同,Border部署VXLAN,Leaf和Spine通过IP的ECMP互通,Leaf节点同时承担VXLAN L2/3转发,Leaf之间通过EVPN完成隧道建立和主机路由同步。
图5 强控制模式
同一Leaf下的三层流量无需绕行到Spin,所有流量的路径最优。相关业务子网内的MAC、ARP地址信息分摊到不同的分布式网关上,如,leaf1上只有业务网络1的虚机上线,无业务网络2的虚机业务,那么leaf1上只需维护业务网络1内的MAC及ARP信息。无需维护整网的MAC及ARP信息,有效的将表象信息分担到多台leaf设备上,与集中式网关相比减少了单台设备的表项资源消耗,更加适合大型云数据中心使用。需要运维人员对网络技术有一定的了解,underly网络需要运维人员手动或通过部署软件来搭建。
基于国网数据中心网络现状及业务需求综合考虑[9],建议采用网络厂商整体解决方案的发展路线,采用弱控制、分布式网关部署模式,同时结合国网统一云平台,实现定制化的管理能力。网络厂商在SDN领域具备较多成功案例及实施经验,厂商的SDN解决方案在设计之初已经对行业内用户的数据中心网络对SDN技术的痛点及需求做过深入的市场调查及研究分析,所提供的解决方案可以有效解决用户在数据中心SDN领域遇到的网络问题。
网络架构:采用核心(Spine节点)+接入(leaf节点)的两层网络架构,核心设备采用两台中高端交换机,虚拟化部署。每两台接入交换机配置网络虚拟化,并通过多条链路与核心交换机FULL MESH互联。
网络性能:若千兆服务器接入,推荐采用万兆光纤链路上行;若万兆服务器接入,推荐采用万兆以上链路上行。上行链路建议多链路上行,分担数据流量,降低超载比。
网络管理:核心节点、接入节点、及安全设备接入管理网,虚拟网络控制器通过管理网实现对网络和安全资源的统一控制和调度。
网络互通性:通过核心节点实现SDN网络与传统网络之间的互通[10]。
基于SDN的新型网络架构分为Underlay物理网络和Overlay虚拟网络,Underlay物理网络的核心节点、接入节点和未来的Server 接入节点之间运行三层动态路由协议(推荐OSPF或ISIS),Overlay虚拟网络采用EVPN+VXLAN,实现虚机VM在服务域内的任意物理位置任意部署,任意扩展,配合云平台可以实现业务全自动部署。
图6 云数据中心网络架构
本文通过研究SDN、Openflow等技术,本文提出了SDN技术在广域网和数据中心网络两种场景下应用方式。数据中心网络建议使用网络厂商整体解决方案,采用弱控制、分布式网关部署模式,同时结合国网统一云平台,实现定制化的管理能力。广域网建议采用网络厂商整体解决方案,同时自研上层管理平台
[1] 张朝昆, 崔勇, 唐翯祎, 等. 软件定义网络(SDN)研究进展[J]. 软件学报, 2015, 26(1): 62-81.
[2] 吴舜, 张辉, 邢宁哲, 等. 基于SDN的网络运维系统设计与开发[J]. 电信科学, 2016, 32(3): 163-170.
[3] 蔡娟娟. 基于OpenFlow的SDN技术研究[J]. 电脑迷, 2016(6).
[4] 侯长逸. OpenFlow网络软件路由研究[J]. 兰州大学学报(自然科学版), 2013(2): 260-263.
[5] 王楠. Openflow网络中路由机制的研究与实现[D]. 北京邮电大学, 2012.
[6] 刘海客, 李集林, 张华健. 基于OpenFlow网络的弹性服务质量保障方法[J]. 计算机应用, 2016, 36(s1): 20-24.
[7] 朱明明, 夏寅贲, 徐小飞. 基于SDN的数据中心网络研究[J]. 邮电设计技术, 2014(3): 23-29.
[8] 汪正康, 周鹏, 肖俊超, 等. 基于SDN的数据中心网络资源调度机制[J]. 计算机系统应用, 2015, 24(8): 212-218.
[9] 吴强, 徐鑫, 刘国燕. 基于SDN技术的数据中心基础网络构建[J]. 电信科学, 2013, 29(1): 130-133.
[10] 赖香武, 彭大芹, 黄德玲, 等. 基于SDN的数据中心网络路由算法研究[J]. 无线互联科技, 2016(24): 38-40.
Research on Data Center Network of Electric Power Enterprise Based on OpenFlow
ZHANG Ning, LIU Jun, ZHANG Shu-lin, LIU Shi, TANG Jia, WANG Ying, GUANG Ze-jing
(State Grid Information & Telecommunication Branch, BeiJing 100761)
In recent years, with the continuous application of cloud computing and big data technology, the scale of enterprise cloud computing data center is gradually expanding. The virtualization technology of computing resources and storage resources provides computing and storage guarantee for the construction of cloud data center. Traditional network architecture has become the bottleneck of the development of cloud data center, and the new network architecture is imminent. Through in-depth study of SDN technology and OpenFlow technology, and comparative analysis of three current development routes of SDN technology, this paper designs the cloud data center network of power enterprises.
Electric power enterprise; Cloud data center; OpenFlow
TP393
A
10.3969/j.issn.1003-6970.2018.12.018
张宁(1989-),男,中级工程师,从事电力数据通信网运维管理;刘军(1970-),男,高级工程师,信息通信调度管理;张书林(1968-),男,工程师,信息通信调度管理;刘识(1984-),男,高级工程师,从事电力信息通信方式资源管理管理;唐佳(1985-),女,高级工程师,从事电力信息通信方式资源管理管理;王颖(1980-),女,高级工程师,从事电力信息通信系统管理;广泽晶(1986-),女,高级工程师,从事电力通信方式资源管理。
张宁,刘军,张书林,等. 基于openflow的电力企业数据中心研究[J]. 软件,2018,39(12):77-82