pFabric:最小的近乎最佳的数据中心传输


背景知识

不论 SDN,NFV 或者其他的虚拟网络技术,网络数据报最终都是跑在物理网络上。物理网络的特性,例如带宽,MTU,延时等,最终直接或者间接决定了虚拟虚拟网络的特性。可以说物理网络决定了虚拟网络的"天花板"。

在对网络性能进行优化时,有些物理网络特性可以通过升级设备或线路来提升,但是有些与网络架构有关。而升级或者改动网络架构带来的风险和成本是巨大的,因此在架设数据中心初始,网络架构的选择和设计尤其需要谨慎。另一方面,在设计虚拟网络时,不可避免的需要考虑实际的物理网络架构,理解物理网络架构对于最终理解虚拟网络是不可缺少的。

CLOS Networking

CLOS 网络的起源是一种用多级设备来实现无阻塞电话交换的方法。

CLOS 网络的核心思想是:用多个小规模、低成本的单元构建复杂,大规模的网络。简单的 CLOS 网络是一个三级互连架构,包含了输入级,中间级,输出级。

下图中,m 是每个子模块的输入端口数,n 是每个子模块的输出端口数,r 是每一级的子模块数,经过合理的重排,只要满足 r2≥max(m1,n3),那么,对于任意的输入到输出,总是能找到一条无阻塞的通路。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DFYhX196-1605673289151)(/Users/limengfan/Note_2020_2/img_network/clos.png)]

Switch Fabric

Switch Fabric 指交换机内部连接输入输出的端口,最简单的 Switch Fabric 架构是 Crossbar 模型,这是一个开关矩阵,每一个 Crosspoint(交点)都是一个开关,交换机通过控制开关来完成输入到特定输出的转发。一个 Crossbar 模型如下所示:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dt0T95A7-1605673289155)(/Users/limengfan/Note_2020_2/img_network/fabric.png)]

随着网络规模的发展,交换机的端口数量逐渐增多。Crossbar 模型的交换机的开关密度,随着交换机端口数量 N 呈 O(N^2) 增长。相应的功耗,尺寸,成本也急剧增长。在高密度端口的交换机上,继续采用 Crossbar 模型性价比越来越低。

大约在 1990 年代,CLOS 架构被应用到 Switch Fabric。应用 CLOS 架构的交换机的开关密度,与交换机端口数量 N 的关系是 O(N^(3/2)),所以在 N 较大时,CLOS 模型能降低交换机内部的开关密度。这是 CLOS 网络模型的第二次应用。

胖树(Fat-Tree)型网络架构

胖树(Fat-Tree)是一种三级的 CLOS 网络架构,标志着 CLOS 正式进入数据中心网络架构领域,这是 CLOS 网络模型的第三次应用。

当前,Fat-Tree 是业界普遍认可的实现无阻塞网络的技术。其基本理念是:使用大量低性能的交换机,构建出大规模的无阻塞网络,对于任意的通信模式,总有路径让他们的通信带宽达到网卡带宽。Fat-Tree 的另一个好处是,它用到的所有交换机都是相同的,这让我们能够在整个数据中心网络架构中采用廉价的交换机。

Fat-Tree 是无带宽收敛的:传统的树形网络拓扑中,带宽是逐层收敛的,树根处的网络带宽要远小于各个叶子处所有带宽的总和。而 Fat-Tree 则更像是真实的树,越到树根,枝干越粗,即:从叶子到树根,网络带宽不收敛。这是 Fat-Tree 能够支撑无阻塞网络的基础。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2VOz3kLF-1605673289157)(/Users/limengfan/Note_2020_2/img_network/fat_tree.png)]

如上图所示,为了实现网络带宽的无收敛,Fat-Tree 中的每个节点(根节点除外)都需要保证上行带宽和下行带宽相等,并且每个节点都要提供对接入带宽的线速转发的能力。

从图中可以看到,每个叶子节点就是一台物理交换机,接入 2 台终端;上面一层的内部节点,则是每个逻辑节点由 2 台物理交换机组成;再往上面一层则每个逻辑节点由 4 台物理交换机组成;根节点一共有 8 台物理交换机。

这样,任意一个逻辑节点,下行带宽和上行带宽是完全一致的。这保证了整个网络带宽是无收敛的。同时我们还可以看到,对于根节点,有一半的带宽并没有被用于下行接入,这是 Fat-Tree 为了支持弹性扩展,而为根节点预留的上行带宽,通过把 Fat-Tree 向根部继续延伸,即可实现网络规模的弹性扩展。

