logo资料库

Data Center TCP个人版翻译.docx

发布时间：2022-06-17 发布人：admin 分类：说明书 资料大小：0.56M 资料格式：docx 举报 版权申诉
第1页 / 共20页
第2页 / 共20页
第3页 / 共20页
第4页 / 共20页
第5页 / 共20页
第6页 / 共20页
第7页 / 共20页
第8页 / 共20页
资料共20页，剩余部分请下载后查看
    Data Center TCP 摘要 云数据中心拥有各种应用程序，将那些需要较小的可预测延迟的和其他需要大量持续吞吐量 的工作负载混合在一起。在这种环境下，当今最先进的 TCP 协议出现不足。我们提供一个 6000 台服务器组成的生产集群的衡量结果，并揭示导致高应用延迟的损害，这损害源于在 数据中心的交换机上 TCP 对有限可用缓存空间的要求。例如，带宽饥饿的“后台”流在交换 机上建立排队，由此影响延迟敏感的“前台”传输性能。 针对这些问题，我们提出 DCTCP，一种用于数据中心网络的类 TCP 协议。DCTCP 使用在网络 中的 ECN（显示拥塞通知）来提供多位反馈给终端主机。我们使用 1 和 10Gbps 速度和浅层 缓冲交换机评估 DCTCP。我们发现 DCTCP 与 TCP 相比，提供相同或更好的吞吐量，同时减少 90%的缓冲空间。不同于 TCP，DCTCP 对短流也提供高突发宽限和第延迟。在把握源于操作测 量的工作负载时，我们发现 DCTCP 提供应用程序来处理 10X 当前后台的传输，同时不影响前 台传输。此外，一个 10X 在前台传输的增加量并不导致任何超时，因此大大消除了恶意问题。 分类和主题描述：C.2.2 [计算机通信网络]：网络协议 一般项目：测量，性能 关键词：数据中心网络，ECN，TCP 1. 介绍 最近几年，数据中心网络已经转变了计算，大规模整合企业 IT 到数据中心枢纽，和云计算 服务提供商如亚马逊，微软和谷歌的出现。数据中心设计的一个一贯主题已经成为使用低成 本的商品组件[16]来建设高可用性，高性能计算和存储基础设备。相应的趋向也出现在数据 中心网络。尤其，低成本交换机在顶层是十分常见的，可提供多达 48 个 1Gbps 的端口，价 格低于 2000 美元——差不多是一个数据中心网络的服务器的价格。最近几项研究提出了设 想创造经济，通过在这些商品交换机之上建立新型构架，实现易于管理数据中心的目标 [2,12,15]。 这个设想现实吗？答案主要决定于商品交换机能把握数据中心实际应用传输（交通）的程度。 在本文中，我们专注于软实时系统应用程序（软实时系统中，即使任务过早或过晚完成，仍 有一定的收益。软实时是假实时但相对时延较小），支持（组成）大量数据中心构建的网络 搜索、零售（或者翻译成传播、转播）、广告和推荐系统。这些应用产生多样化的长短流组 合，并需要数据中心网络中的三样东西：短流的低延迟，高突发容忍和长流的高利用率。 前两个要求源于许多这些应用程序使用的分区/聚合（§2.1 中描述的）工作流模式。最终 结果的近实时期限转化成工作流各个任务的时延目标。这些目标从~10ms 到~100ms 不等，且 在截止期限之前未完成的任务会被取消，从而影响最终结果。因此要求低延迟的应用程序直 接影响到返回结果的质量，从而影响收益。减少网络延迟允许运用程序开发者投入更多提高 相关性和用户体验的循环算法。 第三个要求，长流（或大流）的高利用率，源于不断更新这些应用程序内部数据结构的需要， 以内数据的新鲜度同样影响到结果的质量。因此，这些长流量的高吞吐量与低延迟和突发容 忍一样很重要。 在本文中，我们做了两个主要贡献。第一，我们测量并分析了在一个月内从~6000 台服务器 （§2）收集到的生产流量（>159TB 的压缩数据），从那些网络由商品交换机组成的数据中 心中提取应用程序模式和需求（尤其是低延迟需求）。定义了损害性能的损伤，并与流量和 交换机的属性相关联。 第二，我们提出解决这些损害以满足应用程序（§3）需要的数据中心 TCP（DCTCP）.DCTCP 使用 ECN（显示拥塞通知），一种已经可以在现代商品交换机上使用的工具。我们以 1 和 10Gbps
    的速度在有 ECN 功能的商品交换机（§4）上评估 DCTCP。我们发现 DCTCP 在基准研究中成 功地支持了 10x 应用程序前台和后台的流量增长。 测量数据表明数据中心中 99.91%的流量是 TCP 流量。流量由查询流量（2KB 到 20KB 大小）， 时延敏感短报文（100KB 到 1MB）和吞吐量敏感长流（1MB 到 100MB）组成。查询流量经历内 部广播（incast）损耗，在[32,13]的存储网络背景下讨论。然而，数据同时揭示新的与内 部广播无关的损耗。因为长流消耗一些或者所有在交换机上可用的缓冲空间，查询和时延- 敏感短报文经历长时延。我们从这些测量数据中学到的关键点是：为了满足这样一个多样的 长短流混合（模式），交换机缓存占用需要保持低（状态），同时为长流量保持高吞吐量。 DCCTCP 正是为此设计。 图 1：在一个博通胜利交换机上测量的排队长度。两条长流量从不同的 1Gbps 端口发送到通 用的 1Gbps 端口。交换机启用了动态内存管理，允许流向公共接收器动态抓取高达 700KB 的缓冲区。 DCTCP 在源点将 ECN（显示拥塞通知）和一个新型控制方案组合在一起。它从 ECN 标记的单 比特流中提取网络拥塞的多位反馈。源点估计被标记包的分数，并使用那个估计作为拥塞程 度的一个信号。这使得 DCTCP 可以在非常低的缓存占用在工作，同时仍然实现高吞吐量。图 1 说明 DCTCP 和 TCP 相比，在只占用交换机数据包缓存区的一小部分时实现全吞吐连的有效 性。 在设计 DCTCP 时，一个关键的要求是它可以用现有硬件机制实现——意味着我们的评估可以 在物理硬件上进行，并且解决方案可以部署于我们的数据中心。因此，我们不考虑如 RCP[6] 的不能在任何商业交换机上实现的解决方案。 我们强调 DCTCP 是为数据中心环境设计的。在本文中，我们没有声明 DCTCP 对外围网络的适 应性。数据中心环境[19]和外围网络存在显著不同。比如，在没有排队的情况下，RTT（往 返时间）可以小于 250us。应用程序不仅需要极其高的带宽，还需要低延迟。通常，只有少 量统计复用：一个单独的流可以支配特定的路径。同时，数据中心环境提供确定的优势。网 络基本同质，并且在单一的管理控制下。因此，后台兼容性，对传统协议的增量部署和公平 性不是主要问题。与外部网络的连接通常通过能有效地分散来自外部的内部流量的负载均衡 器和应用代理，所以与传统 TCP 的公平性问题无关。我们不解决怎样在内部和外部流量之间 分摊数据中心带宽的问题（在数据中心外部至少有一个终端）。最简单的一种解决方案涉及 到使用以太网优先级（服务等级）来使内流量和外流量在交换机上分开，数据中心的 ECN 标记严格实施于内流量。 TCP 文献有很多，并且尝试控制队伍长度的拥塞控制协议主要分为两大种：（i）基于延迟 的协议，使用测量的 RTT 的增加作为队伍时延增长的信号，从而控制拥塞。这些协议十分依 赖于精确的 RTT 测量，因此很容易受到在非常低延迟环境的数据中心中的（杂波）干扰的影
    响。较小的干扰波动延迟变得与拥塞无法区分，算法可能表现出反应过度。（ii）AQM（主 动队列管理）使用来自拥塞交换机明确的反馈实现。我们提出的算法在这大类里。测量并分 析集群中的流量和相关的损害深度，我们发现 DCTCP 提供了所有我们寻求的好处。DCTCP 只 需改 TCP 中的 30 行代码和在交换机上设立一个单独参数（即可实现）。 2.数据中心中的交流 为了理解数据中心传输协议面临的挑战，我们首先描述一个常见的应用程序架构，即分区/ 聚合，这促使延迟成为数据中心中的关键指标。我们测量由这些应用程序架构产生的同步和 突发模式，并确认这些模式导致的三个性能损耗。 2.1 分区/聚合 图 2：分区/聚合设计模式 图 2 中所示的分区/聚合设计模式是许多大型 Web 应用程序的基础。来自较高层应用程序的 请求被分成碎片并外包给在较低层的工人。来自这些工人的响应汇总成一个结果。网页搜索， 社交网络内容构成和广告选择都大致基于这个应用程序设计模式。像这样的交互式软实时应 用程序，延迟是关键指标，总允许延迟由客户影响研究[21]等因素决定。在减去典型互联网 和渲染（翻译）延迟后，应用程序的“后端”部分一般分配在 230-300ms。这个限度被称为 总（时间）SLA。 许多应用有多层次分区/聚合模式工作流，其中一层的延迟将导致其他层开始的延迟。此外， 响应一个请求可能需要迭代地调用模式，聚合器（总和者）向下层的工人发出串行请求以准 备一个响应（通常为 1 到 4 个迭代，尽管多达 20 次也可能发生）。例如，在网络搜索中， 一个请求可能被发送给多个聚合器和工人，每个（聚合器和工人）负责索引的不同部分。基 于回答，聚合器可能改进求情并重新发送它以提高索引结果的相关性。分区/聚合的滞后实 例因此可以加在一起威胁到请求的总 SLA 时间。实际上，我们发现延迟运行很接近 SLA 目标， 因为开发人员利用所有可用的时间预算来计算可能的最佳结果。 为防止所有的 SLA 时间被违反，工人节点被分配十分紧的截止期限，一般在 10-100ms 左右。 就当一个节点错过其最终期限，计算在没有那个相应下继续进行，从而降低了结果的质量。 此外，工人延迟的高比例很重要。例如，99.9%的高延迟意味着 1000 个响应中至少有一个低 质量的结果或者长延迟（或者两者），潜在地影响可能导致不会再来(使用/访问)的大多数用 户。因此，延迟通常会跟踪到 99.9%，且截止时间与高百分数相关。图 8 显示了一个产品监 控工具截取到的一幕，跟踪高百分数。 在这么紧的截止时间内，数据中心内的网络延迟在应用程序设计中骑着重要的作用。喜多应 用程序发现使用最先进的 TCP 仍很难满足这些截止时间，所以开发人员通常求助于复杂特殊 的解决方案。例如，我们的应用程序仔细地控制每个工人发送的数据量并增加抖动。据报道， Facebook 已经开发了他们自己的基于 UDP 的拥塞协议[29]。
    图 3：在聚合器(请求)和服务器间的后台流（更新和短报文）之间在到达新工作的间隔时间 2.2 工作负载特性描述 接下来我们将测量三个与网页搜索和其他服务相关的生产集群的工作负载属性。测量结果用 于说明数据中心流量的性质，同时为理解为什么 TCP 表现不佳以及创建评估 DCTCP 的基准 打下基础。我们在超过 150 个支架上装备了总数超过 6000 台的服务器。这三个集群支持软 实时查询流量，与紧急短报文流量相结合，其中短报文用以协调获取并组织用以维持请求响 应质量的海量数据的集群中的活动和连续后台流量。我们使用这些术语便于解释和分析，开 发人员不会在简单的类集合中拆分流。测量仪器被动地收集描述延迟的套接字层的日志 （logs），被选中的包层的日志和应用层的日志——一个月内总共大约 150TB 的压缩数据。 在集群中的每个支架拥有 44 个服务器。每个服务器通过 1Gbps 的以太网连接到一个架顶交 换机（ToR）。ToR 都是浅层缓冲，共享内存的交换机；每个有 4MB 的缓冲空间共享总共 48 个 1Gbps 的端口和两个 10Gbps 的端口。 请求流量。集群中的请求流量遵循分区/聚合模式。请求流量由很短，对时延要求严格的流 组成，有以下模式。高级别聚合器（HLA）查询分区到大量中级聚合器（MLA），后者又转 而将查询分配到与 MLA 相同级别的其他 43 个服务器上。服务器同时作为 MLA 和工人，所 以每个服务器将作为一些查询的聚合器同时作为其他查询的工人。图 3（a）显示了中层聚 合器请求到达的 CDF 时间，请求从 MLA 到工人是 1.6KB，而工人到 MLA 的响应在 1.6 到 2KB。 后台流量。与查询流量并发的是一个复杂的混合后台流量，由大小流量组成。图 4 显示了后 台流量大小的 PDF，说明大多数后台流量有多小但后台流量中的大多数字节是大流量的一部 分。后台流量的关键（key）很大，1MB 到 50MB 不等，拷贝新鲜数据给工人的更新流和时 间敏感短报文流，大小由 50KB 到 1MB，那个更新控制在工人上声明。图 3（b）表示到达新 的后台流的时间间隔。后台流之间的内部到达时间间隔反映了支持应用程序的许多不同服务 的叠加和多样性：（1）间隔时间的变动很高，尾部很重；（2）出现嵌入式尖峰，例如 0ms 的间隔解释了 CDF 与 Y 轴相贴直到 50%；（3）相对大量的流出流量周期性地出现，因为工 人周期性地轮询一定数量的对等体来寻找更新了的文件。 流并发和大小。图 5 显示一个 MLA 或者工人节点同时参与流数量的 CDF（定义为在 50ms 窗口期间活动流的大小）。当所有流都考虑到了，并发流的中位数是 36，由每个服务器与 43 个其他服务器交流的分区/聚合流量模式的广度产生。99.99%超过 1600 个，有一台服务 器的中位数有 1200 个连接。
    图 4：分配给后台流量流大小的 PDF。总字节的 PDF 显示随机选择的字节是来自给定大小的 流的概率。 图 5：并发连接数量的分配 当只考虑大流量（>1MB）时，统计复用的程度很低——并发大流的中位数是 1,CDF 为 75% 时是 2.然而这些流都足够大，以至于他们持续了几个 RTT 时间，并且会由于引起队列建立来 消耗重要的缓存空间。 宗旨，吞吐量敏感大流，时延敏感短流和突发查询流量，都存在于同一个数据中心网络中。 在下节中，我们将看到 TCP 如何无法满足这些流的性能要求。 2.3 了解性能损耗 我们发现，为解释在生产集群中看到的性能问题，我们需要研究在集群中的长短流的交互， 以及承载流量的交换机和流量的交互方式。 2.3.1 交换机 与大多数商品交换机相同，这些集群中的交换机是共享存储交换机，目的是通过使用逻辑上 所有交换机端口可用的通用数据缓存区来使用统计复用增益。到达接口的包被存储到一个被 所有端口共享的高速多端口存储器中。共享池中的内存由 MMU 动态分配给包。MMU 通过 动态调整任意接口可获得的最大内存，试图满足每个接口的内存所需并同时保持公平性。如 果一个包必须在流出接口排队，但这个接口已经达到它最大分配内存或者共享池本身已经耗 尽，那么这个包会被丢掉。建设大型多接口内存十分昂贵，最便宜的交换机是浅缓冲的，导
    致包缓冲区变成最稀缺的资源。浅包缓冲区导致三种特定的性能损耗，我们在下面讨论。 图 6：流在多端口交换机上交互的三种导致性能问题的方式 图 7：在生产环境下测量的一个真实的聚播事件。时间轴显示查询发送超过 0.8ms，除了一 个响应其他都超过 12.4ms。那个响应丢失了，并在 RTO 时间（300ms）后重传。RTT+队列 估计了端口到聚合器的队列长度。 2.3.2 聚播（incast） 如图 6（a）所示，如果许多流短时间内在交换机的同一个接口汇集，包可能耗尽交换机内 存或者该接口的最大允许缓存，导致包丢失。即使是小流也可能发生这种情况。这种流量模 式由使用分区/聚合设计模式自然地出现，因为工人响应的数据同步器的请求和在从交换机 接口连接到聚合器的队列中创建聚播[32]。 截止至今的聚播研究[32,13]涉及到精心构建的实验测试场景。我们发现类聚播问题只在生产 环境发生并且十分重要——不仅降低性能，更重要的是，用户体验。问题是导致聚播的响应 将几乎可以肯定地错过聚合器截止时间，并被排除在最终结果外。 我们通过数据包级的监控抓取聚播实例。图 7 了观察到的例子的时间线。因为这个应用程序 中每个单独的响应只有 2KB 大小 两个包 1（1.每个查询都会到架构中的所有机器，每个机 器响应 2KB，所以总响应大小超过 86KB），包的丢失几乎总是导致 TCP 超时。在我们的网 络栈中，RTO 时间被设为 300ms。因此，每当超时发生时，响应几乎总是超过聚合器的截止 时间。 开发人员对应用系统代码做了两个主要更改来防止工人响应的超时。首先，他们故意限制响 应大小为 2KB 来提高所有响应可纳入交换机内存的可能性。其次，开发人员增加了应用程
    序级抖动[11]来同步通过一个随机量的时间（通常平均为 10ms）故意延迟的响应。关于抖 动的问题是它通过增加中值响应时间（因为增加时延）为代价，减少了在较高百分比上的响 应时间（通过避免超时）。这在图 8 中生动得说明。减少 RTO 时间的建议减少了超时的影 响[32]，但如我们下面所示，这提议没有解决其他重要的时延来源。 图 8：拥有聚播流量模式的生产应用程序的响应时间百分比。转发的请求在 10ms 的窗口中 抖动（故意延迟），直到上午 8:30 抖动被关闭。第 95 和低百分数下降了 10 倍，而第 99.9 的百分数翻倍了。 2.3.3 队列积累 长寿命，贪婪的 TCP 流将导致瓶颈队列的长度增长，直到丢包，导致熟悉的锯齿模式（图 1）。 当长短流通过同一队列时，如图 6（b）所示，发生两个损耗。第一个，短流的包丢失会导 致上述的聚播问题。第二个，出现队列积累损耗：即使没有包丢失，短流因排在大流的包后 面经历增长的时延。因为群中的每个工人都处理查询流量和后台流量（需要大流量更新工人 的数据结构），这种流量模式经常出现。 仔细观察图 7 显示响应的到达分布在~12ms 左右。因为所有响应的总体大小只有 43x2KB=86KB——1Gbps 大约在 1ms 的传输时间——令人惊讶的是，在这样的传输中将会有 少许聚播损失。然而，关键问题在于由其他流引起的队列占有率—后台流-和当长流和短流 重合时发生的损失。 为了确立长流影响队列响应的延迟，我们测量工人和聚合器之间的 RTT：这是工人发送响应 并接受到来自聚合器 TCP ACK 的时间间隔，在图 7 中标记为“RTT+队列”。我们测量到机架 内 RTT 在不排队的情况下大约在 250us，而架间 RTT 在 250us 以下。这意味着“RTT+队列” 是好的在聚合器收集响应期间用以度量发送给聚合器的包队列长度的工具。图 9 中的 CDF 是 19k 大小队列长度分布。这表明 90%的响应包排队时间似乎小于 1ms，10%的排队时间显 示为 1 到 14ms （动态缓冲的最大量为 14ms）。这表明查询流确实在经历排队时延。此外， 注意响应一个请求需要多次迭代，这将放大这个时延的影响。 注意这种时延与聚播无关。没有包丢失，所以减少 RTO 时间没有帮助。此外，甚至不需要 许多同步的短流。因为延迟是有排队导致的，唯一的解决方案是减少队列的大小。
    图 9：聚合器 RTT 的 CDF。长流分享队列导致 10%的响应出现 1 到 14ms 的不可接受的排队 时延。 2.3.4 缓冲压力 考虑到在数据中心中长短流的混合，一个端口上的短流被任意其他端口上的活动影响是很常 见的，如图 6（c）所示。事实上，这种流量模式的短流丢失率取决于通过其他端口的长流 的数量。这种现象的解释是不同端口的活动因共享内存池联系在一起（耦合）。 长贪婪 TCP 流在其接口上建立队列。因为缓冲区空间是共享资源，建立的队列减少了吸收来 着分区/聚合流量的突发流量的缓冲区空间大小。我们定义这种损耗为缓冲压力。其结果是 包丢失和超时，如同在聚播中，但不需要请求同步流。 3.DCTCP 算法 DCTCP 设计的动机是在§2.3 中介绍的性能损耗。DCTCP 的目标是在商品浅层缓冲交换机上 实现高突发容忍，低延迟和高吞吐量。为此，DCTCP 被设计来处理小队列占有，而不会损失 吞吐量。 DCTCP 主要通过与拥塞程度成正比的响应拥塞实现这些目标。一旦缓冲区占用超过固定的小 阈值，DCTCP 就会在交换机上使用的单一标记方案来设置数据包的拥塞体验（CE）码点。DCTCP 源通过用一个决定于被标记包的分数的因素减少窗口来做出反应：分数越大，减少因子越大。 注意这里的关键贡献不是控制法本身是很重要的。这是来自在单个位序列标记中存在的信息 导出多位反馈的行为。其它在这个信息上行动的其他控制法也可以得出。因为 DCTCP 要求 网络提供单个位的反馈，我们能够重新使用大量在现代 TCP 栈和交换机中可用的 ECN 机制。 反应与拥塞程度成正比的想法同样在基于延迟的拥塞控制算法[5,31]中使用。事实上，我们 可以观察路径延迟信息作为隐式多位反馈。然而，在很高数据速率和低延迟网络结构中，感 测在浅缓冲交换机中建立的队列会非常嘈杂。例如，在 1Gbps 下，10 个包的积压构成 120us 的排队时延，10Gbps 只需 12us。这样小的排队时延增加的精确测量对现在的服务器来说是 个艰巨的任务。 在缺少规模统计复用的情况下，对响应与拥塞程度成正比的需要尤其严重。标准 TCP 在它收 到 ECN 通知时将其窗口减少成一半。实际上，TCP 对拥塞的存在做出响应，而不是程度2。 （2.其他使用不变因素和/或者其他拥有相同问题的固定反应的变量）将窗口丢弃成半会导 致在链接的输入速率和可用容量的不匹配。在只有少量流分享缓冲的高速数据中心环境中 （§2.2），这将导致缓冲区下溢和吞吐量损失。
    分享到：
    赞 收藏

    相关推荐

    资料库

    网络技术

    共收录2367份资料，累计7个分类，关注成员有19位，主要包括：综合布线,网管软件,网络监控,网络设备,其它,系统集成,网络基础

    热门标签

    综合布线 网管软件 网络监控 网络设备 其它 系统集成 网络基础

    最新资料