ONOS性能技术白皮书(Black Bird)

本白皮列举了构建电信级SDN控制平面所面临的各种挑战,提供了一套有效的电信级符合度衡量指标,并介绍了如何使用这些指标来衡量ONOS Black Bird版本能否提供电信级可靠性。本文档的读者对象需要具备一定的技术背景。

SDN的价值

SDN之所以能成为业界最热门的话题之一,背后是有原因的。 SDN实现了数据平面与控制平面的分离,把专用的封闭式设备的功能分解成了SDN控制平面(SDN网络操作系统)、数据平面、应用程序和服务。SDN控制平面就像大脑,通过各类抽象、API和协议来支撑不同的应用,实现对网络的控制、配置和管理。

SDN不仅支持网络集中控制,同时还可以提高网络可视性,为用户提供更大的选择空间。SDN可以融合使用不同网络层次的技术,让每个网络层次按照自己的节奏独立发展,从而加速业务创新。对最终用户来说,提高新业务部署效率和降低业务成本是SDN的价值所在。

SDN面临的最大发展障碍之一 ── 低性能

SDN的技术和商业优势已广为人知。Google、Facebook、Microsoft以及其他一些公司已经用自身的成功实践证明了在广域网和数据中心网络场景部署SDN的优势。

要想在运营商网络部署SDN,SDN控制平面1[在本文中,SDN网络操作系统和SDN控制平面可互换使用。]必须具备高性能、可扩展性和高可用性。如何构建一个电信级SDN控制平面来满足这些要求是一个很有挑战性的设计问题,需要对高可用性、性能和规模这三个密切相关的方面进行细致全面的技术分析。事实上,性能低下的SDN控制平面已经成为制约SDN商业部署和应用的瓶颈。

此外,简单的性能指标,如Cbench,不能完整或准确反映网络的性能和扩容能力。我们需要制定一套更完善的指标来衡量电信级符合度,这是本文讨论的重点。通过一种可接受的、分析式的方式来解决规模和性能问题对推动SDN在现网部署有重要意义。

SDN控制平面的性能指标

如果把SDN网络操作系统看作一个黑盒子,以下几项肯定是它的关键性能指标:

  • 拓扑变化时延:该指标用于衡量操作系统对各类拓扑事件,如链路Up/Down、端口Up/Down、交换机添加/删除等事件的反应速度。该指标可以反映集群全网视图状态更新的速度,包括通知应用拓扑发生变化的速度。
  • 拓扑变化吞吐量:该指标用于衡量单位时间内处理拓扑事件的数量。该指标反映了网络拓扑事件(如大量交换机或链路Down)的处理范围和时间,同时它还反映了SDN控制平面可以支持的网络规模。
  • 流创建吞吐量:该指标用于衡量操作系统可根据应用请求或网络事件触发创建的流的数目。
  • 北向时延:该指标用于衡量操作系统响应应用请求和网络事件的速度。
  • 北向吞吐量:该指标用于衡量操作系统处理持续增长的应用请求的能力,以及支持的最大负载。

很难确定什么样的指标值才能达到运营商网络的要求。运营商也是最近才开始在实验室中开展SDN试验,目前还没有太多关于现网需求的数据。在不能确保SDN控制平面具备高性能、电信级可靠性的情况下,运营商不会贸然在现网部署SDN。

我们首先要做的就是确定需要实现哪些初始目标才能满足运营商网络对性能指标的要求。通过和运营商密切合作,我们设定了以下目标作为初始目标:

  • 流创建吞吐量达到100万条/秒。
  • 拓扑变化时延和北向时延小于100毫秒 (理想值为10毫秒或更低)。

吞吐量总是越高越好,时延总是越低越好。吞吐量越高、时延越低,SDN控制平面可以支持的应用和功能类型就越多。但是,我们必须确定一个基线──基于这个基线,SDN控制平面可以提供和现有分布式控制平面类似的性能。

可扩展性

SDN带来的好处之一是把所有网络状态聚合到一个集中的位置,让服务提供商能够实例化各种使用这些状态的新业务。随着时间的推移,服务供应商收集的实时网络状态越来越多,使用这些状态的应用也越来越多。这就意味着,服务提供商要能够对SDN控制平面进行扩容,增加其吞吐量,同时保持其低时延,并保证全网视图的准确性。理想情况下,我们可以简单地通过向集群添加更多计算资源(如CPU和存储器)来对SDN网络操作系统进行扩容。这种增量扩容能力是非常重要的,它让服务提供商能够提供面向未来的网络,通过有效扩容应对需求增长。

一个SDN操作系统的可扩展性可以定义为该系统通过无缝提高控制平面容量(集群中的服务器)来增加SDN操作系统吞吐量的能力。扩容后,SDN操作系统继续保持低时延(甚至比扩容前更低),同时还维护着一张集中的逻辑网络视图。
接下来的问题是──如何衡量SDN操作系统的可扩展性?这里有两个关键指标:

  • 添加新的服务器后,吞吐量上升
  • 添加新的服务器后,时延保持不变或下降