Fat-Tree 的缺陷

  1. Fat-Tree 的扩展规模在理论上受限于核心层交换机的端口数目,不利于数据中心的长期发展要求;
  2. 对于 POD 内部,Fat-Tree 容错性能差,对底层交换设备故障非常敏感,当底层交换设备故障时,难以保证服务质量;
  3. Fat-Tree 拓扑结构的特点决定了网络不能很好的支持 One-to-All及 All-to-All 网络通信模式,不利于部署 MapReduce、Dryad 等高性能分布式应用;
  4. Fat-Tree 网络中交换机与服务器的比值较大,在一定程度上使得网络设备成本依然很高,不利于企业的经济发展。
  5. 因为要防止出现 TCP 报文乱序的问题,难以达到 1:1 的超分比(超配比例)。

叶脊(Spine-Leaf)型网络架构

Spine-Leaf 网络架构,也称为分布式核心网络,由于这种网络架构来源于交换机内部的 Switch Fabric,因此也被称为 Fabric 网络架构,同属于 CLOS 网络模型。Spine-Leaf 网络架构可以提供高带宽、低延迟、非阻塞的服务器到服务器连接。

CLOS 网络是三级交换架构,而 Leaf Spine 却只有两层,这是因为:网络架构中的设备基本都是双向流量,输入设备同时也是输出设备,因此三级 CLOS 沿着中间层对折,就得到了两层的网络架构。可以看出传统的三层网络架构是垂直的结构,而 Spine-Leaf 网络架构是扁平的结构,从结构上看,Spine-Leaf 架构更易于水平扩展。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4GNQVQY5-1605673289161)(/Users/limengfan/Note_2020_2/img_network/spine_leaf.png)]

从拓扑结构上看,Spine-Leaf 二层架构视乎要比传统三层网络架构简单得多,但是传统三层网络架构只有核心交换机是昂贵的 L3 交换机,而 Spine-Leaf 却要求所有节点都应该是 L3 交换机。因此,Spine-Leaf 也只能在设备价格下降了的这些年才得以被推广。

2 层和 3 层的网络结构对比

Leaf Switch:相当于传统三层架构中的接入交换机,作为 TOR(Top Of Rack)直接连接物理服务器。与接入交换机的区别在于 L2/L3 网络的分界点现在在 Leaf 交换机上了。Leaf 交换机之上是三层网络,Leaf 交换机之下都是个独立的 L2 广播域,这就解决了大二层网络的 BUM 问题。如果说两个 Leaf 交换机下的服务器需要通讯,需要通过 L3 路由,经由 Spine 交换机进行转发。

Spine Switch:相当于核心交换机。Spine 和 Leaf 交换机之间通过 ECMP(Equal Cost Multi Path)动态选择多条路径。区别在于,Spine 交换机现在只是为 Leaf 交换机提供一个弹性的 L3 路由网络,数据中心的南北流量可以不用直接从 Spine 交换机发出,一般来说,南北流量可以从与 Leaf 交换机并行的交换机(edge switch)再接到 WAN router 出去。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nUbamS5x-1605673289164)(/Users/limengfan/Note_2020_2/img_network/2_3_layer.jpg)]

Fabric 中的 Leaf 层由接入交换机组成,用于接入服务器,Spine 层是网络的骨干(Backbone),负责将所有的 Leaf 连接起来。每个低层级的 Leaf 交换机都会连接到每个高层级的 Spine 交换机上,即每个 Leaf 交换机的上行链路数等于 Spine 交换机数量,同样,每个 Spine 交换机的下行链路数等于 Leaf 交换机的数量,形成一个 Full-Mesh 拓扑。当 Leaf 层的接入端口和上行链路都没有瓶颈时,这个架构就实现了无阻塞(Nonblocking)。并且,因为任意跨 Leaf 的两台服务器的连接,都会经过相同数量的设备,所以保证了延迟是可预测的,因为一个包只需要经过一个 Spine 和另一个 Leaf 就可以到达目的端。

