一、     超高速交换网络

l  传统交换架构，非真正意义的“无阻塞”

在“数据中心级交换机”概念出现以前(这个概念也是随着云计算发展而产生的，此前只有核心交换机、高端交换机的概念)，盒式交换机一般是单芯片，机架式交换机则主要是“交换网+IO芯片”结构，比较先进的交换网一般采用crossbar，架构如图1所示。

传统高端设备以交换线卡连接crossbar高性能交换网，数据在Crossbar内部选路基于实现配置好的规则，同一数据流在内部的运转路径是确定的(HASH算法)，因此存在特殊情况下在交换不同级层上会发生阻塞的现象，如图1的数据流1和2在第一级、数据流3和4在第二级的阻塞(情景有点类似于等价路由或链路捆绑的流量不完全均衡性)。这种架构的交换网容量并不大，一般以支持10GE为主。这种非真正意义的“无阻塞”在一般性数据中心并不会遇到挑战，但在大型互联网数据中心，随着近年来ISP业务不断丰富、业务规模不断扩大和实际带宽消耗迅猛增长，已经出现了传统交换架构在互联网数据中心难以满足性能需求的现状。

图1 传统Crossbar交换架构的阻塞分析模型

l  无阻塞交换，云计算核心交换平台的关键且基本的要求

到了新一代交换平台产生的时代，数据中心级核心交换平台的能力已经确定在10Tbps的级别，交换系统的架构产生了本质的变化，这种变化是为了应对云计算超高速100G、以及实现今后10T环境下的完全无阻塞所带来的挑战而变革产生的架构，也就是CLOS架构。

那么，完全无阻塞的意义就是对一个交换架构无论是理论分析还是实测，都能够达到真正的无阻塞交换(如果不能全线速，完全无阻塞也用处不大了)。完全无阻塞的概念，也是在云计算环境下开始逐步强调的，因为云计算中心应用密度比之传统数据中心高得多，流量情况更为复杂，数据性能要求更为严格，如果在交换平台核心不能满足完全无阻塞的交换条件，瞬时引起的阻塞必然会导致网络流量异常，即使是理论上小概率的瞬时阻塞，也可能在云计算网络中反复出现。这对大型网络来说，是存在隐患的，因为不断增长的业务和流量可能因为核心平台的隐患而有所限制(莫名其妙的情况下发现网络偶然不畅)，这种潜在问题有时是无法分析清楚的，特别是已经在运行的网络。因此，完全意义上的无阻塞交换，是云计算核心交换平台的关键而基本的要求。

新一代交换架构三级CLOS&CELL交换可支持完全无阻塞交换，是完全遵循复杂业务流要求的，能够将大规模密集流量在交换系统内部均匀交换，避免了阻塞带来的性能恶化与严重下降。其实现基本原理如图2所示，在系统内部采用动态选路方式(线卡、交换网保存内部数据转发路径信息，如果出现路径不可用或网板、线卡故障，选路信息动态改变，这一切操作由硬件系统内完成)，业务线卡接收到的数据包文，进行等长切片处理形成定长信元，每个信元加载动态选路的标记头(长度不够的信元会进行内部填充)。

图2 H3C新一代CLOS架构&Cell交换实现模型

l  如何构造无阻塞交换网络

云计算需要超大的计算能力和网络交换能力，通过网络来组织数千台至上万台服务器的协同计算，因此云计算的支撑网络也提出了无阻塞的方向。

首先看如何构造大规模的线速网络，如图3所示，从两个方向来扩展，在层次上，每一层的交换设备上行所有链路带宽与下行的所有链路带宽相等，在同一层次，按照下一层设备的上行端口数扩展，如此直到最高层(目前主流构造两层到三层网络结构)。

图3 大规模网络扩展方式

构造线速交换网络比较简单，但是要达到无阻塞，当前的技术实现还不够彻底，因为在网络级别只能使用链路负载均衡技术实现对带宽的充分利用。如图4所示，实现方式主要有两种。

图4 链路负载均衡

Round robin方式：将数据流依次向可用链路均匀转发(可以基于统计速率、也可以基于逐包方式)，一般来说，当服务器之间全部使用定长报文(如1500字节)交互数据，基本就构成了一个“完全无阻塞交换网络”(是定长数据交换条件下)，但是存在的问题是，同一数据流的不同报文可能经过不同网络路径到达目的地，经过网络大规模流量浪涌后会存在严重的乱序问题。

HASH方式：使用网络设备的硬件负载均衡算法，基于数据流的二三层地址信息和四层端口号信息得到不同链路的选路信息，能够保证同一数据流经过相同路径到达目的地，避免乱序，但是不同数据流因为流量大小有差异，使得网络不同链路难以完全均衡，不过在当前技术条件下，不均衡度已经极小，十分接近完全无阻塞交换网络了。

