2017_NSDI_LetFlow Let It Flow Resilient Asymmetric Load Balancing论文翻译

本文已参与「新人创作礼」活动，一起开启掘金创作之路。

2017_NSDI_LetFlow Let It Flow Resilient Asymmetric Load Balancing论文翻译

我直接用软件翻译的，不准确，大概意思差不多，建议看原文哦！

让它流动:弹性非对称负载平衡和小流量切换****

摘要  数据中心网络需要高效的多路径负载平衡，以实现高二等分带宽。尽管近年来在应对这一挑战方面取得了很大进展，但一种既易于实施又能抵御网络不对称的负载平衡设计仍然难以实现。在这篇文章中，我们展示了flowlet交换，一个十多年前首次提出的想法，是一种强大的不对称弹性负载平衡技术。小流量具有显著的弹性:它们的大小会根据路径上的交通状况自动变化。我们利用这种洞察力开发了LetFlow，这是一种非常简单的负载平衡方案，能够抵抗不对称。LetFlow只是为flowlets随机挑选路径，让它们的弹性自然地平衡不同路径上的流量。我们对真实硬件和数据包级模拟的广泛评估表明，该方法非常有效。尽管更简单，但在非对称场景中，它的性能明显优于其他流量遗忘方案，如WCMP和普雷斯托，同时在试验台实验中，平均流量完成时间在CONGA的10-20%以内，在不对称大、流量负载重的模拟拓扑中，平均流量完成时间为CONGA的2倍。

1简介****

数据中心网络必须提供大的bisection带宽，以支持大数据分析、网络服务和云存储等应用程序日益增长的流量需求。他们通过多根树拓扑(如Clos [13]和Fat-tree [1])中多条路径上的流量负载平衡来实现这一点。这些设计被广泛部署；例如，谷歌报告称，其数据中心使用的Clos结构的二等分带宽超过1 Pbps[25]。

当今数据中心的标准负载平衡方案，等成本多路径(ECMP) [16]，使用数据包报头上的散列将流随机分配到不同的路径。ECMP因其简单性而被广泛部署，但也存在众所周知的性能问题，例如哈希冲突和无法适应网络拓扑中的不对称。因此，在更好的数据中心网络负载平衡设计方面，出现了大量的工作[10，2，22，23，18，3，15，21]。

这些设计的一个决定性特征是它们用来做出决策的信息。在频谱的一端是无视流量交通状况[16，10，9，15]或仅依赖于交换机处的局部测量[24，20]的设计。ECMP和普雷斯托[15]属于这一类，他们以循环方式为固定大小的数据块(称为“流单元”)选择路径。另一个极端是设计[2，22，23，18，3，21，29]，它们使用不同路径上的交通状况和拥堵的知识来做出决策。最近的两个例子是CONGA [3]和HULA [21]，它们使用交换机之间的反馈来收集路径拥塞信息，并将流量转移到不太拥塞的路径。

需要路径拥塞信息的负载平衡方案自然要复杂得多。当前的设计在终端主机[23，18]或交换机[3，21，30]上使用集中式结构控制器[2，8，22]来频繁优化路径选择或要求non-trivial的机制，以实现端到端或逐跳反馈。另一方面，缺乏路径拥塞可见性的方案有一个关键缺点:它们在不对称拓扑中表现不佳[3]。正如我们在2.1中讨论的，原因是不对称路径上的最佳流量分配取决于(动态变化的)流量条件；因此，流量无关方案根本无法做出最佳决策，并且在不对称拓扑中表现不佳。

不对称在实践中很常见，原因有很多，例如链路故障和网络设备的异构性[31，12，3]。因此，优雅地处理不对称是很重要的。这就提出了一个问题:是否有简单的负载平衡方案能够抵抗不对称？在本文中，我们通过开发LetFlow来肯定地回答这个问题，LetFlow是一个简单的方案，它不需要任何状态来做出负载平衡决策，但是它对网络不对称具有很强的弹性。