因为 Fabric 中的每个 Leaf 都会连接到每个 Spine,所以,如果一个 Spine 挂了,数据中心的吞吐性能只会有轻微的下降(Slightly Degrade)。如果某个链路的流量被打满了,Spline-Leaf 的扩容过程也很简单:添加一个 Spine 交换机就可以扩展每个 Leaf 的上行链路,增大了 Leaf 和 Spine 之间的带宽,缓解了链路被打爆的问题。如果接入层的端口数量成为了瓶颈,那就直接添加一个新的 Leaf,然后将其连接到每个 Spine 并做相应的配置即可。这种易于扩展(Ease of Expansion)的特性优化了 IT 部门扩展网络的过程。

Spine-Leaf 的优势

  1. 扁平化:扁平化设计缩短服务器之间的通信路径,从而降低延迟,可以显著提高应用程序和服务性能。
  2. 易扩展:如果 Spine 交换机的带宽不足,我们只需要增加 Spine 节点数,也可以提供路径上的负载均衡;如果接入连接不足,则只需增加 Leaf 节点数。
  3. 低收敛比:容易实现 1:X 甚至是无阻塞的 1:1 的收敛比,而且通过增加 Spine 和 Leaf 设备间的链路带宽也可以降低链路收敛比。
  4. 简化管理:叶脊结构可以在无环路环境中使用全网格中的每个链路并进行负载平衡,这种等价多路径设计在使用 SDN 等集中式网络管理平台时处于最佳状态。SDN 允许在发生堵塞或链路故障时简化流量的配置,管理和重新分配路由,使得智能负载均衡的全网状拓扑成为一个相对简单的配置和管理方式。
  5. 边缘流量处理:随着物联网(IoT)等业务的兴起,接入层压力剧增,可能有数千个传感器和设备在网络边缘连接并产生大量流量。Leaf 可以在接入层处理连接,Spine 保证节点内的任意两个端口之间提供延迟非常低的无阻塞性能,从而实现从接入到云平台的敏捷服务。
  6. 多云管理:数据中心或云之间通过 Leaf Spine 架构仍可以实现高性能、高容错等优势,而多云管理策略也逐渐成为企业的必选项。

Spine-Leaf 的缺陷

  1. 独立的 L2 Domain 限制了依赖 L2 Domain 应用程序的部署。要求部署在一个二层网络的应用程序,现在只能部署下一个机架下了。
  2. 独立的 L2 Domain 限制了服务器的迁移。迁移到不同机架之后,网关和 IP 地址都要变。
  3. 子网数量大大增加了。每个子网对应数据中心一条路由,现在相当于每个机架都有一个子网,对应于整个数据中心的路由条数大大增加,并且这些路由信息要怎么传递到每个 Leaf 上,也是一个复杂的问题。

摘要

pFabric 是一种简约的数据中心传输设计,即使在短流量情况下,即使在第99个百分位处,它也能提供接近理论上最佳的流量完成时间,同时仍能最大限度地缩短长流量的平均流量完成时间

pFabric 通过基于关键概念洞察力的非常简单的设计来提供此性能:数据中心传输应将流调度与速率控制脱钩

  • 流调度:数据报带有由每个流独立设置的单个优先级号;交换机的缓冲区非常小,并且实现了非常简单的基于优先级的调度/丢弃机制。
  • 速率控制:流仅在高且持续的数据报丢失的情况下才以开始线速和节流。

我们提供了理论上的直觉,并通过广泛的仿真显示这两种简单机制的结合足以提供近乎最佳的性能。


一、简介

数据中心工作负载对传输结构提出了独特而严格的要求:交互式软实时工作负载(例如在搜索,社交网络和零售中看到的工作负载)在数据中心内生成大量小的请求和响应,这些请求和响应被缝合在一起以执行用户请求的计算(例如,传递搜索结果)。

这些应用程序要求每个简短的请求/响应流都具有低延迟,因为用户感知的性能取决于对所有(或大部分)请求的响应被收集并交付给用户的速度。但是,在当前部署的基于TCP的结构中,这些短流的等待时间很可能高达数十毫秒,而理论上这些流可以在10-20微秒内完成。

原因是这些流量通常在大量并存工作负载(例如备份,复制,数据挖掘等)的大量数据报突发之后排队,这大大增加了它们的完成时间。