二、     浪涌，云计算环境下的一个网络现象

在云计算环境下，性能无疑成为最为关注的核心要素，但是，有了超高速的交换性能，不一定表示网络能够达到理想的效果,还需要关注网络浪涌的吸收容量，我们从分析端口流量情况和网络实际流量情况入手。

l  端口流量

图5是我们进行毫秒级网络流量研究时得到的流量图，不妨称之为微观流量视图(事实上早在2000年左右，运营商的研究机构已经在622M骨干网发现了这个现象)。在秒级、分钟级以上的宏观时间尺度下，流量A和B的采样曲线十分平滑，这是因为流量观测的累积平均效果造成的，当采样尺度缩小到毫秒级，我们发现，从端口得到的流量曲线发生了变化，最高的流量值可能达到平均流量的2-3倍(当然，也有更低的曲线值)。

图5 微观的流量视图

这个问题的本质来源于交换机的线速转发特性(实际上核心、高端交换机内部还有更大的加速比，即内部交换通道速率一般远高于对外的端口速率，但我们不必过于复杂化)。线速转发的机制，使得交换机在接收或者发送任意一个报文的时候，都不同于我们观察到的结果(我们看到的都是一段时间内的平均速率)，任一个报文都是以千兆或万兆速率在转发，而且持续达到线速后，报文之间的转发时间间隔(或称帧间隙)达到了最小值。我们以图6为例作一个不太严格的分析，在千兆端口下，假定转发的报文大小为端口MTU级，即报文为1500字节，计算出的串行化时延约为12微秒，由于报文之间还有帧间隙，为简单起见，假设为8微秒(实际帧间隙非常之小)，那么一个报文的转发到链路时间为20微秒。也就是说，要体现交换机线速转发，端口上每20微秒就发送一个1500字节报文。隐含的事实是，任何一个1500字节的报文都以20微秒的标准在交换端口转发出来，所用带宽均为1Gbps。

图6 微观采样的理想化分析

那么如果网络中我们观测到一个端口流量是500Mbps，该如何来理解这个信息呢？如图7所示，最理想的情况当然是每40微秒转发一个报文，这样网络流量最平稳，最恶劣的情况是，在观测周期内，前半段时间流量20微秒的密集(即持续千兆速率转发)，后半段时间无数据转发。当然，正常情况下是界于二者之间非常随机的。

图7 平均速率的理解模型

l  网络的实际流量

网络是由多个网络设备组成的，网络的流量难以有很合适的描述模型，不同的网络业务模型、性能要求都不一样，我们只分析网络数据流的走向情况。

先看一个全线速、完全无阻塞交换机的数据流向,包含两种情况（如图8所示）。不论是A还是B，对单个网络节点而言，即使是全线速无阻塞的性能，也面临着在短时间的高带宽向低带宽的数据流向，相对而言情况A比较容易确定，情况B比较复杂。因此分析网络的实际流量，其本质上网络节点的流量并不是均衡的，也就是说，网络实际流量并不是完全按照网络设备的无阻塞架构来转发的，总是会造成一个瞬时拥塞，即进入交换机的带宽比出交换的带宽要高，如数据中心内部多台服务器向少数服务器传送数据的情况，如图9所示。左边两种情况都不会影响业务性能，但是最右边引起瞬时拥塞，如果产生丢包，必然对上层应用产生影响，特别是云计算环境下，数据流量超大，拥塞的数据被丢掉后必然使得整个云平台的性能和可用性大为降低。这种恶劣的影响并非网络设备交换性能不够产生的，实质上是网络流量的不可控可变带宽比产生瞬时收敛造成的(如多个万兆到少数万兆、万兆到千兆等)。

 

图8 定向与不定向的网络流量

 

图9 网络中的可变动态带宽比

基于以上两方面的分析，我们确定云计算环境下的一个网络现象---浪涌(在一般网络条件下称为流量突发，burst)，密集的高速流量，瞬时的收敛性数据传输与同步特点。比之一般网络的突发更为严峻的是云计算网络一旦发生拥塞丢包，所需要处理的数据量比常规条件下大得多。如图10所示，网络端口的平均流量并不高，但是从两个端口向一个端口的流量由于疏密不均，造成了突发。在入端口方向，由于交换线速转发的特点，宏观平缓数据流在不同毫秒级范围内度量结果也不一样(340pps～800pps的成倍关系)，当这两个端口流量要向同一端口输出时，是不是会造成更为恶劣的流量突发---浪涌情况？

