3、设计

这一章我们描述软件定义广域网架构的细节。

3.1、概述

我们的软件定义网络从逻辑上可以看做三层,如图所示,

B4服务于多个广域网节点,每个节点都有很多服务器集群。在每个B4节点内,交换机硬件层主要用来转发数据,不运行复杂的控制软件,站点控制层包括网络控制服务器,托管OpenFlow控制器和网络控制应用。

这些服务器支持分布式路由和流量工程作为路由覆盖。OpenFlow控制器根据网络控制应用指令和切换时间,并指示交换机根据此变化的网络状态设置转发条目数。对于单个服务器和控制进程的错误容忍度。Paxos的每个站点实例选择多个可用软件副本中的一个作为主要实例。

全局层由逻辑上的中心的应用(包括SDN Gateway和中心TE服务器)组成,通过站点级网络控制应用实现对整个网络的控制。SDN网关将中央TE服务器的OpenFlow细节和硬件交换。我们使用独立的领导者选举在多个广域网站点上复制全局层应用程序,用以设置主领导者。

我们网络中的每个服务器集群都是一个具有一组IP前缀的逻辑“自治系统”(AS)。每个集群包含一组BGP路由器(在Fig.2中没有表示)路由器与每个广域网站点的B4交换机对等。即使在引入SDN之前,我们也运行B4作为一个单一的自治系统,提供运行传统BGP/ISIS网络协议的集群之间的传输。我们之所以选择BGP是因为它在域之间的隔离性和操作员对协议的熟悉程度。基于SDN的B4必须支持现有的分布式路由协议,以实现与非SDN广域网实施的互操作性,并逐步推出。

我们考虑了将现有路由歇息与集中式流量工程集成的一些选择。以积极地方式,我们将建立一个综合的,集中地服务,结合路由(例如,ISIS功能)和传输工程。我们选择将路由和流量工程部署为独立的服务,最初部署标准路由服务,随后部署中央TE作为覆盖。这种分离提供了许多好处。它使我们能够专注于构建SDN基础架构的初始工作,例如OFC和代理,路由等。而且,由于我们最初部署了我们的网络,没有像TE这样的新的外部课件功能,因此在尝试实现诸如TE之类的心功能之前,给了开发和调试SDN架构的时间。

也许最重要的是,我们使用有线交换转发表条目在基线路由协议纸上分层传输工程。这种隔离给了我们的网络一个“大红按钮”;面对流量工程,我们可以禁用该服务并回退到最短路径转发。这种故障恢复机制已被证明是非常宝贵的(第六节)。

每个B4站点由多个交换机组成,可能有数百个单独的端口连接到远程站点。为了扩展,TE将每个站点抽象为具有给定容量的单个边缘的单个节点到每个远程站点。为了实现这种拓扑抽象,所有跨站点到站点边界的流量必须均匀分布在所有组成的链路上。B4路由器使用ECMP三列的自定义辩题来实现必要的负载均衡。

在剩余的章节里面,我们描述了如何将在单独的控制服务器上运行的现有路由协议与支持OpenFlow的硬件交换机集成在一起。第四节我们描述了如何在这个基线路由实现纸上分层TE。

3.2、交换机设计

传统的观点认为,广域路由器必须具有深度的buffers,非常大的转发表以及对高可用性的硬件支持。所有这些功能增加了硬件成本和复杂性。我们假设,通过仔细的断电管理,我们可以调整传输速率,来避免较高的丢包率。此外,我们的交换机运行在相对较小的一组数据中心,所以我们不需要大的转发表。最后,我们发现交换故障通常是由软件产生的,而不是硬件的问题。通过移动交换机硬件上的大多数软件功能,我们可以通过现有分布式系统广泛采用的已知技术来管理这种软件容错。

即便如此,我们选择构建自己的硬件的主要原因是,现有的平台无法支持SDN部署,即可以导出对交换机转发行为的低级控制。使用定制交换机硬件所带来的二外成本不仅仅是通过支持注入集中式TE之类的新型服务所带来的效率提升来偿还的。考虑到各个站点所需的带宽,我们需要一个高基数交换机;部署更少,更大的交换机将产生管理和软件可扩展性的好处。