LetFlow非常简单:交换机为每个flowlet随机选择一条路径。就这样！一个flowlet是一个数据包的突发，它与其他突发在时间上有足够的间隔——称为“小流超时”。Flowlet交换[27，20]是十多年前提出的，作为一种在多条路径上拆分TCP流而不导致数据包重新排序的方法。值得注意的是，正如本文所揭示的，flowlet交换也是一种强大的弹性负载平衡技术。

这种弹性的原因是小流量的大小是有弹性的，并且根据不同路径上的交通状况而变化。在具有低每流带宽和高延迟的慢速路径上，流往往更小，因为流超时的可能性更大(流的包间间隙很大)。另一方面，在快速路径上，由于flowlet超时比在慢速路径上更不可能发生，因此flow let变得更大。 这种弹性源于这样一个事实，即更高层的拥塞控制协议(如TCP)会对流路径上的流量状况做出反应，在拥塞路径上减慢(导致更小的流)而在未拥塞路径上加快(导致更大的流)。

由于其弹性，小流量可以补偿不准确的负载平衡决策，例如，在不同路径上发送不正确比例的flowlets的决策。Flowlets通过改变流量大小来实现这一点，从而自然地将流量从慢速(拥堵)路径转移到快速(未拥堵)路径。由于基于flowlet的负载平衡决策不需要精确，因此不需要明确的路径拥塞信息或反馈。

唯一的要求是负载平衡算法不应该预先确定流量是如何在路径间分配的。相反，它应该允许小流程“探索”不同的路径，并自动确定每个路径上的流量(弹性)大小。因此，与Flare [27，20]等试图通过小流量实现目标流量分流的方案不同，LetFlow只是为每个小流量随机选择一条路径。

 

我们做出了以下贡献:

我们展示了简单的负载平衡方法，该方法以流量无关的方式为每个流[31]或数据包[15]选择路径，在不对称拓扑中表现不佳，我们发现小流交换是不对称情况下弹性负载平衡的强大技术。

我们设计并实现了LetFlow ，这是一个使用flowlets的简单随机负载平衡算法。LetFlow易于在硬件中实现，无需对终端主机或TCP进行任何更改即可部署。我们描述了一个主要数据中心交换机的实际实现。

我们通过详细的模拟和理论分析，分析(LetFlow如何平衡非对称路径上的负载。对于简化的流量模型，我们表明具有较低速率的流更有可能经历小流量超时，并且小流量倾向于将流移动到不太拥挤的路径，在那里它们达到较高的速率。

我们在小型硬件测试平台和大规模模拟中广泛评估了(5) LetFlow，这些模拟跨越了大量具有真实流量模式、不同拓扑和不同传输协议的场景。我们发现LetFlow非常有效。它在真实的测试平台上实现了10-20%的CONGA [3]的平均流量完成时间，在高不对称和流量负载下的模拟中实现了2倍的CONGA，并且性能明显优于竞争方案，如WCMP [31]和Presto的理想化变体[15]。

2动机和见解****

本文的目标是开发一个简单的负载平衡方案，该方案能够抵御网络不对称。在本节中，我们首先描述不对称带来的挑战和现有方法的缺点(2.1)。然后，我们展示了基于LetFlow的设计(2.2)背后的关键见解。

2.1不对称负载平衡****

在不对称拓扑中，一个或多个源/目标对之间的不同路径具有不同的可用带宽量。不对称可以通过设计产生(例如，在具有可变长度路径的拓扑中，如BCube [14]、水母[26]等)。)，但大多数数据中心网络使用对称拓扑。1然而，不对称在实践中很难避免:链路故障和异构交换设备(具有不同的端口数量、链路速度等)。)在大型部署中很常见，会导致不对称[31，24，3]。例如，不平衡条带化[31]，当Clos拓扑的一层中的交换机基数不能被相邻层中的交换机数量整除时，就会产生不对称(详情参见[31])。图1显示了我们将在本节中考虑的两种基本不对称拓扑。这里的不对称是由一个环节的失败造成的。例如，在图1a中，L0和S1之间的链路断开，因此任何L0 → L2流量只能使用L0 → S0 → L2路径。这导致负载平衡L1 → L2流量不对称。