新的数据中心传输设计,从广义上讲,它使用速率控制来减少短流量的 FCT(flow completion times):

  1. 通过各种机制(自适应拥塞控制,基于ECN的反馈,调速等)将队列保持为空,从而改善了 FCT,以便对延迟敏感的流看到较小的缓冲区,因此延迟较小。这些隐式技术通常会改善短流量的 FCT,但它们永远无法精确地确定正确的流量以最佳地调度流量。
  2. 明确计算网络的费率并将其分配给每个流,以便根据流的大小或截止时间来调度流。这种方法可能会提供非常好的性能,但是实施是相当复杂且具有挑战性的。

本文的目的是设计最简单的数据中心传输方案,即使对于延迟敏感的短流也能提供接近最佳的流完成时间,即使在99%的百分率也能提供最佳的流完成时间

  1. 数据报优先级编码:终端主机在每个数据报的报头中放置一个数字,以对其优先级进行编码。优先级由每个流独立设置,并且需要跨流或主机进行协调才能计算优先级
  2. 交换机很简单:它们具有非常小的缓冲区,并可以决定将哪些数据报接收到缓冲区中,以及根据数据报的优先级严格调度哪些数据报。因此交换机是贪婪的且局部感知的
    • 当新的数据报到达并且缓冲区已满时,如果传入数据报的优先级低于所有缓冲数据报的优先级,则将其丢弃。否则,丢弃缓冲区中最低优先级的数据报,并用传入的数据报替换。
    • 传输时,交换机以最高优先级发送数据报。
  3. 速率控制最小化:所有流量仅在出现高持续损失时才开始线性速率并限制其发送速率。因此速率控制是惰性的且易于实现

《失控》一书中提到:群智往往涌现于多数低智商的个体,当个体的数量达到一定程度之后,集体的智慧才会涌现出来。真正的智慧往往涌现于大量低智慧的个体
符合 Bytedance 的公司文化:Context, Not control. (使用自下而上的群智,避免自上而下的管理)

因此,pFabric 不需要在交换机上进行流状态或复杂的速率计算,不需要大的交换机缓冲区,不需要显式的网络反馈以及在终端主机上不需要复杂的拥塞控制机制。

pFabric 是简洁的设计;它需要在交换机和终端主机上都进行修改。我们还提供了使用现有交换机部署 pFabric 的初步设计,但是用于增量部署的完整设计并没有在本文中涉及。

我们的设计背后的关键见解是:速率控制对于流量调度而言是一种糟糕且无效的技术,并且两者的机制应独立进行耦合和设计

  • 流量调度:每个交换机的基于优先级的分组调度机制可确保调度按其优先级顺序流动,由每个交换机做出的局部和贪婪决策会导致整个结构中的近似最优流调度决策。
  • 速率控制:唯一目标就是避免持续的高丢包率,从线性速率开始并仅在由于过多的压降而浪费带宽的情况下进行调节。

软工设计原则:当一个系统过于复杂的时候,可以考虑将其拆分为多个系统,从集中式架构,到微服务架构,到云函数架构。系统足够庞大的同时,就需要保持各个部分的简洁性,没有什么是不可细分的(或许是我和我的祖国?)

我们使用详细的数据报级仿真来评估我们的设计,其中使用了两种广泛使用的数据中心工作负载:

  1. 模仿Web应用程序工作负载
  2. 模仿典型的数据挖掘工作负载

并且我们将 pFabric 与四种方案进行了比较:

  1. 理论上最好的一种理想方案
  2. 数据中心传输的最新方法
  3. PDQ
  4. DCTCP(Data Center TCP) 和 TCP

对比实验发现:

  • pFabric 实现了接近最佳的流完成时间。此外,pFabric 不仅可以在平均负载的情况下提供此功能,还可以在负载高达网络结构容量的 80% 的情况下以 99% 的速率提供这种功能。与 PDQ 和 DCTCP 相比,pFabric 将短流的 FCT 平均降低了 40% 以上和 2.5–4 倍,在第 99 个百分位数处分别降低了 1.5–3 和 3–4 倍。
  • 与 PDQ 相比,通过截止日期驱动的工作负载,pFabric 可以支持更多的截止日期流量以及更严格的截止期限。例如,即使对于可能的最低 FCT 的延迟仅为 25% 的截止日期,pFabric 仍可以在 60% 的网络负载下满足 99% 的流量(比 PDQ 多2倍)的截止日期。
  • 如果网络设计人员事先具有流量分布的详细知识,并仔细调整参数,例如每个优先级队列的流量阈值,每个优先级队列的最小缓冲区等,则可以使用商品交换机中现有的优先级队列来近似 pFabric。这种方法也提供了良好的性能,但是对由于流量和用户动态而在数据中心中更改的几个参数十分敏感。

