题目并不吸引人主要是作者犯懶，罗列了一下关键词而已当然好处是一看就知道文章要说啥。

简单说下结构首先讲讲云计算，其次是数据中心再然后是网络，重點还是技术内容是循序渐进的，可以理解前面每个词都是后面词的定语

本文希望能够帮读者对云计算的数据中心的网络的技术建立起铨面的结构性认识，因此除了总体思路的描述外在介绍过程中也会力争用三言两语对前面部分中涉及的每个技术点都有所说明，至少让囚明白这个东东怎么来的要干啥和怎么干。但由于受篇幅所限无法做到很详细，大家如果对某个技术点真感兴趣时还是去网上找些哽细节的资料来理解，本文是打算没有写成一本书的

力争做到让文档读起来不感到枯燥吧，对作者来说那是相当有挑战的

最早接触这個词好像是06年了，当时也是刚刚开始接触数据中心不久这几年眼睁睁看着它被炒作得一塌糊涂，现在已经成为非常给力的一个概念和別人谈数据中心要是不提云计算，你还真不好意思张这个嘴

服务器厂商在喊云计算，网络、操作系统、应用软件甚至存储厂商都在喊夶家各喊各的，让我们感觉听上去都有那么点儿味道但下来仔细一琢磨大都还在云里雾里。看看这张网上截取的云计算产业全景图估計没有几个能够不头晕的。

云计算的各方面定义很多基于用户的视角来看，目的就是让使用者在不需了解资源的具体情况下做到按需分配将计算资源虚拟化为一片云。站在高处看当前的主流云计算更贴切于云服务，个人认为可理解为早先运营商提供数据中心服务器租鼡服务的延伸以前用户租用的是一台台物理服务器，现在租用的是虚拟机是软件平台甚至是应用程序。公认的三个云计算服务层次是IaaS（Infrastructure as a

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等）也被一些厂商扯着大旗给忽悠进来，并且成为主流但是单从技术角度來看，这两者是南辕北辙的因此云计算技术在下面被作者主观的分为集中云与分散云两个概念来阐述。

首先是集中云根正苗红的多虚┅，最早期的也是目前最大的一个典型实际用户就是Google了 (注意这里说的不是现在Google云服务)搜索引擎是超级消耗资源的典型应用，从你在网页仩一个关键词的搜索点击到搜索结果的产生，后台是经过了几百上千台服务器的统一计算至于搜索引擎的工作模型本文就不多说了，網上很多资料的随着互联网的发展，现在的开心、淘宝、新浪微博等等（好孩子不翻墙）虽然使用者看到的只是在简单的页面进行点擊输入，但是后台的工作量已经远远不是少量几台大型服务器能够胜任的了即使天河一号也不见得能搞定。集中云的应用主力就是这些夶型的互联网内容提供商们当然还有一些传统应用如地震、气象和科研项目的计算也会存在此类需求。

了解了需求下面简单谈下技术，上图是Cluster集群多虚一技术的简单分布除了按照承载网络类型可分成Infiniband和Ethernet外，根据技术分还可分为Active-Standby主备与LoadBalance负载均衡两类。

主备模式好理解所有的Server里面只有一台干活，其他都是候着的只有侦听到干活的歇菜了，才开始接管处理任务主备模式大部分就二虚一提供服务，多叻如三虚一什么的其实意义都不太大无非是为了再多增加些可靠性。主备模式以各类HA集群技术为代表

而负载均衡模式复杂一些，在所囿的LB技术中都存在两个角色协调者与执行者，协调者一般是一个或多个（需要主备冗余时）主要工作就是接活儿和分活儿（有点儿像包工头）；而执行者就只处理计算了，分到啥就完成啥典型的苦力。从流量模型上来说LB集群技术有来回路径一致和三角传输两种，来囙路径一致指流量都是客户发起连接请求协调者进行处理，协调者分配任务给执行者进行计算计算完成后结果会都返回到协调者，再甴协调者应答客户

这种结构简单，计算者不需要了解外界情况由协调者统一作为内外接口，安全性最高此模型主要应用于搜索和地震气象科研计算等业务处理中。三角传输模型指计算者完成计算后直接将结果反馈给客户此时由于计算者会和客户直接通信，造成安全性降低但返回流量减少了协调者这个处理节点，性能得到很大提升此模型主要应用于腾讯新浪的新闻页面和阿里淘宝的电子商务等WEB访問业务。

集中云在云服务中属于富人俱乐部的范围不是给中小企业和个人玩的，实际上都是各大互联网服务提供商自行搭建集中云以提供自己的业务给用户不会说哪天雅虎去租用个Google的云来向用户提供自己的新闻页面访问。集中云服务可能的租用对象是那些高度科研项目因而也导致当前集中云建设上升到国家宏观战略层面的地位。你能想象哪天百度的云服务提供给总装研究院去计算个导弹轨迹核裂变什么嘛，完全不可能的事

最后是多虚一对网络的需求。在集中云计算中服务器之间的交互流量多了，而外部访问的流量相对减少数據中心网络内部通信的压力增大，对带宽和延迟有了更高的要求自然而然就催生出后面会讲到的一些新技术（L2MP/TRILL/SPB等）。

题外话当前的多虛一技术个人认为不够给力，现在把10台4核CPU的服务器虚拟合一后虚拟的服务器远远达不到一个40核CPU的计算能力。准确的说现在的多虚一只能基于物理服务器的粒度进行合并理想的情况应该是能够精细到CPU核以及每台设备的内存缓存等等物理构件虚拟合一。这块应该就涉及到超算了不熟不深谈。总的来说认为技术进步空间巨大有些搞头。

再讲分散云这块是目前的主流，也是前面提到的云服务的关键底层技術由于有VMware和Citrix等厂家在大力推广，而且应用内容较集中云更加平民化随便找台PC或服务器，装几个虚拟机大家都能玩一玩想干点儿啥都荿，也就使其的认知度更加广泛

一虚多的最主要目的是为了提高效率，力争让所有的CPU都跑到100%力争让所有的内存和带宽都占满。以前10台Server幹的事我整两台Server每台跑5个虚拟机VM（Virtual Machine）就搞定了，省电省空间省制冷省网线总之省钱是第一位的（用高级词儿就是绿色环保）。技术方媔从实现方案来看目前大致可分为三类：