不对称为什么具有挑战性？ 非对称拓扑中的负载平衡很困难，因为非对称拓扑中跨路径的流量优化分配通常取决于实时流量需求和不同路径上的拥塞情况[3]。相比之下，在对称拓扑中，无论流量条件如何，在所有(最短)路径上平均分配流量总是最佳的。例如，考虑图1a中的拓扑。假设工作负载由L0 → L2和L1 → L2流量组成。L1→L2的流量应该如何通过S0和S1在两条路径上分配？不难看出，理想的分流取决于L0 → L2流量的多少。例如，如果所有流量都在L1和L2之间，那么我们应该通过S0发送一半流量，通过S1发送一半流量。但是，如果有40 Gbps的L0 → L2流量，那么L1 → L2流量应该尽可能避开S0。

表1从两个关键维度比较了几种建议的负载平衡方案:(1)它们用于做出负载平衡决策的信息；以及(2)决策粒度(我们稍后讨论这一方面)。依赖于关于不同路径上流量状况的显式端到端(全局)信息的负载平衡设计可以处理不对称性。从传输层信号(例如，ECN标记)、集中式控制器和网络内逐跳或端到端反馈机制，有多种方法可以以不同的精度和复杂性收集这些信息。一个例子是CONGA [3]，它使用架顶(或“叶”)交换机之间的显式反馈环路来收集perpath拥塞信息。

相比之下，无视交通状况的方案通常有不对称的困难。正如一些设计[31，9，15，24]所提出的，即使基于拓扑对不同的路径进行不同的加权，情况也是如此。使用拓扑总比没有好，但是它没有解决依赖于实时交通状况的最优交通分割的基本问题。例如，正如我们接下来要展示的，在上面的场景中，了解拓扑并没有帮助。

动态工作负载不对称。 真实的数据中心流量和拥塞是高度动态的[6，7]。由于服务器以与网络链路相同的速度(或几乎相同的速度)运行，当一些高速流开始时，拥塞会迅速出现，当这些流结束时，拥塞也会迅速消散。真实数据中心工作负载的动态性使得非对称拓扑中的负载平衡更具挑战性，因为负载平衡算法必须适应快速变化的流量条件。

为了说明这个问题，再次考虑图1a中的拓扑，假设交换机L0和L1下的服务器向L2下的服务器发送流量。流量是通过泊松过程随机启动有限长度的流量生成的，流量大小分布真实(详见第5章)。L0 → L2和L1 → L2流量的平均速率分别为20 Gbps和48 Gbps。

理想情况下，位于叶L1的负载平衡器应该基于实时L0 → L2流量动态分割流量。相反，我们考虑简单的随机负载平衡，其中(1)两条路径的权重相等；(2)与s0路径相比，S1路径具有更高的权重(大约2.4比1)。这个权重是静态设置的，以均衡两条路径上的平均负载。这表示使用长期流量估计来优化路径权重的假设系统(例如，集中式控制器)。图2显示了两种权重设置的平均FCT，负载平衡决策是在每流、每包和每流粒度上做出的。将结果归一化为CONGA [3]获得的平均FCT，以供参考。每流情况与ECMP和WCMP相同[31]。每个数据包的情况提供了随机数据包分散[10]和普雷斯托[15]等方案的性能上限，这些方案使用静态权重在更精细的粒度上平衡负载。)结果显示，在每个流和每个包的粒度上，随机化的流量无关负载平衡在两种权重设置下的表现都明显差于CONGA。

总之，现有的负载平衡设计要么明确使用全局路径拥塞信息来做出决策，要么在不对称方面表现不佳。此外，基于拓扑或粗略流量估计的静态权重在动态设置中是不充分的。在下一节中，我们将描述LetFlow如何克服这些挑战。

2.2让小流程****

再次考虑图2。值得注意的是，同样的随机负载平衡方案在每个流和每个包的粒度上表现不佳，但在flowlet级别做出决策时表现非常好[27，20]。在每个flowlet中统一随机选择路径已经做得很好了；优化路径权重进一步提高了性能，几乎与CONGA匹配。

回想一下，流是同一流的数据包的突发，它们在时间上相距足够远，因此可以在不同的路径上发送，而不会导致数据包在接收器处重新排序。更准确地说，两个流之间的间隙必须超过一个阈值(流超时)，该阈值大于路径之间的延迟差；这确保了分组被有序地接收。

