分布式计算平台Hadoop环境下的组网方案v02new.pptVIP

一个有意思的现象，使用了大Buffer的交换机之后，JOB的时间会缩短，吞吐量会上去，但是仍然会看到有TCP Retransmission 这是因为心跳和TCP ACK等信令报文被积压在了Buffer中，没有及时到达，导致TCP重传 1 2 3 4 5 6 … 24 48 … 30 29 28 27 26 25 Packet Shared Buffer TCP数据报文 TCP ACK报文 Job Tracker与Task Tracker之间的心跳报文 NameNode与DataNode之间的心跳报文 为了减缓TCP Incast，高吞吐量需要Switch具备一定的Buffer，来缓存溢出的流量。但是低延迟则相反，留在Buffer中的时间越短越好。 心跳报文/TCP ACK需要低延迟，需要被快速的送达目的地。如何让这类报文避过Buffer的延迟？ 使用DCTCP，减少TCP Incast带来的流量溢出。在保持高吞吐量的同时，将Buffer队列维持在一个较小的占用比例，以此让心跳报文/TCP ACK在Buffer中停留的时间大大缩短。 N3548支持DCTCP，同时具备ULL，所以会让心跳报文/TCP ACK传递的更快。 ECN首先由传输层进行能力协商 协商完毕后控制IP头的ECT、CE标致位 接收端接收到CE包，向发送端发送拥塞通知 目前TCP通过使用两个预留标志位来实现能力协商和拥塞通知 TCP新建标志位为CWR（Congestion Window Reduce）和ECE（ECN-Echo） UDP等其余传输层协议需要应用层通知 ECN:Congestion Notification SYN=1, ECE=1, CWR=1 支持拥塞通告，也支持拥塞窗口调整 SYN=1, ACK=1, ECE=1，CWR=0 支持拥塞通告，不支持拥塞窗口调整 ACK=1，ECE=0，CWR=0 能力协商结束 TCP 握手阶段 拥塞发生 IP ECT=1, CE=0 IP ECT=1, CE=0 IP ECT=1, CE=1 ACK=N, ECE=1，CWR=0 通知发生拥塞 Data, CWR=1 接收到拥塞通知，发送窗口减半 ACK=M, ECE=0, CWR=0 接收到CWR=1，ECE清除，否则持续发送 传统的ECN模式 Data Center TCP Algorithm Switch side: Mark packets when Queue Length K. Queue is not full Sender side: Maintain running average of fraction of packets marked (α). In each RTT: Adaptive window decreases: Note: decrease factor between 1 and 2. B K Mark Don’t Mark Source: Data Center TCP (DCTCP), SIGCOMM 2010, New Dehli, India, August 31, 2010. Incast Results with DCTCP 2MB 4MB 8MB 每台服务器使用翻倍的以太网链路接入交换矩阵，消除TCP Incast。以空间换时间。 简单粗暴：增加Server与网络之间的带宽 MapReduce的运行方式会造成TCP Incast，降低Hadoop的运算效率。 网络架构设计灵感来自于CRS ，设计要点包括： 加速比/Speedup、ECMP 、 Self Routing、Buffer 解决TCP Incast的方式： 大Buffer 适量的Buffer + DCTCP（N3548） 使用翻倍的以太网链路接入交换矩阵，消除TCP Incast * * * * * * /~ychen2/professional/TCPIncastWREN2009.pdf * * * Transcript: Lets see, we have two linecards trying to send 10G to an input linecard but thanks to the virtual output queues that are using Cisco 12000 or ASR 9000 it just works correctly. There is no blocking for this traffic because the arbiter will correctly grant the capacity and any other traff