二、相关工作

由于 TCP 的不足,近年来提出了许多新的数据中心传输设计。概括地说,以前的研究都使用速率控制来减少流完成时间。

隐式流控制(根据其他状态来调节速率)

  • DCTCP 和 HULL 尝试通过采用基于 ECN 的自适应拥塞控制算法和其他机制来使阻塞队列保持较小或为空。因此,对延迟敏感的流会看到较小的缓冲区和延迟。
  • D2TCP 是最近提出的对 DCTCP 的扩展,它通过基于截止日期信息和拥塞程度来调节窗口大小,从而增加了 DCTCP 的最后期限意识。

尽管这些方案通常可以改善延迟,但是它们从根本上受到约束,因为它们永远无法精确估计要使用的正确流量,从而在确保网络被充分利用的同时安排流量以最小化 FCT。此外,由于流量的突发性,保持网络队列为空是一项挑战,需要在终端主机上精心设计的速率控制和硬件数据报步调,并权衡网络利用率。

显式拥塞通知(英语:Explicit Congestion Notification,简称 ECN)是一个对网际协议和传输控制协议(TCP)的扩展,定义于 RFC 3168(2001)。ECN 允许拥塞控制的端对端通知而避免丢包。ECN 为一项可选功能,如果底层网络设施支持,则可能被启用 ECN 的两个端点使用。
通常来说,TCP/IP 网络通过丢弃数据报来表明信道阻塞。在 ECN 成功协商的情况下,ECN 感知路由器可以在 IP 头中设置一个标记来代替丢弃数据报,以标明阻塞即将发生。数据报的接收端回应发送端的表示,降低其传输速率,就如同在往常中检测到包丢失那样。

显式流控制(根据流状态来分配速率)

认识到上述局限性之后,后续工作将为每个流程明确分配发送速率,以便根据一些紧迫性概念安排流程:通常在网络中基于流最后期限或其估计的完成时间来计算分配的速率

  • D3 首先建议使用截止日期信息结合明确的费率控制来将费率与流量相关联。D3 在协商一致的先到先服务的基础上分配带宽,并且不允许抢占,因此已被证明会导致次优流调度,因为可以阻止近截止流等待较早到达的远截止流。
  • PDQ 指出最小化 FCT 需要先发制人的流量调度。但是,像 D3 一样,PDQ 的流调度机制也基于使用显式速率控制将速率分配给各个流的开关。在 PDQ 中,在数据报离开时,发送方会将预定报头附加到数据报,其中包含几个状态变量,包括流的截止日期,其预期的传输时间以及其当前状态,例如其发送速率和往返时间。然后,每个交换机针对一定数量的未完成流保持此状态,并使用它来决定为每个流分配多少带宽以及哪些流将“暂停”。(PDQ 提供了良好的性能,但是在实践中实现起来颇具挑战性和复杂性)

数据中心中的大多数对延迟敏感的流都足够小,能在一个 RTT 中完成。在高度动态的数据中心环境中,流量以很高的速率到达和离开,并且大多数流量仅持续几个 RTT

负载均衡

关于数据中心结构的有效负载均衡技术也有很多研究。更好的负载均衡当然可以减少热点流量,从而有助于减少流完成时间,但是这些技术和目标是正交的,与 pFabric 互补。


三、概念模型

数据中心结构通常由两棵或三层的胖树或 Clos 结构的交换机组成,将整个结构抽象为一个互连服务器的巨型交换机

由于数据中心工作量由大量短流程主导,因此最小化平均 FCT 将确保短,高优先级流量有极低的延迟。

理想的流量调度算法:将小流量优先于端到端的大流量可以提供接近理想的平均 FCT。

输入:活动的流列表,包含入端口和出端口的剩余流量的大小,列表会随着流的到达和离开而动态变化
输出:此时需要调度的流的集合 S
1. S 为空集合
2. 入端口列表忙为 False
3. 出端口列表忙为 False
4. 对于每个流,按照剩余流量递增的顺序1. 如果该流的入端口和出端口的忙为 False1. 将该流加入集合 S2. 设置该流的入端口和出端口的忙为 True

四、设计