我们的关键见解是(除了支持细粒度负载平衡之外)flowlet具有一个独特的属性，它可以做出如下决定:流根据其路径上的拥塞程度自动改变大小。它们在慢路径上收缩(具有较低的流量带宽和较高的带宽)，在快路径上膨胀。这种弹性属性允许小流量通过自动将流量转移到不太拥挤的路径来补偿较差的负载平衡决策。我们通过一个简单的实验证明了flowlets对不良负载平衡决策的弹性。两个叶交换机L0-L1通过两个主干交换机S0-S1连接，通过S1的路径的容量是通过S0的路径的一半(参见图1b中的拓扑)。叶L0以112 Gbps的平均速率(超过可用120 Gbps容量的90%)向叶L1发送流量，流量由短流量和大流量的实际混合(5)组成。

我们在每个流、每个包和每个流的基础上比较加权随机负载平衡，如前一节所述。在这种拓扑中，理想情况下，负载平衡器应该在三分之二的时间内选择S0路径。为了对不准确的决策建模，我们在一系列模拟中将S0路径的权重(概率)从2%变化到98%。在每个权重下，我们绘制了三个方案的总体平均流完成时间(FCT)，标准化为所有实验中实现的最低值(每个数据包负载平衡使用S0的66%权重)。

图3显示了结果。我们观察到，在接近理想点的狭窄权重范围之外，基于流量和数据包的负载平衡会显著恶化。这并不奇怪，因为在这些方案中，每条路径上的流量直接由负载平衡器选择的权重直接决定。如果任一路径超出其容量，性能会迅速下降。

然而，使用小流量进行负载平衡在很大的重量范围内都是稳健的:对于20–95%之间的所有重量，负载平衡在最佳值的2倍以内。原因由图4解释，图4显示了两条路径上的平均流大小如何根据负载平衡器选择的权重而变化。如果负载平衡器使用了正确的权重(S0为66%，S1为33%)，那么两条路径上的流大小大致相同。但是，如果权重不正确，小流量的大小会调整以保持实际流量的平衡。例如，即使只有2%的流通过S0发送，S0路径上的流也会比S1路径上的流增长∞65倍，以保持流量在57%到43%的比例下合理平衡。

这个实验表明，一个简单的方案，在不同的路径上以流量无关的方式传播小流量，可能是非常有效的。本质上，由于其弹性，小流程隐含地反映了路径流量条件(我们在4中精确地分析了为什么小流程是弹性的)。LetFlow利用这一特性在没有显式信息或复杂反馈机制的情况下实现了良好的性能。

3设计和硬件实现****

LetFlow实现起来非常简单。所有功能都位于交换机上。交换机从每个流的可用选项(由路由协议给出)中随机选择一个输出端口。决策是在每个流的第一个数据包上做出的；只要flowlet保持活动状态(没有足够长的间隙)，后续数据包就遵循相同的上行链路。

流量检测。 交换机使用流量表来检测flowlets。表中的每个条目由端口号、avalid位和管理位组成。当一个包到达时，它的5元组头被散列到一个索引中，用于访问flowlet表中的一个条目。如果该条目是活动的，即有效位被设置为1，则数据包被发送到存储在该条目中的端口，年龄位被清零。如果条目无效，负载平衡器会从可用选项中随机选择一个端口来转发数据包。然后，它将有效位设置为1，清除年龄位，并在表中记录所选端口。

在一个固定的时间间隔内，一个独立的检查器进程检查每个条目的年龄位。如果未设置年龄位，检查器会将年龄位设置为1。如果年龄位已经置位，则检查器通过清除有效位来老化条目。被散列到该条目的任何后续数据包都将被检测为新的流。CONGA [3]也使用了这种一位aging方案，它能够在不维护每个流的时间戳的情况下检测流。代价是flowlet超时可以取∏和2∏之间的任何值。通过在每个条目中使用更多的年龄位可以获得更高的精度，但是我们发现一个位就足以在LetFlow中获得良好的性能。

超时间隔∞起着关键作用:将其设置得太低会有重新排序的风险，但如果设置得太高，则会减少flowlet的机会。我们在第4章中分析了小程序超时在小程序有效性中的作用。