高可用性

高可用性是部署SDN到服务提供商网络的先决条件。虽然我们可以通过添加新的服务器来实现SDN控制平面扩容,我们仍然需要依赖SDN控制平面的自愈能力来应对单服务器故障。我们需要在不影响整体系统运行的情况下进行软件和硬件升级。
评估分布式SDN控制平面自愈能力的方法之一是模拟故障并观察系统如何应对。当具备高可用性的操作系统发生故障时,我们期望看到以下结果:

  • 冗余保护措施自动生效,业务不中断。
  • 系统性能正常,和系统当前可处理的资源数目成正比。
  • 系统自愈后,实例重新上线,系统自动平衡工作负载。

构建电信级SDN控制平面所面临的挑战

无论构建什么样的分布式系统,我们都需要确保所有实例作为单一逻辑体运行。复杂的实现细节──如状态是如何管理的、协同是如何实现的,应通过简单易懂的抽象进行屏蔽,让上层应用无法感知。ONOS引入的一个很重要的抽象就是全网视图。清晰准确的全网视图大大简化了网络控制实现。例如,过去需要引入诸如OSPF之类的分布式路由协议才能实现的用例现在只需要在网络视图上应用简单的最短路径算法即可实现。

为什么简单的方法不能用

本节探讨在分布式SDN控制平面维护一张准确且一致的网络视图所面临的关键挑战。按理说这些问题不会在单实例控制器中存在。

单实例控制器不仅可以提供整网视图,还可以根据网络变化实时更新整网视图。此外,单实例控制器还能以很小的开销把整网视图发送给各应用──因为相关状态可以在本地进行维护。但这种简化是以网络可用性和规模为代价的。一旦控制器故障,网络控制立即瘫痪。部署控制器热备可以在一定程度上缓解可用性问题:当主用控制器故障时,备用控制器可以立即接管控制。但是,每个控制器实例都必须能够独立管理整个网络、支撑所有网络监控和编程应用。随着网络规模持续扩大和网络控制应用不断增多,现有解决方案终将无法应对,我们需要真正的网络扩容方案。

构建可扩展的SDN控制平面的方法之一是运行多个控制器实例,让每个实例只控制整网的一部分。当网络规模扩大时,我们只需要简单地添加新的控制器实例。此外,如果一个控制器实例发生故障,其他正在运行的控制器实例会自动接管该控制器实例所管理的网络,确保网络控制不中断。

但这种简单直接的解决方案又引入了新的问题,且大多数问题都与如何有效地管理状态有关。在一个分布式环境中,每个控制器实例只维护自己所控制的网络分片的视图。为了实现全网视图抽象,控制平面需要根据零散的网络分片视图拼出准确的整网视图,并把整网视图以最小的开销发送给各应用。另外,当底层网络变化时,控制平面要能及时更新整网视图,确保该视图与底层网络状态一致。

除了整网视图状态,控制平面还需要跟踪各类控制平面相关的状态,并确保这些状态能够为各类应用所用。这些状态包括应用意图、流、流统计数据、资源分配、网络策略信息、交换机到控制器的映射、其它网络控制应用特定状态。每个状态都有自己独特的一致性语义、读写模式、位置限制和耐用性预期。一个好的SDN控制平面架构必须能够满足这些独特的状态管理需求,同时又兼顾到性能和可扩展性。

分布式SDN控制器常见的做法是利用一个集中的数据存储来管理各类状态。数据存储本身具有冗余保护机制。这种方法看似合理,但其实有诸多问题,这点我们在进行ONOS研究和原型设计时深有体会。

一致性还是可用性

首先,分布式数据存储采用的要么是高可用性架构,要么是强一致性架构。在网络分片场景下,要么选择强一致性,接受更新不可用的风险;要么选择高可用性,接受系统状态与实际状态不一致的可能性。任何分布式状态管理系统都会面临这个基本的权衡。数据存储的选择对整个系统的行为和性能有显著影响。如前所述,SDN控制平面有必要管理不同类型的状态,但不是所有状态都需要强一致性和高可用性。如果我们把所有状态存放在采用了高可用性或强一致性架构的数据存储中,其结果要么是系统性能欠佳,要么是更糟的情况──系统根本无法正常运行。

性能

集中式数据存储面临的另一个挑战是控制器实例可用的本地状态极少。对于有些需要频繁使用的状态,如全网视图,频繁访问集中数据存储来获取数据会严重限制系统性能。引入缓存并没有真正解决这个问题,因为引入缓存后,我们还需要考虑如何保持本地缓存与数据存储之间的一致性性。

扩容的挑战