图10 突发的基本形态

突发毕竟是瞬时的，一般情况下认为是毫秒级的或亚秒级的(所以叫瞬时拥塞)，而平均流量并没有达到所用的带宽，如果是持续的拥塞，则应该是带宽需要扩容了。

对网络节点的突发分析也适用于整个云计算网络，即使是无阻塞的网络架构，其上承载的浪涌突发数据流也是不定向的，整个网络的浪涌吸收能力决定了云计算的密集数据吞吐、交互、处理能力。

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

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

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

图11 入端口缓存

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

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

图12 时延与转发

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

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

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

：

图13 常见的缓存公式

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

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

l  动态收敛比：N

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

图14 动态收敛比定义

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

                     -----------------------------公式1

 

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

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

图15 突发数据量和网络传送时间

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

  ----------------------------------公式2

l  临界缓存值：buffer0

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

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

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

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

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

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

图16 临界缓存buffer0

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

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

图17 临界缓存与收敛比的关系

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

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

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

实例分析一：网络搜索

应用的基本描述

l   查询服务器向200台响应服务器发起请求

l   每台响应服务器发出60KB的数据，折合1.5KB报文约40个，响应服务器在最短时间向网卡发送数据，时间非常短(1-2毫秒)，可认为所有服务器发生了瞬时突发

l   查询服务器将所有请求收到的时间规定在40-60毫秒内，我们设为50毫秒

l   当时使用的这个设备缓存大，但是缓存分配的个数只有4K个单元，且均分到不同端口，因此随着应用的负载增加，逐步出现检索丢包的现象。

图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毫秒的响应时间条件下可获取更大的突发能力。

 

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

l   20000学生规模，300台左右服务器

l   两台接入设备使用VRRP方式运行在三层主备模式。

l   上行各为一个千兆，两台设备之间为两个千兆互联

l   右边设备为Master，使用了一块4:1收敛的交换线卡上行，缓存<500KB，其它线卡缓存

l   问题是每学期学生集中选课时网络异常，但是平均流量很小，不足200Mbps

l   当人为进行A和B链路切换(数据流从B上)，VRRP主备不倒换时，故障消失，平均流量依然为200Mbps左右。

图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，在缓存满时已经传输的数据量是

带宽到2G后，缓存满时已经传输的数据量是

19/9，说明原有缓存满后，已经传输的数据量超过了原来的两倍，这样就极大降低了突发。从slave的角度，收敛比只有2:1，也能够缓解缓存的要求，同时数据流经过了Master和slave设备，经过了两级网络缓存，进一步改善了突发。

五、     H3C S7600（X）产品设计

H3C S7600（X）系列交换机产品是杭州华三通信技术有限公司（以下简称H3C公司）面向云计算数据中心核心、下一代园区网核心和城域网汇聚而专门设计开发的核心交换产品。部分采用先进的CLOS多级多平面交换架构，可以提供持续的带宽升级能力，支持数据中心大二层技术TRILL、纵向虚拟化和MDC（一虚多）技术，支持EVB和FCOE，并完全兼容40GE和100GE以太网标准。该产品基于H3C自主知识产权的Comware V5/V7操作系统，以IRF2（Intelligent Resilient Framework 2，第二代智能弹性架构）技术为系统基石的虚拟化软件系统，进一步融合MPLS VPN、IPv6、应用安全、应用优化，无线等多种网络业务，提供不间断转发、不间断升级、优雅重启、环网保护等多种高可靠技术，在提高用户生产效率的同时，保证了网络最大正常运行时间，从而降低了客户的总拥有成本（TCO）。

面对下一代数据中心突发流量，创新的采用了“分布式入口缓存”技术。每个端口可以精确地对所有流向该端口的各个业务流进行精确的带宽分配和流量整形，转发平面的精确调度确保支持Ingress方向的分布式缓存，有效共享和利用分布在各线卡上的缓存空间，提供更好的缓存效果。

网络应用模型已经由C/S转换为B/S模型，应用方式的转变，导致网络突发流量的增大，大缓存机制已经成为网络设备的迫切需求。S7600（X）每万兆端口支持200ms突发流量，每个板卡集成多个高性能交换芯片，每个交换芯片采用1.2G缓存，交换芯片连接到每个万兆接口为256Mbuffer，分布到每个千兆接口为21.3Mbuffer，再结合分布式入口缓存机制，满足大型数据中心高突发流量的需求。

转自：http://www.h3c.com/cn/Products___Technology/Products/Switches/Data_Center_Switch/S7600-X/S7600-X/White_Paper/201506/877127_30003_0.htm