三、云计算核心交换网络的缓存结构

对于交换机而言，缓存方式也有不同的机制：出端口和入端口缓存。传统技术实现多以出端口缓存为主，这种机制使得所有数据流的突发在出端口处被缓存，缓存的大小即是网络最大可能的突发值。

新一代云网络的核心交换平台一般采用入端口缓存（如图11所示），一般结合虚拟输出队列(VoQ)技术，在每个入端口方向配置大容量缓存，在出端口配置较小缓存，使用专用流量管理器件TM(traffic manager)进行内部流量管理，并采用credit来控制每个端口入方向的数据向出端口的突发，每个出端口向其它入端口分配credit数量，当出端口在线速向外转发数据时，如果入方向过来的数据速度较快，在达到或超过出端口设定的突发门限时，出端口不再为入端口分配credit，从而使得入端口的数据缓存在本地的大容量buffer中，当出端口(保持线速对外转发)的排队下降到门限以下，继续向入端口分配credit，使得缓存的数据得以继续转发。

 

http://www.h3c.com.cn/res/201004/21/20100421_960444_image011_671510_30008_0.png
图11 入端口缓存

因此入端口缓存机制下，各端口的数据在出端口拥塞时都能在本地缓存，因而缓存容量是与入端口数成正比的线性关系。这种线性比例的缓存能力，能够自适应于云计算的不定向浪涌流量，交换缓存架构能够自动调节不同方向的瞬时流量拥塞压力，是当前云计算网络的主要应用技术。

而对于时延与缓存，很多人一谈到大缓存设备，立即联想到大的交换时延，而低时延必然是小缓存，其实，两者之间并没有必然的联系，一切取决于网络的应用情况。对于交换而言，一般的存储转发时延是几个微秒，与缓存大小并无绝对关系，如图12所示，对于无拥塞的轻载网络A，数据进入交换机缓存后立即进行查表转发，大缓存和小缓存的效果是一样的，当出现瞬时拥塞后如B，大缓存能够避免丢包(重传引起的时延比缓存的时延大多了)，而小缓存在大规模突发流量下如C，必然对突发的缓存量少，会丢弃报文。

 

http://www.h3c.com.cn/res/201004/21/20100421_960445_image012_671510_30008_0.png
图12 时延与转发

但并不是所有应用都需要大缓存(毕竟成本不一样)，因此考虑到时延的网络平台需要根据应用的具体情况构建，一般情况下建议实测来选择建网方案。

四、浪涌缓存模型分析---多大缓存合适？

有不少研究曾经着重于网络到底需要多大的缓存，最著名莫过于图13这个公式了，该公式更多地被应用到路由器作为广域链路连接时的缓存大小确定，其目的是为了充分利用昂贵的广域网带宽。

 

http://www.h3c.com.cn/res/201004/21/20100421_960446_image013_671510_30008_0.png
图13 常见的缓存公式

其中：Buffer指缓存大小，单位Byte；BW数据传送带宽；RTT(Round-Trip Time) 往返时延，在网络中它是一个重要的性能指标，它表示从发送端发送数据开始，到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认)，总共经历的时延。

数据中心的缓存如何来建模呢？数据中心与广域网有显著区别，内部带宽可以是足够的(高速交换)，但是突发浪涌很严重，那么缓存主要不是用来充分利用带宽的，而是用来吸收浪涌的。这里的模型并不具有严格的学术意义，但是，用户如果能够在日常注意收集数据中心的相关业务数据，对于自身的缓存需求建模和网络性能分析是很有参考意义的，下文描述的模型有助于分析某些应用中的问题。

• 动态收敛比：N

如图14所示，在云计算网络中，由于整个网络都可能是无阻塞的，从表面上是看不到收敛的，但是计算的交互并不是我们想象的那样完全均衡的按照我们想象进行无阻塞交换，而是经常发生诸如数十个计算节点与几个计算节点进行数据传输，或者如同搜索一样，几台服务器从数百台服务器获取搜索结果，这都会在网络中造成瞬时(我们在毫秒级考量的尺度)的数据通道带宽不一致，引起短时的拥塞。因此这种问题的分析也就是数据的入方向(Ingress)带宽高于出方向(Egress)带宽的情况才有意义(其它情况基本不会影响上层业务的品质)。

 