构建具备强一致性和扩容能力的分布式数据存储没那么简单。目前一些商用的开源解决方案要么牺牲一致性来换取可用性(如Cassandra),要么虽然保持了强一致性,但无法在不影响吞吐量的情况下进行扩容(如Zookeeper)。

要构建具备高可用性和无缝扩展能力的高性能SDN控制平面,我们不得不采用一些状态管理解决方案,确保控制平面中各类状态的特殊需求得到满足。

ONOS如何应对高性能、可扩展性和高可用性需求

ONOS是一个可扩展的分布式系统,采用自下而上的设计,通过提供一组简单而强大的分布式状态管理原语来实现SDN控制平面的高性能和高可用性目标。

ONOS会考虑每类控制平面状态的独特属性,并基于这些属性为各类状态提供语义和性能最佳的解决方案。

ONOS采用控制器实例集群来管理网络。当网络规模扩大或网络控制应用程序增多推动SDN控制平面需求增长时,我们可以通过添加新的商用服务器来扩容控制器集群。扩容后,ONOS自动向新添加的控制器实例分配部分工作负载。从架构的角度看,ONOS集群规模不存在根本性的限制,ONOS集群可以无缝扩展,支撑快速发展的网络。

高可用性对ONOS架构至关重要。每个关键的控制平面功能都设计了保护机制。当一个实例发生故障时,其他实例自动接管该实例下的业务,确保业务不中断。故障倒换语义是内置到软件中的,无需人工干预。此外,ONOS上运行的应用可以利用该系统的可用性构件来提供永久在线(always-on)体验。

ONOS没有采用集中的数据存储来管理所有状态,相反,ONOS采用了一组状态管理构件来管理相关的控制平面状态。分布式状态管理是ONOS与其他分布式SDN控制器的主要区别。

最终一致性

整网视图需要频繁读取,要想实现高性能,必须要把读取开销降到最低。然而,仅仅在本地缓存这种状态的办法并不可取,可能会出现缓存状态与实际网络状态不一致的问题。

ONOS采用了一种很新颖的方式来解决这个问题。ONOS把全网视图看作一个状态机,网络事件依次获取状态信息。为了保证快速状态访问,每个控制器实例都在内存上维护一份全网视图状态机副本。一旦在数据平面检测到网络事件,ONOS立即通过逻辑时钟给这些网络事件打上时间戳,并在整个控制平面广播这些网络事件。每个控制器实例单独更新自己的全网视图状态机副本,通过逻辑时间戳来判断并丢弃乱序的网络事件。同时,ONOS后台会周期性运行一个轻量级任务来检测和同步处于异步状态的全网视图状态机副本,确保这些状态机副本与实际物理网络状态一致,这个过程被称为逆商(anti-entropy)。

ONOS的实践表明,这种简单的方法可以很好地确保状态的最终一致性。这里只是以全网视图为例来说明如何确保状态的最终一致性。通过该方法,ONOS可以快速检测和应对各类网络事件。此外,该方法还可以很好地应用于其他场景(如数据源位于控制器外部或一个状态被分割成多份,而每次只允许一个单实例对数据进行操作)。ONOS管理所有意图相关的信息时也是用的这种最终一致性数据存储抽象。

强一致性

最终一致性方案可以很好地应用于全网视图及意图相关状态,但这个方案对需要强一致性的用例并不适用。以交换机到控制器的映射为例。ONOS需要确保在任何时间都有一台控制器充当交换机的控制设备。这条交换机到控制器的映射信息需要在各个控制器实例之间保持强一致性,即,所有控制器实例均认可交换机当前的控制设备。最终一致性方案显然不适用这个特殊的场景。需要强一致性的另一个控制平面状态是跟踪网络资源分配的状态,如“应用X给链路L1分配了10G带宽”。ONOS需要提供事务语义用于状态更新,这点非常重要。最终一致性方案显然不适合这种场景。

扩容问题是建立强一致性数据存储时经常遇到的一个问题。由于集群规模越大,协调开销越大,强一致数据存储的吞吐量与集群大小通常并不呈正比。通过把大块数据存储分割成小单元,ONOS提供了一个很好的解决这个问题的办法。每个单元,或者说分片,负责管理一个关键空间分区。每个分片同时归属到三台控制器,确保高可用性。复制状态机(RSM)通过强一致性方案协调各分片的更新信息。分片RSM的完整性通过RAFT共识算法来维护。利用这种方法,我们只需要添加新的服务器就可进行扩容。扩容后ONOS会重新平衡分片的分布情况,把部分分片归属到新添加的控制器实例。

面向应用开发者的状态管理构件

ONOS可以把核心状态管理构件转化成简单的抽象开放给外界,方便上层应用开发,这是ONOS特有的功能。应用开发人员可以只专注于自己想表达的核心业务逻辑,不必担心状态分布的复杂细节。
本文目录:

PDF下载地址:http://pan.baidu.com/s/1c1IqmJ2


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/17115.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于16-06-15
0