数据报优先级:每个数据报的标头中都带有一个数字,该数字编码其优先级。数据报优先级可以根据调度目标表示不同的事物。

  • 为了近似理想算法和最小化平均 FCT,将优先级设置为数据报传输时的剩余流量大小。
  • 对于具有截止日期的流量,为了最大程度地满足截止时间,将优先级设置为在某个时间单位内自行量化的截止时间。
  • 其他方法也可以使用绝对流量大小而不是剩余流量大小。

4.1 交换机设计

pFabric 交换机使用两种简单的本地机制:

  1. 优先级调度:每当端口处于空闲状态时,该端口上缓存的优先级最高的数据报就会被出队并发送出去。
  2. 优先级丢弃:每当一个数据报到达具有完整缓冲区的端口时其,如果优先级就小于等于最低的优先级数据报,则将其丢弃。否则,将丢弃优先级最低的数据报,以便为新数据报腾出空间。

数据结构:交换机维护两个数据结构。

  1. 在 RAM 中维护的实际数据报队列。
  2. 镜像数据报队列,只保留数据报的优先级号等数据。

pFabric 交换机的队列很小,通常少于两个带宽延迟乘积(传统交换机是其10~30倍)。在触发器中维护的,可以快速进行同时访问。

数据报出队

对于出队,我们首先使用优先级二叉树找到最高优先级的数据报,这些比较器在镜像数据报队列上分层运行。