为了扩大单个家还击芯片的容量,我们在铜底板的两个阶段Clos拓扑中构建了多个商用硅交换机芯片的B4交换机。下图展示了使用24个独立的16*10GE非阻塞交换机芯片组成的128端口的10GE交换机。我们确定每个入口芯片将输入数据包弹回到spine干层,除非目的地在同一入口芯片上。这些spine芯片根据书籍报的目的地将数据包转发到适当的输出芯片。

交换机包含一个运行Linux的嵌入式处理器。最初,我们直接在交换机上运行所有路由协议。我们可以吧交换机放到一系列现有的部署中来获得硬件和软件的使用经验。接下来,我们开发了一个OpenFlow代理(OFA),一个用户级的进程运行在我们的交换机硬件上实现了OpenFlow协议的稍微扩展版本,以利用我们交换机的硬件流水线。OpenFlow代理连接一个远程的OpenFlow控制器,接受OpenFlow(OF)命令并将适当的分组和转发事件转发给OpenFlow控制器。例如,我们配置硬件交换机将路由协议数据包转发到这个路径。

OpenFlow代理收到例如BGP数据包,并将它们转发给OpenFlow控制器,然后OpenFlow控制器将它们传递给我们的BGP堆栈。

OpenFlow代理将OpenFlow消息转换为驱动程序命令来设置芯片转发表项。这里有两个挑战。第一,我们必须在OpenFlow架构中立版本的转发表条目和现代商业交换芯片的复杂包处理流水线之间架起一座桥梁,这个流水线拥有许多链接不同大小和语义的转发表。OpenFlow代理将转发状态的高级视图转换为底层硬件的高校映射规范。第二,OpenFlow代理导出一个带有几百个10Gb/s端口的单个无阻塞交换机的抽象。然而,底层交换机由多个物理交换芯片组成,每个物理交换芯片都具有单独管理的转发表项。

3.3、网络控制功能

大多数B4功能都在位于交换机硬件上的站点控制层的网络控制服务器上。网络控制服务器和交换机共享一个专门的带外控制平面网络。

Paxos为所有控制功能处理领导选举。每个站点上的Paxos实例在预先配置好的一组可用副本之间执行应用程序级别的故障检测,以实现给定的控制功能。当大多数Paxos服务器检测到故障时,他们会在剩余的可用服务器组中选择出新的领导者。然后Paxos以单调递增的新ID向选举的领导者提供回叫。领导者使用这新的ID来明确的向客户表明自己的身份。

我们使用修改版本的Onix来控制OpenFlow。从这项工作的角度来看,OpenFlow控制器最有趣的方面就是网络信息库(NIB)。网络信息库包括网络的当前拓扑,中继线配置和链路状态(运行,消耗等)状态。OpenFlow 控制器是热备用。虽然OpenFlow代理保持与多个OpenFlow控制器的有效连接,但是一次只有一个OpenFlow控制器通信是活动的,并且对于给定的一组交换机,只有一个OpenFlow控制器保持状态。在启动或者新领导选举时,OpenFlow控制器从本地配置读取网络的预期静态状态,然后与各个交换机同步以获得动态网络状态。

3.4、路由

B4网络的一个主要挑战是整合基于OpenFlow的交换机控制和当前现存的路由协议来支持混合的网络部署。为了集中注意力于OpenFlow或者SDN,我们在网络控制服务器上为BGP/ISIS选择开源的Quagga栈。我们写了一个Routing Application Proxy(RAP)作为SDN应用,来提供Quagga和OpenFlow交换机的连接。RAP负责三件事:(1)BGP/ISIS的路由更新(2)交换机和Quagga的路由协议包流(3)从交换机到Quagga的接口更新。

下图简要描述这个整合。

4、流量工程

流量工程的目标是在可能使用多个路径的竞争应用程序之间共享带宽。我们系统的目标功能是为应用程序提供最大最小公平分配。一个最大最小公平的解决方案最大限度的利用利用率,只要进一步的利用手艺不是惩罚公平份额的应用。

4.1、集中式流量工程架构

下图表示了我们流量工程的架构。

流量工程服务器按照下面状态来操作:

网络拓扑图将站点表示为顶点,将站点到站点连接表示为边缘。SDN网关将来自多个站点和各个交换机的拓扑事件合并为流量工程。流量工程聚合中级来计算站点边缘。这种抽象显著减少了流量工程优化算法输入图的大小。

流组(FG):对于可扩展性,流量工程不能以单个应用程序的粒度进行操作。因此,我们将应用程序集合到一个流组中,定义为{源站点,目标站点,QoS}元组。