负载平衡决策。如前所述，LetFlow只是从每个新的flowlet的所有可用端口中随机选择一个端口。硬件成本。

实现成本(就芯片面积而言)主要是针对Flowlet表，对于一个64K条目的表，大约需要150K个门和3兆位内存。对于现代开关芯片，面积消耗可以忽略不计(< 0.3%)。LetFlow已经在一个主要的数据中心交换机产品线的硅中实现。

四、分析****

我们已经看到，由于flowlets的弹性，它们能够适应不准确的负载平衡决策。在本节中，我们将更深入地了解小流量弹性的原因（§4.1）。我们发现，这是因为像TCP这样的高层拥塞控制协议根据其路径上的可用容量调整流量速率。利用这些见解，我们开发了一个马尔可夫链模型（§4.2），该模型显示了LetFlow如何平衡负载，以及关键参数flowlet超时在LetFlow的有效性中所起的作用。

4.1为什么Flowlets具有弹性？****

要知道为什么小花是有弹性的，让我们首先考虑什么引起小花。Flowlet是由TCP在子RTT时间尺度上的突发性引起的[20]。TCP倾向于在一个或几个集群突发中传输一个数据包窗口，在RTT期间散布空闲时段。这种行为是由各种因素造成的，如慢启动、ACK压缩和数据包丢失。

一个简单的解释是，为什么小流的大小会随着路径条件的变化而变化（例如，在拥挤的路径上缩小），它指向了丢包。理由是：在拥挤的路径上，丢弃的数据包越多；每一次下降都会导致TCP将其窗口大小减半，从而导致至少一半的RTT[5]空闲，并（可能）导致一个flowlet。

虽然这个论点是有效的（并且很容易从经验上观察到），但我们发现，flowlets之所以具有弹性，还有一个更基本的原因，那就是像TCP这样的拥塞控制协议如何适应流路径上的条件。当流被发送到较慢（拥塞）的路径时，拥塞控制协议会降低其速率。3由于流速度减慢，其数据包在超时时间内没有到达的可能性更高，从而导致flowlet结束。另一方面，快速路径上的流（具有更高的速率）有更高的机会使数据包在超时时间内到达，从而减少了flowlet机会。

为了说明这一点，我们构建了以下模拟：25个长寿命TCP流在瓶颈链路速度分别为40 Gbps和10 Gbps的两条路径上发送流量。我们将流的窗口大小限制为256 KB，并将两个链路上的缓冲区大小设置为足够大，这样就不会出现丢包。flowlet超时设置为200µs，RTT设置为50µs（在没有排队延迟的情况下）。

图5显示了每个路径上的流的数量是如何随时间变化的。我们有两个观察。首先，流路径的变化主要发生在前30ms；在这一点之后，流量超时变得罕见，流量达到非平衡。其次，在这种平衡状态下，两条路径上的流分割是理想的：40 Gbps路径上有20条流，10 Gbps路径上有5条流。这导致每条路径上的平均流量为2 Gbps，这是可能的最大值。

在这种情况下，平衡是稳定的，因为在任何其他状态下，一条路径上的流的速率（平均）将小于另一条路径上的流。这些流比对应的流更有可能经历flowlet超时。因此，系统具有自然的“随机漂移”，将其推向最佳平衡状态。请注意，随机漂移不能保证系统保持最佳状态。原则上，如果发生flowlet超时，流可能会更改路径。但由于TCP的确认时钟传输，在这种情况下不会发生这种情况。具体地说，由于TCP窗口大小是固定的，ACK时钟导致分组传输的重复模式。因此，一旦流达到一个RTT没有flowlet超时的状态，它们将永远锁定到该状态。

在实践中，交叉流量和TCP的数据包传输以及数据包之间的间隙将具有更大的动态性。通常，TCP的包间间隙取决于窗口大小、RTT和RTT内突发程度。TCP包间间隙的精确表征是一个难题。但很明显，随着流量的降低和RTT的增加，数据包之间的间隙会增加。

为了寻找一个更简单、非TCP特定的模型，我们接下来分析一个简单的泊松包到达过程，该过程提供了关于LetFlow如何平衡负载的见解。