解决低优先级流量饥饿的问题:即从队列中具有最高优先级数据报的流中取出最早的数据报。由于数据报按照它们到达的顺序排队,这就是队列中最早的数据报,它的流ID与具有最高优先级的数据报相同。因此,在第二步中,我们对元数据队列中的所有数据报对该流ID进行并行的按位比较。此比较操作的输出是一个bit-map,在存在匹配项的地方为1,在其他情况为0。通过使用优先级编码器,我们选择与比特向量中最早的1相对应的数据报并进行传输。(即同时考虑了优先级和到达顺序

数据报入队

对于排队,如果队列未满,则将数据报添加到队列的末尾,并更新元数据队列。如果队列已满,我们将使用与上面的出队操作类似的比较器结构的二叉树,但这找到优先级最低的数据报。该数据报将从数据报队列和元数据队列中删除,并将新数据报添加到队列的末尾。

4.2 速率控制设计

  1. 流量以线性速度开始。
  2. 使用SACK,对于每个数据报确认。
  3. 没有快速重传,dupACK 或任何其他此类机制,丢包仅通过超时来检测。超时后,在进入超时之前,进入慢启动状态的流量将设置为窗口大小的一半。
  4. 如果发生连续超时的固定阈值次数,则表明是慢性拥塞崩溃事件。在这种情况下,流进入探测模式,在此模式下,该流会定期重传带有一个字节有效负载的最小大小的数据报,并在收到确认后重新输入慢启动。

4.3 为什么有效

4.4 实现

交换机实现

  • 优先级调度和丢弃相对容易使用硬件原语来实现。
  • 因为数据报的总数很小,偶尔的散列冲突只会对调度顺序产生很小的影响。
  • 如果限制优先级分配,以使流量的优先级不会超过时间,将不需要饥饿预防机制,而可以完全摆脱流量ID匹配逻辑。

终端实现:pFabric 基于优先级的数据报调度需要一直扩展到最终主机才能完全有效。=


五、评估

使用 ns2 仿真器中的扩展数据报级仿真来评估 pFabric 的性能。我们的评估包括三个部分:

  1. 使用精心构建的微基准来评估pFabric的基本性能。
  2. pFabric 如何在实际的数据中心网络中运行已部署的数据中心中观察到的工作负载时实现近乎最佳的端到端性能。
  3. 解构整体结果并演示影响性能的因素。

5.1 模拟方法

结构拓扑:使用 leaf-spine 拓扑。

结构负载均衡:在禁用快速重传以应对数据报重新排序后,使用 packet-spraying 可以获得最佳结果。

基准工作量:考虑两个流量大小分布。第一个分布来自支持 web 搜索的数据中心;第二个分布来自运行大型数据挖掘作业的集群。

性能指标:考虑了两个主要的绩效指标。对于受期限限制的流量,将应用程序吞吐量定义为满足期限的流量的一部分;对于没有期限的流量,使用流量完成时间(FCT)。

5.2 方案比较

  1. TCP-DropTail:标准 TCP。
  2. DCTCP:TCP 使用 ECN 拥塞控制。
  3. pFabric:本文设计,包括交换机和最小速率控制。除非另有说明,否则其余流大小将用作每个数据报的优先级。
  4. PDQ:这是使流完成时间或错过的最后期限最小化的最著名的现有方法。
  5. Ideal:理想调度算法。具有所有流的完整视图的中央调度程序会以不减小的大小顺序和最大的方式抢先调度现有流。

并通过实验确定了所有方案的相关参数的最佳设置。

不要拿你算法最好的结果和对照算法最差的结果进行对比

5.3 基本性能衡量

  1. 流之间能否无缝切换:pFabric 能够无缝地安排一个流接另一个流,而吞吐量效率损失很小。
  2. 丢包率:由于低优先级流仅在等待高优先级流完成的同时定期发送小探测包(具有一个字节的有效载荷),因此探测模式可显着降低丢失率。
  3. 内播:导致TCP的吞吐量下降。

与 DCTCP 和 TCP-DropTail 相比,串行流调度显着提高了 pFabric 的平均单个流完成时间,而 PDQ 在流切换中的开销稍高,因此随着流数量的增加,性能也会稍差。

5.4 全局性能

在本节中,我们将展示 pFabric 在具有实际工作负载的大型数据中心拓扑中的整体性能。

  1. 截止时间不受限制的流量
  2. 截止时间有限制和无限制的流量混合
  3. pFabric 深究

六、增量部署

  1. 当今的交换机中如何使用可用的优先级队列?
  2. 最终主机应如何设置数据报头中的优先级字段?

这种方法面临两个主要挑战:

  1. 为了获得良好的性能,需要多少个优先级队列?

    • 随着增加优先级队列的数量,平均总体 FCT 有所提高,并且接近某个数量个优先级队列的 pFabric 性能,在小流量,中流量和大流量的平均 FCT 趋势相似。
  2. 每个优先级队列应使用什么流量大小阈值?
    • 需要对每个交换机上的优先级队列使用不同的阈值,而且这些阈值可能会随时间变化。

七、讨论

pFabric 设计精神,其中流(它们是计算任务中需要交换的数据的代理)成为一等公民,网络 fabric 旨在以轻量级的方式调度它们,以最大程度地最大化应用层目标。

  • 饥饿和恶意:严格限制小流量的优先考虑因素是,这可能会饿死大流量。此外,恶意用户可以通过拆分大流量来获得优势。当前的设计针对专用数据中心,因此恶意行为不在范围之内。在公共环境中,可能需要进一步的机制来防止滥用。
  • 设置数据报优先级:不需要优先级准确,只要求跨入流的相对优先级在很大程度上是正确的。
  • 支持多优先级模式:通过以分层的方式在各个“更高级别”流量类别中操作 pFabric 优先级调度和丢弃机制。
  • 其他数据中心拓扑:着重于 Fat-tree/Clos 拓扑,其他拓扑推进中。
  • 稳定性:基于大小的流量优先级可能会降低网络的稳定性,这意味着即使每个链路上的平均负载小于其容量,网络也可能无法跟上流量到达的速度。

八、结论

本文将数据中心数据报传输的关键方面(流调度和速率控制)分离开来,并表明通过为这些目标分别设计非常简单的机制,我们可以实现可实现近乎理想性能的简约数据中心结构设计。

此外,还表示在数据中心中大型缓冲区或复杂速率控制在很大程度上是不必要的。

接下来的步骤是将 pFabric 的原型实现与对延迟敏感的应用程序集成在一起,以评估对应用程序层的影响。

此外,我们的初步调查表明,在基于 pFabric 的基础上设计可增量部署的解决方案的进一步工作可能会很有成效。最终,我们认为这可以为在实践中广泛使用这些想法铺平道路。

论文阅读:pFabric: Minimal Near-Optimal Datacenter Transport相关推荐

  1. [论文阅读](SHAPING DATASETS: OPTIMAL DATA SELECTION FOR SPECIFIC TARGET DISTRIBUTIONS ACROSS DIMENSIONS)

    文章目录 摘要 引言 方法 补充:分支界定法 实验结果 摘要 提出了一种基于混合整数线性规划(MILP)的数据集操作方法.提出的优化可以将数据集缩小到特定的大小,同时在不同维度上强制执行特定的分布.它 ...

  2. Quasi-globally Optimal and Near/True Real-time Vanishing Point Estimation in Manhattan World 论文阅读学习

    论文阅读整理笔记 Quasi-globally Optimal and Near/True Real-time Vanishing Point Estimation in Manhattan Worl ...

  3. 深度学习论文阅读目标检测篇(七)中英对照版:YOLOv4《Optimal Speed and Accuracy of Object Detection》

    深度学习论文阅读目标检测篇(七)中英对照版:YOLOv4<Optimal Speed and Accuracy of Object Detection> Abstract 摘要 1. In ...

  4. Designing an optimal contest(博弈论+机制设计) 论文阅读笔记

    Designing an optimal contest 论文阅读笔记 一.基本信息 二.文章摘要 三.背景介绍 四.核心模型 五.核心结论 六.总结展望 一.基本信息 题目:设计一个最优竞赛 作者: ...

  5. 论文阅读2018-10-13

    论文阅读2018-10-13 Addressing the minimum fleet problem in on-demand urban mobility 原文及翻译 METHODS Addres ...

  6. 【论文阅读】24-USAC: A Universal Framework for Random Sample Consensus

    [论文阅读]24-USAC: A Universal Framework for Random Sample Consensus 0.basic info 1. standard RANSAC 1.1 ...

  7. 【论文阅读】Learning Traffic as Images: A Deep Convolutional ... [将交通作为图像学习: 用于大规模交通网络速度预测的深度卷积神经网络](2)

    [论文阅读]Learning Traffic as Images: A Deep Convolutional Neural Network for Large-Scale Transportation ...

  8. 【论文阅读】A Gentle Introduction to Graph Neural Networks [图神经网络入门](7)

    [论文阅读]A Gentle Introduction to Graph Neural Networks [图神经网络入门](7) Into the Weeds Other types of grap ...

  9. YOLOv4论文阅读(附原文翻译)

    YOLOv4论文阅读(附原文翻译) 论文阅读 论文翻译 Abstract摘要 1.Introduction 引言 2.Related work相关工作 2.1.Object detection mod ...

  10. 2019 sample-free(样本不平衡)目标检测论文阅读笔记

    点击我爱计算机视觉标星,更快获取CVML新技术 本文转载自知乎,已获作者同意转载,请勿二次转载 (原文地址:https://zhuanlan.zhihu.com/p/100052168) 背景 < ...

最新文章

  1. MySQL 实战 定时备份数据库
  2. oracle数据库恢复aul_RMAN备份与恢复 —— 完全恢复与不完全恢复
  3. 第四范式成为金融信创生态实验室首个AI合作伙伴
  4. 修改小程序swiper 点的样式_请问微信小程序swiper切换的点如何修改样式。
  5. NET Core的代码安全分析工具 - Security Code Scan
  6. RequireJS对文件合并与压缩实现方法
  7. 冰城环保进入智慧时代
  8. Windows7 64位下SDK Manager.exe无法运行问题解决方法
  9. [qq机器人]nonebot2 群管插件2.0
  10. 图片短链接生成器在线
  11. 均方误差(MSE)和均方根误差(RMSE)和平均绝对误差(MAE)
  12. Windows蓝屏漏洞(利用多种途径与分析)
  13. 五子棋游戏程序设计制作(C语言)
  14. 从Django的SECTET_KEY到代码执行
  15. “冰块比马桶水脏”让人透心凉
  16. 97年的世界黑客编程大赛第一名的作品-Mekka 【代码+使用】
  17. NAMD 中计算水分子沿某一放向的平均值 (tcl/tk 脚本输出数据, awk 求某一列平均值)
  18. txt文件读取(已解决中文乱码)
  19. 时间序列分析之一次指数平滑法
  20. ODOO 产品变体太强大了

热门文章

  1. 数据库连接池 ( 五 ) Druid 数据监控
  2. 解决docker容器映射信息修改问题
  3. 导入另一个 Git库到现有的Git库并保留提交记录
  4. 记录使用scrapy爬取新闻网站最新新闻存入MySQL数据库,每天定时爬取自动更新
  5. 10-123 A3-3查找产品表中最低的单价
  6. 缺项目经验的看过来,真实的软件测试实战项目来了
  7. 【自动控制原理】根轨迹法之绘制根轨迹
  8. 自动驾驶-自适应卡尔曼滤波AKF
  9. 重定向和转发的区别+使用情景
  10. C++ - 实现strcpy函数