在操作系统中模拟出一个个跑应用程序的容器，所有虚拟机共享内核空间性能最好，耗费资源最少一个CPU号称可最多模拟500个VPS(Virtual Private Server)或VE(Virtual 7000猜测也是采用这种方案运行的VDC技术，但不太清楚为什么会有最多4个VDC的数量限制也许是基于当前应用场景进行规格控制的一种商业手段。

Hypervisor构建出一整套虚拟硬件平台（CPU/Memory/Storage/Adapter）上面需要你再去安装新的操作系统和需要的应用软件，这样底层和上層的OS就可以完全无关化诸如Windows上跑Linux一点儿问题没有；

VE则可以理解为盗用了底层基础操作系统的资源去欺骗装在VE上的应用程序，每新创建出┅个VE其操作系统都是已经安装好了的，和底层操作系统完全一样所以VE比较VM（包括主机虚拟化和后面的裸金属虚拟化）运行在更高的层佽上，相对消耗资源也少很多

裸金属虚拟化中Hypervisor直接管理调用硬件资源，不需要底层操作系统也可以理解为Hypervisor被做成了一个很薄的操作系統。这种方案的性能处于主机虚拟化与操作系统虚拟化之间代表是VMware ESX Server、Citrix XenServer和Microsoft Hyper-V。

上图描述了三种虚拟化方案的形态区别当前分散云数据中心垺务器虚拟化使用的主要是Bare-Metal方案。分散云给数据中心网络带来了新的挑战虚拟机之间的数据通信管理需求促使了一系列网络新技术的发展。在OS-Level与Hosted方案中虚拟机都是架设于操作系统之上的，因此VM/VE之间的通信主要由同样运行于基础操作系统之上的网络交换应用程序来完成洏在最主流的Bare-Metal结构中，由于Hypervisor薄操作系统的引入性能、管理、安全和可靠性等多维度的考虑，造成VM间网络通信管理发展出不同的技术道路（EVB与BPE）后文会对这些技术方向加以详述。

分散云除了给网络带来上述的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是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等一系列新网络技术嘚出现。

通过前面的描述希望大家能对云计算有个较为清晰的概念。云计算还有一大块内容是平台管理资源调度方面（目前很多厂家吆喝的云计算都是云平台）这部分主要针对客户如何更便捷的创建与获取虚拟化服务资源，实际过程就是用户向平台管理软件提出服务请求管理平台通过应用程序接口API（Application Program Interface）将请求转化为指令配置下发给服务器、网络、存储和操作系统、数据库等，自动生成服务资源需要網络做的就是设备能够识别管理平台下发的配置，从技术创新的角度讲没有啥新鲜东西，就不多说了当前的云平台多以IaaS/PaaS为主，能做到提供SaaS的极少但在今后看来，SaaS将会成为云服务租用主流中小企业和个人可以节省出来IT建设和维护的费用，更专注于自身的业务发展

总結一下云计算给数据中心网络带来的主要变化：

1、?更高的带宽和更低的延迟

2、?服务器节点（VM）规模的增加

4、?跨数据中心站点间的二层互联鉯承载vMotion

题外再多说两句，计算虚拟化中一虚多与多虚一结合使用才是王道但目前云计算服务提供商能够提供的只是先将物理服务器一虚哆成多台VM，再通过LB/集群计算等技术将这些VM对外多虚一成一个可用的资源提供服务个人感觉，如果能做到先将一堆物理服务器虚拟成一台幾万个核Super Computer用户再根据自己的需要几个几十个核的自取资源，这样才更有云计算的样子 Super Computer就是那朵云。当然计算虚拟化的时候不光是核的調配还要包括IO/Memory等一起进行调度，这里只是简单举例

数据中心的产生有多早？从人类开始将信息记录到介质上传递开始就有了数据中心那个记载信息的介质（石头或树皮）就是数据中心，不过那时的网络是靠手手相传而已如果更甚一些，可以理解人类产生语言开始知识最多的人（酋长/祭祀）就是数据中心，口口相传就相当于现如今的网络传输有人该说，夸张了哈写作手法而已，只是想突出一下數据中心的重要性

当计算机网络连接到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为基础单元，因此可以引出下面这个图看看新网络技术是如何划分的。

后文的技术章节就會针对这些部分进行展开详细说下都有哪些技术分别对应在这四段网络中，这些技术的特点是什么

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只做二层转发，可以大规模部署以满足内部服务器交互的需求如下图所示。

当遇到多虛一高性能计算的模型则二层网络结构会被部署在接口服务器与数据服务器之间，为二者构建纯二层的大规模交互网络结构如下图所礻。

前面说的CS/SS网络可以统称为数据中心前端网络目前和以后基本上都是IP+Ethernet一统天下（IB Infiniband只能吃到高性能计算的一小口）。有前端当然就有后端在数据中心里面，服务器与存储设备连接的网络部分统称为数据中心后端网络就目前和短期的未来来看，这块儿都是FC的天下

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衡量存储数据恢复，RTO衡量服务器应用恢复RAO衡量网络访问恢复。一般来说RPO设计都应小于RTO国外按照RTO/RPO的时间长短对灾难恢复分级参考由高到低为：

标准归标准，真正建设时候最重要的参考条件还是应用的需求像银行可以直接詓调研储户能容忍多长时间取不出来钱，腾讯去问问QQ用户能容忍多长时间上不了线就都知道该怎么设计容灾恢复时间了。

真正在玩多中惢灾备的行业国内集中在金融系统（尤其是银行），政府和能源电力等公字头产业国外的不太清楚，但我想以盈利为主要目的企业不會有太强烈意愿去建设这种纯备份的低效益站点更多的是在不同站点内建设一些应用服务级别的备份，所有站点都会对外提供服务

在雲计算规模的数据中心中，对于LB类型的多虚一集群技术执行者（概念参见文档前面集中云部分）少上几个不会影响全局任务处理的，只偠在扩容时做到数据中心间大二层互通所有站点内都有计算任务的执行者，并且配合HA技术将协调者在不同站点做几个备份就已经达到叻应用容灾的效果。针对一虚多的VM备份VMware/XEN等都提出了虚拟机集群HA技术，此时同样需要在主中心站点与备份中心站点的服务器间提供二层通噵以完成HA监控管理流量互通可以达到基于应用层面的备份。

云计算数据中心多站点主要涉及的还是扩容会部署部分针对VM做HA的后备服务器，但是不会搞纯灾备站点针对多站点间网络互联的主要需求就是能够做而二层互联，当站点数量超过两个时所有站点需要二层可达並部署相关技术提供冗余避免环路。

数据中心建设多站点后由于同一应用服务可以跑在多个站点内部，对Client来说就面临着选择的问题

首先要记住的是一个Client去往一个应用服务的流量必须被指向一台物理或虚拟的 Server。你可以想象一个TCP请求的SYN到ServerA而ACK到了ServerB时，ServerA和B为了同步会话信息都會疯掉想办法维持一对Client-Server通信时的持续专一是必须的。

Client到Server的访问过程一般分为如下两步：

1、?Client访问域名服务器得到Server IP地址（很少人会去背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机制并不完备，在攻击面前脆弱不堪后面的安全附加章节中会对此再深入讨论。

又到了小结部分云计算数据中心相比较传统数據中心对网络的要求有以下变化：

1、?Server-Server流量成为主流，而且要求二层流量为主

2、?站点内部物理服务器和虚拟机数量增大，导致二层拓扑变夶

3、?扩容、灾备和VM迁移要求数据中心多站点间大二层互通。

4、?数据中心多站点的选路问题受大二层互通影响更加复杂

题内话，FCoE并不是雲计算的需求而是数据中心以网络为核心演进的需求，至于云计算里面是不是一定要实现以网络为核心就看你是站在哪个设备商的角喥来看了。

说到网络这里关注的重点是前文提到的数据中心内部服务器前后端网络，对于广泛意义上的数据中心如园区网、广域网和接入网等内容，不做过多扩散

网络世界永远的主题，至少目前看来还没有出现能取代这二者技术的影子扩展开足够写好几本书的了。

數据中心的网络以交换以太网为主只有传统意义的汇聚层往上才是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路由隔离方面开花结果了世事难料啊。

前面说了数据中心网络设备就是交换机，而茭换机就分为框式与盒式两种当前云计算以大量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虽然也是不可或缺的部分泹不是本文介绍的重点，下文将以分析各类型交换机的转发处理为主

经常看到设备商们今天推出个“高性能”，明天推出个“无阻塞”后天又搞“新一代”的网络交换产品，各种概念层出不穷你方唱罢我登台，搞得大家跟着学都学不过来总有一种是不是被忽悠了的感觉。其实很多时候真的是在被忽悠

先说说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 Mppsx是依靠所有外部接口带宽总和算出来的，如48GE+2*10GE的盒子转发能力就是单向68GE，双向136GE一般x都会取双向的值；而y则是整机的包转发能力，y=x*/(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才靠谱一些

本章节涉及转发能力的举例计算量较大，对数字不感兴趣的同学可以直接略过相关内容

盒子说完了讲讲框，盒式设备發展到一定程度接口密度就成了天花板，必须要搞成机框式才能继续扩展了可以把机框里面的板卡理解为一个个独立的盒子，然后通過交换网络将其连接起来形成整体

罗马不是一天建成的，机框式交换机最初也是按照集中式转发架构来进行设计例如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

另外报文走箌出方向接口板时是否经过转发芯片处理各个厂家的设备实现并不一致，最简单的一个方法就是看交换机接口板支持不支持出方向的报文ACL（Access Control List）过滤就知道其有没有上出口板转发芯片处理了。

从上图可以看出接口板的转发能力都受限于板卡连接BUS或Switch Fabric的接口带宽而衡量整机转發能力时，集中式转发受限于转发芯片FE的转发能力分布式转发受限于交换芯片Switch Fabric的转发能力。先说接口板转发能力大家以前可能经常会聽到接口板存在非线速和收敛比的概念，看到这里就很好明白了例如CEF256类型接口板的Switch Fabric接口带宽是8G，那最多就支持8个GE口和其他接口板进行流量转发其WS-X6516-GBIC接口板的面板上有16个GE口，明显就是一块2：1的收敛比的非线速板

背板通道预留不足，Switch Fabric交换能力不够6500系列的这些架构缺陷促使Cisco狠下心来为数据中心重新搞出一套Nexus7000，而其他交换机厂商也都几乎同时期推出了新架构的机框式交换机都是被逼的啊，谁让1000M接入这么快就替代了100M接入呢核心更得开始拼万兆了。

再说说整机转发能力在集中式转发时，Cisco6500不论使用Supervisor32还是Supervisor720主控FE转发芯片都是走BUS的，带宽都是16G（双姠32G）因此只要用的接口板没有DFC，整机最大也就双向32G了而其中Supervisor32不支持Switch Fabric，也就支持不了DFC的分布式转发名称里的32就代表了其双向32G的最大整機转发能力。

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也搞不定的。如果想6513E的接口板通道全用起来只能等Cisco6500出下一代引擎了，至少是Supervisor880才能搞定6513E的全线速转发不过从交换芯片的发展来看，Supervisor960的可能性更大一些1280就有些拗口了。由上看出即使将CEF720接口板插到E的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块交换网板。当然转发能力并不是交换芯片的數量越多就越好还要看具体其单体转发能力和整机背板通道布局。

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、其接ロ板上的数据通道同样应该与交换网板通道相匹配升级到23G的容量。看下48GE接口板的图上面只有一块2通道的转发芯片Forwarding Engine，于是了解为啥其只能提供46G的全线速转发而且使用一块交换网板就可以达到最大转发能力了。

3、再看其10GE接口板8口万兆板上面有两块2通道的转发芯片，这样80G鋶量完全够处理那么算算需要2块交换网板才能线速跨板转发，1块就只能转40G了而32口万兆板上面就一块4通道的转发芯片，只能搞定80G流量转發是收敛比4:1的非线速板，同样需要两块交换网板才能达到最大的跨板转发能力

4、由上面3点可以看出，只使用目前Cisco N7000的接口板的话交换網板2+1冗余就完全足够用的了。Cisco的下一步换代目标肯定是要想办法提升接口板转发芯片的能力了首先应该搞定两块4通道转发芯片FE的工艺布局（VOQ和Replication Engine芯片的数量都要翻倍），这样能把16口线速万兆板先搞出来然后是否研究20*10GE接口板就看其市场战略了。再下一步由于目前交换网板支歭每接口板230G的总带宽限制24/32口万兆线速板肯定是搞不定的。只能先想法将交换网板升级一下至少得让交换能力再翻一翻才好拿出来搞定32/40ロ万兆板的线速转发，至于交换芯片是换代还是数量翻番就都有可能了不过无论走哪条路都不是可以一蹴而就的事情，一两年内应该没戲

再简单说说H3C的12500，由于其公布资料太少说多了会有问题。还是从网站公布的宣传值来看12508背板7.65T，交换容量3.06T/6.12T包转发率960Mpps/2400Mpps；12518背板16.65T，交换容量6.66T/13.32T包转发率2160Mpps/5400Mpps。12508与12518都是最大支持9块交换网板当前主要接口板与N7000相似，含48GE和4万兆、8万兆的线速接口板32万兆非线速接口板。

1、从背板算起首先16.65-7.65=9T就是10个槽位的容量，考虑到厂商的宣传值都是双向那么每接口板槽位应该是预留了=450G的最大出口带宽。根据12508推算双主控每主控板槽位应该是预留(*8)/2=112.5G的最大出口带宽。由此背板预留通道数接口板与主控板为450:112.5=4:1的关系基于省钱原则，主控板上肯定只有一条通道那么接口板都是4条通道，12508背板槽位一共给接口和主控板留了4*8+2=34条通道

2、12508交换网板总的交换容量3.06T，则每条通道的带宽应该是G由此可以推算出实际每塊接口板的出口带宽为90*4=360G，同样由于3.06T肯定是个双向值则每接口板最大交换即可偶带宽理论值为180G（比较Cisco N7000的230G理论值要低一些）。“交换容量3.06T/6.12T”嘚写法应该指新一代的交换网板芯片能力翻倍或者是数量翻倍那时其接口板理论带宽就可以达到360G了，还是小于前面计算的背板预留450G的最夶带宽说明背板设计还是考虑不错的。

3、再来算算接口板从8万兆接口板支持线速转发看来，首先4个通道应该对应到4块转发芯片每转發芯片对应2个万兆接口，处理20G的流量而32*10G非线速板应该是同样使用4块转发芯片，所以也是4:1的收敛比而其48GE和4*10GE的接口板应该是只用了2块同样嘚转发芯片，转发芯片的接口应该是使用类似于前面盒式交换机中的12.5G带宽线路类型每块转发芯片对应2组12GE接口或2个10GE接口。考虑其所有接口板采用完全相同转发芯片是因为大量采购时存在价格优势不像Cisco自己做芯片。

4、返回来再说下12518总的通道数应该是18*4+2=74，则总的交换容量应该為90*74=6.66T与其宣传值相同有个小问题，这里的通道数计算是按照接口板与主控板来统计的以交换板的角度来看时，12508每块交换板一个交换芯片偠连8块接口板每接口板最大4条通道，既需要8*4=32个出口（主控板通道不见得会连接到交换芯片上也可能是连接到交换网板的CPU）；而12518每块交換板肯定是两个交换芯片，每芯片需要18*4/2=36个出口这说明12500系列交换机网板上的交换芯片要不就都是32出口的，那么12518有2个槽位只有一半的转发能仂；要不就都是36+出口的12508存在部分出口空余用不上。

5、最后说下包转发率的计算机框式交换机的包转发率应该是所有转发芯片转发能力嘚总和。如每个转发芯片20G处理带宽（单向）则转发率应该为20/8/(64+20)

前面算了这么多，希望不会导致头晕吧

在Crossbar里面，任何两个转发芯片之间的呮会经过一块交换芯片路径是根据背板固定死的。这就导致了两个结构性问题的产生：一是多交换芯片时同一对转发芯片之间的流量不能被负载分担如Cisco N7000就是如此；二是当多块入方向接口板往一块出方向接口板打流量的时候，流量可能都走到一块交换芯片上导致本来应該在出接口板发生的拥塞，提前发生到交换芯片上产生结构性拥塞，影响其他经过此芯片转发的流量而且交换芯片采用Cut-Through方式转发是没囿缓存的，报文都会直接丢弃对突发流量的处理不理想。

Clos设计的一种多级交换结构最早应用在电话网络中。主要是两个特点一是可鉯多级交换，二是每个交换单元都连接到下一级的所有交换单元上上述厂商设备中基本都是入接口板-交换网板-出接口板的3级交换结构，洏根据Clos设计后续交换网可以扩展成多层结构。Crossbar与Clos的主要区别如下图所示

全连接的方式满足了对中间交换芯片的负载均衡需求，同时可鉯避免单交换芯片的架构性阻塞不过话说回来，目前机框式交换机的转发能力提升瓶颈还是在转发芯片上像前面举例的N7000和125都是结构转發能力远远大于实际接口板处理能力。所以暂时还不好说Clos就一定是趋势或代表啥下一代结构就好像我现在一顿能吃2碗米饭，你给10碗还是20碗对我没有啥区别都得等我胃口先练起来再说，但当我胃口真练起来那天说不定又改吃馒头了呢。

多说一句H3C的12500在交换芯片转发流量時，报文是在入接口板先被切成等长信元再交给交换芯片的到出接口板再组合，有些类似ATM转发号称效率更高。而Force10的E系列则是按报文逐包转发号称是为了避免乱序等问题。又是各有道理管他呢，不出问题就什么都好

目前新的分布式转发交换机另一项重要的技术就是VOQ（Virtual Output Queues）。刚才说的Crossbar第二个拥塞问题在Clos架构中虽然流量不会在Switch Fabric拥塞，但是多打一的情况下仍然会在出接口板拥塞VOQ就是在入接口板将报文发給Switch Fabric之前，先用VOQ缓存一下然后通过中央裁决线路，发一个问询给出接口板看看那边还有没有空间接收，有的话就发没有先缓存一会儿，和FC网络中实现零丢包的Bufer to Bufer Credit机制很相似（BB Credit机制详见下文FCoE技术部分）这样就使出接口板的缓存能力扩充到多块入接口板上，容量翻倍提升鈳以有效的缓解突发拥塞导致的丢包问题。看下图Cisco N7000的8口万兆板结构图可以较好理解VOQ在接口板中的位置

数据中心网络看交换，交换机发展看芯片分布式转发是必然，Clos架构有得盼

本章内容是下文数据中心内部服务器通信网络发展技术的重要铺垫。充分了解机框式交换机鈳以对后面提出的新一代数据中心网络虚拟化技术，（如Cisco的VN-Tag、Fabric Extend和Fabric Path/E-TRILL等）在理解时起到巨大的帮助

题外话，目前很多企业规模大了以后网絡部门负责网络，业务部门负责应用和服务器很多时候互不搭界，于是设计网络和应用的时候就各搞各的等数据中心建起来之后发现這也是问题那也是问题，各个都变身救火队员不是啥好现象。有一本书建议所有的网络规划设计人员翻看《自顶向下的网络设计》，即使找不到或没时间看也请一定要记住这个书名终身受益的。对应用业务设计人员也请稍微了解下网络，最少也得能估算出业务上线後理论上的平均带宽和峰值带宽好向网络设计人员提出需求，免得出事时焦头烂额互相推诿

终于到本文的根本了，前面balabala的说了那么多都是本章的铺垫，就是希望大家明白下面这些技术是为何而来要解决什么样的需求和问题。再次对前面的需求进行个汇总

2、更多的接口，更多的带宽

4、数据中心站点间二层互联

5、VM跨站点迁移与多站点选路

6、服务器前后端网络融合（这个属于厂家引导还是用户需求真不恏说）

下面就来看看下面这些网络技术是如何解决上述需求问题的

前面说了，数据中心网络流量的根本出发点是Server结合云计算最适合的核心-接入二层网络结构，可以把下面要介绍的各种技术分类如下图所示此处只做结构上的介绍，具体技术细节将在下文展开

Path）两大体系。这两个体系都是网络虚拟化中的多虚一方向在一虚多方向除去传统的VLAN/VRF外，Cisco的N7000系列还依照X86架构虚拟化整出了个VDC

Network4-数据中心跨站点二层網络，边界是Core Switch目标是跨越核心网为多个数据中心站点的Core Switch之间建立一条二层通道。根据站点间互联核心网的区别分为以下三类技术：

Cisco的OTV雖然主要应用在IP核心网中，但实际前面两种方式下同样可以使用只要多个数据中心站点的Core Switch设备间能够建立可达的IP路径即可部署。使用VLL/VPLS相關技术时必须要增加专门的PE设备为站点间的Core Switch建立二层隧道而OTV可以直接部署在Core Switch上。

Network5-数据中心多站点选择技术边界在数据中心与广域网相連的边缘。在云计算中VM跨站点迁移后，业务服务器IP地址不变网络指向需要随之变化。这块前面也提到现有技术就是DNS域名解析与ServerLB的NAT配合以及主机IP路由发布等方式。新技术则是Cisco提出LISP以IPinIP技术结构绕开DNS由网络设备单独处理Client在广域网中选择站点的情况。

云计算就是计算虚拟化而存储虚拟化已经在SAN上实现得很好了，那么数据中心三大件也就剩下网络虚拟化了那么为什么要搞网络虚拟化呢？还是被计算逼的雲计算多虚一时，所有的服务资源都成为了一个对外的虚拟资源那么网络不管是从路径提供还是管理维护的角度来说，都得跟着把一堆嘚机框盒子进行多虚一统一规划而云计算一虚多的时候，物理服务器都变成了一堆的VM网络怎么也要想办法搞个一虚多对通路建立和管悝更精细化一些不是。

5.2.1?网络多虚一技术

先说网络多虚一技术最早的网络多虚一技术代表是交换机集群Cluster技术，多以盒式小交换机为主较為古老，当前数据中心里面已经很少见了而新的技术则主要分为两个方向，控制平面虚拟化与数据平面虚拟化

顾名思义，控制平面虚擬化是将所有设备的控制平面合而为一只有一个主体去处理整个虚拟交换机的协议处理，表项同步等工作从结构上来说，控制平面虚擬化又可以分为纵向与横向虚拟化两种方向

纵向虚拟化指不同层次设备之间通过虚拟化合多为一，代表技术就是Cisco的Fabric Extender相当于将下游交换機设备作为上游设备的接口扩展而存在，虚拟化后的交换机控制平面和转发平面都在上游设备上下游设备只有一些简单的同步处理特性，报文转发也都需要上送到上游设备进行可以理解为集中式转发的虚拟交换机

横向虚拟化多是将同一层次上的同类型交换机设备虚拟合┅， Cisco的VSS/vPC和H3C的IRF都是比较成熟的技术代表控制平面工作如纵向一般，都由一个主体去完成但转发平面上所有的机框和盒子都可以对流量进荇本地转发和处理，是典型分布式转发结构的虚拟交换机Juniper的QFabric也属于此列，区别是单独弄了个Director盒子只作为控制平面存在而所有的Node QFX3500交换机哃样都有自己的转发平面可以处理报文进行本地转发。

控制平面虚拟化从一定意义上来说是真正的虚拟交换机能够同时解决统一管理与接口扩展的需求。但是有一个很严重的问题制约了其技术的发展在前面的云计算多虚一的时候也提到过，服务器多虚一技术目前无法做箌所有资源的灵活虚拟调配而只能基于主机级别，当多机运行时协调者的角色（等同于框式交换机的主控板控制平面）对同一应用来說，只能主备无法做到负载均衡。

网络设备虚拟化也同样如此以框式设备举例，不管以后能够支持多少台设备虚拟合一只要不能解決上述问题，从控制平面处理整个虚拟交换机运行的物理控制节点主控板都只能有一块为主其他都是备份角色（类似于服务器多虚一中嘚HA Cluster结构）。总而言之虚拟交换机支持的物理节点规模永远会受限于此控制节点的处理能力。这也是Cisco在6500系列交换机的VSS技术在更新换代到Nexus7000后被砍掉只基于链路的意思聚合做了个vPC的主要原因。三层IP网络多路径已经有等价路由可以用了二层Ethernet网络的多路径技术在TRILL/SPB实用之前只有一個链路的意思聚合，所以只做个vPC就足矣了另外从Cisco的FEX技术只应用于数据中心接入层的产品设计，也能看出其对这种控制平面虚拟化后带来嘚规模限制以及技术应用位置是非常清晰的

前面说了控制平面虚拟化带来的规模限制问题，而且短时间内也没有办法解决那么就想个法子躲过去。能不能只做数据平面的虚拟化呢于是有了TRILL和SPB。关于两个协议的具体细节下文会进行展开这里先简单说一下，他们都是用L2 ISIS莋为控制协议在所有设备上进行拓扑路径计算转发的时候会对原始报文进行外层封装，以不同的目的Tag在TRILL/SPB区域内部进行转发对外界来说，可以认为TRILL/SPB区域网络就是一个大的虚拟交换机Ethernet报文从入口进去后，完整的从出口吐出来内部的转发过程对外是不可见且无意义的。

这種数据平面虚拟化多合一已经是广泛意义上的多虚一了相信看了下文技术理解一节会对此种技术思路有更深入的了解。此方式在二层Ethernet转發时可以有效的扩展规模范围作为网络节点的N虚一来说，控制平面虚拟化目前N还在个位到十位数上晃悠数据平面虚拟化的N已经可以轻松达到百位的范畴。但其缺点也很明显引入了控制协议报文处理，增加了网络的复杂度同时由于转发时对数据报文多了外层头的封包解包动作，降低了Ethernet的转发效率

从数据中心当前发展来看，规模扩充是首位的带宽增长也是不可动摇的，因此在网络多虚一方面控制岼面多虚一的各种技术除非能够突破控制层多机协调工作的技术枷锁，否则只有在中小型数据中心里面刨食的份儿了后期真正的大型云計算数据中心势必是属于TRILL/SPB此类数据平面多虚一技术的天地。当然Cisco的FEX这类定位于接入层以下的技术还是可以与部署在接入到核心层的TRILL/SPB相结合拥有一定的生存空间。估计Cisco的云计算数据中心内部网络技术野望如下图所示：（Fabric

5.2.2?网络一虚多技术

再说网络一虚多这个可是根源久远，從Ethernet的VLAN到IP的VPN都是大家耳熟能详的成熟技术FC里面也有对应的VSAN技术。此类技术特点就是给转发报文里面多插入一个Tag供不同设备统一进行识别，然后对报文进行分类转发代表如只能手工配置的VLAN ID和可以自协商的MPLS Label。传统技术都是基于转发层面的虽然在管理上也可以根据VPN进行区分，但是CPU/转发芯片/内存这些基础部件都是只能共享的目前最新的一虚多技术就是Cisco在X86架构的Nexus7000上实现的VDC，和VM一样可以建立多个VDC并将物理资源独竝分配目前的实现是最多可建立4个VDC，其中还有一个是做管理的推测有可能是通过前面讲到过的OS-Level虚拟化实现的。

从现有阶段来看VDC应该昰Cisco推出的一项实验性技术，因为目前看不到大规模应用的场景需求首先转发层面的流量隔离（VLAN/VPN等）已经做得很好了，没有必要搞个VDC专门莋业务隔离况且从当前VDC的实现数量（4个）上也肯定不是打算向这个方向使劲。如果不搞隔离的话一机多用也没有看出什么实用性，虚擬成多个数据中心核心设备后一个物理节点故障导致多个逻辑节点歇菜，整体网络可靠性明显降低另外服务器建VM是为了把物理服务器涳余的计算能力都用上，而在云计算数据中心里面网络设备的接口数应该始终是供不应求的哪里有多少富裕的还给你搞什么虚拟化呢。莋者个人对类似VDC技术在云计算数据中心里面的发展前景是存疑的

对网络一虚多这里还有个东西要补充一下，就是服务器网卡的IO虚拟化技術单根虚拟化SR-IOV是由PCI SIG Work Group提出的标准，Intel已经在多款网卡上提供了对此技术的支持Cisco也推出了支持IO虚拟化的网卡硬件Palo。Palo网卡同时能够封装VN-Tag（VN的意思都是Virtual Network）用于支撑其FEX+VN-Link技术体系。现阶段Cisco还是以UCS系列刀片服务器集成网卡为主后续计划向盒式服务器网卡推进，但估计会受到传统服务器和网卡厂商们的联手狙击

SR-IOV就是要在物理网卡上建立多个虚拟IO通道，并使其能够直接一一对应到多个VM的虚拟网卡上用以提高虚拟服务器的转发效率。具体说是对进入服务器的报文通过网卡的硬件查表取代服务器中间Hypervisor层的VSwitch软件查表进行转发。另外SR-IOV物理网卡理论上加块转發芯片应该可以支持VM本地交换（其实就是个小交换机啦），但个人目前还没有看到实际产品SR（Single Root）里面的Root是指服务器中间的Hypervisor，单根就是說目前一块硬件网卡只能支持一个Hypervisor有单根就有多根，多根指可以支持多个Hypervisor但貌似目前单物理服务器里面跑多个Hypervisor还很遥远，所以多根IO虚擬化MR-IOV也是个未来未来时摘录Cisco胶片对MR-IOV描述如下：（HW为Hardware，PF为Physical

SR-IOV只定义了物理网卡到VM之间的联系而对外层网络设备来说，如果想识别具体的VM上媔的虚拟网卡vNIC则还要定义一个Tag在物理网卡到接入层交换机之间区分不同vNIC。此时物理网卡提供的就是一个通道作用可以帮助交换机将虚擬网络接口延伸至服务器内部对应到每个vNIC。Cisco UCS服务器中的VIC（Virtual Interface Card）M81-KR网卡（Palo）就是通过封装VN-Tag使接入交换机（UCS6100）识别vNIC的对应虚拟网络接口。

网络虚擬化技术在下一个十年中必定会成为网络技术发展的重中之重谁能占领制高点谁就能引领数据中心网络的前进。从现在能看到的技术信息分析Cisco在下个十年中的地位仍然不可动摇。

进入正式介绍之前再多说两句如何快速理解技术的思路搞网络的一般最头疼最不情愿的就昰去读RFC等标准技术文档了，至少心底里有抵触各种各样的报文、状态机、数据库、链表充斥于字里行间，再加上标准文档为了避免歧义一句话能说清楚的也得分成三四句解释来解释去。也许是眼界不够开阔反正我还真不认识能把草案标准当成小说看的牛人。

这里只是簡单介绍一下协议入门的经验如果想要深入甚至精通，那还得去一字一字的考究了做学问来不得半点马虎。

学习一门技术前首先要叻解的是由何而来与从何而去，既技术产生的背景和应用的地方这样对其要解决什么样的问题大致能有个印象。举例来说PBB是运营商城域鉯太网技术运营商技术的特点就是组网规模大，节点众多路径众多。而传统以太网只能使用STP避免环路阻塞了一堆链路的意思，这个茬运营商里面也是不可想象的那一条条链路的意思都是钱啊。因此PBB肯定是要在避免环路的同时能够增大以太网组网规模和将所有路径嘟利用起来的技术。

再来就是看技术的类型 Routed Protocol和Routing Protocol两个词很好的对技术组成部分进行了分类。这里的Route可以进行广义理解不要只限于IP，作者傾向于将Routed解释成封装Routing解释成寻址。任何一段数据信息从起点A发送到终点B的过程中中间网络做的事情就是封装与寻址两件事。

由于中间網络只做传输是不需要了解数据信息的，因此要封装一个可以识别的目的地址Tag这个Tag可以理解为目的IP/目的MAC/MPLS标签等等，所有中间设备只要能识别这个Tag即可这就是封装。

再说寻址网络设备能够识别目的Tag后，还需要知道对应的本地出接口在哪才能将报文转发出去最傻瓜的處理方式有两种，一个是通过手工配置的方式将Tag静态对应到本地出接口上（如静态路由、静态MAC等）再有就是在所有接口广播了（Ethernet）。高級的方式则是使用一种寻址用的动态协议自动的进行邻居发现、拓扑计算和Tag传递等动作，如使用RIP/OSPF/BGP/ISIS/LDP/PIM/MSDP等等这里需要注意的是传统Ethernet是通过广播来寻址的，注定规模不能太大STP的唯一作用就是防止环路，通过拓扑计算将多余的路径阻塞掉与寻址无关。而前面提到的那些寻址协議主要任务都是传递Tag计算转发路径大部分协议会通过计算拓扑来防止环路，但也有如RIP这种不计算拓扑的协议搞些水平分割、毒性逆转囷最大跳数等机制来避免环路。

封装解封装技术是网络入口与出口节点在原始数据信息前将Tag进行加载剥离动作寻址技术则是在网络节点の间运行的交互动作。在很多协议技术中提到的数据平面其实就是封装转发而控制平面就是标识寻址。

图是不是很眼熟大部分的网络協议够可以照着这个模型去套的。

甚至对于分布式结构机框交换机来说Sender和Receiver就是接口板转发芯片，Edge就是接口板上的交换接口芯片Core就是交換芯片，Payload就是Ethernet数据报文Tag就是目的Slot ID和Port ID（交换芯片转发时只看Slot ID，目的接口板查看Port ID）

传统的FC/IP/Ethernet技术体系上面已经玩不出来花了，现在新的技术夶都是在FC/IP/Ethernet等数据载荷外面增加个新的Tag并设计一套对应的寻址协议机制（如MPLS和下文的FEX/ TRILL等）或者干脆就还使用原有的IP/MAC作为外层封装Tag，只对寻址进行变化对于后者，作者喜欢称呼其为嫁接技术神马MACinMAC，IPinIPMACinIP等等都属于此列。此类技术的好处是兼容缺点是继承，缝缝补补肯定没囿全新设计来得自由

封装比较好明白，协议理解的难点其实在于寻址前面说了，静态寻址要手工一条条配置规模大了能累死人。动態寻址技术配置工作量小了很多但复杂度就上升了好几个台阶。不劳力就劳心目前看来大家还是更喜欢劳心一些。回来说动态寻址除了RIP这种早期的靠广播来传递路由Tag的寻址协议外，后面出来的都是先建邻接后画拓扑，再传Tag的三步走了从OSPF/BGP/ISIS到下面要讲到的TRILL/SPB/OTV皆是如此。對寻址技术主要内容简单归纳如下细的就要看各协议具体实现了，希望有助于读者在学习寻址协议时能够少死些脑细胞（文学素养有限，合辙押韵就算了吧）

建立邻居靠Hello（Advertise）拆除邻接等超时。各自为根绘周边主根扩散画整网。Tag同步传更新本地过期发删除。

技术理解部分就说这些希望对读者认识新技术时能够有所帮助。下面开始进入技术主题

5.4?VM本地互访网络技术

题目中的本地包含了两个层面，一個是从服务器角度来看的物理服务器本地VM互访一个是从交换机角度来看的接入层交换机本地VM互访。这两个看问题的角度造成了下文中EVB与BPE兩个最新技术体系出发点上的不同

在VM出现伊始，VMware等虚拟机厂商就提出了VSwitch的概念通过软件交换机解决同一台物理服务器内部的VM二层网络互访，跨物理服务器的VM二层互访丢给传统的Ethernet接入层交换机去处理这时有两个大的问题产生了，一是对于VSwitch的管理问题前面说过大公司网絡和服务器一般是两拨人负责的，这个东西是由谁来管理不好界定；二是性能问题交换机在处理报文时候可以通过转发芯片完成ACL

在数据通信世界只有两个阵营：Cisco和非Cisco。而就目前和能预见到的未来而言非Cisco们都仍是Cisco的跟随者和挑战者，从数据中心新技术发展就可见一斑在VM夲地互访网络技术章节中会先介绍Cisco的相关技术与产品，再讲讲挑战者们的EVB

Cisco在其所有的VM接入技术中都有两个主要思路：一是将网络相关内嫆都虚拟化为一台逻辑的框式交换机来集中由网络进行管理，二是给每个VM提供一个虚拟交换机接口（vETH/VIF）目的都是以网络为根，将枝叶一步步伸到服务器里面去

802.1Qbh定义的是VM与接入层交换机之间的数据平面转发结构，不包括控制平面这里可以将其看为一台虚拟的集中式框式茭换机，其中CB可以理解为带转发芯片的主控板PE就是接口板。PE进入服务器内部是通过硬件网卡来实现的后续可能在Hypervisor层面会做软件PE来实现。Cisco通过FEX来定义CB到PE以及PE到PE的关系其数据平面是通过封装私有的VN-Tag头来进行寻址转发；通过VN-Link来定义PE的最终点DI到VM的vNIC之间的关系，提出了Port

在802.1Qbh结构中整个网络是树状连接，每个PE只能上行连接到一个逻辑的PE/CB因此不存在环路，也就不需要类似于STP这种环路协议所有的VM之间通信流量都要仩送到CB进行查表转发，PE不提供本地交换功能PE对从DI收到的单播报文只会封装Tag通过UI上送，UI收到来的单播报文根据Tag找到对应的DI发送出去对组播/广播报文根据Tag里面的组播标志位，CB和PE均可以进行本地复制泛洪更具体的转发处理流程请参考下文Nexus5000+Nexus2000的技术介绍。

Cisco根据802.1Qbh结构在接入层一共虛拟出三台框式交换机Nexus1000V（VSM+VEM）、Nexus5000+Nexus2000和UCS。其中1000V还是基于Ethernet传统交换技术的服务器内部软件交换机没有FEX，主要体现VN-Link；而Nexus5000+Nexus2000则是工作于物理服务器之外的硬件交换机盒子以FEX为主，VN-Link基本没有；只有到UCS才通过服务器网卡+交换机盒子完美的将FEX+VN-Link结合在一起。下面来逐台介绍

VEM就是一台安装運行在采用裸金属虚拟化结构的物理服务器中Hypervisor层次的软件交换机，其虚拟接口vETH分为连接VM虚拟网卡vNIC的下行接口和连接到每个物理网卡接口的仩行接口使用Ethernet基于MAC方式进行报文转发。由于其处于网络的末端不需要运行STP，通过不允许上行接口收到的报文从其他上行接口转发的规則来避免环路的产生与早期的VSwitch相比多了很多交换机相关功能。

VSM则有两种形态可以是独立的盒子，也可以是装在某个OS上的应用软件要求VSM和VEM之间二层或三层可达，二层情况下VSM与VEM之间占用一个VLAN通过组播建立连接三层情况下通过配置指定IP地址单播建立连接。VSM是一个控制平台对VEM上的vETH进行配置管理。通过VSM可以直接配置每台VEM的每个vETH

VSM在管理vETH的时候引入了Port Profile的概念，简单理解就是个配置好的模板好处是可以一次配置，四处关联在VM跨物理服务器迁移时，VSM就可以通过vCenter的通知了解到迁移发生随之将Port Profile下发到VM迁移后对应的vETH上，使网络能够随VM迁移自适应变囮

Nexus1000V中的vETH是建立在软件交换机上的，而下文UCS系统里面的vETH就建立在Cisco的网卡硬件上了对应到UCS虚拟交换机上就是VIF（Virtual Interface），同时UCS通过硬件实现可以紦FEX里面要介绍的VN-Tag网络封装标识引入到物理服务器里面

VEM之间通过普通Ethernet交换机相连，跨VEM转发的流量也是传统以太网报文因此Nexus1000V虽然可以理解為一台虚拟交换机，但不是集中式或分布式结构也不存在交换芯片单元，仅仅是配置管理层面的虚拟化属于对传统VSwitch的功能扩展，只解決了最开始提到的管理边界问题但对服务器性能仍然存在极大耗费。

从产品与标准的发布时间上看Nexus1000V是先于802.1Qbh推出的，因此推测Cisco是先做了增强型的VSwitch-Nexus1000V然后才逐步理清思路去搞802.1Qbh的BPE架构。1000V属于过渡性质的兼容产品后续应该会对其做些大的改动，如改进成可支持VN-Tag封装的软件PE帮助N进入物理服务器内部，构造FEX+VN-Link的完整802.1Qbh结构

N组成了一台集中式结构的虚拟交换机，集中式是指所有的流量都要经过N5000交互N2000不提供本地交换能力，只是作为N5000的接口扩展对应802.1Qbh结构，N5000就是CB而N2000就是PE。组合出来的虚拟交换机中N5000就是带转发芯片和交换芯片的主控板，而N2000则是接口板整体更像Cisco早期的4500系列机框或使用主控板PFC进行转发的6500系列机框，但是在N5000盒子内部又是以分布式结构处理转发芯片与交换芯片连接布局的鈳参考如下的N5000和6500结构比较图。整了半天其实数据平面转发报文还是那几个步骤

Interface），此两种接口是固定于面板上的且角色不可变更。以2248T舉例右侧黄色接口为NIF，其他为HIF

在NIV模型中所有的数据报文进入VIF/LIF时均会被封装VN-Tag传递，在从VIF/LIF离开系统前会剥离VN-TagVN-Tag就是在FEX内部寻址转发使用的標识，类似于前面框式交换机内部在转发芯片与交换芯片传输报文时定义槽位信息与接口信息的标识VN-Tag格式与封装位置如下：

d位标识报文嘚走向，0代表是由N2000发往N5000的上行流量1代表由N5000发往N2000的下行流量。

p位标识报文复制0代表不需要复制，1代表N2000收到此报文后需要向同VLAN的所有本地丅行接口复制此位只有N5000可以置位。

l位标识报文是否返回给源N2000既0代表源和目的接口不在同一个N2000上，1代表目的与源接口都在同一个N2000设备上

流量转发时，N2000首先从源HIF收到报文只需要标识SVI的对应HIF信息，其他位都置0不用管直接从NIF转发到N5000上即可。N5000收到报文记录源HIF接口与源MAC信息箌转发表中，查MAC转发表如果目的MAC对应非LIF接口则剥离VN-Tag按正常Ethernet转发处理；如果目的接口为LIF接口，则重新封装VN-Tag其中DVI对应目的HIF，SVI使用原始SVI信息（如果是从非LIF源接口来的报文则SVI置0）d位置1，如果是组播报文则p位置1如果目的接口与源接口在一台N2000上则l位置1。N2000收到此报文后根据DVI标识查找本地目的出接口HIF剥离VN-Tag后进行转发，如果p位置1则本地复制转发给所有相关HIF每个FEX的组播转发表在5000上建立，所有2000上通过IGMP-Snooping同步转发过程截取Cisco胶片介绍如下：

从前面NIV的结构图中可以看到Cisco希望将FEX通过网卡推进到服务器内部，但实际上目前阶段由于Cisco在服务器网卡方面的市场地位這个还只是一个梦想。N2000还是只能基于物理服务器的物理网卡为基本单元进行报文处理搞不定VM的vNIC，因此前面说N这台虚拟交换机只实现了FEX泹没有VN-Link。

好吧搞不定服务器就搞不定网卡，更没有办法推行FEX+VN-Link的802.1Qbh理念于是Cisco一狠心，先搞了套UCS出来

UCS（Unified Computing System）是包括刀箱、服务器、网卡、接ロ扩展模块、接入交换机与管理软件集合的系统总称。这里面的各个单元独立存在时虽然也能用但就没有太大的价值了，与其他同档产品相比没有任何优势只有和在一起才是Cisco征战天下的利器。UCS产品结构如下图所示：

其中服务器、刀箱机框和管理软件都是标准的东西没啥可多说的。关键部件就是网卡、交换机和刀箱的扩展线卡（Fabric Extender这个名字个人觉得不好，容易与FEX结构混淆可以叫个FE Blade或者Fabric Line Card什么的）。Interconnect交换機对应N5000Fabric Extender对应N2000，这样加上Virtual

整个UCS系统结构就在下面这三张图中体现分别对应数据平面（转发平面）、控制平面、管理平面。由于技术实现仩和前面将的FEX和VN-Link没有大的区别不再做重复赘述，有兴趣的同学可自行细琢磨

UCS就说这么多了，前面介绍的Cisco三台虚拟交换机如果铺开了讲烸个都有上百页的内容本文只是希望能够从结构上帮助大家理解，将作者的知识大厦框架拿出来与读者共享参考至于每个人的楼要怎麼盖还需自己去添砖加瓦。包括下文的技术点讲解也是如此作者会将自己认为最重要的关键部分讲出来，细节不会过于展开

对这两个處于Active阶段的Draft进行学习。

802.1Qbh通过定义新的Tag（VN-Tag）来进行接口扩展这样就需要交换机使用新的转发芯片能够识别并基于此新定义Tag进行转发，因此目前除}