一个隧道(Tunnel)表示网络中的站点级路径,例如站点序列(A->B->C)。B4在IP封装中使用IP实现隧道。

一个隧道组(Tunnel Group)将流组映射到一组隧道和相应的权重。这个权重制定了沿每个隧道转发的流组流量的比例。

流量工程服务器输出隧道组,并通过引用将隧道好流组输出到SDN网关。网关将这些隧道和流组转发给OpenFlow控制器,OpenFlow控制器又将其安装在使用OpenFlow的交换机中。

4.2、带宽函数

为了获得相对优先级,我们将带宽函数与每个应用程序相关联(例如,下图),实际上是应用程序与B4之间的契约。

这个函数指定给与应用程序的带宽分配一个任意的无量纲规模的流量相对优先级,我们称之为公平份额。我们从管理员指定的静态权重(函数的斜率)中指定相关的应用程序优先级。在这个例子中,App1,App2,App3的权重分别为10,1,0.5.带宽函数通过带宽强制器进行配置,测量并提供给流量工程。

每个流组将多个应用程序需求从一个站点复用到另一个站点。因此,流组的带宽函数是每个应用带宽函数的分段线性加法组合。流量工程的最大-最小目标函数就是这个每流组公平份额维度。带宽强制器(Bandwidth Enforcer)还汇总了应用程序的带宽函数。

例如,给定下图

带宽强制器测量在站点A和站点B之间App1的流量是15Gbps,App2的流量是5Gbps。得到如下图的带宽函数。

这里可以看到FG1的函数为:

FG2的函数为:

流组2的带宽函数包含只有App3的10Gbps的流量。我们将测量需求中配置的应用带宽功能进行平滑处理,因为分配测量的需求相当于一个流组接受的无线公平份额。

带宽强制实施器还计算在边缘执行的带宽限制。带宽强制器的细节超出了本文的范围。为了简单起见,我们不进一步讨论流组的QoS方面的内容。

4.3、流量优化算法

在所有流组中分配公平份额的LP最优解决方案是昂贵的,并且不能很好地扩展。因此我们设计了一个算法,实现了相似的公平性和至少99%的带宽利用率,相对于我们部署的LP,性能提高了25倍。

流量工程优化算法有两个主要组成部分:(1)隧道组生成为使用带宽功能的流组分配带宽以优化处理瓶颈;(2)隧道组量化改变每个TG中的分流比以匹配交换机硬件表支持的粒度。

我们通过一个实例来介绍算法是如何操作的:

下图表示了一个包含4个节点的拓扑图,成本是附加到边缘的抽象数量,通常代表边缘延迟。隧道的花费是他的边 的总和。

上图中A->D边的花费期望是1,但是是10,。上图中有两个流组,FG1(A->B)需要20Gbps的流量,FG2(A->C)需要10Gbps流量。

上图中表示这些流组的带宽函数,作为当前测量的需求和配置优先级的函数。

隧道组的生成

隧道组生成根据需求和优先级为FG分配带宽。它根据带宽函数在流组之间分配边缘容量,使得边缘上所有竞争的流组都能获得相等的公平份额或者完全满足其需求。当它填充所有流组时,通过增加他们在其首选隧道上的公平份额来找到瓶颈(以最小的公平份额)。流组的首选隧道是不包含瓶颈边缘的最小成本路径。

隧道组的生成不会进一步使用瓶颈。所以我们冻结了所有会通过它的隧道。对于所有的流组,我们移动到下一个首选隧道,继续增加流组的公平份额,并找到下一个瓶颈。当每个流组都满足或者我们找不到一个优选的隧道时,算法终止。

我们用T_x^y来表示流组FG_x的第y个最首选的隧道。在我们的例子中,开始时我们分别对流组FG1和流组FG2的首选通道填充:我们通过给每个流组分配平等的公平份额来在流组之间分配带宽。在公平份额为0.9时,通过带宽函数给流组GF1分配10Gbps,流组FG2分配0.45Gbps。在这种情况下,边A->B变满了,也就是成为瓶颈了。这使得T_1^1变成自由状态。算法继续分配带宽到流组FG1上,它的下个首选隧道是。公平份额是3.33,流组FG1多收到8.33Gbps流量流组FG2多收到1.22Gbps流量,使A->C成为下一个瓶颈。流组FG1现在必须强制下一个首选隧道,流组FG2也强制实行第二次首选通道。流组FG1多收到1.67Gbps的流量,变成满的状态。流组2收到剩余的3.33Gbps流量。

