负载均衡机制Presto阅读笔记

标题

Presto: Edge-based Load Balancing for Fast Datacenter Networks

ABSTRACT

背景

数据中心需要处理大量的两种流（吞吐量敏感、延迟敏感），基于哈希映射的负载均衡机制（ECMP），在发生哈希冲突时导致拥塞，并且在非对称拓扑中表现不佳。

论文贡献

提出一种负载均衡机制——Presto：

• 近乎完美的负载平衡
• 在软件边缘（soft edge）工作
• 无需更改硬件或传输层
• 能够高速运行

INTRODUCTION

第一二段

重述背景问题：基于流哈希的流行负载平衡方案，例如ECMP，在发生哈希冲突时会导致拥塞，且在非对称拓扑环境下表现不佳。

举例主流的解决办法及其缺点：粒度粗、反应慢、需要额外的硬件配置

第三段

重新审视负载均衡设计：

ECMP尽管有其局限性，但由于其主动属性，它仍有实用性。ECMP的缺陷是网络拓扑（或容量）的不对称性和流量大小的变化引起的，如果在一个对称的网络拓扑中，所有的流都是小流，此时ECMP展现出最理想的表现

第四段

能否利用上述特点设计一个性能良好的、主动的、无需专用硬件的、无需修改端点运输的机制呢？

第五段

设想的机制应该满足一些要求：

• 算法必须简单、轻量
• 对重排序具有鲁棒性（健壮性），控制重排序对TCP拥塞机制的影响。

第六段

提出Presto，介绍文章贡献

• 设计了Presto机制
• 改进了GRO，
• 展示了Presto的网络故障恢复能力和适应非对称网络拓扑的能力
• 在10Gbps的测试平台上对presto进行评估，并与其他负载均衡机制对比
  

CHALLENGES

重排序对TCP的影响

重排序使TCP的发送方状态趋于保守，两个调参解决方法：

• 降低DUP-ACK门槛会导致增加恢复时间（is not ideal because in-creasing the DUP-ACK threshold increases the time to re-cover from real loss.）
• 更改FACK会在重排序时降低性能

重排序的计算消耗

GRO (Generic Receive Offload)是一种网络协议栈的优化技术，能够提高系统接收TCP数据包的性能。但面对极端的包乱序时，GRO失效，造成较大的计算负担。因此必须降低包乱序造成的影响。

DESIGN

在软件边缘实现负载均衡

A key design decision in Presto is to implement the functionality in the soft edge (eg. the vSwitch and hypervisor of the network

主动管理拥塞

Presto的第二个设计关键是使用了主动管理拥塞的方法。

负载均衡机制必须在突然的拥塞导致缓冲区溢出之前作出反应，这一要求否定了响应式机制，因为它们太慢了。分布式响应机制（Distributed reactive schemes）对拥塞的响应更快，但不仅部署的障碍很高，还需要小心地避免震动。

Per-Hop vs End-to-End Multipathing

Presto在全局、端到端的级别上进行。

优点有二：

• 更好地分配flowcell映射到多条路径
• 端到端允许在vSwitch上进行加权调度以重新平衡流量

负载粒度

presto使用flowcell作为负载粒度，每个flowcell的大小为64KB，这是一个经验值，目的是最大限度的利用TSO的性能

发送端

在高层次上，控制器将网络划分为多个生成树的集合。然后，控制器在每个生成树中为每个vSwitch分配唯一的转发标签。为了帮助接收端重新排序，发送端在每个段中设置依次增加的flowcell ID，这在后续GRO处理乱序的部分起作用。

接收端

如果不能与接收的数据包合并，那么不要积极的上推数据包。确保按上推的段是有序的。

非对称下的故障处理

对于非对称的网络拓扑结构，使用加权多路径调度、轮询的方法进行最优的负载均衡。

选择合适的粒度

流粒度、包粒度、Flowlets粒度都有一些问题。
Presto的粒度是基于flowcell，这是一个大小为64KB的单元，之所以选取64KB这个数值，是为了最大限度地利用TSO的高速性能。

GRO改进设计

什么是GRO

“GRO是一种类似TSO的技术，它直接控制网卡(NIC)，将一些包聚合成一个更大的段，上推到TCP层，这一操作有效的提高了TCP的性能，减轻了CPU的计算压力。”

但在极端乱序的情况下，GRO会失效。

Presto正是对GRO进行了改进，使其在乱序的情况下也能正常生效。

下面先说一下在有序的条件下，GRO是怎么工作的。

对于一些有序的数据包，GRO会将它们整合成一个更长的段，一次性上推到TCP/IP层

GRO将包合并，减少了段的数量，使TCP/IP层花费更少的时间，从而提高了性能，减轻了CPU的负担。

GRO在乱序情况下失效

但在极端的乱序下，GRO会失效。

因为GRO的设计是快速、简单的，所以当 1）包之间出现间隔 2）达到最大长度（一个flowcell被填满）3）超时 时，GRO会立刻将当前的段上推。

在乱序情况下，GRO并没有起到整合的作用，上推到TCP/IP层的段还是很散，降低了TCP的性能，造成了巨大的CPU开销。

改进GRO

Presto是这样改进GRO的：



当出现空隙时，不立刻上推，而是等待一段时间


等待乱序的包重新填补空隙，结合成一个更长的段后，再上推，这样减少了乱序对GRO的影响。

这里有一个问题：一旦出现空隙，就要等待吗？

事实上，空隙可能由乱序产生，也可能是由丢包产生，比如下面这个例子：

机制应该能够区分丢包和乱序，对于乱序，可以稍等一段时间，待空隙被填补满后，再结合成整段上推。对于丢包，应该立刻上推，尽快让TCP/IP层对丢包做出反应。

这个等待的时间太长会阻碍TCP/IP及时对丢包作出反应，太低也会导致其他问题。

Presto通过对近期的重排事件的监测，设计了一种自适应方案来动态地设置这个等待时长。

伪代码

论文中提供了两个伪代码。

第一个代码是根据字节长度来给flowcell分配ID号和地址，第三行实现在全部地址中轮询的操作。
第二个代码是控制GRO上推，函数getFlowcell(S)的功能是获取S的flowcell ID

性能对比

论文通过多个实验验证了Presto的性能更优。

参考资料