数据中心网络是现代网络和云计算的重要基础设施,实现数据中心网络负载均衡是保证网络吞吐并提高服务体验的关键环节.首先分析了数据中心网络与传统互联网之间的区别,总结其特点及特殊性在负载均衡方案设计方面的优势.然后从数据中心的复杂性和多样性角度分析其负载均衡方案设计所面临的挑战.将现有数据中心网络负载均衡方案根据不同的实现层次从网络层、传输层、应用层和综合方案4个角度进行分析,对比各个方案的优缺点,并从控制结构、负载均衡粒度、拥塞感知机制、负载均衡策略、可扩展性和部署难度几个方面进行综合评价.最后对现有数据中心网络负载均衡方案进行总结,并指出未来可能的研究方向.
Data center networks are the important infrastructure of the modern Internet and cloud computing. It is critical to achieve load balancing in data center networks for guaranteeing high throughput and improving service experience. The difference between the data center network and traditional Internet is firstly analyzedand the features of data center networks and the facilitation for designing load balancing schemesare concluded. Then, the challenges of designing load balancing schemes are analyzedin data center networks from the perspective of complexity and diversity. Existing load balancing schemes in data center networksare classified into four types, i.e., the schemes based on the network layer, the transport layer, the application layer, and the synthetic designs, according to different modification types. The advantages and disadvantages of these schemes are detailedand they are evaluatedfrom the point of the control structure, the granularity of load balancing, the congestion sensing mechanism, the strategy of load balancing, scalability and the difficulty of deployment. Finally, all load balancing schemes are summarizedand some future feasible directionsare presented.
随着现代网络的发展和云计算的兴起, 数据中心承载了当前互联网中的大部分数据流量和应用功能.用户对网络资源的需求不断增大, 导致了数据中心的规模越来越大.作为数据中心的基础设施, 数据中心网络(data center network, 简称DCN)由于其拓扑结构和传输能力的限制, 使其在当前背景下实现用户所需的性能受到了前所未有的挑战.目前, 国内外互联网巨头, 包括Amazon、Google、Facebook、Microsoft、Baidu、Alibaba等, 针对自己不同的性能需求, 实现了其内部数据中心的数据存储、网络搜索以及大范围的网络计算等功能, 为自己的用户提供了满足需求的保障.传统网络发展的半个世纪以来, 涌现了许多提升网络传输性能并提高用户体验的机制, 包括各种TCP版本和QoS机制等.然而, 数据中心的特殊性使得这些机制并不能直接应用或效果很差.因此, 为了使数据中心提供更好的服务, 关键在于针对数据中心网络设计专门的负载均衡策略.
数据中心承载了不同用户的不同需求, 对于不同用户的不同应用流量, 理想情况下是为这些流量提供差异化服务.数据中心中的流量从其大小来看, 可分为大流和小流, 大小流的区分可根据流的传输数据量或流的持续时间来进行区别; 从应用层面来看, 可将流分为吞吐量敏感的流和时延敏感的流, 需为吞吐量敏感的流提供足够的带宽保障, 为时延敏感的流提供满足时延要求的调度; 从流的时域特性来看, 可将流分为突发流和稳定流, 稳定流可利用流量工程方法进行长时负载均衡, 而突发流的不稳定性会影响网络的整体性能.数据中心处理的流量种类繁多, 从总体来看, 数据中心最理想的状态是提供高吞吐量低时延的网络服务.对数据中心网络中的流量进行管理能够提高网络链路的整体利用率, 降低网络的拥塞情况, 减少传输过程中的重传, 因此设计合理、高效的数据中心网络负载均衡方案十分关键.数据中心与传统互联网有较大不同, 具有以下几个特点.
(1) 结构化的拓扑.为提高数据中心服务能力, 并实现更好的网络可扩展性, 数据中心网络采用结构化的、规整的拓扑来连接数据中心中的服务器.结构化的拓扑可以提供有保障的传输能力, 并降低了网络的扩展难度.典型的结构化的数据中心网络拓扑包括Clos[
(2) 易获取的流量需求.数据中心由服务供应商进行维护, 为自己或用户提供服务能力, 以满足不同应用的需求.因此, 数据中心容易获得进入及离开其网络的流量统计信息, 以及不同应用类型在其网络内部传输的流量.对于大部分应用来说, 流量需求是可获知的, 因此可利用已获得的网络流量信息, 感知网络的传输情况, 从而执行相应的负载均衡机制, 实现最优的流量部署.
(3) 统一的管理机制.数据中心一般具有统一规格的网络设备以及一致的管理策略.运营商为网络设备设置计划的配置, 部署相应的管理策略, 并统一进行维护和升级.因此, 在数据中心中设计专用的负载均衡方案, 相较于互联网来说能够更容易地部署, 管理难度和开销也更小.
数据中心的特殊性使得为其设计专有的负载均衡方案成为当前数据中心网络的研究热点.现有的数据中心网络负载均衡方案充分利用了数据中心的特点, 在互联网负载均衡机制的基础上进行方案改进或重新设计, 以解决数据中心网络对于高带宽低时延的根本需求.然而, 随着数据中心规模的不断扩大, 以及数据中心承载的功能的不断增加, 原来满足需求的数据中心网络负载均衡方案难以实现新的目标, 因此, 在新的应用场景下设计合适的负载均衡方案亟待研究.已有的负载均衡机制从4个层面进行考虑, 即网络层、传输层、应用层和综合方案.网络层负载均衡方案中, 利用数据中心中的网络设备对网络状态和流量信息进行收集, 实现流量的合理调度; 传输层方案则从主机端对数据中心网络状态进行感知, 调整发送端的发送速率或动作使得数据中心网络不出现或少出现拥塞情况, 以此实现网络的负载均衡.应用层主要针对应用相关的服务器之间的负载均衡, 通过不同的流映射机制平衡服务器的负载, 从而保证数据中心的服务能力.综合方案则是通过跨层设计来提升数据中心网络负载均衡效果, 保证传输性能.这些类型的负载均衡方案从不同层次来实现数据中心网络的高吞吐量低时延需求.本文对这些方案进行了总结, 并对比了方案之间的联系、差异以及优缺点等.已有的数据中心网络负载均衡方案并不能适用于所有应用场景, 在不同的网络环境中, 设计怎样的负载均衡策略需要进一步的探讨.
本文对数据中心网络的负载均衡方案进行了深入分析.首先, 列举了数据中心网络负载均衡方案设计过程中存在的挑战, 包括网络动态性、拥塞感知难度、包乱序、设备故障以及方案可部署性等几个方面的问题.然后, 将目前已有的数据中心网络负载均衡方案分为网络层、传输层、应用层和综合方案4类, 并对各层实现方案根据负载均衡粒度或不同负载均衡目标进行细分, 对各种类型的负载均衡机制进行详细的分析, 对比不同负载均衡机制的优缺点.之后, 在这些分析的基础上, 将各方案从不同优化角度、有效性、可扩展性和部署难度等方面进行评估, 总结各个机制的性能差异.最后, 总结已有的数据中心网络负载均衡机制, 并提出了设计数据中心网络负载均衡机制的新思路, 为负载均衡机制提供了可行的研究方向.
本文第1节对数据中心网络中设计负载均衡方案存在的挑战进行阐述.第2节对已有数据中心网络负载均衡方案进行分类, 对各个方案进行总结并比较各个方案的优缺点.第3节对已有数据中心网络负载均衡方案进行对比和评估.第4节对本文进行总结, 并提出未来设计数据中心网络负载均衡方案可能的研究方向.
数据中心网络作为连接数据中心服务器的基础结构, 其传输性能的好坏直接决定了数据中心的服务能力.由于目前数据中心的复杂性和多样性, 使得设计满足要求的数据中心网络负载均衡方案具有一定的挑战.
(1) 流量动态性.数据中心网络的流量是动态变化的.数据中心中少部分的大流产生了网络中的大部分流量, 大部分的流为小流, 持续时间为几百毫秒; 同时, 大部分的流量在rack内部传输, 一个rack内每秒的动态流可能达到10 000条[
(2) 拥塞感知难度.负载均衡的目的是实现网络资源的充分利用, 从而增大网络的传输能力.因此, 负载均衡实现过程中首先要针对网络状态进行感知, 对目前网络中各链路或各路径的拥塞情况进行度量, 从而为数据包决定合适的传输端口.由于数据中心网络流量特有的高动态性, 使得对网络拥塞的感知具有时滞性, 即当前感知到的拥塞信息为过时的状态, 在集中式的负载均衡方案中, 这种影响尤为明显.因此, 在负载均衡方案中, 感知网络拥塞情况的准确性和及时性直接决定了负载均衡的性能.
(3) 包乱序.大多数网络负载均衡方案基于流粒度进行调度, 基于流粒度的方案难以接近网络流模型的最优性能.数据中心中由于拓扑存在等价多路径, 因此性能较好的数据中心网络负载均衡方案一般基于比流更小的粒度进行调度, 在多个路径上进行数据传输.由于传输层协议的确认机制, 这类将流进行分割后传输的方案会造成数据包的乱序问题, 即接收端接收到的数据包顺序错乱.传输层将乱序包的确认视为网络丢包并进行重传, 严重降低了数据的传输效率, 增大了流的完成时间, 同时也降低了网络吞吐量.因此, 如何在提高网络吞吐量的同时减少包乱序, 或设计相应机制降低包乱序的影响, 是在设计数据中心网络负载均衡方案中必须考虑的问题.
(4) 设备故障.数据中心中部署着大量网络设备, 随着网络规模的不断扩大, 设备出现故障的情况变得频繁.网络设备故障对数据中心数据传输有很大影响, 尤其是转发设备的故障会导致连接的中断, 降低了数据传输的吞吐量, 增大了网络时延.当网络设备发生故障后, 负载均衡方案需及时对故障情况进行响应, 对网络中被影响的流量进行重新调度, 以实现网络的最优传输.因此, 在设计数据中心网络负载均衡方案时, 需考虑对网络故障情况的响应, 避免由于网络故障导致网络特性变化而影响负载均衡方案的性能.
(5) 部署难度.数据中心虽然由运营商进行统一管理, 但实际维护过程中, 数据中心网络的升级并不十分频繁, 而且在数据中心规模庞大的情况下, 难以进行统一的更新.同时, 数据中心网络设备替换周期较长, 一些新的技术无法在旧的网络设备中实现.因此, 在设计数据中心网络负载均衡方案过程中, 需考虑方案的可部署性, 避免对网络进行较大规模的改动, 同时还需要考虑方案在实际部署过程中的成本开销等.
数据中心的特性, 使得数据中心网络负载均衡方案的设计具有较大的挑战性, 需要综合考虑网络的结构特点和流量规律, 并要兼顾实际部署过程中方案的可实现性, 因此需要进一步的深入研究.
现有的数据中心网络负载均衡方案种类繁多, 国内外学者从不同角度和不同层面设计了相应策略[
数据中心网络负载均衡方案分类角度
The classification of load balancing schemes in data center networks
数据中心网络由于规则的拓扑, 端到端之间存在多条等价路径, 因此通常采用ECMP[
(1) ECMP
数据中心网络存在多条等价转发路径, 使得负载均衡机制能够将流量均匀分配到各个路径上, 实现网络传输能力的最大化.ECMP是数据中心网络中最常用的负载均衡方案.其在交换机本地实现哈希机制, 交换机对到达数据包的包头域, 比如五元组(包括了源IP地址、目的IP地址、源端口号、目的端口号以及协议号), 进行哈希, 然后根据哈希结果选择相应的转发端口进行数据转发.ECMP本质上是基于流的转发策略, 其对相同流的五元组有相同的哈希结果, 保证了流的转发一致性.同时, ECMP是一种主动的负载均衡机制, 其主动地进行流哈希, 不感知网络拥塞情况, 对哈希结果的好坏不进行评价.ECMP在数据中心中的流量都是小流的情况下, 性能很好且可接近最优的网络传输性能.然而, ECMP在采用哈希机制的过程中, 会出现哈希冲突的情况.因此当网络中存在大流时, ECMP会出现大流冲突的现象, 即多条大流哈希到同一条链路或路径, 导致网络拥塞的情况发生, 从而降低网络的吞吐量.虽然ECMP具有明显的缺点, 但其简单且可部署性好, 使其在数据中心网络中被广泛采用.
(2) WCMP
WCMP是针对ECMP存在的不平衡问题而提出的一种加权哈希负载均衡方案.ECMP机制设计过程中假设网络拓扑是对称的, 网络中的流量是平衡的.然而实际情况中, 这些假设大都无法满足.数据中心中由于网络设备的异构性或设备故障的发生, 会导致网络产生不对称的情况; 同时, 数据中心中由于不同功能的服务器在机架上的部署, 使得网络中的流量不是均匀分布的.在这些情况中采用ECMP进行负载均衡会造成网络传输的不平衡, 降低网络的性能.WCMP对ECMP机制进行改进, 利用权重对流哈希产生的交换机端口进行权重选择.网络中利用中央控制器进行网络状态感知, 当发现网络出现不平衡性时, 中央控制器计算出最优的权重分配并发送给相应交换机, 交换机本地修改哈希权重执行数据包转发.WCMP可以通过修改权重的方式来应对各种网络不平衡的情况.然而, 由于其采用集中式的网络状态感知方式, 对不对称情况的感知有一定的周期, 因此在动态性较大的数据中心中难以迅速响应网络的变化.但总体上来说, 其能在一定程度上满足网络负载均衡的需求.
基于网络层的数据中心网络负载均衡方案是最直接、有效的解决方案, 其通过修改数据包或流的调度机制直接影响网络中链路或路径的利用率.从负载均衡粒度角度来分, 粒度从小到大可将网络层的负载均衡方案分为包粒度、flowlet粒度、flowcell粒度和流粒度等, 其分类结果如
网络层方案分类结果
The classification results of the schemes base on the network layer
基于包进行的负载均衡机制理论上是最优的策略.包作为网络传输的基本单元能够最大限度地平衡各链路的负载.然而, 由于包乱序问题的存在, 基于包粒度的负载均衡机制仍有许多问题需要解决.目前, 典型的网络层基于包粒度的数据中心网络负载均衡方案包括DRB[
(1) DRB
DRB(位逆转反弹)利用数据中心中Clos拓扑的结构特点实现基于包粒度的网内负载均衡.终端选择每个包转发路径时, 选择Clos拓扑的顶层交换机作为反弹交换机, 以确定上行转发路径和下行转发路径.因此, DRB通过基于位逆转的顶层交换的选择策略, 实现了包发送过程中链路的交错选择, 从而实现了各链路的负载均衡, 减少了网络中的排队长度以及避免了包乱序现象的出现.部署过程中, DRB采用IP-in-IP包封装技术实现与顶层反弹交换机的数据交互, 利用静态路由实现封装报文转发, 并设计专门的拓扑更新协议实现终端对网络状态的感知.与传统的RB(随机反弹)、RRB(轮询反弹)和ECMP相比, DRB能够实现更大的吞吐量、更短的排队长度、更低的排队时延以及更小的RTT时间.与MPTCP相比, DRB可在保证较高网络利用率的同时实现更低的平均时延.与DeTail相比, DRB在吞吐量和时延方面的性能都更好.DRB是一种主动负载均衡技术, 通过网络结构特性平衡流量, 然而, 其无法对网络的拥塞情况进行感知, 需要结合TCP实现终端的发送速率调节来处理网络拥塞情况.同时, 在网络非对称情况下, DRB的负载均衡性能取决于其对网络变化的感知速率.
(2) RPS
利用数据中心网络对称拓扑的特点, 以及TCP的重复ACK和DSACK机制对少量乱序包的容忍能力, RPS将流的每个包随机地通过所有等价路径进行发送.相同的源和目的地路径上的链路可组成一个等价类, 等价类中的链路组成的路径具有相似的队列状态, 因此能够保证近乎相等的时延.在网络对称的情况下, RPS在不同的过订阅率和不同的流量模式场景中, 相比于ECMP和MPTCP都具有更大的吞吐量和更小的流完成时间.此时, 网络中各路径的排队长度差别很小, 而且RPS造成的重复ACK相较于ECMP也要少.然而实际数据中心网络中经常存在非对称的情况, 此时, RPS利用的对称拓扑特性被破坏, 造成乱序包大量增加, 从而大大降低了网络吞吐量.RPS对被非对称影响的所有流的包进行标记, 设计SRED机制在交换机中对标记的包执行RED策略, 实现主动的队列管理, 从而保证路径时延的近似.通过非对称场景下的实验验证了SRED的性能, 相比于Droptail和RED机制能够实现更高的吞吐量和更小的流完成时间, 相比于MPTCP也具有明显的优势.然而, 由于非对称场景出现情况复杂, RPS的队列管理机制可能造成网络利用率下降, 而且SRED的丢包会进一步降低网络吞吐量.
(3) DRILL
DRILL是一种分布式的、随机的网内本地负载均衡机制, 在交换机本地存储对称路径集合.当一条流的包到达时, DRILL利用power-of-two-choices[
数据中心网络流量具有一定的特性, 通过分析TCP传输层协议的流量发送特点, 发现TCP的突发流量会造成flowlet的出现.Flowlet的定义是一条流突发的包集合[
(1) CONGA
CONGA是一种拥塞感知的分布式负载均衡方案, 其大部分功能在数据中心网络边缘交换机实现.在典型的叶脊拓扑中, CONGA在叶子交换机中维护Congestion-To-Leaf和Congestion-From-Leaf两张表来实现路径的选择和网络状态的存储, 同时在本地维护flowlet表并根据网络情况设定的阈值实现flowlet的检测.当流的包到达时, 叶子交换机查找本地flowlet表并根据表项中的出端口进行转发; 否则, 交换机在所有可行的出端口和Congestion-To-Leaf表中选择最不拥塞的出端口进行转发.CONGA利用不同源和目的地对之间传输的包实现路径拥塞情况的检测, 利用基于VXLAN[
(2) CLOVE
现有的数据中心网络负载均衡机制需要更新网内交换机或是改变虚拟机网络栈, 会带来很大的成本开销和更新周期.CLOVE从网络边缘角度出发, 在虚拟机控制程序上实现位于虚拟边界的拥塞感知的负载均衡机制.在CLOVE中, 数据中心网络仍然采用现有的ECMP转发技术, 负载均衡中的路径发现和选择以及拥塞感知都在虚拟机监控程序上实现.虚拟机监控程序发送具有不同的源端口号和生存时间的探针以发现源和目的地之间的路径.利用ECMP五元组哈希的不同结果, 将源端口号和不同路径进行映射.在虚拟机监控程序中实现基于flowlet的调度, 每个flowlet的转发路径根据拥塞情况进行权重路由, 拥塞感知可利用ECN或INT[
(3) HULA
由于CONGA在边缘交换机保存大量拥塞状态, 从而限制了其可扩展性, 并且CONGA在硬件中的实现导致其存在不小的部署开销和难度, 因此提出了HULA, 一种分布式的、单跳的负载感知的架构以实现数据中心网络负载的均衡.HULA中, 每个交换机维护路径利用率表, 表中存有Dst_ip、Best hop和Path util, 分别表示对应的ToR的IP地址、发往该ToR的最优下一跳出口以及该出口到ToR路径的最大链路利用率.类似传统距离向量协议, 路径拥塞状态在ToR之间进行逐跳传播, 交换机只知道到达目的地的最优路径下一跳出口.路径状态感知过程中, ToR交换机周期性地发送设计的探针, 其中包含torID(24 bits, 表示发出探针的tor)和minUtil(8 bits, 表示最优路径的最小利用率), 当探针到达交换机后, 会将其对应入口的出口利用率和原minUtil中的较大值保存在minUtil中, 更新后交换机复制该探针并向其邻居发送.所有交换机执行相同策略, 从而实现拥塞信息的传播.HULA以flowlet粒度进行负载均衡, 交换机本地维护flowlet表, 新的flowlet到达后根据路径利用率表选择最优下一跳进行该flowlet包的发送.为了降低部署难度, HULA采用P4[
(4) LetFlow
LetFlow充分发掘flowlet对拥塞自适应的特性, 提出一种非常简单的交换机本地决策的flowlet负载均衡方案.通过对数据中心网络流量的观察, 发现flowlet的大小能够直接反映网络的拥塞情况, 拥塞严重的路径其flowlet更小, 不拥塞的路径其flowlet更大.因此利用flowlet自身特性能够实现自适应的决策.在交换机本地维护flowlet表并进行flowlet检测, 然后为每个新的flowlet在所有可行出口中随机选择一个出口进行转发.通过这种简单的机制, 能够保证拥塞路径上的flowlet数据逐渐转移到更不拥塞的路径上, 从而实现负载均衡.在不同的数据集中进行比较, LetFlow相比于ECMP和CONGA, 能够实现更小的流完成时间.在网络非对称情况下, LetFlow也能达到最优的性能.同时, LetFlow对不同的传输层协议具有很好的鲁棒性.LetFlow机制非常简单, 其在交换机中造成的硬件开销相比于已有机制小很多, 同时能够实现非常好的性能.但是flowlet的拥塞后感知的缺点使其无法对网络的突发拥塞进行感知, 需要等到网络拥塞后造成新的flowlet出现时才能进行处理, 因此对于需要处理突发流的情况难以满足性能要求.
已有的flowlet机制能够很好地感知网络的拥塞情况, 但存在几个缺点.一方面, flowlet大小不固定, 不拥塞的路径上一个flowlet的数据量很大, 拥塞路径上一个flowlet的数据量很小, 网络中存在不同大小的flowlet, 使得对flowlet的调度存在难度.另一方面, flowlet调度是网络出现拥塞后进行的调度机制, 当交换机感知到flowlet后网络已经产生了拥塞或丢包, 这种被动机制一定程度上会降低网络的传输性能.为了避免flowlet的缺点, He提出基于大小相等的flowcell进行负载均衡的方案[
(1) Presto
Presto是一种在边界虚拟机监控程序执行基于flowcell粒度的主动负载均衡方案.该方案源于ECMP对小流可实现接近最优性能的思考, 在端系统将流量分成大小一致的flowcell进行多路传输.在边界虚拟机监控程序中, 将虚拟机发送的流量分割成与网络场景相关的、固定大小的flowcell, 考虑到现有虚拟机的TCP协议中TSO(TCP segment offload)大小为64KB, 因此选择flowcell的大小为64KB来减少小流被分割的可能性.在实现多路传输的过程中, 将网络中各路径进行标签化, 并在虚拟机监控程序采用shadow MAC[
基于流粒度进行调度是大多数负载均衡方案的策略.这类方案主动或被动地对网络每条流执行路径选择.通过集中式或分布式机制感知网络当前负载情况, 对网络中传输的流进行路径选择.当网络状态发生变化后, 通过预定策略选择部分流进行整体迁移, 从而实现网络的负载均衡.目前, 典型的网络层基于流粒度的数据中心网络负载均衡方案除了ECMP和WCMP之外, 还包括:Hedera[
(1) Hedera
Hedera是一种集中式的、可扩展的动态流调度系统, 其利用一个中央控制器从边界交换机中收集网络的流量信息, 并分析网络中存在的大流以实现大流的调度, 从而实现网络的负载均衡.Hedera利用估计算法实现网络大流的检测, 根据从边界交换机获取的流量信息迭代地计算各边界交换机对间所有流的稳态带宽需求, 并将超过链路带宽一定阈值的流视为大流, 在调度过程中为计算出的大流重新选择路径.Hedera设计了两种大流路径选择算法:Global First Fit和模拟退火算法.Global First Fit算法中, 调度器维护链路的剩余带宽, 并为每个大流选择第1个可行的路径进行迁移.模拟退火算法则对所有可行路径空间进行搜索, 尽量选择最优的路径实现调度. Hedera提出的集中式控制机制对大流的负载均衡非常有效, 在不同的流量模式场景下, Hedera相比于ECMP, 具有更大的平均对半带宽, 可接近最优性能.由于Hedera是一种集中式的控制机制, 因此其需要收集的网络状态很多, 在现有信息获取机制下, 会造成非常大的传输开销.Hedera中采用OpenFlow协议进行数据收集和路径安装, 受限于现有设备的性能, 调度器只能实现5s周期的调度, 使其无法处理流量变化迅速的网络场景.
(2) MicroTE
由于数据中心网络流量具有短期的部分可预测性, 因此可利用该特性优化流量的部署.MicroTE是一种细粒度的流量管理机制, 其通过分析ToR交换机对之间流量的可预测性, 对可预测的流量进行细粒度调度.在服务器实现本地流量信息采集, 并每隔一定时间(如:0.1s)将本地流量发送到指定的服务器进行流量信息的聚合以及流量可预测性分析, 然后指定服务器再周期地向中央控制器通告聚合后的ToR对之间的流量信息.中央控制器生成全局流量信息, 并利用装箱启发算法对可预测的流量进行最优路径选择.对不可预测流量则根据可预测流量路径选择后的剩余网络带宽能力, 执行加权的ECMP调度策略.在不同的网络拓扑中, MicroTE相比于ECMP具有更高的带宽利用率, 且十分接近最优的带宽利用.在不同的流量可预测程度下, MicroTE都能接近最优性能, 且能尽量避免ECMP造成的丢包情况的发生.同时, 在网络可预测性不高的情况下, MicroTE与ECMP能够实现无缝衔接, 因此其具有很好的可扩展性.然而, 网络状态采集仍然是控制器决策的瓶颈, 秒级粒度的调度无法处理突发流的情况, 而且利用服务器进行信息采集不可避免地会带来巨大的开销.
(3) Mahout
为实现网内不同流量类型的差异化调度, Mahout对网络中的大流和小流采取不同的调度策略来实现数据中心网络的负载均衡.Mahout在终端检测socket的缓存大小, 将缓存超过一定阈值的流视为大流, 周期性地(如:1s)将大流的包进行标记, 通过这种带内信号的方式实现大流通告.当边界交换机接收到包时, 若没有标记, 则该包对应的流为小流, 交换机对小流执行ECMP策略进行转发; 若该包属于大流, 则交换机会将该包复制并发送给中央控制器, 由中央控制器进行大流管理.控制器利用Increasing First Fit[
(4) Devoflow
Devoflow是一种集中式和分布式相结合的负载均衡方案, 其将大部分流的控制转移到交换机中以减小控制器的开销以及网络的响应时间.Devoflow尽量在交换机本地实现网络中小流的路径选择, 利用OpenFlow协议的通配符特性, 设计本地路由克隆机制.当新流到达后, 数据包会匹配通配符直到该流表匹配超过一定阈值后, 交换机会本地克隆该流表来为命中的流生成新流表, 并根据概率分布为新流表在多个可行端口中选择转发出口.同时, 交换机本地对流表阈值进行检测, 当其匹配命中数据大于一定阈值后, 将该流视为大流并通报给控制器, 控制器为该流选择最不拥塞的路径进行重路由.在不同拓扑和数据集中, Devoflow相较于ECMP能够实现更大的吞吐量, 提升的效果与不同的数据集类型相关.相较于基于拉状态的机制, Devoflow与控制器之间的报文交换数据量很小, 同时其在交换机中需要的流表数量也很少, 因此Devoflow的可扩展性非常好.Devoflow尽量将流的处理在网络数据平面中完成, 因此能够更快地对网络进行本地响应.但是由于集中式机制固有的缺点, 使其对网络变化不敏感, 交换机不具有全局状态, 使得提升出口选择效果成为难点.
(5) LocalFlow
LocalFlow是一种交换机本地的负载均衡方案, 其利用装箱算法将流分配到各个端口实现传输.网络中每个交换机都周期性地(如:10ms)执行调度过程, 测量本地流量的速率, 根据速率和出端口数量执行装箱算法, 从而实现流的放置.算法将聚合流量均匀地分配在各出端口, 并对无法放置的流量进行分流, 当剩余能力填满后将剩下的流量继续分配, 同时利用松弛条件减少分割流的数量, 尽量保证小流不被分割.当网络发生故障造成不对称时, 交换机通过底层协议进行感知, 并在调度过程中简单地修改箱子数量大小来实现流量重平衡.实际部署中, LocalFlow设计多精度的分割, 采用扩展的匹配头或OpenFlow中的流表计数器实现精确的流分割, 并与端系统TCP协议相配合, 降低包乱序所带来的影响.在不同的拓扑中, LocalFlow可以实现近优的吞吐量, 相比于ECMP、MPTCP和CONGA, 具有明显的吞吐量提升.相比于简单的包散射机制, LocalFlow具有更少的流分割, 从而实现更小的流完成时间.适当增加TCP的重复ACK阈值能够有效地避免受到包乱序的影响.同时, 低的流分割的精度会降低LocalFlow的性能.LocalFlow是一种主动的拥塞避免机制, 利用灵活的负载感知的流分割来实现网络负载均衡.但是由于其无法感知网络的拥塞信息, 因此对拥塞不敏感.同时, 其通过底层协议进行故障检测, 使不同交换机对不对称情况感知存在时延差异, 可能造成短时间的流量黑洞, 从而导致性能下降.
(6) FlowBender
Flowlender是一种在端系统本地实现的负载均衡机制.现有数据中心采用ECMP实现流的哈希转发, 在不改变交换机硬件的条件下, FlowBender通过在交换机执行扩展的哈希来实现流的路径选择.将原有的哈希函数从五元组扩展为五元组加上TTL(time-to-live)值, 并在端系统利用已有的ECN标记和TCP超时时间来检测每条流的拥塞情况, 根据策略修改拥塞流的TTL值以实现流的换路.为了减少路径切换和包乱序情况的出现, FlowBender在每个RTT时间都对接收到的拥塞信息进行评价, 并设计拥塞感知阈值以提高拥塞感知的准确性.在3层Fat-Tree拓扑的仿真中, FlowBlender相比于ECMP能够实现更小的流完成时间.在不同负载情况下, FlowBender相比于DeTail具有更小的流延迟, 接近RPS的性能.在测试床实验中, FlowBender在不同的网络负载情况下, 相比ECMP能够有效地减小流的时延, 随着负载的增加, 优化效果更明显.FlowBender是一种简单、有效的负载均衡机制, 部署成本低, 效果好.但其扩展的哈希不能保证改变TTL值一定就能改变转发路径, 因而会延长拥塞响应的周期, 造成拥塞处理不及时.而且, 基于ECN和TCP超时来感知网内拥塞无法处理流量动态性强的场景.
(7) Freeway
数据中心网络存在不同的流量需求, 吞吐敏感和时延敏感的流量对于网络路径的时延要求不同.Freeway是一种将大流和小流隔离后进行传输的方案.其利用数据中心网络拓扑的等价路径特性, 将网络中的ToR对之间的路径根据路径的利用率和排队情况分成低时延路径和高吞吐路径.利用SDN网络中的控制器收集网络中各链路的利用率信息, 将网络中的ToR路径根据核心交换机的位置分为固定数量的低时延路径和高吞吐路径, 剩余路径作为动态路径并根据网络流量情况在两类路径中进行切换.交换机接收路径类型信息并为小流作本地决策, 通过最不拥塞路径进行转发.端系统在发送大流前和控制器交互大流信息, 控制器根据优化算法为大流选择合适的路径并加以部署, 然后通知端系统发送相应数据.当网络中路径类型发生变化时, 执行对应的操作实现调度.在Fat-Tree拓扑中进行仿真, 实验中低时延路径和高吞吐路径的数量变化反映出Freeway对网络状态感知准确.在真实数据集场景下, Freeway相比于ECMP、Hedera和包散射方案能够实现更大的大流吞吐量和更小的小流时延, 同时能够保证更少的TCP超时事件.Freeway实现了大流和小流路径的隔离, 但如何在网络流量变化剧烈的情况下实现快速的路径分类需要进一步加以考虑, 将不同类型流量分开传输还可能导致出现链路利用率不高的问题.
(8) Expeditus
Expeditus充分利用Fat-Tree拓扑中聚合层交换机之间存在成对连接的特性, 提出了一种二阶段的分布式拥塞感知的负载均衡机制.数据中心网络中交换机对其上行链路的入口和出口拥塞情况进行本地测量.第1阶段中, 当一个流从源ToR交换机发送到目的ToR交换机时, 该流的第1个包到达源ToR后, 会将本地所有上行链路的出口拥塞信息携带在以太网包头中, 通过ECMP机制将包发送到目的ToR交换机.目的ToR交换机提取包头中的拥塞信息并与本地所有上行链路入口拥塞信息进行比较, 选择最不拥塞的目的聚合层交换机进行数据返回.第2阶段中, 当被选择的目的聚合层交换机接收到返回的包后, 其将本地所有上行链路入口拥塞信息携带在返回包中继续通过ECMP进行发送.源聚合层交换机接收到返回包后, 将包中拥塞信息与本地所有上行链路出口拥塞信息进行综合, 选择最不拥塞的核心层交换机安装转发规则.当第1个返回包返回源ToR交换机后, 该流的路径建立成功, 之后的包根据网内交换机安装好的转发规则进行传输.在不同的数据集实验中, Expeditus相比于ECMP具有更短的流完成时间.在不同的流量模式场景下, Expeditus相比于ECMP能够实现更高的吞吐量, 性能接近最优的调度机制.当网络存在不对称情况时, Expeditus仍可以实现网络的负载均衡, 性能好于ECMP.在2层叶脊网络中, Expeditus相比于ECMP和CONGA能够实现更短的流完成时间.Expeditus利用二阶段的ToR和聚合层交换机的选择来接近最优的路径, 在一个RTT时间内实现最不拥塞的路径部署.然而, 当网络动态性高且路径拥塞情况不稳定时, 对各路径的拥塞情况感知不及时会降低路径选择的效果.
(9) Scheduling Algorithm
由于现有数据中心网络中经常出现非对称情况, 传统ECMP机制无法根据非对称状态调整流量分配策略, 因此, 基于网络状态的调度算法是解决这类问题的一种方法.Mehrnoosh等人提出一种在线不分流的低复杂度且具有拥塞感知的调度算法[
网络层方案设计针对性的网络流量调度机制或交换机转发策略, 通过不同粒度的传输管理来实现数据中心网络负载均衡目标.通过分析现有网络层方案, 从方案的关键设计和方案性能两个角度对各方案进行对比, 比较结果见
数据中心网络负载均衡网络层方案对比
The comparison of load balancing schemes based on the network layer in data center networks
方案 | 关键设计 | 方案性能 | ||||||||
特点 | 包标记 | 大小流 | 拥塞信息 | 非对称 | 突发流 | 失序 | 最优性 | 复杂度 | 速度 | |
DRB | 位逆转选择路径 | 无 | 无 | 无 | 不考虑 | 不考虑 | 无 | 无 | 低 | 快 |
RPS | 包散射 | 无 | 无 | 无 | 不考虑 | 不考虑 | 严重 | 无 | 低 | 快 |
DRILL | 交换机选择最不拥塞出口发送包 | 无 | 无 | 交换机队列 | 考虑 | 考虑 | 可能 | 本地 | 一般 | 快 |
CONGA | 边界交换机维护flowlet并选路 | 有 | 隐含 | 包携带 | 考虑 | 不考虑 | 可能 | 全局 | 高 | 一般 |
HULA | 交换机维护最优路径下一跳 | 有 | 隐含 | 探测包 | 考虑 | 不考虑 | 可能 | 全局 | 高 | 一般 |
CLOVE | 端系统为flowlet选路 | 无 | 隐含 | ECN标记 | 考虑 | 考虑 | 无 | 全局 | 一般 | 一般 |
LetFlow | 交换机本地为flowlet选路 | 无 | 隐含 | Flowlet间隔 | 考虑 | 不考虑 | 可能 | 本地 | 一般 | 一般 |
Presto | 端系统为flowcell选路 | 有 | 隐含 | 无 | 考虑 | 不考虑 | 可能 | 无 | 一般 | 快 |
ECMP | 交换机本地哈希 | 无 | 无 | 无 | 不考虑 | 不考虑 | 无 | 无 | 低 | 快 |
WCMP | 交换机本地执行权重哈希 | 无 | 无 | 无 | 考虑 | 不考虑 | 无 | 无 | 低 | 快 |
Hedera | 中央控制器周期性调度大流 | 无 | 显示 | 控制器收集 | 考虑 | 不考虑 | 可能 | 全局 | 一般 | 慢 |
MicroTE | 收集流信息并进行集中调度 | 无 | 显示 | 控制器收集 | 考虑 | 不考虑 | 无 | 全局 | 一般 | 一般 |
Mahout | 端侧检测socket并集中调度 | 无 | 显示 | 控制器收集 | 考虑 | 不考虑 | 无 | 全局 | 一般 | 一般 |
Devoflow | 交换机克隆规则, 控制器综合调度 | 无 | 显示 | 控制器收集 | 考虑 | 不考虑 | 无 | 全局 | 高 | 一般 |
LocalFlow | 交换机周期性利用装箱算法分配流量 | 无 | 无 | 交换机本地 | 不考虑 | 不考虑 | 可能 | 本地 | 低 | 慢 |
FlowBlender | 五元组和TTL值进行哈希选路 | 无 | 无 | ECN和包超时 | 不考虑 | 考虑 | 无 | 无 | 一般 | 快 |
Freeway | 路径分类执行全局和分布式选路 | 无 | 显示 | 链路利用率和排队情况 | 考虑 | 不考虑 | 无 | 全局 | 高 | 慢 |
Expeditus | 二阶段选路策略 | 有 | 无 | 包携带 | 考虑 | 不考虑 | 无 | 全局 | 高 | 一般 |
Scheduling Algorithm | 构建全局最优调度模型进行调度 | 无 | 无 | 控制器收集 | 考虑 | 不考虑 | 无 | 全局 | 高 | 慢 |
方案关键设计包括方案特点、是否对包进行标记、是否区分网络大小流进行差异化处理、如何获取网络拥塞信息、是否考虑网络非对称情况、是否设计机制克服突发流情况以及是否会造成传输失序等方面.从比较结果来看, 网内负载均衡方案为了获取网络状态通常会采用包标记来携带相应信息; 不进行包标记的方案通常为集中式状态采集方案或是主动负载均衡方案, 这类方案对网络状态感知较慢或不感知.集中式调度方案通常会显式地进行大流调度, 而基于flowlet调度的方案利用flowlet的特性隐式地实现了大小流的区分.对于分布式方案来说, 大多采用本地信息采集或网络反馈来获取网络状态; 而集中式的方案通常会对全网状态进行收集, 一定程度上会增加状态采集难度.现有网络层负载均衡方案大多通过全局网络信息考虑了网络非对称情况, 但大部分方案没有考虑突发流的处理, 只有依靠交换机本地信息或网络拥塞反馈的方案能够在一定程度上响应突发流情况.对于最关键的失序问题, 基于流粒度的确定的不分流的调度不会造成传输失序, 但对于动态调度的方案则有可能导致失序的出现, 尤其是包粒度的方案出现失序的可能性非常大.虽然基于flowlet的方案能够很大程度地避免失序情况的发生, 但大多数方案仍然需要修改传输层以降低失序带来的影响.
方案性能方面, 从方案的最优性、复杂度和方案执行速度这3个角度进行比较.集中式的方案通常具有网络的全局信息, 因此能够实现全局最优的调度策略; 分布式的方案一般都会根据本地采集状态进行决策, 但部分分布式方案会通过网络状态反馈等机制获取全局信息, 也能实现全局最优的决策.对于固定策略的负载均衡方案, 通常复杂度较低, 需要对网络多个部分进行修改的方案具有较高的复杂度.一般具有较低复杂度的方案能够实现更快的方案执行速度, 复杂度高的方案通常执行速度较慢.但一些集中式方案通常会部署相匹配的分布式策略, 通过综合的管理方式能够弥补集中式方案的低速缺点.
数据中心网络由于其拓扑特性存在多条等价路径, 因此将流量分发到多条路径是实现负载均衡目标的一种方法.传输层方案将网络中的流分成多条子流, 并通过子流的综合管理来调整各流的发送策略, 从而提高网络的吞吐量并实现较小流的完成时间.目前, 典型的基于传输层的数据中心网络负载均衡方案包括MPTCP[
传输层方案分类结果
The classification results of the schemes base on the transport layer
(1) MPTCP
为了利用数据中心网络的多路特性提高网络传输能力, 如何将流分配到多个路径传输并加以管理是关键. MPTCP是一种将流分成多个子流, 并利用多个TCP连接进行子流传输的数据中心流量传输方案.多个TCP连接综合进行流量管理, 通过修改端口或IP地址并结合数据中心网络常用的ECMP路由方式, 实现子流的多路传输, 并将流量向更不拥塞的等价路径进行转移, 从而实现数据中心网络的负载均衡.各个子流TCP的拥塞窗口变化遵循如下规则:当子流
(2) XMP
传统MPTCP方案利用多路特性实现高网络利用率, 而实际数据中心网络中存在不同的流量需求.理想情况下, 大流采用MPTCP而小流采用TCP进行传输.XMP结合网内的链路缓存占用率, 提出了一种平衡吞吐量和带宽的拥塞控制机制.XMP提出BOS算法, 结合ECN机制和网络的带宽时延积以修改子流的窗口, 通过调整子流发送速率从而控制链路的缓存占用率.同时, XMP还提出TraSh算法, 根据效用函数和平衡情况, 调整各子流窗口以实现流量从拥塞路径转移到不拥塞的路径.将BOS和TraSh算法相结合从而实现大流的高吞吐和小流的低时延.在测试床实验中, XMP对网络动态性具有快速的响应能力, 能够将流迅速地根据网络拥塞情况进行迁移.当拥塞控制参数设置合适时, XMP能够实现很好的公平性.在不同流量模式的仿真实验中, XMP相比于DCTCP能够实现更大的吞吐量, 且能够有效地处理多对一传输时吞吐崩溃的问题.同时, 在不同的RTT分布中, XMP也能实现最小的传输时间.XMP提出一种结合网内状态的多路传输的拥塞控制机制, 但其利用ECN进行拥塞感知的方式使其对突发流量不敏感, 而且拥塞控制的关键参数选择与网络流量分布情况和网络结构相关, 对不同场景需通过大量实验才能获得最优参数.
(3) RackCC
在数据中心网络中, 每条路径上都传输许多流, 因此, 相同路径被多条流探测过传输状态, 这种探测是在rack间的层次而不仅仅是端系统间的层次.为了消除重复探测造成的性能损失, RackCC实现了一种rack层次的拥塞控制机制, 将rack之间传输的流聚合成巨大流以执行rack间的传输层控制, 实现更好的公平性和传输性能. RackCC实现了快速的流启动、相同rack对之间流的公平分享以及多流协作的拥塞检测.其在ToR交换机上维护不同路径的ECN到达速率、子流数量以及吞吐量信息, 并周期性地通告连接到该ToR的端系统.RackCC的拥塞控制主要分为巨大流的拥塞控制和子流的拥塞控制, 根据接收端和发送端的约束, 子流发送速率变化为
(4) MMPTCP
传统MPTCP方案对数据中心网络中所有流进行多路传输, 然而, 对于时延敏感的小流来说, 多路传输会增大其控制复杂性和拥塞的概率, 从而延长了小流的流完成时间.MMPTCP提出一种二阶段的传输协议.在第1阶段, MMPTCP通过一个拥塞窗口将流的包随机地发送到网络中, 利用网络中的多路特性提高传输效率.当发送的包超过一定阈值时, MMPTCP进入第2阶段, 将继续发送的包通过正常的MPTCP进行传输.二阶段的方式可以在保证小流的完成时间的同时保证大流的吞吐量.为了处理包乱序问题, MMPTCP利用网络拓扑特性, 在端系统推测流量传输的路径长度, 从而自适应地调整该流对应的重复确认阈值, 降低包乱序造成的影响.在子流数相同的情况下, MMPTCP相比于MPTCP, 能够实现更小的短流完成时间, 同时能够保证大流的吞吐量不变, 还能维持较高的网络利用率和较低的丢包率.相比于TCP和包散射机制, MMPTCP也具有更好的传输性能. MMPTCP将包散射和MPTCP加以结合, 实现了差异化的传输和负载均衡效果, 但包散射造成的包乱序需要通过修改TCP重传机制来处理, 关键阈值的设计与网络状态相关联, 在动态性强的数据中心网络中是一个难以解决的挑战.
(5) VMS
现有的数据中心网络负载均衡机制需要修改网络设备或虚拟机协议栈, VMS则通过修改端系统部署的虚拟交换机, 在端系统传输过程中修改传输路径, 实现新的流量负载均衡方案.VMS在发送端部署VMS发送模块, 通过修改包的5元组中的源端口号为每个流的每个包选择不同的转发路径进行包散射传输, 并在接收端部署VMS接收模块对每个流的包进行还原并发送给相应虚拟机.在每个包的路径选择过程中, VMS采用虚拟窗口机制, 根据网内不同路径ECN的反馈情况选择具有足够传输能力的路径进行传输.VMS在流传输过程中维护流的状态, 并在连接断开时移除相应状态信息.在实验中对VMS的路径数进行评估, 表明8条路径即可实现可接受的性能.同时, VMS可实现非常接近MPTCP的性能, 而且设计的方案使其不易受网络拓扑非对称的影响.通过原型实验, 发现VMS与传统虚拟交换机方案的CPU开销相差不大.VMS提出在端系统虚拟交换机实现负载均衡减小了原有机制的成本开销, 降低了负载均衡方案部署的难度.然而, 在虚拟交换机进行负载均衡时需要对相关的虚拟机流量综合处理, 对于不同需求的流量无法获得差异化传输, 同时, 在网络高负载情况下, 发送端和接收端模块的协议栈优化需要进一步加以考虑.
(6) 传输层方案对比
传输层方案利用多路传输优势, 修改端侧协议栈以提高传输效率并实现数据中心网络负载均衡目标.通过分析现有传输层方案, 从方案的关键设计和方案性能两个角度对各方案进行了对比, 比较结果见
数据中心网络负载均衡传输层方案对比
The comparison of load balancing schemes based on the transport layer in data center networks
方案 | 关键设计 | 方案性能 | ||||||
特点 | 控制类型 | 控制因素 | 大小流 | 多阶段 | 状态数 | 差异化 | 复杂度 | |
MPTCP | 多子流TCP传输 | 窗口 | 丢包 | 不考虑 | 无 | 少 | 不考虑 | 低 |
XMP | 大流采用MPTCP传输, 小流采用TCP传输 | 窗口 | ECN、带宽时延积 | 考虑 | 无 | 一般 | 考虑 | 一般 |
RackCC | ToR之间巨大流控制 | 速率 | 路径探测信息 | 不考虑 | 无 | 多 | 考虑 | 高 |
MMPTCP | 二阶段MPTCP传输 | 窗口 | 发送量、拓扑特性 | 考虑 | 有 | 一般 | 考虑 | 一般 |
VMS | 端侧包散射 | 窗口 | ECN | 不考虑 | 无 | 一般 | 不考虑 | 一般 |
方案关键设计从方案特点、拥塞控制类型、拥塞控制影响因素、大小流差异化处理和是否多阶段控制等几个方面进行比较.传输层方案都是通过多路管理来平衡网络中的数据传输性能, 多路之间拥塞控制通常采用传统TCP中的拥塞窗口进行控制; 随着新型协议栈的出现, 也使得基于发送速率的控制被应用到传输层方案中, 相比于基于窗口的方案能够更快地达到均衡目标.大部分传输层方案采用常用的拥塞控制影响因素, 包括丢包和ECN等进行发送状态调整; 部分方案还考虑了网络结构特性或进行网络状态探测, 这类方案对网络状态感知相对准确.早期传输层方案通常不考虑大小流对传输的影响, 由于小流在多路传输情况下受影响较大, 因此后续方案通常实现了大小流的单独处理, 部分方案还设计了多阶段的处理方式, 进一步提升了传输性能.
在方案性能方面, 对传输层方案需要维护的状态数、是否实现了差异化管理以及方案复杂度等几个方面进行对比.大部分传输层方案维护的状态数不多, 但部分方案的拥塞管理与网内状态紧密相关, 因此会产生较多的状态维护需求.大部分方案考虑了网内的差异化管理, 显式或隐式地对大流和小流进行差异化处理, 实现大小流之间的公平.考虑不同传输层方案的管理开销和对网络的修改程度, 大部分方案不具有很高的复杂度, 但是对于网内多部分配合的方案, 其高复杂度会降低方案的可部署性.
数据中心中部署大量服务器来执行不同任务, 因此不同任务的流需要调度以实现相应的需求.从应用角度执行负载均衡决策是最能满足应用需求的方式.数据中心网络中服务器之间的负载均衡是最经典的负载均衡问题.数据中心中部署大量不同应用的服务器来提供不同类型的服务.当某个应用的流到达数据中心后, 数据中心需要将该流路由到某个服务器进行处理, 由于服务器负载情况的不同以及网络状态的变化, 将流导入不同的服务器会造成不同的开销和性能, 尤其是服务器的利用率会导致不同的流处理完成的时间, 从而直接影响服务的完成质量.因此, 实现服务器之间的负载均衡能够提高数据中心的服务能力, 并保证数据中心的健壮性.目前, 典型的数据中心服务器负载均衡方案包括Ananta[
应用层方案分类结果
The classification results of the schemes base on the application layer
(1) Ananta
Ananta实现了多租户云平台中可扩展的软件负载均衡器和NAT, 其将网络分成3层:顶层是路由器, 在网络层基于ECMP实现负载分发; 第2层是Mux, 即一系列可扩展的专用服务器来实现负载均衡, 其在内存中维护网络连接的状态并实现应用服务器的4层负载均衡; 第3层是虚拟交换机, 通过在每个服务器中部署虚拟交换机来提供有状态的NAT功能.Ananta设计了可扩展的网内处理机制, 使网内多个网络元素能够同时处理相同VIP的包, 从而不需要同步地维护每个流的状态; 并下放部分功能到端系统, 让端系统只维护本地虚拟机的状态, 从而提高Ananta在数据中心的可扩展性.当一条流到达云数据中心后, 路由器会将流路由到Mux, 然后Mux为该流选择并记录DIP后利用IP-in-IP的封装机制将包发送到端系统, 由端系统的HA(host agent)进行解析.当流从数据中心内部向源返回数据时, 端系统会与AM(ananta manager)交互来选择路由以实现绕过Mux的快速路径转发, 从而降低Mux的负载并实现更快速的数据传输.通过性能测试, 发现Ananta的快速路径返回机制能够有效地减少Mux的CPU开销, 同时更高的Mux的CPU利用率会延长其检测SYN洪泛攻击的时间.在实际公有云的部署中, 绝大部分SNAT端口分配可以得到及时的响应, 并且Ananta在长时间内可维持较高的可用性, 从不同Mux的带宽和CPU利用率来看, ECMP可以实现Mux之间均匀的负载均衡.Ananta通过软件负载均衡机制实现了很好的扩展性, 然而, 软件负载均衡器受限于其处理能力, 其性能是否匹配得上流量的增长, 还需要进一步加以验证.
(2) Duet
为了克服软件负载均衡器固有的有限能力和高处理时延的缺点, Duet提出一种将硬件负载均衡器(Hardware Mux, HMux)和软件负载均衡器(Software Mux, SMux)相结合的可扩展的负载均衡策略.利用现有商业交换机中已实现的ECMP和隧道机制, 在剩余的表项中维护一定数量的VIP-DIP映射, 在每个HMux中维护部分VIP集合以及对应的所有DIIP表项, 并在交换机之间利用BGP通告VIPs来保证其他交换机能够根据VIP路由到该交换机.同时, Duet在网络中部署少量SMuxes, 每个SMux中维护所有VIPs信息以实现灵活性并保证高可用性.Duet设计贪婪算法实现在不同存储能力和带宽约束情况下VIPs在交换机之间的分配, 并利用SMuxes的部署来提高网络的故障容忍能力.测试结果表明, Duet能够实现低时延并保证高可用性, 同时能够有效地处理故障情况, 在VIP迁移过程中可以快速地对网络情况进行响应.在不同的流量场景中, Duet相较于Ananta只需要更少的SMuxes就能达到需要的性能, 并能实现更低的处理时延.在故障情况下, Duet能够实现平滑的过渡, 从而保证最大链路利用率的稳定性.Duet充分利用了现有交换机的剩余能力, 因此部署成本低, 具有较高的容量和较低的处理时延, 可实现高可用性.由于利用分布式方式实现VIPs在HMuxes中的存储, 因此不同场景中需要设计合适的分配算法以实现期望的负载均衡效果.
(3) Maglev
Maglev是一个快速、可靠的分布式软件负载均衡系统, 目前已部署在Google数据中心之中.Maglev将所有入站的包通过ECMP机制转发到设计的Maglev机器上执行软件负载均衡决策, 根据决策结果将包通过通用路由封装机制(generic routing encapsulation, 简称GRE)发送到目的服务器以进行服务, 服务器返回的数据包绕过软件负载均衡器直接返回给源端.Maglev的关键部分在于软件负载均衡器的优化, 其绕过Linux内核, 并设计forwarder模块, 直接在网卡和forwarder之间交互数据和维护连接跟踪表, 同时设计了新的一致性哈希算法实现后端资源的公平分享.从Maglev在Google数据中心部署的效果来看, Maglev设计的forwarder相较于内核处理方式具有明显的处理优势.对于不同的包类型, Maglev可以实现近乎相等的吞吐量, 同时在一定带宽情况下设计的forwarder不会成为瓶颈.在与不同的哈希算法比较的过程中, Maglev的哈希在不同哈希表大小的情况下均能实现近乎完美的负载均衡效果.Maglev通过设计和优化软件负载均衡器实现了可扩展的、灵活的负载均衡系统, 在实际运行中效果显著.然而, 在测试过程中, 在更高速的网络环境下(40Gbps), forwarder中的steering模块会成为性能瓶颈, 导致网卡与steering性能不匹配, 因此, 如何让Maglev适应更高速的网络场景需要进一步设计.
(4) SilkRoad
SilkRoad是一种在交换芯片上实现的快速、有状态的4层负载均衡机制, 其利用单个交换芯片代替软件负载均衡器, 直接在交换机本地进行负载均衡.SilkRoad在P4交换机中实现, 通过存储流五元组的哈希值来减小匹配域大小的存储空间, 并设计DIP池的版本号来减少匹配后的动作数据的存储开销.为了保证每个连接的一致性, 在DIP池更新过程中, SilkRoad利用布隆过滤器存储更新过程影响的流, 并设计转移表来保证这些流处理的正确性.在P4交换机有限的存储空间中, SilkRoad实现了片上的负载均衡.在流级别的仿真环境中, SilkRoad在不同数据中心网络位置上能够实现相应的负载均衡效果, 在相同的需求情况下相比于软件负载均衡器只需要一半甚至更少的设备.与Duet相比, SilkRoad在不同的更新情况和新连接到达时能够实现更好的连接一致性效果, 同时转移表能实现明显的性能提升.SilkRoad通过设计合适的存储和匹配机制, 在P4交换机的芯片中实现了有状态的负载均衡, 然而, P4交换机无法实现比较复杂的功能, 且其性能与硬件负载均衡器存在一定差距, 因此, SilkRoad的性能需要进一步加以验证.
(5) Beamer
在服务器负载均衡过程中, 维护每条流的状态会给负载均衡器带来巨大的开销以及其他问题, 包括标准的扩展事件造成的连接断开、SYN洪泛攻击以及在软件负载均衡器中维护状态会极大地降低吞吐量.Beamer是一种无状态的可扩展的数据中心负载均衡器, 充分利用后端服务器本地维护的连接状态信息来保证连接可靠性, 能够支持TCP和MPTCP的状态维护.Beamer为了实现连续的哈希空间, 将服务器分成多个箱子, 利用稳定哈希算法将每个连接分配到每个箱子中的服务器进行处理.在网络状态迁移和更新过程中, 为了保证连接一致性, Beamer利用daisy chaining技术将到达新服务器的旧连接发回给旧服务器.与维护状态的负载均衡机制相比, Beamer对不同大小的包都具有更快速的处理能力, 在网络故障的情况下能够实现更平滑的吞吐量过渡, 并能均匀地进行流量分配.在对TCP和MPTCP的流传输过程中, 能够保证短的流完成时间.在服务器数量较多的情况下, Beamer能够在短时间内进行新配置的部署.Beamer设计无状态的负载均衡方案, 减轻了负载均衡器的存储和处理开销, 但当网络状态变化影响流的数量较多时, 其daisy chaining机制会导致大量流量通过服务器进行转发, 使得服务器开销增大, 成为网络传输性能瓶颈.
(6) 应用层方案对比
应用层方案考虑数据中心网络中服务器之间的性能差异, 保证服务能够均匀地分配到相应的服务器, 同时维护连接的一致性, 实现数据中心网络的负载均衡.通过分析现有应用层方案, 从方案的关键设计和方案性能两个角度对各方案进行对比, 比较结果见
数据中心网络负载均衡应用层方案对比
The comparison of load balancing schemes based on the application layer in data center networks
方案 | 关键设计 | 方案性能 | ||||||
特点 | 架构 | 状态维护 | 硬件需求 | 瓶颈 | 速度 | 适应性 | 复杂度 | |
Ananta | 3层负载均衡结构 | 软件 | 服务器 | 交换机+服务器 | 软件性能 | 慢 | 高 | 低 |
Duet | 现有商业交换机和软件交换机共同维护 | 软件+硬件 | 交换机 | 交换机+服务器 | 分布式存储 | 一般 | 高 | 一般 |
Maglev | 绕过操作系统的软件负载均衡器 | 软件 | 服务器 | 服务器 | 运行模块 | 一般 | 一般 | 一般 |
SilkRoad | 利用交换芯片代替软件负载均衡器 | 硬件 | 交换机 | P4交换机 | 特殊芯片性能 | 快 | 低 | 高 |
Beamer | 利用连续空间哈希和daisy chaining技术 | 软件 | 服务器 | 服务器 | Daisy chaining技术 | 一般 | 高 | 一般 |
方案关键设计包括方案特点、设计架构、状态维护方式和方案硬件需求几个方面.从比较结果来看, 现有传输层负载均衡方案主要通过软件和硬件负载均衡器的部署实现负载均衡功能, 为了提高负载均衡速度通常会采用相结合的部署方式, 部分方案还对软件负载均衡器进行优化.硬件负载均衡器的优点在于具有更快的处理速度, 软件负载均衡器的优点在于能够维护更多状态并执行更复杂的负载均衡策略.因此, 结合软/硬件是现有应用层方案的趋势.大多数负载均衡状态都在软件负载均衡服务器进行维护, 但部分利用新型交换芯片的方案会在交换机维护部分状态, 这类方案会造成更多的硬件需求.
在方案性能方面, 对应用层方案的性能瓶颈、方案速度、适应性和复杂度几个方面进行比较.应用层方案的性能主要受限于负载均衡器的性能, 但是对于利用特殊存储结构或状态维护算法的方案, 其设计的关键结构和算法也是负载均衡性能的瓶颈.硬件负载均衡方案通常相比于软件负载均衡方案具有更快的速度, 但软件负载均衡方案由于其部署难度较低, 因此具有更高的适应性.对于能够利用现有网络设备的方案其复杂度相对较低, 但对于修改现有网络设备或需要专用设备的方案则具有更高的复杂度, 其部署难度也更大.
数据中心网络流量具有高动态性, 其与传统网络特点不同, 因此优化传统的负载均衡机制只能在一定程度上提升负载均衡效果.影响数据中心网络负载的因素很多, 包括拓扑结构、流量特性和调度机制等, 针对数据中心网络设计合适的负载均衡方案需要综合考虑这些因素, 通过对数据中心网络进行多层设计来达到需要的性能.目前典型的、综合的数据中心网络负载均衡机制包括DeTail[
综合方案分类结果
The classification results of the schemes base on the synthetic design
(1) DeTail
DeTail是一种跨层网络栈设计, 其在底层网络快速检测拥塞, 驱动上层网络执行路由决策以选择更不拥塞的路径, 从而实现网内的负载均衡并保证流的时间约束.DeTail在链路层采用PFC机制[
(2) Fastpass
理想的数据中心网络传输性能包括低时延、高利用率和拥塞避免等, 为了实现网络资源的最优分配, Fastpass提出利用一个中央控制器(arbiter)控制每个发送端发送状态的方案.当每个包需要进行传输时, 需要和arbiter进行交互来获得包的发送时间和路径.Fastpass设计FCP(fastpass control protocol)来实现低带宽开销和低时延的端系统和arbiter之间的消息传递协议, 还设计多个arbiter之间的复制机制以实现故障容忍的恢复策略.Fastpass设计最大最小公平分配的时隙分配算法来实现包发送时间分配, 并利用快速边涂色算法进行包路径选择, 保证arbiter为每个包进行时隙和路径分配的效率.将Fastpass方案与传统基于TCP传输的数据中心网络方案进行对比, Fastpass能够实现近乎零队列的高吞吐量, 显著地缩短了交换机队列的平均大小以及时延, 同时能够保证公平的、快速的吞吐量分配.Arbiter中算法的设计有效地提高了其可扩展性, 并能实现细粒度的时隙控制.Fastpass利用集中式控制的优点, 实现了全局感知的包调度策略, 提高了网络传输性能, 并消除了端系统拥塞控制的需求.然而, 由于大部分调度工作在集中式控制器完成, 因此, 在网络负载较大的情况下, 集中式控制器性能容易成为瓶颈, 限制了其应用场景.
(3) Hermes
Hermes是一种基于端系统的不需要修改交换机的负载均衡方案, 其在端系统设计感知模块进行不同路径的拥塞感知, 并设计重路由模块来确定是否进行重路由.Hermes根据RTT和ECN共同感知路径拥塞状态, 将路径分为3种类型, 并利用包的重传和超时事件来推测交换机故障情况.为了提高端系统对网络的可见性, Hermes采用power-of-two-choices[
(4) NDP
NDP提出一种新的网络传输架构, 可为短流实现接近最优的完成时间, 并在多种场景下提供大吞吐量.NDP对交换机和端系统协议栈都进行修改.在交换机本地采用浅缓存策略(8个包)并执行CP机制[
(5) AuTO
AuTO通过模仿生物神经系统结构设计了一种二级的深度强化学习(deep reinforcement learning, 简称DRL)系统[
(6) 综合方案对比
综合方案对网络中多个层面进行修改, 设计多种机制克服单一修改某个层可能产生的缺陷, 实现性能更好的负载均衡效果.通过分析现有综合的方案, 从方案的关键设计和方案性能两个角度对各方案进行对比, 比较结果见
数据中心网络负载均衡综合方案对比
The comparison of load balancing schemes based on the synthetic designs in data center networks
方案 | 关键设计 | 方案性能 | ||||||
特点 | 需求 | 拥塞信息 | 大小流 | 优先级 | 速度 | 适应性 | 复杂度 | |
DeTail | 采用PFC技术实现无损传输 | PFC实现无损二层 | 交换机队列 | 不考虑 | 有 | 快 | 高 | 高 |
Fastpass | 为每个包分配路径和时间 | 高性能中央控制器 | 无 | 不考虑 | 无 | 慢 | 一般 | 高 |
Hermes | 端侧推测感知拥塞并重路由 | 端侧修改 | RTT和ECN | 不考虑 | 无 | 一般 | 高 | 低 |
NDP | 接收端驱动协议 | 交换机和端侧修改 | 控制包 | 考虑 | 有 | 一般 | 一般 | 高 |
AuTO | 利用二级DRL实现传输管理 | 控制器运行DRL模块并决策 | 流状态 | 考虑 | 有 | 慢 | 一般 | 高 |
方案的关键设计包括方案特点、方案实现关键需求、拥塞信息获取、方案对大小流的考虑情况以及是否考虑不同优先级传输等方面.大部分综合方案对网络具有较大的修改, 包括特殊的设备需求、特殊的传输策略以及高性能的处理需求等.通常, 综合方案会采集网络拥塞信息作为决策参考, 但对于全局最优的方案来说, 拥塞信息可以不考虑.综合方案根据设计不同对大小流会进行不同的处理, 对于有明显大小流需求的场景, 会直接考虑大小的流差异化管理.大部分综合方案都会考虑传输数据的优先级, 优先处理控制信息从而进行及时响应.
方案性能主要考虑综合方案的速度、适应性和复杂度等几个方面.对网内设备修改较多的方案通常执行本地决策, 因此具有更快的处理速度, 而集中式管理的方案会由于管理周期影响其速度.对于设计过程中综合考虑网络特性的方案来说, 其相对于考虑特殊情况的方案来说具有更好的适用性, 不会由于网络情况变化造成性能的明显下降.大部分综合方案都需要修改网络中的多个部分, 因此大多数方案复杂度较高, 除了少数只修改端侧的方案外, 综合方案的部署难度都会相对较大.
数据中心网络负载均衡方案通过不同角度的设计保证了低时延和高吞吐的网络性能.
数据中心网络负载均衡方案评估
The evaluation of load balancing schemes in data center networks
方案 | 方案类型 | 粒度 | 控制结构 | 均衡类型 | 拥塞感知 | 修改位置 | 效果 | 扩展性 | 部署难度 |
DRB | 网络层 | 包 | 分布式 | 主动 | 无 | 端系统+交换机 | 中 | 中 | 容易 |
RPS | 网络层 | 包 | 分布式 | 主动 | 无 | 交换机 | 中 | 好 | 容易 |
DRILL | 网络层 | 包 | 分布式 | 主动 | 本地 | 交换机 | 好 | 好 | 中等 |
CONGA | 网络层 | Flowlet | 分布式 | 被动 | 全局 | ToR | 好 | 中 | 困难 |
HULA | 网络层 | Flowlet | 分布式 | 被动 | 全局 | 交换机 | 好 | 好 | 中等 |
CLOVE | 网络层 | Flowlet | 分布式 | 被动 | 全局 | 端系统 | 中 | 好 | 容易 |
LetFlow | 网络层 | Flowlet | 分布式 | 被动 | 无 | 交换机 | 中 | 好 | 容易 |
Presto | 网络层 | Flowcell | 分布式 | 主动 | 无 | 端系统 | 中 | 好 | 容易 |
ECMP | 网络层 | 流 | 分布式 | 主动 | 无 | 无 | 中 | 好 | 容易 |
WCMP | 网络层 | 流 | 分布式 | 主动 | 无 | 交换机 | 中 | 好 | 容易 |
Hedera | 网络层 | 流 | 集中式 | 主动 | 全局 | 控制器 | 中 | 差 | 容易 |
MicroTE | 网络层 | 流 | 集中式 | 主动 | 全局 | 控制器+端系统 | 中 | 好 | 容易 |
Mahout | 网络层 | 流 | 集中式 | 主动 | 全局 | 控制器+端系统 | 中 | 好 | 容易 |
Devoflow | 网络层 | 流 | 集中+分布 | 主动 | 全局 | 控制器+交换机 | 好 | 好 | 中等 |
LocalFlow | 网络层 | 流 | 分布式 | 主动 | 本地 | 交换机 | 中 | 中 | 困难 |
FlowBlender | 网络层 | 流 | 分布式 | 主动 | 全局 | 端系统 | 中 | 好 | 中等 |
Freeway | 网络层 | 流 | 集中式 | 主动 | 全局 | 端系统+交换机 | 中 | 中 | 中等 |
Expeditus | 网络层 | 流 | 分布式 | 主动 | 本地 | 交换机 | 好 | 好 | 中等 |
Scheduling Algorithm | 网络层 | 流 | 集中式 | 主动 | 全局 | 控制器 | 好 | 差 | 困难 |
MPTCP | 传输层 | 多流 | 分布式 | 被动 | 全局 | 端系统 | 中 | 好 | 容易 |
XMP | 传输层 | 多流 | 分布式 | 被动 | 全局 | 端系统 | 中 | 好 | 中等 |
RackCC | 传输层 | 多流 | 分布式 | 被动 | 全局 | 端系统+ToR | 好 | 中 | 困难 |
MMPTCP | 传输层 | 多流 | 分布式 | 被动 | 全局 | 端系统 | 好 | 中 | 中等 |
VMS | 传输层 | 包 | 分布式 | 被动 | 全局 | 端系统 | 中 | 中 | 中等 |
Ananta | 应用层 | 流 | 分布式 | 主动 | 本地 | 软件Mux | 中 | 中 | 容易 |
Duet | 应用层 | 流 | 分布式 | 主动 | 本地 | 软件Mux+交换机 | 好 | 好 | 容易 |
Maglev | 应用层 | 流 | 分布式 | 主动 | 本地 | 软件Mux | 中 | 中 | 容易 |
SilkRoad | 应用层 | 流 | 分布式 | 主动 | 本地 | P4交换机 | 中 | 中 | 困难 |
Beamer | 应用层 | 流 | 分布式 | 主动 | 本地 | 软件Mux | 好 | 中 | 容易 |
DeTail | 综合 | 包 | 分布式 | 被动 | 本地 | 交换机 | 好 | 中 | 中等 |
Fastpass | 综合 | 包 | 集中式 | 主动 | 全局 | 控制器+端系统 | 好 | 差 | 困难 |
Hermes | 综合 | 流 | 分布式 | 被动 | 全局 | 端系统 | 好 | 中 | 容易 |
NDP | 综合 | 流 | 分布式 | 主动 | 无 | 端系统+交换机 | 好 | 中 | 困难 |
AuTO | 综合 | 流 | 集中+分布 | 主动 | 全局 | 控制器+端系统 | 好 | 中 | 中等 |
从不同方案对比中可以发现, 大部分数据中心网络负载均衡方案通过网络层传输调度直接进行优化, 综合方案普遍性能更好, 但部署难度较大.从不同负载均衡粒度来看, 粒度较小的方案实现的效果较好.在不同控制结构中, 集中式方案会造成巨大开销, 从而限制其扩展性.不同的负载均衡类型对网络拥塞的控制效果也不同, 被动负载均衡在拥塞后进行处理降低了拥塞响应速度, 主动方式可以避免拥塞的发生.对于不同的感知策略, 全局拥塞信息感知对负载均衡具有明显的促进作用, 可以实现全局最优的调度.现有方案中, 越复杂且对网络的修改越多的方案其性能相对来说要更好.然而, 实际数据中心网络部署中, 可部署性是非常重要的问题, 无法简单升级或迭代更新的方案在实际数据中心中难以应用.因此, 数据中心网络负载均衡方案的设计需要从性能、可扩展性和实用性等角度综合考虑, 在满足传输性能的同时还要尽可能地保证低成本和开销.
数据中心网络是现代网络和云计算的重要基础架构, 数据中心网络的传输性能直接影响网络的传输能力和服务体验.因此, 设计高效的数据中心网络负载均衡方案以满足低时延高吞吐的数据中心网络需求十分关键.现有的数据中心网络负载均衡方案可按照不同解决层面分为:网络层、传输层、应用层和综合方案四大类, 其他角度则可从负载均衡粒度、方案控制结构、负载均衡类型和拥塞感知策略等方面对负载均衡方案进行归纳.虽然现有方案设计了多种机制以提高网络传输能力, 但仍存在一些弊端:(1)方案基于传统TCP协议栈, 性能受限于TCP基于窗口的传输策略; (2)负载均衡方案性能依赖于现有数据中心典型的网络拓扑; (3)现有负载均衡方案针对某个场景优化, 适用性不强; (4)现有方案未充分利用数据平面控制能力; (5)没有充分开发新型传输设备的优势.鉴于现有方案的分析, 总结了数据中心网络负载均衡未来可能的研究方向.
(1) 设计新型协议栈
由于传统TCP传输协议栈不适用于数据中心的高速场景, 在负载均衡过程中无法快速达到最优的网络性能, 因此重新设计协议栈是解决传统TCP问题的关键.先前设计的新型协议栈NDP是重新设计网络协议栈的探索, 近期提出的Homa[
(2) 优化数据中心拓扑
现有数据中心网络负载均衡方案主要基于典型的数据中心网络拓扑(Clos拓扑)进行设计, 负载均衡性能受限于拓扑约束, 因此优化数据中心网络拓扑结构是提高网络最大传输能力的重要途径.近期提出的Flat-tree[
(3) 结合机器学习和人工智能技术
由于很多数据中心网络负载均衡机制与网络应用场景和流量特性相关, 而且设计的机制性能依赖于相关参数的选取, 因此可利用机器学习和人工智能技术, 通过分析历史数据实现自适应的参数调整.先前的AuTO方案即是根据网络中流的状态自适应地给定相关阈值, 并进行自学习过程.近期提出的DRL-TE[
(4) 设计新型数据中心网络数据平面
随着网络传输需求的不断增大和各种传输模式的涌现, 传统数据中心网络数据平面已经成为提升传输性能的瓶颈, 因此出现了许多新型数据平面技术, 包括智能网卡的应用[
(5) 结合可编程网络技术
受限于传统网络硬件更新周期长和定制能力差等缺点, 可编程网络提供了一种高效易管理的网络抽象.典型的可编程网络技术包括P4[
doi: 10.1145/1402958.1402967]]]>
doi: 10.1145/1592568.1592576]]]>
Singla A, Hong CY, Popa L, Godfrey PB. Jellyfish: Networking data centers randomly. In: Proc. of the Conf. on Networked Systems Design and Implementation. Berkeley: USENIX, 2012. 225-238.
doi: 10.1145/1644893.1644918]]]>
doi: 10.1145/1879141.1879175]]]>
doi: 10.1145/1672308.1672325]]]>
doi: 10.1145/2829988.2787472]]]>
Noormohammadpour M, Raghavendra CS. Datacenter traffic control:Understanding techniques and tradeoffs. IEEE Communications Surveys & Tutorials, 2018, 20(2):1492-1525.[doi:10.1109/COMST.2017.2782753]
Hopps C. Analysis of an equal-cost multi-path algorithm. RFC 2992, 2000.[doi:10.17487/RFC2992]
doi: 10.1145/2592798.2592803]]]>
doi: 10.1145/2535372.2535375]]]>
doi: 10.1109/INFCOM.2013.6567015]]]>
doi: 10.1145/2834050.2834107]]]>
doi: 10.1145/3098822.3098839]]]>
Mitzenmacher M. The power of two choices in randomized load balancing. IEEE Trans. on Parallel Distribution System, 2001, 12(10):1094-1104.[doi:10.1109/71.963420]
Sinha S, Kandula S, Katabi D. Harnessing TCP's burstiness with flowlet switching. In: Proc. of the ACM Workshop on Hot Topics in Networks. New York: ACM, 2004.
doi: 10.1145/1232919.1232925]]]>
doi: 10.1145/2619239.2626316]]]>
doi: 10.1145/3005745.3005751]]]>
doi: 10.1145/2890955.2890968]]]>
Vanini E, Pan R, Alizadeh M, Taheri P, Edsall T. Let it flow: Resilient asymmetric load balancing with flowlet switching. In: Proc. of the Conf. on Networked Systems Design and Implementation. Berkeley: USENIX, 2017. 407-420.
Mahalingam M, Dutt D, Duda K, Agarwal P, Kreeger L, Sridhar T, Bursell M, Wright C. Virtual extensible local area network (VXLAN):A framework for overlaying virtualized layer 2 networks over layer 3 networks. RFC 7348, 2014.[doi:10.17487/RFC7348]
doi: 10.1109/INFOCOM.2019.8737529]]]>
doi: 10.1145/2656877.2656890]]]>
doi: 10.1145/2829988.2787507]]]>
doi: 10.1145/2620728.2620758]]]>
Al-Fares M, Radhakrishnan S, Raghavan B, Huang N, Vahdat A. Hedera: Dynamic flow scheduling for data center networks. In: Proc. of the Conf. on Networked Systems Design and Implementation. Berkeley: USENIX, 2010.: 89-92.
doi: 10.1145/2079296.2079304]]]>
doi: 10.1109/INFCOM.2011.5934956]]]>
doi: 10.1145/2018436.2018466]]]>
doi: 10.1145/2535372.2535397]]]>
doi: 10.1145/2674005.2674985]]]>
doi: 10.1109/ICNP.2014.59]]]>
doi: 10.1109/TNET.2017.2731986]]]>
Correa JR, Goemans MX. Improved bounds on nonblocking 3-stage clos networks. SIAM Journal on Computing, 2007, 37(3):870-894.[doi:10.1137/060656413]
Shafiee M, Ghaderi J. A simple congestion-aware algorithm for load balancing in datacenter networks. IEEE/ACM Trans. on Networking (TON), 2017, 25(6):3670-3682.[doi:10.1109/TNET.2017.2751251]
Shafiee M, Ghaderi J. An improved bound for minimizing the total weighted completion time of coflows in datacenters. IEEE/ACM Trans. on Networking (TON), 2018, 26(4):1674-1687.[doi:10.1109/TNET.2018.2845852]
doi: 10.1145/2018436.2018467]]]>
doi: 10.1145/2535372.2535384]]]>
doi: 10.1145/3005745.3005772]]]>
doi: 10.1109/INFOCOM.2016.7524530]]]>
doi: 10.1109/ICNP.2017.8117566]]]>
doi: 10.1145/2486001.2486026]]]>
doi: 10.1145/2619239.2626317]]]>
Eisenbud DE, Yi C, Contavalli C, Smith C, Kononov R, Hielscher EM, Cilingiroglu A, Cheyney B, Shang W, Hosein JD. Maglev: A fast and reliable software network load balancer. In: Proc. of the Conf. on Networked Systems Design and Implementation. Berkeley: USENIX, 2016. 523-535.
doi: 10.1145/3098822.3098824]]]>
Olteanu V, Agache A, Voinescu A, Raiciu C. Stateless datacenter load-balancing with beamer. In: Proc. of the Conf. on Networked Systems Design and Implementation. Berkeley: USENIX, 2018. 125-139.
doi: 10.1145/2342356.2342390]]]>
doi: 10.1145/2619239.2626309]]]>
doi: 10.1145/3098822.3098841]]]>
doi: 10.1145/3098822.3098825]]]>
doi: 10.1145/3230543.3230551]]]>
doi: 10.1145/3230543.3230557]]]>
Cheng P, Ren F, Shu R, Lin C. Catch the whole lot in an action: Rapid precise packet loss notification in data center. In: Proc. of the Conf. on Networked Systems Design and Implementation. Berkeley: USENIX, 2014. 17-28.
doi: 10.1145/2829988.2787484]]]>
Silver D, Huang A, Maddison C, Guez A, Sifre L, Driessche G, Schrittwieser J, Antonoglou I, Panneershelvam V, Lanctot M, Dieleman S, Grewe D, Nham J, Kalchbrenner N, Sutskever I, Lilicrap T, Leach M, Kavukcuoglu K, Graepel T, Hassabis D. Mastering the game of Go with deep neural networks and tree search. Nature, 2016, 529(7587):484-489.[doi:10.1038/nature16961]
Bai W, Chen L, Chen K, Han D, Tian C, Wang H. Information-agnostic flow scheduling for commodity data centers. In: Proc. of the Conf. on Networked Systems Design and Implementation. Berkeley: USENIX, 2015. 455-468.
doi: 10.1145/3230543.3230564]]]>
doi: 10.1145/3098822.3098837]]]>
doi: 10.1109/INFOCOM.2018.8485853]]]>
doi: 10.1145/3127479.3132252]]]>
doi: 10.1145/3190508.3190531]]]>
doi: 10.1145/3132747.3132764]]]>
doi: 10.1145/3098822.3098823]]]>
Sharma NK, Liu M, Atreya K, Krishnamurthy A. Approximating fair queueing on reconfigurable switches. In: Proc. of the Conf. on Networked Systems Design and Implementation. Berkeley: USENIX, 2018. 1-16.