1、前言
题目并不吸引人，主要是作者犯懒，罗列了一下关键词而已，当然好处是一看就知道文章要说啥。
简单说下结构，首先讲讲云计算，其次是数据中心，再然后是网络，重点还是技术。内容是循序渐进的，可以理解前面每个词都是后面词的定语。
本文希望能够帮读者对云计算的数据中心的网络的技术建立起全面的结构性认识，因此除了总体思路的描述外，在介绍过程中也会力争用三言两语对前面部分中涉及的每个技术点都有所说明，至少让人明白这个东东怎么来的，要干啥和怎么干。但由于受篇幅所限，无法做到很详细，大家如果对某个技术点真感兴趣时，还是去网上找些更细节的资料来理解，本文是打算没有写成一本书的。
力争做到让文档读起来不感到枯燥吧，对作者来说那是相当有挑战的。
2、云计算
最早接触这个词好像是06年了，当时也是刚刚开始接触数据中心不久，这几年眼睁睁看着它被炒作得一塌糊涂，现在已经成为非常给力的一个概念。和别人谈数据中心要是不提云计算，你还真不好意思张这个嘴。
服务器厂商在喊云计算，网络、操作系统、应用软件甚至存储厂商都在喊。大家各喊各的，让我们感觉听上去都有那么点儿味道，但下来仔细一琢磨大都还在云里雾里。看看这张网上截取的云计算产业全景图，估计没有几个能够不头晕的。
云计算的各方面定义很多，基于用户的视角来看，目的就是让使用者在不需了解资源的具体情况下做到按需分配，将计算资源虚拟化为一片云。站在高处看，当前的主流云计算更贴切于云服务，个人认为可理解为早先运营商提供数据中心服务器租用服务的延伸。以前用户租用的是一台台物理服务器，现在租用的是虚拟机，是软件平台甚至是应用程序。公认的三个云计算服务层次是IaaS（Infrastructure as a Service）、PaaS（Platform as a Service）和SaaS（Software as a Service），分别对应硬件资源、平台资源和应用资源。对于用户来说：
1、当提供商给你的是一套a 个核CPU、b G大小内存的主机、c M带宽网络以及d G大小存储空间，需要你自己去装系统和搞定应用程序，那么这就是IaaS，举例如Amazon EC2；
2、当提供的是包含基本数据库和中间件程序的一套完整系统，但你还需要根据接口编写自己的应用程序时，那么就是PaaS，举例如Google AppEngine、Microsoft Azure和Amazon SimpleDB, SQS；
3、最傻瓜的方式自然是连应用程序都写好了，例如你只需要告诉服务提供商想要的是个500人的薪酬管理系统，返回的服务就是个HTTPS的地址，设定好帐号密码就可以访问过去直接使用，这就是SaaS了，如SalesForce、Yahoo Hadoop和Cisco Webex: Collaboration SaaS等。
为啥举例都是国外的呢，因为国内目前的云服务状况是，能提供的都处于IaaS阶段，有喊着要做PaaS的，但还没听说有SaaS的。
说完公共的，该讲些私货了。
个人理解云计算的核心首先是计算，什么网络、存储、安全等等都是外延，从技术上讲云计算就是计算虚拟化。最早的云计算来自于网格计算，通过一堆性能较差的服务器完成一台超级计算机才能完成的计算任务，简单的说就是计算多虚一。但是现如今一虚多（VM/XEN等）也被一些厂商扯着大旗给忽悠进来，并且成为主流。但是单从技术角度来看，这两者是南辕北辙的。因此云计算技术在下面被作者主观的分为集中云与分散云两个概念来阐述。
2.1 集中云
首先是集中云，根正苗红的多虚一，最早期的也是目前最大的一个典型实际用户就是Google了 (注意这里说的不是现在Google云服务)。搜索引擎是超级消耗资源的典型应用，从你在网页上一个关键词的搜索点击，到搜索结果的产生，后台是经过了几百上千台服务器的统一计算。至于搜索引擎的工作模型本文就不多说了，网上很多资料的。随着互联网的发展，现在的开心、淘宝、新浪微博等等（好孩子不翻墙），虽然使用者看到的只是在简单的页面进行点击输入，但是后台的工作量已经远远不是少量几台大型服务器能够胜任的了，即使天河一号也不见得能搞定。集中云的应用主力就是这些大型的互联网内容提供商们，当然还有一些传统应用如地震、气象和科研项目的计算也会存在此类需求。
了解了需求，下面简单谈下技术，上图是Cluster集群多虚一技术的简单分布，除了按照承载网络类型可分成Infiniband和Ethernet外，根据技术分，还可分为Active-Standby主备与LoadBalance负载均衡两类。
主备模式好理解，所有的Server里面只有一台干活，其他都是候着的，只有侦听到干活的歇菜了，才开始接管处理任务。主备模式大部分就二虚一提供服务，多了如三虚一什么的其实意义都不太大，无非是为了再多增加些可靠性。主备模式以各类HA集群技术为代表。
而负载均衡模式复杂一些，在所有的LB技术中都存在两个角色，协调者与执行者，协调者一般是一个或多个（需要主备冗余时），主要工作就是接活儿和分活儿（有点儿像包工头）；而执行者就只处理计算了，分到啥就完成啥，典型的苦力。从流量模型上来说，LB集群技术有来回路径一致和三角传输两种，来回路径一致指流量都是客户发起连接，请求协调者进行处理，协调者分配任务给执行者进行计算，计算完成后结果会都返回到协调者，再由协调者应答客户。
这种结构简单，计算者不需要了解外界情况，由协调者统一作为内外接口，安全性最高。此模型主要应用于搜索和地震气象科研计算等业务处理中。三角传输模型指计算者完成计算后直接将结果反馈给客户，此时由于计算者会和客户直接通信，造成安全性降低，但返回流量减少了协调者这个处理节点，性能得到很大提升。此模型主要应用于腾讯新浪的新闻页面和阿里淘宝的电子商务等WEB访问业务。
集中云在云服务中属于富人俱乐部的范围，不是给中小企业和个人玩的，实际上都是各大互联网服务提供商自行搭建集中云以提供自己的业务给用户，不会说哪天雅虎去租用个Google的云来向用户提供自己的新闻页面访问。集中云服务可能的租用对象是那些高度科研项目，因而也导致当前集中云建设上升到国家宏观战略层面的地位。你能想象哪天百度的云服务提供给总装研究院去计算个导弹轨迹，核裂变什么嘛，完全不可能的事。
最后是多虚一对网络的需求。在集中云计算中，服务器之间的交互流量多了，而外部访问的流量相对减少，数据中心网络内部通信的压力增大，对带宽和延迟有了更高的要求，自然而然就催生出后面会讲到的一些新技术（L2MP/TRILL/SPB等）。
题外话，当前的多虚一技术个人认为不够给力，现在把10台4核CPU的服务器虚拟合一后，虚拟的服务器远远达不到一个40核CPU的计算能力。准确的说现在的多虚一只能基于物理服务器的粒度进行合并，理想的情况应该是能够精细到CPU核以及每台设备的内存缓存等等物理构件虚拟合一。这块应该就涉及到超算了，不熟不深谈。总的来说认为技术进步空间巨大，有些搞头。
2.2?分散云
再讲分散云，这块是目前的主流，也是前面提到的云服务的关键底层技术。由于有VMware和Citrix等厂家在大力推广，而且应用内容较集中云更加平民化，随便找台PC或服务器，装几个虚拟机大家都能玩一玩，想干点儿啥都成，也就使其的认知度更加广泛。
一虚多的最主要目的是为了提高效率，力争让所有的CPU都跑到100%，力争让所有的内存和带宽都占满。以前10台Server干的事，我整两台Server每台跑5个虚拟机VM（Virtual Machine）就搞定了，省电省空间省制冷省网线，总之省钱是第一位的（用高级词儿就是绿色环保）。技术方面从实现方案来看，目前大致可分为三类：
操作系统虚拟化OS-Level
在操作系统中模拟出一个个跑应用程序的容器，所有虚拟机共享内核空间，性能最好，耗费资源最少，一个CPU号称可最多模拟500个VPS(Virtual Private Server)或VE(Virtual Environment)。缺点是操作系统唯一，如底层操作系统跑的Windows，VPS/VE就都得跑Windows。代表是Parallels公司（以前叫SWsoft）的Virtuozzo（商用产品）和OpenVZ（开源项目）。Cisco的Nexus 7000猜测也是采用这种方案运行的VDC技术，但不太清楚为什么会有最多4个VDC的数量限制，也许是基于当前应用场景进行规格控制的一种商业手段。
主机虚拟化Hosted
先说下Hypervisor或叫做Virtual Machine Monitor（VMM），它是管理虚拟机VM的软件平台。在主机虚拟化中，Hypervisor就是跑在基础操作系统上的应用软件，与OS-Level中VE的主要区别在于：
Hypervisor构建出一整套虚拟硬件平台（CPU/Memory/Storage/Adapter），上面需要你再去安装新的操作系统和需要的应用软件，这样底层和上层的OS就可以完全无关化，诸如Windows上跑Linux一点儿问题没有；
VE则可以理解为盗用了底层基础操作系统的资源去欺骗装在VE上的应用程序，每新创建出一个VE，其操作系统都是已经安装好了的，和底层操作系统完全一样，所以VE比较VM（包括主机虚拟化和后面的裸金属虚拟化）运行在更高的层次上，相对消耗资源也少很多。
主机虚拟化中VM的应用程序调用硬件资源时需要经过:VM内核->Hypervisor->主机内核，导致性能是三种虚拟化技术中最差的。主机虚拟化技术代表是VMware Server（GSX）、Workstation和Microsoft Virtual PC、Virtual Server等。
裸金属虚拟化Bare-metal
裸金属虚拟化中Hypervisor直接管理调用硬件资源，不需要底层操作系统，也可以理解为Hypervisor被做成了一个很薄的操作系统。这种方案的性能处于主机虚拟化与操作系统虚拟化之间。代表是VMware ESX Server、Citrix XenServer和Microsoft Hyper-V。
上图描述了三种虚拟化方案的形态区别。当前分散云数据中心服务器虚拟化使用的主要是Bare-Metal方案。分散云给数据中心网络带来了新的挑战，虚拟机之间的数据通信管理需求促使了一系列网络新技术的发展。在OS-Level与Hosted方案中，虚拟机都是架设于操作系统之上的，因此VM/VE之间的通信主要由同样运行于基础操作系统之上的网络交换应用程序来完成。而在最主流的Bare-Metal结构中，由于Hypervisor薄操作系统的引入，性能、管理、安全和可靠性等多维度的考虑，造成VM间网络通信管理发展出不同的技术道路（EVB与BPE），后文会对这些技术方向加以详述。
VMware ESX与Xen/Hyper-V的Bare-Metal方案实现结构有所不同，简单如下图所示。
分散云除了给网络带来上述的VM通信问题，同样由于其对服务器硬件能力的极端榨取，造成网络中的流量压力增大，与集中云一样存在着带宽扩展的需求。原本一台服务器一个操作系统跑一个应用只需要10M流量带宽就够了，现在装了10个VM跑10个应用，带宽可能就需要100M了。
大型机与小型机的一虚多技术早在30年前IBM就做出来了，现在RISC平台上已经相当完善了，相比较而言X86架构的虚拟化才处于起步阶段，但X86架构由于性价比更高成为了分散云计算的首选。
X86架构最早期是纯软件层面的Hypervisor提供虚拟化服务，缺陷很多，性能也不够，直到2006年Intel推出了实现硬件辅助虚拟化的VT技术CPU产品后才开始迅猛发展（AMD也跟着出了VM技术）。硬件辅助虚拟化技术主要包括CPU/Chipset/Network Adapter等几个方面，和网络技术紧密相关的就是网卡虚拟化了，后文会对如SR-IOV等网卡虚拟化技术应用进行更具体分析。随着2007年Intel VT FlexMigration技术的推出，虚拟机迁移成为可能，2009年Intel支持异构CPU间动态迁移再次向前迈进。
vMotion
这里再多唠叨几句vMotion技术。vMotion是VMware公司提出的虚拟机动态迁移技术名称（XEN也有相应的XENMotion技术），由于此名称被喊得最早，范围最广，认知度最高，因此下文提到虚拟机迁移技术时大都会使用vMotion来代称。
先要明确vMotion是一项资源管理技术，不是高可靠性技术，如果你的某台服务器或VM突然宕机了，vMotion是无助于应用访问进行故障切换和快速恢复的。vMotion是将一个正常的处于服务提供中的VM从一台物理服务器搬家到另一台物理服务器的技术，vMotion的目的是尽可能方便的为服务管理人员提供资源调度转移手段，当物理服务器需要更换配件关机重启啦，当数据中心需要扩容重新安排资源啦，这种时候vMotion就会有用武之地了。
设想一下没有vMotion上述迁移工作是怎么完成的，首先需要将原始物理服务器上的VM关机，再将VM文件拷贝到新的物理服务器上，最后将VM启动，整个过程VM对外提供的服务中断会达到几分钟甚至几小时的级别。而且需要来回操作两台物理服务器上的VM，对管理人员来说也很忙叨。
使用vMotion后，两台物理服务器使用共享存储来保存VM文件，这样就节省了上述步骤2中的时间， vMotion只需在两台物理服务器间传递当前的服务状态信息，包括内存和TCP等上层连接表项，状态同步的拷贝时间相对较短，而且同步时原始VM还可以提供服务使其不会中断。同步时间跟VM当前负载情况及迁移网络带宽有关，负载大了或带宽较低使同步时间较长时，有可能会导致vMotion出现概率性失败。当状态同步完成后，原始物理服务器上的VM会关闭，而新服务器上的VM激活（系统已经在状态同步前启动完毕，始终处于等待状态），此时会有个较短的业务中断时间，可以达到秒级。再者vMotion是通过VMware的vCenter管理平台一键化完成的，管理人员处理起来轻松了许多。
这里要注意vMotion也一定会出现业务中断，只是时间长短区别，不要轻易被一些宣传所忽悠。想想原理，不论怎么同步状态，只要始终有新建发生，在同步过程中原始服务器上新建立的客户连接，新服务器上都是没有的，切换后这部分连接势必被断开重建，零丢包只能是理想值。VMware也同样建议将vMotion动作安排在业务量最少的时候进行。
vMotion什么场景适用呢？首先肯定得是一虚多的VM应用场景，然后是对外业务中断恢复的可靠性要求极高，一般都是7*24小时不间断应用服务才用得上，最后是计算节点规模始终在不断增长，资源调度频繁，管理维护工作量大的数据中心。
另外共享存储这个强制要求会给数据中心带来了整体部署上的限制，尤其是下面提到的跨数据中心站点vMotion时，跨站点共享存储的问题解决起来是很麻烦的，由于这部分内容和网络关系不大，属于存储厂商的地盘，对跨站点共享存储技术有兴趣的读者可以参考EMC/IBM等厂商的资料看看，本文就不过多介绍了。
vMotion的出现推动了数据中心站点间大二层互联和多站点动态选路的网络需求，从而导致OTV和LISP等一系列新网络技术的出现。
2.3?云计算小结
通过前面的描述，希望大家能对云计算有个较为清晰的概念。云计算还有一大块内容是平台管理资源调度方面（目前很多厂家吆喝的云计算都是云平台）。这部分主要针对客户如何更便捷的创建与获取虚拟化服务资源，实际过程就是用户向平台管理软件提出服务请求，管理平台通过应用程序接口API（Application Program Interface）将请求转化为指令配置下发给服务器、网络、存储和操作系统、数据库等，自动生成服务资源。需要网络做的就是设备能够识别管理平台下发的配置，从技术创新的角度讲，没有啥新鲜东西，就不多说了。当前的云平台多以IaaS/PaaS为主，能做到提供SaaS的极少。但在今后看来，SaaS将会成为云服务租用主流，中小企业和个人可以节省出来IT建设和维护的费用，更专注于自身的业务发展。
总结一下云计算给数据中心网络带来的主要变化：
1、?更高的带宽和更低的延迟
2、?服务器节点（VM）规模的增加
3、?VM间通信管理
4、?跨数据中心站点间的二层互联以承载vMotion
题外再多说两句，计算虚拟化中一虚多与多虚一结合使用才是王道。但目前云计算服务提供商能够提供的只是先将物理服务器一虚多成多台VM，再通过LB/集群计算等技术将这些VM对外多虚一成一个可用的资源提供服务。个人感觉，如果能做到先将一堆物理服务器虚拟成一台几万个核Super Computer，用户再根据自己的需要几个几十个核的自取资源，这样才更有云计算的样子， Super Computer就是那朵云。当然计算虚拟化的时候不光是核的调配，还要包括IO/Memory等一起进行调度，这里只是简单举例。
3?、数据中心
数据中心的产生有多早？从人类开始将信息记录到介质上传递开始就有了数据中心，那个记载信息的介质（石头或树皮）就是数据中心，不过那时的网络是靠手手相传而已。如果更甚一些，可以理解人类产生语言开始，知识最多的人（酋长/祭祀）就是数据中心，口口相传就相当于现如今的网络传输。有人该说，夸张了哈，写作手法而已，只是想突出一下数据中心的重要性。
当计算机网络连接到Server的那一刻起，整个世界的网络就从网状变成了树状，一个个数据中心就是网络世界的根。
3.1?Client与Server
在所有的数据通信会话中，只有两个永恒的角色，Client与Server。为了下文叙述简便，作者把数据中心内部的终端统一称之为Server，数据中心外部的为Client。这样网络间的流量通信就只剩下Client-Server（CS）与Server-Server（SS）两种了。其实更准确说还是只有CS一种，SS通信也是有个发起方和响应方的。QQ/MSN等即时通信软件的流量模型实际可理解为CSC；唯有P2P对CS结构有所颠覆，但不管怎么处理也必定会存在Server角色进行最初的调度。
所有数据中心需要处理的业务就是CS和SS两种，CS肯定是基于IP进行L3转发的了，SS则分为基于IP的L3和基于MAC的L2两种转发方式。基于IP的SS通信主要是不同业务间的数据调用，如WEB/APP服务器去调用DB服务器上的数据，再如有个员工离职，职工管理系统会同步通知薪酬管理、考勤管理、绩效管理等一系列系统进行删除信息的相关操作。基于MAC的SS通信则是同一类服务器间的数据同步计算，比如使用WEB集群分流用户访问时，需要对修改或增删的数据进行集群同步；再比如多虚一中集群一起计算任务时协调者和执行者之间的大量通信进行任务调度。
可以看出云计算数据中心给网络带来的挑战主要是基于MAC的二层（OSI模型）SS通信。在一虚多技术影响下，Server的概念已经扩展到以单台VM为基础单元，因此可以引出下面这个图，看看新网络技术是如何划分的。
Network1：VM到VM之间的SS二层互联网络
Network2：DC站点内部SS二层互联网络
Network3：跨DC站点间的SS二层互联网络
Network4：DC到Client之间的CS三层互联网络
后文的技术章节就会针对这些部分进行展开，详细说下都有哪些技术分别对应在这四段网络中，这些技术的特点是什么。
3.2?层次化与扁平化
数据中心的网络结构取决于应用计算模型，计算模型主要分为层次化与扁平化两种结构。层次化结构如下图所示，典型的应用如WEB-APP-DB、搜索引擎或高性能计算（地震、科研）等。特点是客户请求计算结果必须逐层访问，返回数据也要逐层原路返回。
计算模型扁平化结构如下图所示，特点是数据层服务器会将结果直接返回给客户，不需要再由接口层服务器进行处理，也有管这种模型叫做三角传输的。典型的应用如一些Internet网站服务采用的LB结构，LB服务器就是只做调度，WEB服务器会直接将请求结果返回给用户。
注意，上面说的是计算模型，和网络模型并不是一一对应，采用层次化结构计算模型一样可以进行扁平化组网，如下图所示。
从网络角度讲，扁平化相比较层次化结构最大的好处是可以减少服务器的网卡接口数量（省钱），然而缺点是没有清晰的层次，部署维护的复杂度就会相应提升。总体来说，当前数据中心实际组网建设中，这两种方式谁都没占据到绝对优势，上哪种结构完全看规划者的考量重点是在哪个方面。
前面说过，云计算主要分为多虚一与一虚多两种虚拟化结构。一虚多对传统计算模型没有太大影响，只是将其服务器从物理机到虚拟机数量规模扩大了N倍，网络规模也随之进行扩大。而多虚一中，协调者角色对应了接口层服务器，执行者角色则对应数据层服务器，由于此时大量的通信交互是在不同执行者之间或执行者与协调者之间，需要重点关注的大规模网络就由原来的接口层服务器之前，转移到了接口层服务器与数据层服务器之间。
3.3?三层结构与两层结构
在以往的数据中心网络建设时，关注的重点都是指接口层服务器前的网络，传统的三层网络结构如下图所示。其中的汇聚层作为服务器网关，可以增加防火墙、负载均衡和应用加速等应用优化设备。
但在云计算数据中心里面Ethernet网络规模扩大，流量带宽需求增加，因此不会在网络中间位置再插入安全和优化设备了，转发性能太低，上去就是瓶颈，汇聚层的位置也就可有可无了。再加上带宽收敛比的问题，短期内大型云计算数据中心网络里面不会出现汇聚层的概念。以前是百兆接入、千兆汇聚、万兆核心，现在服务器接入已经普及千兆向着万兆迈进了，除非在框式交换机上40G/100G接口真的开始大规模部署，还有可能在云计算数据中心里面再见到超过两层的级联结构网络。现如今的云计算数据中心流行的都是如下图所示的千兆接入，万兆核心的两层网络结构。
此两层网络结构部署在接口层服务器之前，则一般会将服务器网关部署在Core Switch上，但前提是网络规模不会太大，Core不会太多（2个就差不多了），否则VRRP/HSRP等多网关冗余协议只能走到一个活动网关，会导致网络效率很低。还有一种方式是将服务器网关部署在Access Switch上，Access SW与Core SW之间通过OSPF等动态路由协议达到全互联，使用等价路由达到多Core SW的负载均担。但此方式的缺点是L3路由交互转发效率较低，部署复杂且占用大量IP地址。在未来的TRILL/SPB等二层Ethernet技术结构中，可能会出现专门作为网关与外部进行IP层面通信用的边缘交换机（由于出口规模有限，2-4台足够处理），内部的Core SW只做二层转发，可以大规模部署以满足内部服务器交互的需求，如下图所示。
当遇到多虚一高性能计算的模型，则二层网络结构会被部署在接口服务器与数据服务器之间，为二者构建纯二层的大规模交互网络，结构如下图所示。
3.4?Server与Storage
前面说的CS/SS网络可以统称为数据中心前端网络，目前和以后基本上都是IP+Ethernet一统天下（IB Infiniband只能吃到高性能计算的一小口）。有前端当然就有后端，在数据中心里面，服务器与存储设备连接的网络部分统称为数据中心后端网络。就目前和短期的未来来看，这块儿都是FC的天下。
简单说两句存储，DAS（Direct Attached Storage）直连存储就是服务器里面直接挂磁盘，NAS（Network Attached Storage）则是网络中的共享文件服务器，此二者大多与数据中心级别存储没什么关系。只有SAN（Storage Area Network）才是数据中心存储领域的霸主，磁盘阵列会通过FC或TCP/IP网络注册到服务器上模拟成直连的磁盘空间。而目前FC SAN是主流中的主流，基于TCP/IP的IP SAN等都是配太子读书的角色。
在服务器到存储的后端网络中，涉及到IO同步问题，高速、低延迟与无丢包是对网络的基本需求，而Ethernet技术拥有冲突丢包的天然缺陷，FC的无丢包设计使其领先一步，加上早期Ethernet还挣扎在100M带宽时，FC已经可以轻松达到2G，所以在后端网络中从开始到现在都是FC独占鳌头。但是从发展的眼光看，Ethernet目前已经向着40G/100G迈进，而FC的演进并不理想，无论是BASE10的10/20/40G路线（主要用在FC交换机之间，目前基本已经被淘汰）还是BASE2的2/4/8/16/32G路线（当前主流FC应用）都已经落后，加上各种以太网零丢包技术（CEE/DCE/DCB）的出现，以后鹿死谁手还真不好说。
在目前阶段，为了兼容数据中心已有的主流FC网络和存储设备，在基于iSCSI技术的IP SAN技术没能开花结果的情况下，众多Ethernet网络厂商又推出了FCoE来蚕食服务器到存储这块蛋糕。下文技术章节会专门介绍FCoE的内容。
先简单说下，FCoE没有惦着像IP SAN那样一下子完全取代FC去承载后端网络，而是走前后端网络融合，逐步蚕食的路线，是网络厂商们将数据中心的核心由服务器向网络设备转移的重要武器。如下图，就是看谁做太阳，谁做星星。相比较IP SAN的壮烈牺牲，FCoE采用了一条更为迂回的兼容道路，目前已经出现了支持FCoE的存储设备，也许Ethernet完全替代FC的时代真的能够到来。
如果FCoE能成功，虽然短期内交换机、服务器和存储的价格对比不会有太大的变化，但是占据了核心位置，对未来的技术发展就有了更大的话语权，附加值会很高。又如当前的EVB（Edge Virtual Bridging）和BPE（Bridging Port Extend）技术结构之争也同样是话语权之争。
顺便一提，当一项完全不能向前兼容的全新技术出现时，除非是有相当于一个国家的力量去推动普及，而且原理简单到8-80岁都一听就明白，否则注定会夭折，与技术本身优劣无太大关系。老话说得好，一口吃不成胖子。
?
3.5?数据中心多站点
这是个有钱人的话题，且符合2-8原则，能够建得起多个数据中心站点的在所有数据中心项目中数量也许只能占到20%，但他们占的市场份额肯定能达到80%。
建多个数据中心站点主要有两个目的，一是扩容，二是灾备。
扩容
首先说扩容，一个数据中心的服务器容量不是无限的，建设数据中心时需要考虑的主要因素是空间、电力、制冷和互联。数据中心购买设备场地建设只是占总体耗费的一部分，使用过程中的耗能维护开销同样巨大，以前就闹过建得起用不起的笑话。当然现在建设时要规范得多，考虑也会更多，往往做预算时都要考虑到10年甚至以上的应用损耗。
再讲个故事，以前曾有某大型ISP打算找个雪山峡谷啥的建数据中心，荒郊野外空间本来就大，融雪制冷，水力发电，听上去一切都很美，但是就忘了一件事，互联。光纤从哪里拉过去，那么远的距离中间怎么维护，至少从目前阶段来说这个问题无解。也许等到高速通信发展到可以使用类似铱星的无线技术搞定时，数据中心就真的都会建到渺无人烟的地方吧，现在还只能在城市周边徘徊。貌似听说过国外有建得比较偏远的大型数据中心，但个人觉得应该还是人家通信行业发达，光纤资源丰富，四处都能接入。但至少目前国内的运营商们不见得会支持，大城市周边搞搞就算了，远了没人会陪你玩。
有些扯远，回到正题。现在国内已经有超过10k台物理服务器在一个数据中心站点的项目了，再多我还没有听说过。只有几百上千的物理服务器就敢喊搞云计算是需要一定勇气的，既然是云，规模就应永无止境。所以建多个数据中心站点来扩容就成了必然之举。这时就可能遇到Cluster集群计算任务被分配在多个站点的物理服务器或虚拟机来完成的情况，从而提出了跨多个数据中心站点的Ethernet大二层互联需求。
在扩容时，就可以充分利用vMotion等虚拟机迁移技术来进行新数据中心站点的建设部署，同样需要站点间的大二层互通。支持IP层的vMotion目前虽然已经出现，但由于技术不够成熟，限制很多，实用性不强，还是以Ethernet二层迁移技术为主。
灾备
再说说灾备，最近几年天灾人祸着实不少，数据中心容灾就越来越受到重视。扩容和灾备的主要区别就是：扩容的多个站点针对同一应用都要提供服务；而灾备则只有主站点提供服务，备份站点当主站点挂掉的时候才对外服务，平时都处于不运行或者空运行的状态。
参考国标《信息系统灾难恢复规范》GB/T 20988－2007，灾备级别大致可划分为数据级别（存储备份），应用级别（服务器备份），网络级别（网络备份），和最高的业务级别（包括电话、人员等所有与业务相关资源）。
国内外统一的容灾衡量标准是RPO（Recovery Point Objective）、RTO（Recovery Time Objective）和RAO（Recovery Access Objective）了，通过下图形象一些来体现他们的关系。
简单来说RPO衡量存储数据恢复，RTO衡量服务器应用恢复，RAO衡量网络访问恢复。一般来说RPO设计都应小于RTO。国外按照RTO/RPO的时间长短对灾难恢复分级参考由高到低为：
Class 1/A???? RTO=0-4 hrs; RPO=0-4 hrs
Class 2/B???? RTO=8-24 hrs; RPO=4 hrs
Class 3/C???? RTO=3 day; RPO=1 day
Class 4/D???? RTO=5+ days; RPO=1 day
标准归标准，真正建设时候最重要的参考条件还是应用的需求，像银行可以直接去调研储户能容忍多长时间取不出来钱，腾讯去问问QQ用户能容忍多长时间上不了线，就都知道该怎么设计容灾恢复时间了。
真正在玩多中心灾备的行业，国内集中在金融系统（尤其是银行），政府和能源电力等公字头产业，国外的不太清楚，但我想以盈利为主要目的企业不会有太强烈意愿去建设这种纯备份的低效益站点，更多的是在不同站点内建设一些应用服务级别的备份，所有站点都会对外提供服务。
小结
在云计算规模的数据中心中，对于LB类型的多虚一集群技术，执行者（概念参见文档前面集中云部分）少上几个不会影响全局任务处理的，只要在扩容时做到数据中心间大二层互通，所有站点内都有计算任务的执行者，并且配合HA技术将协调者在不同站点做几个备份，就已经达到了应用容灾的效果。针对一虚多的VM备份，VMware/XEN等都提出了虚拟机集群HA技术，此时同样需要在主中心站点与备份中心站点的服务器间提供二层通道以完成HA监控管理流量互通，可以达到基于应用层面的备份。
云计算数据中心多站点主要涉及的还是扩容，会部署部分针对VM做HA的后备服务器，但是不会搞纯灾备站点。针对多站点间网络互联的主要需求就是能够做而二层互联，当站点数量超过两个时所有站点需要二层可达，并部署相关技术提供冗余避免环路。
3.6?多站点选择
数据中心建设多站点后，由于同一应用服务可以跑在多个站点内部，对Client来说就面临着选择的问题。
首先要记住的是一个Client去往一个应用服务的流量必须被指向一台物理或虚拟的 Server。你可以想象一个TCP请求的SYN到ServerA，而ACK到了ServerB时，ServerA和B为了同步会话信息都会疯掉。想办法维持一对Client-Server通信时的持续专一是必须的。
Client到Server的访问过程一般分为如下两步：
1、?Client访问域名服务器得到Server IP地址（很少人会去背IP地址，都是靠域名查找）
2、?Client访问Server IP，建立会话，传递数据。
当前的站点选择技术也可以对应上面两个步骤分为两大类。
第一类是在域名解析时做文章，原理简单来说就是域名服务器去探测多个站点内IP地址不同的服务器状态，再根据探测结果将同一域名对应不同IP返回给不同的Client。这样一是可以在多个Client访问同一应用时，对不同站点的服务器进行负载均担，二是可以当域名服务器探测到主站点服务器故障时，解析其他站点的服务器IP地址给Client达到故障冗余目的。这时要求不同站点的服务地址必须在不同的三层网段，否则核心网没法提供路由。缺点很明显，对域名解析服务器的计算压力太大，需要经常去跟踪所有服务器状态并Hash分配Client请求的地址。此类解决方案的代表是F5/Radware/Cisco等厂商的3DNS/GSLB/GSS等技术。
第二类就是把多个站点的服务IP地址配置成一样，而各个站点向外发布路由时聚合成不同位数的掩码（如主中心发布/25位路由，备中心发布/24位路由），或通过相同路由部署不同路由协议Cost值以达到主备路由目的。使用掩码的问题是太细则核心网转发设备上的路由数量压力大，太粗则地址使用不好规划很浪费。使用Cost则需要全网IP路由协议统一，节点规模受到很大限制。另外这种方式只能将所有Client访问同一服务IP的流量指向同一个站点，负载分担只能针对不同的服务。好处则是这种站点选择技术谁都能用，不需要专门设备支持，部署成本低成为其存活的根据。
在云计算大二层数据中心部署下，各个站点提供同一服务的Server都处于一个二层网络内，且不能地址冲突，与前面描述的两种站点选择技术对服务器IP设置要求都不匹配，因此需要配合SLB设备一起使用。可以理解其为一种基于IP粒度的多虚一技术，使用专门LB硬件设备作为协调者，基于IP地址来分配任务给服务组中不同的Server执行成员。LB设备通常将多个Server对应到一个NAT组中，外部访问到一个NAT Server虚拟IP地址，由LB设备按照一定算法分担给各个成员。LB设备同时会探测维护所有Server成员状态。当各个站点内LB设备将同一服务对外映射为不同的虚拟IP地址时，可以配合域名解析方式提供Client选路；而配置为相同时则可以配合路由发布方式使用。
现有的站点选择技术都不尽如人意，即使是下文介绍的Cisco新技术LISP也只是部分的解决了路由发布技术中，发布服务器地址掩码粒度过细时，给核心网带来较大压力的问题，目前还不算是一套完整的站点选择解决方案。个人感觉，最好的路还是得想法改造DNS的处理流程，目前的DNS机制并不完备，在攻击面前脆弱不堪，后面的安全附加章节中会对此再深入讨论。
3.7?数据中心小结
又到了小结部分，云计算数据中心相比较传统数据中心对网络的要求有以下变化：
1、?Server-Server流量成为主流，而且要求二层流量为主。
2、?站点内部物理服务器和虚拟机数量增大，导致二层拓扑变大。
3、?扩容、灾备和VM迁移要求数据中心多站点间大二层互通。
4、?数据中心多站点的选路问题受大二层互通影响更加复杂。
题内话，FCoE并不是云计算的需求，而是数据中心以网络为核心演进的需求，至于云计算里面是不是一定要实现以网络为核心，就看你是站在哪个设备商的角度来看了。
4?、网络
说到网络，这里关注的重点是前文提到的数据中心内部服务器前后端网络，对于广泛意义上的数据中心，如园区网、广域网和接入网等内容，不做过多扩散。
4.1?路由与交换
网络世界永远的主题，至少目前看来还没有出现能取代这二者技术的影子，扩展开足够写好几本书的了。
数据中心的网络以交换以太网为主，只有传统意义的汇聚层往上才是IP的天下。参考前文的需求可以看出，数据中心的以太网络会逐步扩大，IP转发的层次也会被越推越高。
数据中心网络从设计伊始，主要着眼点就是转发性能，因此基于CPU/NP转发的路由器自然会被基于ASIC转发的三层交换机所淘汰。传统的Ethernet交换技术中，只有MAC一张表要维护，地址学习靠广播，没有什么太复杂的网络变化需要关注，所以速率可以很快。而在IP路由转发时，路由表、FIB表、ARP表一个都不能少，效率自然也低了很多。
云计算数据中心对转发带宽的需求更是永无止境，因此会以部署核心-接入二层网络结构为主。层次越多，故障点越多、延迟越高、转发瓶颈也会越多。目前在一些ISP（Internet Service Provider）的二层结构大型数据中心里，由于传统的STP需要阻塞链路浪费带宽，而新的二层多路径L2MP技术还不够成熟，因此会采用全三层IP转发来暂时作为过渡技术，如前面提到过的接入层与核心层之间跑OSPF动态路由协议的方式。这样做的缺点显而易见，组网复杂，路由计算繁多，以后势必会被Ethernet L2MP技术所取代。
新的二层多路径技术会在下文做更详细的介绍，不管是TRILL还是SPB都引入了二层ISIS控制平面协议来作为转发路径计算依据，这样虽然可以避免当前以太网单路径转发和广播环路的问题，但毕竟是增加了控制平面拓扑选路计算的工作，能否使其依然如以往Ethernet般高效还有待观察。MPLS就是一个尴尬的前车之鉴，本想着帮IP提高转发效率而生根发芽，没想到却在VPN路由隔离方面开花结果了，世事难料啊。
4.2?EOR与TOR
前面说了，数据中心网络设备就是交换机，而交换机就分为框式与盒式两种。当前云计算以大量X86架构服务器替代小型机和大型机，导致单独机架Rack上的服务器数量增多。受工程布线的困扰，在大型数据中心内EOR（End Of Row）结构已经逐步被TOR（Top Of Rack）结构所取代。盒式交换机作为数据中心服务器第一接入设备的地位变得愈发不可动摇。而为了确保大量盒式设备的接入，汇聚和核心层次的设备首要解决的问题就是高密度接口数量，由此框式交换机也就占据了数据中心转发核心的位置。
4.3?控制平面与转发平面
对交换机来说，数据报文转发都是通过ASIC（Application Specific Integrated Circuit）芯片完成，而协议报文会上送到CPU处理，因此可以将其分为控制平面与转发平面两大部分。
控制平面主体是CPU，处理目的MAC/IP为设备自身地址和设备自身发给其他节点的报文，同时下发表项给转发ASIC芯片，安排数据报文的转发路径。控制平面在三层交换机中尤为重要，需要依靠其学习路由转发表项并下发到ASIC芯片进行基于IP的转发处理。而二层交换机中数据报文的转发路径都是靠MAC地址广播来直接学习，和控制平面CPU关系不大。
转发平面则是以ASIC芯片为核心，对过路报文进行查表转发处理，对交换机来说， ASIC转发芯片是其核心，一款交换机的能力多少和性能大小完全视其转发芯片而定。而控制平面CPU虽然也是不可或缺的部分，但不是本文介绍的重点，下文将以分析各类型交换机的转发处理为主。
4.4?Box与集中式转发
经常看到设备商们今天推出个“高性能”，明天推出个“无阻塞”，后天又搞“新一代”的网络交换产品，各种概念层出不穷，你方唱罢我登台，搞得大家跟着学都学不过来，总有一种是不是被忽悠了的感觉。其实很多时候真的是在被忽悠。
先说说Box盒式设备。盒式交换机从产生到现在，以转发芯片为核心的集中式转发结构就没有过大的变化。集中式转发盒子的所有接口间流量都是走转发芯片来传输，转发芯片就是盒子的心脏。
而这个心脏的叫法多种多样，神马Port ASIC、Switch Chip、Fabric ASIC、Unified Port Controller等等都是各个厂家自行其说罢了，关键就看各个物理接口的PHY（将0/1信号与数据互相转换用的器件）连接到哪里，哪里就是核心转发芯片。一般的中小型交换机设备厂商（H3C/中兴/锐捷/ Foundry/Force10等，Juniper目前的数据中心Switch不提也罢，下文会简单说说未来的QFabric）都会直接采购Broadcom和Marvell等芯片生产厂商的产品，只有Cisco和Alcatel等寥寥几家大厂商有能力自己生产转发芯片。但说实话，从转发能力来看这些自产的还真不见得能赶上公用的，人家专业啊。自产的最大好处其实在于方便搞些私有协议封包解包啥的，我的芯片我做主。
下面来说说集中式转发能力的计算，假设一个盒子喊自己的转发能力是x Gbps/y Mpps，x是依靠所有外部接口带宽总和算出来的，如48GE+2*10GE的盒子，转发能力就是单向68GE，双向136GE，一般x都会取双向的值；而y则是整机的包转发能力，y=x*1000/2/8/(64+20)，1000是G到M的转换，2是双向，8是每字节8比特，64是报文最小载荷，20是IP头长。要注意下面的机框式转发就不是这么算的了。大部分盒子的包转发能力还是能够很接近这个理论值的，毕竟能选的转发芯片就那么多，设备厂商在这里自己搞不出太多猫腻来。唯一有可能用来混淆客户的就是用芯片转发能力替代设备接口转发能力作为x值来宣传，绝大部分交换机使用的芯片转发能力是大于所有接口带宽总和的。这时x与y都会比实际的要大一些，但是很明显，芯片再强，没有接口引出来也没用的。所以这里的防忽悠技巧就是数接口数自己加一下。
再说结构，决定一款盒式交换机的接口转发容量的是转发芯片，反之你看一款盒子的接口排布情况大概能反推出其使用的芯片能力。转发芯片的接口多种多样（如SGMII、XAUI、HIG、Senders等），但通常每个芯片只连接24个GE接口（8个口一个PHY，3个PHY为一组），因此遇到24GE口交换机，通常都是单芯片的，而48GE或更多就肯定是多芯片的了。而10GE接口的多少要看芯片的能力，个人了解Broadcom有支持24个10GE的转发新片，应该还有能力更强的。现在作者知道的10GE接口密度最高的盒子是Arista的7148SX和Juniper的QFX3500，都支持48个10GE接口，具体布局有待拆机检查。
多芯片交换机还是很考验设备厂商架构设计人员的，既要保证芯片间足够带宽互联无阻塞，又要考虑出接口不能浪费，需拿捏好平衡。所以现在的多芯片盒式交换机设备大多是2-3个转发芯片的，再多的就极少了，芯片间互联设计起来太麻烦了。举两个例子，大家可以看看下面这两种结构有没有问题。
首先是我们能不能用两块6个HIG接口级别转发能力的ASIC（HIG接口带宽12.5GE），设计一款48GE+4*10GE的交换机呢？答案是可以做，但存在结构性拥塞，芯片间至少需要4条HIG才能满足完全无阻塞。
再来看一个，能不能用3块4个HIG接口级别转发能力的ASIC搭建出一款48GE+2*10GE的交换机呢？没有问题，如下图所示内部结构是完全无阻塞的，缺点是部分流量会多绕经1个ASIC转发。
看完了前面这部分，相信大家对盒式交换机都能有个大致了解了，这里只讲讲结构，更详细的转发功能流程就需要有兴趣的童鞋自行去查看下各种芯片手册。另外上述两个例子只为讲解，请勿将当前市场产品对号入座。
刚刚说了，当盒子里面芯片较多的时候连接起来很麻烦，于是出现了新的转发单元Switch Fabric（Cisco N5000上新的名词叫做Unified Crossbar Fabric）。其实这个东东在框式交换机里面很常见，下面会有更详细的介绍。而在盒式交换机里面，目前看到的发布资料使用此种架构的就是Cisco的3750X和N5000了，连接方式如下图所示，这已经接近分布式转发的范围了。
作者将这个Fabric单元叫做交换芯片，便于和前面的ASIC转发芯片区分，二者的主要区别是，交换芯片只处理报文在设备内部的转发，类似Cut-Through，为不同转发芯片间搭建路径，不做过滤和修改。而转发芯片要对报文进行各种查表、过滤和修改等动作，包括缓存都在其中调用，大多是基于Store-Forward方式进行报文处理，是交换机处理数据报文的核心部件。
3750X目前还没有看到进一步的发展需要，而N5000其实是为了Cisco的网络虚拟化架构而服务，不再单单属于传统意义上的Ethernet交换机了。Juniper为QFabric设计的QFX3500接入盒子（48*10GE+4*40GE）估计也是类似于N5000这种带交换芯片的分布式架构。另外怀疑Arista的7148SX也是分布式架构的，应该是6个8*10G的转发芯片通过交换芯片连接，和它的机框式交换机中48*10G接口板布局相同。
总的来说盒子里面搞分布式的最主要原因就是希望提高接口密度，尤其是万兆接口密度，后面相信还会有其他厂商陆续跟进，但是其接口数量需求是与部署位置息息相关的，盲目的扩充接口数并不一定符合数据中心的需要。
再唠叨几句数据中心Box交换机的选型，前面说了Top Of Rack是Box的主要归宿，一个标准Rack目前最高的42U，考虑冗余怎么也得搞2台Box，剩下最多装40台1U的Server，那么上48GE+4*10GE的Box就是最适合的。依此类推，接口数量多的box不见得真有太大作用，位置会很尴尬。考虑选择Box的最大转发容量时，直接根据服务器接口数来计算接口即可。目前随着FCoE的推进，服务器提供10GE CNA接口上行到接入交换机越来越常见，那么对Box的要求也随之提升到10GE接入40G/100G上行的趋势，像Juniper的QFX3500（48*10GE+4*40GE）明显就是上下行带宽1：3收敛的交换机，估计下一代Top Of Rack的数据中心交换机怎么也得要40*10GE+4*100GE的接口才能彻底搞定42U机架，如果全部署2U的服务器，则最少也需要16*10GE+4*40GE接口的Box才靠谱一些。
4.5?Chassis与分布式转发
本章节涉及转发能力的举例计算量较大，对数字不感兴趣的同学可以直接略过相关内容。
盒子说完了讲讲框，盒式设备发展到一定程度，接口密度就成了天花板，必须要搞成机框式才能继续扩展了。可以把机框里面的板卡理解为一个个独立的盒子，然后通过交换网络将其连接起来形成整体。
罗马不是一天建成的，机框式交换机最初也是按照集中式转发架构来进行设计。例如Cisco4500系列（又是Cisco，没办法，就他家产品最全，开放出来的资料最多，而且确实是数通领域的无冕之王，下文很多技术也都跟其相关），其接口板（LineCard）上面都没有转发芯片的（XGStub ASIC只做接口缓存和报文排队的动作），所有的数据报文都需要通过背板通道（Fabric），上送到主控板（Supervisor）的转发芯片（Forwarding Engine）上进行处理。结构如下图所示，其中PP（Packet Processor）是做封包解包的，FE（Forwarding Engine）是做查表处理的。
在早期Cisco6500系列交换机设备上同样是基于总线（BUS）的集中式转发结构。如Classic类型接口板（Module）就只有Port ASIC做缓存和排队，所有的报文同样要走到主控板（Supervisor32或720）上的转发芯片（PFC3）来处理。普通的CEF256和CEF720系列接口板虽然以Switch Fabric替代BUS总线通道来处理接口板到主控板的流量转发，但仍然是靠主控板上的PFC3对流量进行集中处理，因此还是集中式转发。直到CEF256和CEF720的DFC（Distributed Forwarding Card）扣板出来，才能在板卡上进行转发，称得上是真正的分布式架构。而最新的第四代接口板dCEF720 Linecards已经直接将DFC变成了一个非可选组件直接集成在接口板上。
分布式架构指所有的接口板都有自己的转发芯片，并能独立完成查表转发和对报文的L2/L3等处理动作，接口板间通过交换芯片进行报文传递，机框的主控板只通过CPU提供协议计算等整机控制平面功能。分布式架构接口板上都会专门增加一个Fabric连接芯片（Fabric Interface或Fabric Adapter Process等），用以处理报文在框内接口板间转发时的内部报头封装解封装动作。当报文从入接口板向交换芯片转发时，连接芯片为报文封装一个内部交换报头，主要内容字段就是目的出接口板的Slot ID和出接口Port ID，交换芯片收到报文后根据Slot ID查找接口转发，出接口板的连接芯片收到后根据Slot ID确认，并将此内部交换报头去掉，根据Port ID将报文从对应出接口转出交换机。很显然分布式对比集中式的区别主要是芯片更多，成本更高，转发能力也更高。目前各厂商最新一代的主流数据中心交换机都已经是完全的分布式转发架构（如Cisco的N7000，H3C的12500等）。
下面说下Chassis的转发能力，这个可比盒子要复杂多了，各个厂家多如繁星的机框、主控和接口板种类足以使用户眼花缭乱。还是以Cisco6500系列交换机举例，一法通万法通，搞明白这个其他的也不过尔尔了。选择Cisco6500还有一个主要原因就是其结构从集中式跨越到分布式，从BUS总线通道跨越到Crossbar转发，堪称传统机框交换机百科全书。
FIRE（Fabric Interface & Replication Engine）为Cisco的接口板连接芯片，除了作为连接Switch Fabric的接口对报文进行内部报头的封包解包动作外，还能提供本地镜像和组播复制功能。图中举例了报文在65机框式交换机中跨接口板转发的主要节点。集中式转发时板内接口间流量转发同样适用此图，而分布式转发时板内转发流量不需要走到Switch Fabric。
另外报文走到出方向接口板时是否经过转发芯片处理各个厂家的设备实现并不一致，最简单的一个方法就是看交换机接口板支持不支持出方向的报文ACL（Access Control List）过滤，就知道其有没有上出口板转发芯片处理了。
从上图可以看出接口板的转发能力都受限于板卡连接BUS或Switch Fabric的接口带宽，而衡量整机转发能力时，集中式转发受限于转发芯片FE的转发能力，分布式转发受限于交换芯片Switch Fabric的转发能力。先说接口板转发能力，大家以前可能经常会听到接口板存在非线速和收敛比的概念，看到这里就很好明白了，例如CEF256类型接口板的Switch Fabric接口带宽是8G，那最多就支持8个GE口和其他接口板进行流量转发，其WS-X6516-GBIC接口板的面板上有16个GE口，明显就是一块2：1的收敛比的非线速板。
再如CEF720类型接口板的Switch Fabric接口是2*20G（单板上有两个FIRE），那48GE口的单板也明显不可能是线速的了。即使是号称第四代的dCEF720接口板，其Switch Fabric接口和CEF720一样都是2*20G接口，那么X6708-10G接口板（提供8*10GE接口）和X6716-10G接口板（提供16*10GE接口）只能是2：1和4：1收敛的非线速板了。
背板通道预留不足，Switch Fabric交换能力不够，6500系列的这些架构缺陷促使Cisco狠下心来为数据中心重新搞出一套Nexus7000，而其他交换机厂商也都几乎同时期推出了新架构的机框式交换机，都是被逼的啊，谁让1000M接入这么快就替代了100M接入呢，核心更得开始拼万兆了。
再说说整机转发能力。在集中式转发时，Cisco6500不论使用Supervisor32还是Supervisor720主控，FE转发芯片都是走BUS的，带宽都是16G（双向32G），因此只要用的接口板没有DFC，整机最大也就双向32G了。而其中Supervisor32不支持Switch Fabric，也就支持不了DFC的分布式转发，名称里的32就代表了其双向32G的最大整机转发能力。
Supervisor720主控支持18*20的Switch Fabric交换，名称中的720是指整个Switch Fabric的双向交换能力18*20*2=720G。但其中1个通道用于连接FE转发芯片，1个通道暂留未用，只有16个通道留给了接口板，意味着整机实际最大能够支持的双向转发能力是16*20*2=640G。Supervisor720-10GE支持20*20的Switch Fabric，多出来的2个10G通道给了Supervisor上的2个10GE接口，实际提供给接口板的交换通道仍然是16*20G。
刚刚说了，目前最新的CEF720系列接口板每块有2*20G的出口，简单做个除法，16/2=8，主控板的交换芯片最多能够承载8块CEF720接口板，熟悉Cisco6500产品的同学这时候就会想到6513机框怎么办呢。6513除去7-8的主控槽位外，一共有11个接口板槽位，1-6槽位背板只提供1个Switch Fabric通道，9-13才能提供2个通道，正好是6+2*5=16个通道满足主控板的Switch Fabric交换能力。而6513E虽在1-6槽位背板提供了2个通道，但实际上1-6槽位也同样只能支持1个Switch Fabric通道，否则Supervisor720的Switch Fabric也搞不定的。如果想6513E的接口板通道全用起来，只能等Cisco6500出下一代引擎了，至少是Supervisor880才能搞定6513E的全线速转发，不过从交换芯片的发展来看，Supervisor960的可能性更大一些，1280就有些拗口了。由上看出即使将CEF720接口板插到6513/6513E的1-6槽，也只能跑20G的流量，这下连24GE接口板都无法线速了。
前面算了好多数，好在都是加减乘除，只要搞明白了，完全可以避免选型时再被设备厂商忽悠。题外话，很多厂商的机框千兆接口板（24或48个光/电口）都可以在其同时代盒式交换机中找到相似的影子，假如看到支持相同接口数量类型的接口板和盒子，相信里面的转发芯片十之八九也用的一样。万兆接口板不做成盒式是因为接口密度太低，价格上不去；而高密万兆的盒子做不成接口板则是因为框式交换机交换芯片和背板通道结构限制导致跨板转发能力上不去。
?
框式交换机架构从集中式发展到分布式后，整机的转发能力迎来了一次跳跃性发展，从Cisco6500的Supervisor32到Supervisor720就可见一斑。那么下一步路在何方呢，各个厂家都有着不同的看法。看回到前面分布式转发的结构图，可以想到要继续提升转发能力有两个主要方向，一个是将单芯片处理能力提升，交换芯片只处理一次查表转发，工作简单相对更容易提升，而转发芯片要干的事情太多就不是那么好换代的了。
而另一条路就是增加芯片的数量，转发芯片由于要排布在接口板上，毕竟地方就那么大，发展有限，现在的工艺来说，一块单板放4个转发芯片基本上已经到极限了，6个的也只看到Arista的7548接口板上有，再多的还没有见过，因此转发芯片的发展还是要看芯片厂商的能力了。而像Cisco6500的Supervisor720一样将交换芯片布在主控板上的话，同样面临空间的限制，上面还得放些CPU/TCAM什么的，最多每块主控上面放2个交换芯片就顶天了，双主控能支撑4个，但是全用做转发的话就做不到冗余了。最新的思路是将交换芯片拿出来单独成板，这样只要新机框设计得足够大，交换芯片的数量就不再是限制。例如Cisco的N7000可以插5块交换网板，而H3C的12500能够插9块交换网板。当然转发能力并不是交换芯片的数量越多就越好，还要看具体其单体转发能力和整机背板通道布局。
以Cisco的N7000举例分析，其交换网板Fabric Modules上的CFA（Crossbar Fabric ASICs）宣称是支持每槽位（Slot）2*23G的通道交换，整机最大支持2*23*5=230G的每槽位单向转发能力。这样能看出来啥呢？
1、N7010上8个板卡槽位，2个主控槽位（主控槽位支持1条23G通路），一共是8*2+2=18条通道，可以看出7010的交换网板上就一块Crossbar Fabric ASIC，这个交换芯片和以前Cisco6500 Supervisor720上的18*20交换芯片除了每通道带宽从20G提升到了23G以外，通路数都是18条没有变化，应该属于同一代交换芯片产品。7018可以算出是16*2+2=34条通道，那么其每块交换网板上应该是2个与7010相同的CFA交换芯片，而且还空了2条通道暂时没用上。
2、其接口板上的