流组FG2的两个隧道比是1.67:3.33(约等于0.3:0.7,正则化所以他们的和为1)。分配到流组FG1的三个隧道的比值为10:8.33:1.67(约等于0.5:0.4:0.1)流组2分配的平均份额是10,流组FG1分配的平均份额是无穷因为它是满的状态。

我自己根据理解画出如下图:

在公平份额为0.9时流量分配如下:

这个时候A->B就满了。然后在公平份额为3.33时,流量如下图:

这个时候可以看到A->C这条线路满了,然后下一步的流图如下:

这个时候可以看到C->B也满了。

隧道组量化

隧道组量化将分割调整为底层硬件支持的粒度,相当于解决整数线性规划问题。鉴于确定最佳分割量化的复杂性,我们再次使用贪婪方法。我们的算法使用启发式算法来保持公平性和吞吐效率,与理想的非量化隧道组相当。

回到我们的例子,我们将上面的分配分成0.5的倍数。我们从FG2开始,我们把它的分化比率减到0.0:0.5.我们需要在两个隧道中的一个上添加0.5来完成量化。在T_2^1上增加0.5来减少流组FG1低于5,让这个方法不那么最大最小均衡。然而,在T_2^2上增加0.5使得流组FG1满了,而且把流组FG2的公平份额到达10。因此,我们计算流组FG2新的比例为0:1,相似的,我们计算流组FG1的比例为0.5:0.5:0。这些隧道组就是就是流量工程算法的最后输出。注意,具有较高带宽功能的流组如何将具有较低带宽功能的流组推向较长和较低容量的隧道。

5、流量工程协议和OpenFlow协议

5.1、流量工程状态和OpenFlow

原站点交换机实现流组。当交换机的目的IP地址与流组相关的前缀之一匹配时,交换机将数据包映射到流组上。与流组匹配的入包通过相应的隧道组转发。每个输入数据包以期望的比例三列到与隧道组相关联的隧道之一。隧道路径中的每个站点都维护每个隧道的转发规则。原站点交换机封装数据包是包含IP地址,IP地址能唯一标识隧道。外部目标IP地址是隧道ID而不是实际目标地址。流量工程预配置封装交换机中的表以创建正确的封装,传输站点交换机中的表根据其隧道ID正确转发数据包,并对站点交换机进行解封装,以识别哪些隧道ID应该终止。因此,安装隧道需要在多个站点配置交换机。

5.2、例子

最新文章

  1. Paths_Quartz2D
  2. 使用AOP 实现多数据源 切换
  3. CSS Hack大全-教你如何区分出IE6-IE10、FireFox、Chrome、Opera
  4. 无责任Windows Azure SDK .NET开发入门篇三[使用Azure AD 管理用户信息--3.4 Edit修改用户信息]
  5. POI2001 Gold mine(二叉排序树 黑书经典)
  6. Java 简单算法--排序
  7. web服务器决定支持多少人同时在线的因素
  8. RFID电子标签加工的倒装工艺
  9. 定时执行.SH
  10. vty密码登录,到AAA验证登录,以及远程配置网络
  11. jasperreports+IReport 5.56,集成到Spring MVC4.0案例
  12. 关于springboot2.x 的 RedisCacheManager变化
  13. Docker Macvlan 应用部署
  14. C++中多维数组传递参数
  15. 《深入理解Java虚拟机》(四)虚拟机性能监控与故障处理工具
  16. JavaScript中给onclick绑定事件后return false遇到的问题
  17. yield表达式形式
  18. Ubuntu16 源码方式安装postgresql数据库
  19. iOS 里RGB 配色 UIColor colorWithRed
  20. Exchange & Office 365最小混合部署

热门文章

  1. MySQL多种安装方式选择
  2. redis实战之事务与持久化
  3. LeetCode 336. Palindrome Pairs
  4. php7 新特性整理
  5. 在装有windows跟ubuntu的机器上重新安装windows后修复ubuntu的grub
  6. mysql之 double write 浅析
  7. xj监控端口,模拟登陆脚本
  8. Hybrid APP混合开发
  9. BMP格式转JPEG格式
  10. POJ3258(最大化最小值)