4.2马尔可夫链模型****

考虑在两条路径P1和P2上传输的流量，瓶颈容量分别为C1和C2。4假设来自流i的数据包到达是一个泊松过程，速率为λi，与所有其他流无关。泊松到达对于TCP流量（突发性）来说是不现实的，但它允许我们捕获系统动态的本质，同时保持模型的可跟踪性（有关模型限制的更多信息，请参见下文）。

假设flowlet超时由∆, 每个新的flowlet随机映射到两条路径中的一条。此外，假设同一路径上的流实现了路径容量的相等份额；

其中，n1和n2表示每条路径上的流数。这是拥塞控制协议提供的公平带宽分配的理想化。最后，设λa=C1 c2为两条路径上的总到达率。

不难证明（n1，n2）形成马尔可夫链。在每个状态（n1，n2），如果下一个要到达的数据包触发其流的新flowlet，则负载平衡器可以（随机）为该流选择不同的路径，从而导致向状态（n1）的转换−1，n2 1）或（n1 1，n2−1). 如果下一个数据包没有启动一个新的flowlet，那么该流将保持在相同的路径上，并且状态不会改变。

设p1n1，n2和p2n1，n2为从（n1，n2）到（n1）的跃迁概率−1，n2 1）和（n1 1，n2 1−1） 分别，如图6所示。在附录A中，我们推导了以下转移概率表达式：

j∈ {0,1}. 当λa远大于λi，如果流的数量很大，并且（n1，n2）不是太不平衡，则为这种情况。

根据公式（2）比较p1n1、n2和p2n1、n2，可以深入了解流如何在路径之间转换。对于适当选择的值∆, 每流速率较低的路径上的流量更有可能改变路径。（拥堵路径上更容易转路径）此行为将系统推向C1/n1的状态≈C2/n2意味着良好的负载平衡。（两条路径上速率差不多就表示负载均衡）请注意，这正是我们在前面的TCP流模拟中观察到的行为（图5）。

Flowlet超时的角色(∆).  实现上述良好的负载平衡行为取决于∆. 如果∆非常大，然后是pjn1，n2≈0（无超时）；如果∆非常小，然后pjn1，n2≈C1/2（C1-C2）。在这两种情况下，转移概率都不依赖于流的速率，因此flowlet切换的负载平衡特性丢失。这一行为如图7所示，图7显示了路径1上的流数在几个值的概率分布∆, 其中n=100个流，C1=40 Gbps，c2=10 Gbps。这些图是从初始状态（50,50）开始，通过数值求解1011步后马尔可夫链的概率分布得到的。

在这种情况下，理想的工作点是（80,20）。图中显示，对于小型∆（30µs和50µs）和大型∆（900µs），状态分布远不理想。但是，对于中等值的∆（300µs和500µs），分布集中在理想点附近。

那么我们应该怎么做呢∆在实践中被选择？纯粹基于这个模型，这个问题很难回答。首先，泊松假设没有捕获TCP流的RTT依赖性和突发性，这两个因素都会影响数据包间的间隙，从而导致flowlet超时。其次，在选择flowlet超时时，我们必须注意避免数据包重新排序（除非采取其他缓解措施来防止重新排序的不利影响[11]）。

尽管如此，该模型提供了一些有用的见解，可用于设置∆. 这需要（粗略地）对突发性进行一点调整：我们假设流以突发数据包的形式传输，作为速率λi/b的泊松过程。根据经验，我们发现在我们的模拟设置中，TCP以大约b=10的突发方式发送（§5）。使用此值，我们运行一系列模拟以获得∆米南德∆最大值、最小值和最大值∆为此，负载平衡器在两条路径上实现了近乎理想的流分割。在这些模拟中，我们改变流量的数量，并考虑两个情况下，20/10 Gbps和40/10 Gbps路径。

图8显示∆闵和∆最大流量是每种情况下平均流量的函数：（C1 C2）/n。平均流速和流量之间存在明显的相关性∆. 随着平均流速的增加，∆需要简化以实现良好的负载平衡。大约500µs的flowlet超时支持最大的流速范围。我们在实验中采用该值（§5）。