2. 清华大学 信息化技术中心, 北京 100084
2. Information Technology Center, Tsinghua University, Beijing 100084, China
全世界共有4 172个数据中心,分布在119个国家[1]。这些数据中心之间通过高速的网络相互连接,提供有保障的数据传输服务。
为了提供高效的数据传输服务,越来越多的应用[2-3]构建在数据中心网络之上,它们通过构建覆盖网络来优化数据的传输路径[4-6]。覆盖网络由于其可以在现有网络的架构上叠加虚拟化技术,因而可以在对基础网络不进行大规模的修改下,实现应用在网络上的承载,并能与其他网络业务分离。
SDN(software defined networking)[7]技术是一种新型网络创新架构,是网络虚拟化的一种实现方式,其核心技术OpenFlow通过将网络设备控制面与数据面分离开来,从而实现了网络流量的灵活控制,使网络作为管道变得更加智能。
随着SDN技术的发展,越来越多的研究开始利用SDN技术构建数据传输的覆盖网络。其中一部分研究集中在如何构建高效的覆盖网络路由器领域。
OOR(open overlay router)[8]是一款基于SDN的开源的覆盖网络路由器,旨在实现一款能够灵活、模块化的可编程覆盖网络路由器。
OOR具备以下3个特点:1) OOR实现了一套基于SDN的覆盖网络路由器,控制协议使用NETCONF/YANG模型;2)在数据平面它使用LISP协议搭建传输隧道;3)为了实现搭建私网IP与公网IP之间的传输隧道,它需要把传输路径上的路由器做配置上的修改,并提供了一款修改后的OpenWRT路由器操作系统来方便部署搭建。OOR为了实现私网IP与公网IP之间隧道的搭建,需要修改路由器的配置,这无形中增加了OOR的部署成本。
为了解决上述问题,本文提出一种覆盖网络路由器软件(software overlay router,SOR),具备如下4个特点。
1) SOR完全构建在开源软件的基础上,极大地降低了路由器的开发成本;这些开源软件已经被很多公司应用到生产环境中,具备很高的稳定性,从而降低了路由器的维护成本。
2) SOR支持OpenFlow协议作为控制协议,能够提供精确到Flow级别(IP报文的五元组)的调度控制,增加了流量控制的灵活性。
3) SOR支持构建多种隧道协议,包括传统的GRE和VXLAN隧道;同时为了满足私网节点与公网节点建立隧道的需求,SOR引入基于TCP的VPN隧道,从而不需要对其他路由器做任何修改,极大地降低了部署成本。
4) SOR支持多种隧道协议,能够根据网络环境更加充分地利用链路资源。
在SOR基础上,本文提出了多种隧道间的流量调度(traffic engineering of multi tunnels,TEOFMT)算法,通过下发OpenFlow流表的方式实现对流量在不同隧道间传输的灵活控制。整个设计构建在SDN技术基础之上,SOR位于数据平面,TEOFMT则工作于控制平面。
1 覆盖网络路由器设计为了便于大规模部署覆盖网络路由器,需要考虑以下3方面的内容。
1) 高效性。不同协议的报文在同一条链路传输所能达到的最大速率不同,比如TCP报文能够更加充分的利用链路的可用带宽。因此覆盖网络路由器要能够建立多种类型的隧道,并根据链路带宽创建能够最大化利用链路带宽资源的隧道类型。
2) 可用性。目前广泛使用的隧道协议包括GRE和VXLAN等,它们都需要隧道两端的节点具备公网IP地址,但是网络运营商出于安全和地址复用的原因,通常会在用户的接入网络侧做地址翻译(network address translation)。只具备私网IP地址的节点无法与公网IP地址节点建立传统的GRE和VXLAN隧道。因此覆盖网络路由器需要能够满足私网IP节点与公网IP节点建立隧道的场景。
3) 可扩展性。覆盖网络路由器可能同时与若干个其他覆盖网络路由器建立不同种类的隧道,迫切需要一种能够灵活地调度流量在不同种类隧道之间传输的算法。
1.1 隧道类型的选择GRE和VXLAN是目前互联网广泛使用的隧道协议。其中GRE属于点对点隧道协议,而VXLAN则是将待传输的报文作为UDP协议的负载进行传输,但是存在以下2个问题:
1) 由于点对点协议以及UDP协议中没有考虑到链路的性能参数,所以GRE和VXLAN隧道协议都无法充分利用链路的带宽资源;
2) GRE和VXLAN协议要求两端节点必须具备公网IP,而目前绝大多数用户都位于NAT后,使得2种隧道协议的应用场景受到一定的限制。
为了解决上述2个问题,本文引入基于TCP协议的OpenVPN隧道。首先,TCP协议有流量拥塞的控制算法,能够充分的利用链路的可用带宽;其次,OpenVPN支持私网IP节点主动与公网IP节点建立隧道链接,适用于节点只具备私网IP的场景。
由于使用VXLAN和GRE在2个具备公网IP的节点间建立隧道,为了确保安全,本文将覆盖网络路由器部署在防火墙之后,防火墙的功能是过滤来自非覆盖网络路由器的VXLAN和GRE流量。OpenVPN基于TLS加密,并使用CA验证,同时防火墙的引入进一步提高了OpenVPN隧道的安全性。
因此,覆盖网络路由器应该具备建立GRE、VXLAN、OpenVPN 3种隧道协议的功能。
1.2 覆盖网络路由器架构本文有专门的测量程序采集链路的网络性能参数,而覆盖网络路由器只专注于流量在隧道间的转发,这完全符合SDN的设计思想,其中覆盖网络路由器位于数据转发平面。
开源软件交换机Open vSwitch[9]目前被广泛应用于数据中心的流量调度系统中,它支持OpenFlow协议下发流表来控制流量在GRE和VXLAN隧道之间的转发,但是OpenVPN[10]隧道不支持OpenFlow协议,所以无法直接通过OpenFlow协议来控制流量在OpenVPN和GRE、OpenVPN和VXLAN之间进行中转。
为了解决上述问题,本文提出了图 1所示的覆盖网络路由器的架构图。如前所述,每个覆盖网络路由器能够与其他路由器之间建立GRE、VXLAN和OpenVPN 3种隧道,并通过预先配置的内核路由表来实现流量在不同隧道之间的调度。
但是简单的使用内核路由表实现隧道间流量调度存在可扩展性的问题。首先,网络请求报文的目的IP众多,即使按照全球BGP路由表公布的地址前缀来进行聚类依然有659 000个[11],不可能为每一个IP地址前缀都配置一条内核路由表;其次,网络请求的目的IP是动态变化的,而且相同目的IP的报文在不同时间可能需要通过不同类型的隧道进行传输,满足这一需求需要动态的修改内核路由表,这无疑增加了路由器设计的复杂度。
1.3 专用IP为了解决内核路由表可扩展性的问题,本文引入专用IP的概念。为每一个种类的隧道事先分配一个IP网段,并称这个网段为专用IP。
覆盖网络路由器需要创建3种类型的隧道,因此需要为它们分别分配一个专用IP,并预先配置在内核路由表中。本文只需要在内核中配置3条静态的路由表,就能完美地解决IP地址前缀数以万计的问题。当流量需要经过某一种隧道进行转发时,只需要将报文的目的IP修改为该种类型隧道的专用IP,即可完美地解决目的IP动态变化的问题。
1.4 覆盖网络路由器的实现本文在树莓派3代B型以及亚马逊AWS EC2虚拟机中成功搭建了覆盖网络路由器,以此证明覆盖网络路由器大规模部署的可行性。
覆盖网络路由器由多种开源软件构成。表 1列举了覆盖网络路由器搭建过程中使用的软件列表以及相应的版本信息。
其中Open vSwitch软件交换机用来搭建GRE和VXLAN隧道,OpenVPN则用来搭建TCP协议的VPN隧道,两者共同构成了流量转发的数据平面。
本文使用RYU[12]作为覆盖网络路由器的中心控制器,通过下发OpenFlow流表的方式控制流量在隧道间转发。
关于专用IP的选择,为了避免与常用的私网IP地址段(10/8、176.16/12、192.168/16)冲突,同时避免使用公网IP地址段造成IP的浪费,本文使用100.64/10保留地址作为专用IP的地址分配池,只需要保证同一个SOR内不同隧道分配的专用IP不同,即可同时在控制器中进行配置,进一步增加了SOR的可用性及可扩展性。比如可以配置目的IP为100.64.0.0/24、100.64.1.0/24、100.64.2.0/24的报文,分别通过GRE、VXLAN和OpenVPN隧道进行转发。
2 流量调度算法设计节1介绍了覆盖网络路由器的具体设计,并利用预先配置的专用IP内核路由表实现多种隧道间流量的灵活调度。通过修改报文的目的IP达到流量转发的目的,但是如果报文转发后不经处理,报文是无法到达正确的目的地的。
为了实现正确转发报文的目的,本文提出了TEOFMT算法,如图 2所示。
TEOFMT算法的核心思想是要在隧道的对端复原修改后的报文,为此需要在控制器中维护一张报文的四元组映射关系表,如表 2所示。
当节点A想要向节点B通过隧道T发送流量时,只需要将报文的目的IP修改为节点A为隧道T分配的专用IP,目的端口修改为节点A的全局唯一端口,这样修改后的报文通过查找内核路由表后就会通过隧道T转发出去。节点B根据控制器中维护的报文四元组映射表就可以将报文复原。如果报文需要在节点B的隧道间进行转发,那么继续按照TEOFMT算法向节点B下发相应的流表。
由于TEOFMT算法需要在控制器中维护一张TCP/UDP报文的四元组映射关系表,因此被称为有状态的流量调度算法。
3 实验验证 3.1 实验环境拓扑图为了测试TEOFMT算法的可用性以及流量转发效率,本文搭建了图 3所示的实验环境:
1) 在北京A、北京B和天津C中安装OpenVPN和Open vSwitch;
2) 北京A创建一个网段为10.213.204.96/29的子网,同时与北京B建立基于Open vSwitch的GRE隧道;
3) 在北京B和天津C之间建立基于TCP协议的OpenVPN隧道;
4) 天津C对来自OpenVPN隧道的报文执行SNAT翻译后转发;
5) 在北京B中配置如表 3所示的内核路由表。
3.2 基于DVTS的应用测试
本文使用DVTS[13]视频会议系统来测试TEOFMT算法的可用性,并将视频传输时链路的丢包率作为衡量视频会议质量的指标。本文使用DVTS-SASM[14]软件来测量链路的丢包率。
DVTS-SASM通过发送载有DV数据的RTP协议报文来模拟DVTS视频流,Server端将接收到的视频流转发给Client,Client端将接收和发送的视频数据做对比来计算双向链路的丢包率。在使用DVTS-SASM测量链路丢包率时,Client端采用随机端口,Server端使用8000端口。
TEOFMT算法在A、B、C节点中安装的OpenFlow流表如图 4和5所示,以实现Client与Server的端到端流量互通。
利用DVTS-SASM测量Client与Server之间每个小时的覆盖网络链路丢包率,一天的测量结果如图 6所示。从测量结果可以看出,即使是发送30 Mbps大小的视频流,链路的丢包率依然为0。测试结果表明TEOFMT算法具备高可用性,并能够满足网络应用对数据传输的需求。
3.3 基于iPerf的带宽测试
覆盖网络通常使用TCP、GRE、VXLAN 3种协议来创建隧道,同一条链路对这3种隧道类型的速率限制也不尽相同。在实验环境中,A和B由于都位于中国教育网(CERNET)北京的数据中心里,所以两者之间的链路带宽不是整个实验网络的瓶颈,相反C的出口带宽只有100 Mbps,会对整个链路的带宽造成很大的影响。
图 7展示了一天内B与C之间的链路基于3种不同的隧道协议VXLAN(UDP)、OpenVPN(TCP)和GRE的链路带宽的平均值以及偏差的对比情况。从测量结果可以看出基于TCP协议的隧道能够更加充分地利用网络带宽资源。在不建立覆盖网络的情况下,B与C之间的链路无法提供DVTS视频会议所要求的30 Mbps的传输带宽。
本文利用iPerf测量工具测量Client与Server之间链路在覆盖网络存在条件下的UDP带宽,具体的测量算法如图 8所示。
图 9是iPerf工具的带宽测量结果。当B和C之间建立TCP协议的隧道后,Client和Server之间的链路带宽能够稳定在70 Mbps左右,完全可以满足DVTS视频流30 Mbps的带宽需求。测量结果表明如果选择合适的协议来建立隧道,并利用TEOFMT算法进行不同隧道间的流量调度,能够极大地提高链路资源的利用率。
4 结论
本文首先提出了一种基于SDN的SOR的设计,构建在开源软件基础上,既能满足私网节点与公网节点建立隧道的需求,又具备部署成本低、开发成本低、维护成本低的特点,同时支持多种隧道协议,有助于充分利用网络链路资源。其次,在SOR的基础上提出了一种基于OpenFlow协议的TEOFMT算法。TEOFMT按照其维护的TCP/UDP报文的四元组映射表来修改报文,并最终根据内核路由表将报文转发到相应的隧道中。由于中心控制器使用OpenFlow协议进行流量调度,该算法具备很高的可扩展性。最后,在CERNET的数据中心间搭建了实验环境,利用视频会议系统DVTS验证了算法的高可用性,使用iPerf测量覆盖网络的链路带宽,证明TEOFM算法能够提高网络链路资源的利用率。实验结果表明,本文提出的SOR和TEOFMT算法具备可扩展性和高可用性,能够满足网络应用对数据传输的需求。
[1] | Data Center Map APS. Colocation data centers. [Z/OL]. (2017-08-07). http://www.datacentermap.com/datacenters.html. |
[2] | LIU Y, NIU D, LI B. Delay-optimized video traffic routing in software-defined interdatacenter networks[J]. IEEE Transactions on Multimedia, 2016, 18(5): 865–878. DOI:10.1109/TMM.2016.2538718 |
[3] | CHEN F, ZHANG C, WANG F, et al. Cloud-assisted live streaming for crowdsourced multimedia content[J]. Multimedia IEEE Transactions on, 2015, 17(9): 1471–1483. DOI:10.1109/TMM.2015.2460193 |
[4] | IZARD R, WANG Q, KRIBBS B, et al. OpenFlow-based live video streaming with GENI cinema[C]//IEEE Conference on Computer Communications Workshops. San Francisco, CA, USA: IEEE, 2016: 1039-1040. |
[5] | MCKEOWN N, ANDERSON T, BALAKRISHNAN H, et al. OpenFlow:Enabling innovation in campus networks[J]. Acm Sigcomm Computer Communication Review, 2008, 38(2): 69–74. |
[6] | CAI C X, LE F, SUN X, et al. CRONets: Cloud-routed overlay networks[C]//2016 IEEE 36th International Conference on Distributed Computing Systems (ICDCS). Nara, Japan: IEEE, 2016: 67-77. |
[7] | KAWASHIMA R, MATSUO H. Non-tunneling edge-overlay model using OpenFlow for cloud datacenter networks[C]//2013 IEEE 5th International Conference on Cloud Computing Technology and Science (CloudCom). Bristol, UK: IEEE, 2013, 2: 176-181. |
[8] | ALBERT L, FLORIN C, ALBERTO R, et al. Open overlay router[Z/OL]. (2017-04-12). https://github.com/Open-OverlayRouter/oor. |
[9] | PFAFF B, PETTIT J, KOPONEN T, et al. The design and implementation of open vSwitch[C]//12th USENIX Symposium on Networked Systems Design and Implementation. Oakland, CA, USA: USENIX Association, 2015: 117-130. |
[10] | GERT D, DAVID S, JAMES Y, et al. OpenVPN[Z/OL]. (2017-04-12). https://github.com/OpenVPN/openvpn. |
[11] |
余坤, 包丛笑, 李星.
利用网站服务器测量链路性能[J]. 清华大学学报(自然科学版), 2014, 54(4): 474–479.
YU K, BAO C X, LI X. Internet path performance measurements using web servers[J]. Journal of Tsinghua University (Science and Technology), 2014, 54(4): 474–479. (in Chinese) |
[12] | FUJITA T, YAMAMOTO T, IWASE Y, et al. RYU[Z/OL]. (2017-04-12). https://osrg.github.io/ryu/. |
[13] | OGAWA A, KOBAYASKI K, SUGIURA K, et al. Design and implementation of DV based video over RTP[C]//10th International Packet Video Workshop. Cagliari, Italy: University of Cagliari, 2000. |
[14] | BAO C X, LI X, JIANG J P, et al. Scalable application-specific measurement framework for high performance network video[C]//17th International Workshop on Network and Operating Systems Support for Digital Audio & Video. Urbana-Champaign, IL, USA: ACM, 2007: 87-92. |