网络带宽已经跨过了10M/100M/1000M，当前的10G、N*10G的高速带宽正成为网络建设的基本规格。随着>8*10G性能的需求日趋强烈，超高速网络(40/100G平台)技术已经开始在当前的数据中心部署使用。

　　云计算网络的性能要求超过常规应用数据中心，这样的要求使得网络平台构建上性能的考虑区别于传统的认识，深入认识云的底层特质。网络的交换容量和网络浪涌的吸收容量即是云计算(或大型数据中心)网络的性能关注点要同时关注的两方面。

　　超高速交换网络之前的几个概念

　　线速

　　指的是线路数据传送的实际速率能够达到名义值，比如千兆端口能够实际吞吐量到千兆，这在交换机是比较轻松的事，但是早期的高端路由器端口如果能够达到千兆实际转发速率，那是非常了不起的(不过现在已经稀疏平常了)。

　　超线速

　　如千兆端口能够吞吐的流量超过一千兆(一般也就超出一点点)，这种交换机与标准线速设备对接后容易产生丢包甚至将标准交换机“堵死”。在数据中心环境下极少数情况也允许满足超线速的组网，只是对交换机有特殊要求。

　　全线速

　　交换机的所有端口能够同时达到线速转发。这个能力也体现了交换机的性能，对于某些性能较低的设备，称为达到全线速转发，是指达到了设备的最高性能而已，有可能离该交换机的端口容量总和还远着呢。

　　“无阻塞”全线速

　　有时候在全线速前面再定义一个“无阻塞”，其实是强化交换机的全线速能力，指的是对交换的任意大小字节的报文均能够达到全线速的能力，所有端口都以线速接收帧，并能无延迟地处理被称为“无阻塞（Nonblocking）”，之所以这样叫是因为设备内部没有等待处理的报文（没有阻塞）。但是无阻塞有时也会遇到挑战，在很小的概率下(即实际测试中极不容易出现)，确实能够构造特定测试例使得交换机产生阻塞，这是因为传统交换架构下理论上也能分析出阻塞的可能性。

　　一、超高速交换网络

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

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

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

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

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

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

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

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

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

　　如何构造无阻塞交换网络

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

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

图3大规模网络扩展方式

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

图4链路负载均衡

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

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

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

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

　　端口流量

　　图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平均速率的理解模型

　　网络的实际流量

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

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

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

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

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

图10突发的基本形态

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

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

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

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

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

图11入端口缓存

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

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

图12时延与转发

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

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

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

图13常见的缓存公式

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

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

　　动态收敛比：N

　　如图14所示，在云计算网络中，由于整个网络都可能是无阻塞的，从表面上是看不

图14动态收敛比定义

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

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

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

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

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

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

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

　　临界缓存值：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的值，即允许网络传输时间更长。

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

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

　　实例分析一：网络搜索

　　应用的基本描述

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

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

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

　　当时使用的这个设备缓存大，但是缓存分配的个数只有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毫秒的响应时间条件下可获取更大的突发能力。

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

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

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

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

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

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

　　当人为进行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，在缓存满时已经传输的数据量是buffer0*1/19

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

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

　　五、结束语

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