http://www.h3c.com.cn/res/201004/21/20100421_960447_image014_671510_30008_0.png
图14 动态收敛比定义

简单起见，假设端口的带宽BW是固定的(千兆或万兆)，流量的入端口数为Mi，出端口数为Me，要求Mi大于Me，那么：

http://www.h3c.com.cn/res/201004/21/20100421_960448_image015_671510_30008_0.png
http://www.h3c.com.cn/res/201004/21/20100421_960449_image016_671510_30008_0.png
http://www.h3c.com.cn/res/201004/21/20100421_960450_image017_671510_30008_0.png -----------------------------公式1    

• 突发数据量和网络传送时间：D和T

我们再来定义两个指标，如图15所示，对于构建云计算网络的用户来说，Tm是由业务层面提供的参考数据，D也应由业务层面给出，但一般难有具体值，需要经过分析来获取，后文将给出两个分析案例。

 

http://www.h3c.com.cn/res/201004/21/20100421_960451_image018_671510_30008_0.png
图15 突发数据量和网络传送时间

实际的数据传送时间为t，t必须小于等于Tm才能满足业务要求，那么：

http://www.h3c.com.cn/res/201004/21/20100421_960452_image019_671510_30008_0.png ----------------------------------公式2

• 临界缓存值：buffer0

我们再定义一个临界缓存值buffer0，是指能够刚好满足突发要求的最小缓存值，即在数据D的突发量下，buffer0刚好能够容纳这些数据(因为在缓存容纳数据的同时，出端口还在往外转发数据)，如图16所示。

我们借用水池漏水的题目，如图16所示，蓄水池的大小是buffer0，粗水管以BH的速率往水池里灌水，细水管以BL的速率往外流水，问题：

1.   当水池装满后，粗水管一共灌了多少水？

--------------求突发量D与buffer0、入出带宽BH和BL的关系

2.   如果当水池满后就停止灌水，那么从最开始灌水，到水池的水流干，一共要多长时间？

--------------求突发量D下，数据传送时间t与buffer0和带宽关系(是否满足应用的需求)

 

http://www.h3c.com.cn/res/201004/21/20100421_960453_image020_671510_30008_0.png
图16 临界缓存buffer0

通过对以上问题的求解（由于篇幅有限，这里求解过程略去），我们得出当网络的出带宽等于入带宽时，是不需要buffer的。同样，根据公式分析，在发生瞬时拥塞的条件下，增加出口带宽(入带宽不变)可以减少对buffer的要求。

临界缓存与收敛比的关系如图17所示，出带宽增加，不仅收敛比减小，buffer0的要求降低，同时根据t=D/BL得知相同突发数据量的传送时间大幅降低。反过来也根据模型得出，收敛比减小出方向带宽增加时可突发的数据量比原有收敛比要大。

 

http://www.h3c.com.cn/res/201004/21/20100421_960454_image021_671510_30008_0.png
图17 临界缓存与收敛比的关系

如果网络的收敛比不变、缓存也不变，但是随着业务量的突发严重，要求更大的突发量，该如何调整？根据模型公式分析，需要应用层进行调整，即对数据突发进行平缓处理(避免突发过于集中超过buffer0导致大量丢包)，同时增加Tm的值，即允许网络传输时间更长。

上述公式比较离散，分析问题时需要根据条件不断转化，虽然云计算环境非常复杂，但是只要在网络规划、运行过程中不断收集参数，对浪涌的分析与优化是可行的

两个传统数据中心实例说明如何利用模型进行分析

实例分析一：网络搜索

应用的基本描述

• 查询服务器向200台响应服务器发起请求
• 每台响应服务器发出60KB的数据，折合1.5KB报文约40个，响应服务器在最短时间向网卡发送数据，时间非常短(1-2毫秒)，可认为所有服务器发生了瞬时突发
• 查询服务器将所有请求收到的时间规定在40-60毫秒内，我们设为50毫秒
• 当时使用的这个设备缓存大，但是缓存分配的个数只有4K个单元，且均分到不同端口，因此随着应用的负载增加，逐步出现检索丢包的现象。

 

http://www.h3c.com.cn/res/201004/21/20100421_960455_image022_671510_30008_0.png
图18 搜索模型的简单分析

从上面的一些数据，可以得到

突发数据量  D=200*60KB=12MB

