1. 项目概述当存储集群遭遇“交通大堵塞”在数据中心存储集群里有一个让运维和架构师们头疼不已的“幽灵”问题它平时不显山露水一旦发作就能让整个集群的I/O吞吐量瞬间“雪崩”从每秒几个GB暴跌到几十MB这就是TCP Incast。想象一下在一个大型分布式文件系统比如HDFS、Ceph或GPFS中一个客户端请求读取一个被条带化Striping存储在大批服务器上的大文件。为了响应这个请求几十甚至上百台存储服务器会同时向客户端所在的服务器发送数据块。这就像晚高峰时无数条支路的车辆同时涌向一个主干道出口结果就是出口缓冲区交换机或接收端网卡缓冲区瞬间被塞满数据包大量丢失触发TCP的漫长超时重传最终导致整体吞吐量崩溃。传统的“药方”比如DCTCP数据中心TCP或ICTCPIncast拥塞控制TCP试图在发送端或接收端进行局部优化。DCTCP依赖交换机支持ECN显式拥塞通知并标记拥塞发送端据此调整发送窗口ICTCP则在接收端根据自身缓冲区情况动态通告接收窗口。这些方法在并发发送方不多时有效但当并发数超过某个阈值例如DCTCP实验中的35个或者网络拓扑扩展到跨机架、跨交换机时其扩展性和协调效率就捉襟见肘了。根本原因在于它们缺乏一个全局的、实时的上帝视角来统一调度所有流量。这正是我们引入软件定义存储SDS和软件定义网络SDN思想的契机。我们提出的动态公平共享缓冲区策略DyFaShBuP其核心思路非常直观与其让每个TCP连接“盲人摸象”般地猜测网络状态不如由一个集中式的SDS控制器充当“交通总指挥”。这个控制器能实时收集整个I/O路径从发送端存储服务器、经过的交换机到接收端服务器的所有关键参数包括链路带宽、往返时延、各节点缓冲区容量等。基于这些全局信息控制器为每一个并发数据流精确计算并分配一个公平的、能最大化整体吞吐量且避免拥塞的发送窗口大小Window Size, WS。简单说DyFaShBuP不是去“治疗”已经发生的Incast拥塞而是通过前瞻性的、动态的缓冲区配额管理从根本上“预防”它的发生。它像一位高明的调度员在数据洪峰到来前就为每一条数据流规划好了通行速率和车道确保整个交叉路口畅通无睹。这套方案完全基于软件实现无需改动现有的TCP协议栈或网络硬件通过在存储服务器上部署轻量级代理与控制器通信即可实现从中小规模到超大规模数据中心的平滑部署和高效管理。2. 核心原理与架构设计拆解要理解DyFaShBuP如何工作我们需要先深入其设计哲学和系统架构。这不仅仅是几个算法的堆砌而是一套针对存储网络I/O路径特点的全局资源调度体系。2.1 从“端到端”到“路径感知”的范式转变传统TCP拥塞控制是一个典型的分布式、反应式系统。发送方根据丢包或ECN信号被动地调整自己的拥塞窗口Cwnd接收方则根据自身缓冲区告知接收窗口Rwnd。在Incast场景下问题在于信息孤岛每个发送方只知道自己和接收方的状态不知道其他几十个并发发送方在干什么。反应滞后等到丢包或ECN信号传回拥塞已经发生性能损失已经造成。协调开销大在去中心化的模式下要实现所有流的公平性需要复杂的信号交互开销巨大。DyFaShBuP的范式转变在于它利用SDN的思想将网络在这里扩展到整个I/O路径的控制平面与数据平面分离。SDS控制器作为控制平面的大脑掌握了数据平面所有元素服务器、交换机、链路的实时状态。这使得预防式的全局优化成为可能。控制器不是等到缓冲区溢出才行动而是在流建立之初或网络状态变化时就根据全局资源池计算出最优的WS并下发给各个发送端。2.2 系统架构与组件交互整个系统的架构可以清晰地分为三层数据平面存储服务器运行标准的TCP/IP协议栈但安装了一个轻量级的策略执行代理。这个代理不负责复杂计算只负责接收来自控制器的WS指令并据此调整本机TCP连接的发送行为例如通过套接字选项动态设置SO_SNDBUF或通过更底层的机制影响发送窗口。网络交换机支持OpenFlow等南向接口协议的SDN交换机。它负责执行控制器下发的流表规则实现基本的转发功能。更重要的是它需要向控制器上报端口统计信息如流量、缓冲区使用率和链路状态。在我们的设计中交换机无需具备复杂的拥塞感知逻辑这部分功能被上移到控制器。控制平面SDS控制器这是整个系统的核心。它维护着一个全局的策略表表中定义了针对不同存储数据流的处理规则。控制器通过南向接口如OpenFlow与所有交换机通信同时通过北向API或自定义通道与存储服务器上的代理通信。它的核心职责包括网络感知持续收集所有交换机端口的带宽利用率、缓冲区占用、链路延迟等信息。服务器感知通过代理收集各存储服务器的发送/接收缓冲区容量、磁盘I/O速度等。全局计算基于上述信息运用带宽延迟积等模型为每一个活跃的I/O流计算公平的WS。策略下发将计算出的WS指令下发给对应的发送端代理并可能在交换机上安装相应的流表项以实现更精细的QoS策略。管理平面提供用户界面或API供管理员定义存储策略如不同应用、不同租户的QoS需求、监控系统状态、以及进行故障排查。交互流程对应原文图6当一台客户端服务器CFS需要从多个存储服务器FS读取一个条带化文件时它发起请求。请求触发了多个并发的TCP连接建立。交换机检测到新的数据流流表未命中将此事件上报给SDS控制器。SDS控制器收到事件后启动全局计算引擎。它识别出这是一个“多对一”的Incast潜在场景并获取相关路径上所有实体的实时状态。控制器根据公平共享算法后文详述计算出每个并发发送流应分配的WS。控制器将WS值下发给各个发送端存储服务器上的代理。代理应用新的WS调整TCP发送行为。数据开始以受控的、公平的速率传输避免了接收端或交换机缓冲区的溢出。注意这里的关键是“动态”和“公平”。WS不是静态配置的而是随着并发发送者数量、链路延迟、可用带宽的变化而动态调整的。“公平”意味着在同等优先级下每个并发流获得的缓冲区资源进而决定的带宽份额是均等的不会出现某个流饿死或独占的情况。2.3 与DCTCP、ICTCP的核心差异为了更清晰地理解DyFaShBuP的先进性我们将其与主流方案进行对比特性DCTCPICTCPDyFaShBuP (本文方案)控制主体发送端 (基于ECN)接收端 (基于自身缓冲区)集中式SDS控制器 (全局路径)控制粒度单个TCP连接单个TCP连接整个I/O路径上的所有并发连接见性端到端 (仅感知自身拥塞)接收端局部视图全局视图(所有交换机、服务器、链路)动作时机反应式 (检测到拥塞后)反应式/部分主动 (基于接收缓冲区)预防式(流建立时或状态变化时)扩展性瓶颈交换机ECN支持、并发发送方数量(~35)接收端计算能力、单交换机场景控制器计算能力 (可通过多控制器扩展)部署复杂度需交换机支持ECN修改发送端TCP栈需修改接收端TCP栈无需修改TCP栈需部署控制器和代理目标缓解拥塞降低队列延迟防止接收端缓冲区溢出全局公平共享预防Incast最大化整体吞吐从上表可以看出DyFaShBuP的本质优势在于其集中式、全局化、预防性的控制逻辑。它将拥塞控制的决策权从分散的、视野受限的端点收归到一个拥有全知视角的中央机构从而能够做出更优的、协调一致的调度决策。3. 核心算法动态公平共享缓冲区的计算逻辑算法的核心在于如何计算那个“恰到好处”的窗口大小WS。这个WS必须足够大以充分利用链路带宽又不能太大以免超过接收端或交换机的缓冲区容量引发Incast。这里的关键桥梁就是带宽延迟积。3.1 带宽延迟积理解网络的“管道容量”带宽延迟积是理解TCP窗口大小设定的基础。它定义了一个网络链路在特定往返时延RTT内所能容纳的“在途数据”总量。公式非常简单BDP (bits) 链路带宽 (bps) × 往返时延 (s)举个例子假设我们有一条1Gbps即1×10^9 bps的链路RTT是1毫秒即1×10^-3 秒。那么 BDP 1×10^9 × 1×10^-3 1×10^6 bits 125 KBytes这意味着为了完全占满这条1Gbps的链路发送方在任何时刻最多只能有125KB的数据在网络中“飞行”。如果窗口小于125KB链路利用率就不足如果大于125KB多出来的数据只会堆积在缓冲区里最终导致丢包。因此对于单条TCP连接理想的发送窗口应等于BDP。3.2 多对一场景下的公平共享计算Incast场景的核心挑战在于多个发送方共享同一个“瓶颈资源”——通常是接收端的网络接口缓冲区或者是最后一跳交换机的出口缓冲区。在DyFaShBuP模型中SDS控制器将整个I/O路径视为一个整体其瓶颈处的有效BDP就是全局共享的缓冲区资源上限。算法核心思想将瓶颈处的总可用缓冲区容量通常由BDP决定平均分配给所有并发的发送方N。计算公式WS_per_sender BDP_bottleneck / N继续上面的例子如果接收端链路的BDP是125KB现在有20个存储服务器同时向它发送数据。那么为了不撑爆接收端缓冲区SDS控制器会为每个发送方计算并分配WS 125 KB / 20 6.25 KB这意味着每个发送方在同一时刻最多只能有6.25KB的数据在网络上传输。20个发送方加起来正好是125KB完美匹配了链路的管道容量。这样既避免了缓冲区溢出又最大限度地利用了总带宽。算法伪代码实现对应原文Algorithm 1# 输入 瓶颈链路带宽 BW (bps), 瓶颈链路往返时延 RTT (秒), 并发发送方数量 N # 输出 每个发送方应分配的窗口大小 WS (Bytes) def calculate_fair_share_ws(BW, RTT, N): # 计算带宽延迟积 (单位bits) BDP_bits BW * RTT # 转换为字节 (1 Byte 8 bits) BDP_bytes BDP_bits / 8 # 计算公平共享的窗口大小 WS_bytes BDP_bytes / N return WS_bytes # 示例1Gbps带宽1ms RTT20个并发发送方 BW 1e9 # 1 Gbps in bps RTT 0.001 # 1 ms in seconds N 20 WS calculate_fair_share_ws(BW, RTT, N) print(f每个发送方窗口大小: {WS / 1024:.2f} KB) # 输出: 6.25 KB3.3 动态调整与实时响应“动态”一词体现在WS并非一成不变。SDS控制器会持续监控网络状态。以下情况会触发WS的重新计算和分配并发发送方数量N变化有新的存储服务器加入发送或有的服务器完成发送。网络路径变化路由改变导致RTT发生变化。链路带宽波动网络背景流量导致可用带宽变化。缓冲区状态变化接收端或交换机报告缓冲区使用率接近阈值。一旦检测到这些变化控制器会迅速重新执行计算并将新的WS下发给受影响的发送端代理。这种机制确保了策略能够适应动态的数据中心环境。实操心得BDP的测量与估算在实际部署中精确获取BDP的两个参数带宽和RTT是关键。带宽通常可以取链路物理带宽如1Gbps、10Gbps但在共享网络中需要考虑背景流量的影响。RTT的测量可以通过控制器定期发送探测包如ICMP Ping或自定义的带时间戳的协议包来获取。更精细的做法是利用SDN交换机的流统计功能估算数据包的排队延迟。一个实用的技巧是在初始阶段可以采用一个保守的、略小于理论BDP的值作为共享池的上限为背景流量和测量误差留出余量运行稳定后再逐步调整至最优。4. 方案实现与部署考量DyFaShBuP被设计为一个纯软件方案这极大地提升了其部署可行性。它不需要更换昂贵的、支持特定功能的交换机硬件也无需修改操作系统内核中的TCP协议栈。4.1 软件代理的设计与实现存储服务器上的代理是方案落地的重要一环。它的设计原则是轻量、低开销、无侵入。功能代理主要实现两个功能一是向SDS控制器注册并上报本机状态如IP、支持的缓冲区大小、当前活跃连接数等二是接收并执行控制器下发的WS策略指令。实现方式代理可以通过多种方式影响TCP发送窗口套接字选项在连接建立后使用setsockopt()系统调用调整SO_SNDBUF的大小。这是最通用但相对粗糙的方法因为内核可能不会完全遵循这个值。流量控制Traffic Control在Linux系统上可以利用tcTraffic Control工具和netfilter框架为特定流打上标记并通过排队规则qdisc如HTB或TBF来限制其发送速率间接控制窗口的填充速度。这种方式更精确但配置稍复杂。用户态TCP栈在追求极致性能和控制力的场景下可以考虑使用DPDK用户态TCP栈如mTCP、F-Stack代理可以直接操纵用户态协议栈的发送窗口。这对高性能存储服务器如全闪存阵列有吸引力。通信协议代理与控制器之间需要一个轻量、可靠的通信通道。可以使用gRPC、ZeroMQ等RPC框架或者基于Redis的发布/订阅模式。消息格式应包含服务器标识、命令类型如SET_WS、流五元组信息以及目标WS值。4.2 SDS控制器的关键模块控制器是大脑其软件架构应包含以下核心模块拓扑与状态管理模块维护网络设备、服务器和链路的实时视图。使用LLDP或通过SDN控制器南向接口自动发现拓扑。监控与数据收集模块定期轮询或通过事件订阅从交换机和服务器代理收集性能计器带宽、延迟、缓冲区使用率、并发流数量。策略引擎与计算模块这是核心算法所在。它根据收集到的全局状态运行公平共享计算算法为每个流或流组具有相同目的地的流生成WS策略。策略下发与执行模将计算出的策略转换为具体的配置命令通过不同的通道下发给数据平面元素通过OpenFlow给交换机安装流表通过RPC给服务器代理发送WS指令。北向API模块为上层管理系统或运维人员提供查询和配置接口。4.3 部署模式与高可用性对于不同规模的数据中心部署模式可以灵活调整中小型集群可以采用单个SDS控制器实例管理所有交换机和存储服务器。控制器与网络管理平面部署在同一高可用域内。大型/超大型集群必须考虑控制器的水平扩展。可以采用“分区”模式将数据中心划分为多个逻辑区域Pod每个区域由一个SDS控制器实例管理。区域间的协调可以通过一个上层协调器或通过共享数据库来实现。另一种思路是采用“主备”或“集群”模式确保单个控制器故障时业务不中断。高可用性设计要点控制器集群使用类似OpenDaylight、ONOS等SDN控制器集群技术实现控制器实例间的状态同步和故障切换。代理容错服务器代理应具备重连和本地缓存机制。当与控制器失联时可以降级到使用一个安全的、保守的默认WS值或者沿用最后一次下发的有效策略保证基本连通性避免因控制器故障导致网络完全停滞。数据持久化控制器的策略配置和计算状态应定期持久化到数据库中以便故障恢复后能快速重建状态。注意事项控制器的性能与扩展性集中式控制器可能成为性能和扩展性的瓶颈。当流数量达到百万级别时频繁的策略计算和下发给控制器带来巨大压力。优化手段包括1聚合策略对具有相同目的地和QoS要求的流进行分组统一计算和下发策略而不是为每个流单独计算。2增量更新仅当状态变化超过一定阈值时才触发重新计算和下发。3分级控制在边缘交换机部署轻量级决策点处理本地简单的策略复杂和全局的策略才上报给中心控制器。这是未来研究的一个重要方向。5. 性能分析与实验验证理论再完美也需要实验数据的支撑。原文通过模拟实验在三种典型的Incast场景下验证了DyFaShBuP的有效性。我们在此复现并解读其核心发现。5.1 实验场景设定实验模拟了一个典型的存储集群网络关键参数如下交换机48端口1Gbps端口速率。存储服务器均配备足够快的NIC不会成为瓶颈。链路延迟根据场景不同在1ms到1.2ms之间。并发发送方CFS从1到48个。评估指标整体端到端I/O吞吐量。这是衡量方案是否成功的关键——不仅要避免Incast导致的吞吐量崩溃还要尽可能接近链路的总可用带宽。实验对比了三种网络拓扑对应Incast的不同严重程度场景一单机架内单交换机最基础的Incast模型所有发送方和接收方通过同一台交换机相连。场景二单机架到单机架双交换机发送方在机架A接收方在机架B流量需要经过两台接入交换机和可能的核心交换机路径更长延迟稍高。场景三单机架到多机架多交换机最复杂的生产环境场景发送方分布在多个机架流量路径差异大是Incast问题最严峻的考验。5.2 实验结果解读实验结果表明DyFaShBuP在所有三种场景下都成功预防了Incast并保持了接近线速的整体吞吐量。场景一单交换机当48个服务器并发发送时每个流的WS被动态调整为约2.6KB125KB / 48 ≈ 2.6KB。此时每个流的吞吐量约为21.3Mbps2.6KB * 8 bits/byte / 1ms RTT ≈ 20.8Mbps接近理论值48个流的总吞吐量仍接近1Gbps的聚合带宽没有发生崩溃。场景二双交换机由于路径延迟增加到1.1msBDP增大到137.5KB。在48个并发流时每个流的WS约为2.86KB单流吞吐量约23.4Mbps总吞吐量依然维持在高位。场景三多交换机在更长的路径1.2ms RTTBDP150KB和48个并发流下每个流获得约3.125KB的WS单流吞吐量约25.6Mbps总吞吐量表现稳定。核心结论无论并发发送方数量如何增加也无论网络拓扑变得多复杂DyFaShBuP通过动态调整WS始终能将每个流的发送速率限制在接收端缓冲区可承受的范围内。因此整体吞吐量不会因并发数增加而崩溃而是平滑地随着并发数增加每个流分得的带宽等比减少总和始终逼近瓶颈链路的物理极限。这完美解决了传统TCP在Incast场景下吞吐量断崖式下跌的问题。5.3 窗口大小与开销的权衡实验中也揭示了一个重要的工程权衡点窗口大小WS与协议开销。TCP/IP协议头通常40字节和以太网帧开销是固定的。当WS设置得非常小时比如几KB有效数据的占比就会降低协议开销相对变大导致“好吞吐”Goodput即有效应用层吞吐量下降。例如发送一个1460字节标准MSS的数据段需要加上40字节的TCP/IP头再封装成以太网帧至少18字节头尾实际传输的比特中有效载荷占比约为1460/(14604018) ≈ 96%。但如果WS只有2.6KB且网络RTT很小发送方会频繁地发送小数据段虽然不会拥塞但链路利用率可能无法达到100%因为有一部分带宽被协议头“浪费”了。这就是为什么DyFaShBuP在保证不拥塞的前提下会尽可能分配等于BDP/N的WS而不是一个更小的值。同时这也提示了文件系统设计的一个优化点对于非常小的文件应避免将其条带化到过多的服务器上。因为这会触发大量并发的小数据流每个流的WS都很小导致协议开销占比过高整体效率低下。一个最佳实践是在文件系统层面设置一个阈值例如小于1MB的文件禁止其进行宽条带化。5.4 内存占用分析另一个不可忽视的维度是接收端服务器的内存压力。在Incast场景下接收端需要为每一个并发连接在内存中预留缓冲区来存放“在途数据”。所需内存总量 WS × 并发连接数。例如一个Web服务器用100Mbps带宽、100ms RTT服务10000个客户端。BDP 100Mbps * 0.1s / 8 1.25MB。这意味着每个连接需要1.25MB的接收缓冲区10000个连接就需要惊人的12.5GB内存如果带宽提升到1Gbps内存需求会暴涨到约78GB。DyFaShBuP通过主动控制WS实际上也是在控制接收端的内存占用。在计算公平共享WS时SDS控制器必须将接收端服务器的可用内存作为一个约束条件考虑进去。如果计算出的总内存需求WS × N超过了接收端的可用内存控制器就需要进一步调低每个流的WS或者采取其他调度策略如分时发送。这体现了全局控制器的另一个优势资源感知的协同调度。6. 生产环境部署的挑战与应对策略将DyFaShBuP从论文和实验环境推向实际生产会面临一系列工程和运维上的挑战。6.1 控制器性能与扩展性瓶颈这是集中式方案最常被质疑的一点。单个控制器的处理能力、内存和连接数终归有上限。挑战在超大规模数据中心每秒可能有数十万甚至上百万的新流产生。如果每个流都要控制器介入计算将是不可承受之重。应对策略流聚合控制器不针对单个TCP流做决策而是针对“流组”。例如将所有从某个存储池Pool发往某个计算节点的流视为一个统一分配一个聚合的带宽/缓冲区配额组内的微调度由边缘设备或主机代理基于简单规则如轮询完成。分级控制借鉴电信网络的思想建立分级控制器。边缘交换机或ToR架顶式交换机内置轻量级本地控制器处理本机架内的、策略简单的流。只有跨机架、跨POD的复杂流调度才需要上报给区域或全局控制器。事件驱动与增量更新控制器不应频繁轮询。采用事件驱动架构只有网络状态发生显著变化如并发数突变、链路故障时才触发全局重计算。对于大多数稳定运行的流策略可以长时间保持不变。6.2 故障恢复与一致性SDS控制器是整个网络的大脑其故障会导致策略更新停滞。挑战控制器故障期间新的流无法获得策略网络可能退回到无管理的状态引发Incast风险。控制器恢复后如何快速与数据平面同步状态也是一大难题。应对策略主备/集群高可用这是基本要求。使用成熟的分布式一致性协议如Raft、Paxos来同步多个控制器实例的状态。数据平面容错服务器代理和交换机应具备“安全模式”。当与控制器失联时可以切换到预先配置的、保守的默认策略例如使用一个非常小的固定WS或采用标准的TCP Reno算法保证网络基本可用尽管性能不是最优。状态快速同步控制器重启或切换后可以通过从持久化存储中加载最近快照并结合从交换机和代理主动拉取关键状态如活跃流列表来快速重建全局视图。6.3 与现有基础设施的集成数据中心网络往往是异构的并非所有交换机都支持OpenFlow或相同的南向接口。挑战如何在不支持SDN的传统交换机上实施动态缓冲区策略应对策略混合模式在支持SDN的交换机通常是核心和汇聚层上实施精确的流控。在传统的接入层交换机则依靠主机端的代理进行控制。控制器根据网络设备的能力下发不同精度的策略。带外控制对于完全不支持编程的传统交换机DyFaShBuP可以退化为一个纯粹的主机端解决方案。SDS控制器只与服务器代理通信根据拓扑信息估算出路径上的瓶颈带宽和延迟可能不精确然后指导代理设置WS。其效果虽然不如全网协同精确但仍能显著优于完全无协调的状态。6.4 策略的精细度与复杂性“公平”并不总是意味着“平均”。不同的应用、不同的租户可能有不同的优先级和SLA要求。挑战如何实现加权公平共享或优先级调度应对策略DyFaShBuP的核心算法可以很容易地扩展。将公式WS BDP / N修改为WS_i (Weight_i / ΣWeight) * BDP。SDS控制器可以为每个流或流组分配一个权重Weight权重可以基于应用类型、租户合同、付费等级等。这样就在保证避免Incast的前提下实现了差异化的服务质量。7. 总结与展望从Incast缓解到智能存储网络回顾DyFaShBuP方案其最大的价值在于提供了一种基于全局视图和预防性控制的Incast问题系统化解决思路。它跳出了在端点上修修补补的局限利用SDN/SDS的集中控制能力将网络和存储资源作为一个整体进行优化调度。在实际操作中部署这样一个系统需要分步走。我建议先从一个小型的、独立的存储测试集群开始例如一个用于AI训练或大数据分析的GPU存储池。在这些对低延迟和高吞吐极度敏感的场景中Incast的影响尤为突出DyFaShBuP带来的性能提升会非常明显。初期可以重点实现核心的WS动态计算和下发功能控制器可以采用开源的SDN控制器如OpenDaylight, ONOS进行二次开发代理则用Python或Go编写通过tc命令或套接字选项实现窗口控制。在取得初步成效后再逐步将方案扩展到更复杂的生产环境。此时需要重点攻克高可用、水平扩展和与现有网管系统集成等工程难题。可以预见随着存储介质性能的不断提升NVMe-oF RDMA和网络延迟的持续降低微秒级的延迟波动都会被应用感知对网络流量的精细控制需求只会越来越强。未来DyFaShBuP所代表的集中式、应用感知的网络控制思想可以与更多技术结合与RDMA融合在RoCEv2等RDMA over Ethernet网络中如何避免类似Incast的“拥塞崩溃”是一个新课题。集中式控制器可以管理RNIC的缓冲区并指导流量调度。与AI运维结合控制器收集的海量网络和存储性能数据是训练AI模型的绝佳素材。未来可以实现基于机器学习的预测性流量调度在流量模式发生变化前就提前调整策略。跨层优化将文件系统的条带化策略、存储服务器的I/O调度策略与网络层的流量控制策略联动起来实现真正的“存储网络协同优化”。例如控制器可以建议文件系统将某个大文件条带化到特定的、当前负载较轻的服务器集合上。从缓解TCP Incast这一个具体问题出发我们最终通向的是一个更智能、更高效、更可控的数据中心存储网络。这条路充满挑战但每一步扎实的探索都让我们离这个目标更近一些。