业务响应要求时间 Tm=50毫秒

网络收敛比是200千兆端口数据发向1个千兆端口，但是最严重的地方在于查询服务器所在的交换机两个万兆流量打入A所在的千兆端口，不妨设定收敛比为N=20G:1G=20

那么平均要求的传输带宽是12MB/50毫秒=1.9G，说明现有的带宽1G根本不能满足业务需求。

现在应用进行调整，将60KB数据降低到30KB，此时D=200*30KB=6MB,1G带宽是可以满足要求的，现在来看缓存的要求，根据模型公式，buffer0=(1-1/20)*6MB=5.7MB，按照1.5KB一个报文，buffer0至少需要缓存报文个数为5.7MB/1.5KB=3.8K个，因此一个设备的缓存不仅要求大小为5.7MB，可缓存的报文个数还要在4千个左右。

为了优化性能，可以选择两种方式来改进。

第一种是将缓存的所有单元全部分配给查询服务器单端口，这样能够满足突发所需的缓存需求。但是对于负载增加，入信息增加到60KB、服务器群增加的扩展性有很大限制。

第二种，将查询服务器改为万兆，此时收敛比N=2，如果在现有缓存能力(4K个报文32MB容量)下，可以突发的数据量D=buffer0×N/(N-1)=4K*1.5KB*2=12MB，比原来突发量升了一倍。

而业务响应时间t=D/BL=12MB/10G=9.6毫秒，远小于50毫秒的上限，而同步可传输的数据量是原来的10倍(带宽增加了10倍)。如果应用层进行调整，平缓突发如分组或分时(以9.6毫秒为参考)，那么在50毫秒的响应时间条件下可获取更大的突发能力。

 

实例分析二：校园网数据中心应用

• 20000学生规模，300台左右服务器
• 两台接入设备使用VRRP方式运行在三层主备模式。
• 上行各为一个千兆，两台设备之间为两个千兆互联
• 右边设备为Master，使用了一块4:1收敛的交换线卡上行，缓存<500KB，其它线卡缓存
• 问题是每学期学生集中选课时网络异常，但是平均流量很小，不足200Mbps
• 当人为进行A和B链路切换(数据流从B上)，VRRP主备不倒换时，故障消失，平均流量依然为200Mbps左右。

 

http://www.h3c.com.cn/res/201004/21/20100421_960456_image023_671510_30008_0.png
图19 校园网数据中心案例

经过现场诊断和深入分析，解决方法为将右侧Master上行线卡更换为全线速、大缓存的线卡，运行至今未见问题出现。

问题分析：

选课一般时间比较集中，2万个学生选课假定10%的同时在线率，说明服务器要对外处理8000个会话，假定每个报文为512B(报文大小不一，只能假设一个)，则突发数据量可假定为D=2000*512B=1MB，即D=1MB。

收敛比，按照数据流从A链路上行，N=20:1=20 (假定只有同时20台服务器对外工作，其它服务器可能还提供别的服务，也对网络突发是有贡献的)。

因此buffer0=(1-1/20)*1MB=0.95MB，说明缓存要求显然高于现有网络运行产品的要求。

那么，为什么数据流绕行B链路上行能够缓解突发呢？

首先是Master向Slave发送端口的带宽增加了一倍，即相同时间内转发的数据流会更多，超过带宽要求的数据量会下降，而且由于收敛比下降了一半，对缓存的要求也降低。

根据模型公式，原来带宽是1G，在缓存满时已经传输的数据量是http://www.h3c.com.cn/res/201004/21/20100421_960457_image024_671510_30008_0.png
带宽到2G后，缓存满时已经传输的数据量是http://www.h3c.com.cn/res/201004/21/20100421_960458_image025_671510_30008_0.png
19/9，说明原有缓存满后，已经传输的数据量超过了原来的两倍，这样就极大降低了突发。从slave的角度，收敛比只有2:1，也能够缓解缓存的要求，同时数据流经过了Master和slave设备，经过了两级网络缓存，进一步改善了突发。

五、结束语

云计算是前所未有的性能密集型IT业务模式已经是不争的事实，云计算的发展将直接依托于超高速网络，并依赖于超高速交换技术实现服务交付。然而超高速交换本身还不足以解决所有问题，围绕超高速网络环境下的多种关键技术还有待于无缝集成。