分享

［原文可参阅：新浪阮涵的博客］

数据中心网络技术浅析

随着云计算/大数据/移动互联等技术的推动下，作为在网络设备商做了多年研发的我近期一直在想这个问题：云计算下的数据中心网络到底是怎么样？怎么样的基础网络才能满足当前云计算下变化复杂的业务？ 首先，我理解网络架构的设计仍然还是自顶向下的，运行的业务、用户的投资回报（opex/capex）等因素影响着数据中心网络架构以及网络设备软硬件特性的变化。 从目前的种种迹象表明云计算是对数据中心网络的最大驱动力，我们先从当前业务模式技术驱动力开始。

1． 当前业务模式的技术驱动力

最上层是从不同的用户入口接收数据，首先是一个不依赖硬件的云OS, 完成应用、连接和交互，接着是数据智能从海量的数据进行语义分析，再下来是软件基础架构的变化（分布式软件系统等），进而影响着数据中心以及网络、服务器等基础设施的变革。云计算（数据中心计算）的主要技术领域涵盖了存储、计算、超大规模系统、数据中心等，比如存储，不仅要考虑文件、对象以及表等数据组织结构，也要定义访问模式，读少写多、读多写少以及是否实时存储等不同模式会在很大程度上影响存储系统的设计。再如计算，也分为数据密集型、通讯密集型和计算密集型。

2． 数据中心计算对网络的需求

上面简单了解一下目前业务驱动的一个总体架构，数据中心计算对基础网络有哪些需求呢？从用户直观体验上看，用户对于云端数据中心直接关心是提供运算能力和存储服务，因此狭义的数据中心主要包含计算和存储，但是如果没有数据中心网络的话又把我们带回仅仅scale-up的大型机时代，网络把数据中心的计算和存储连接在一起，在Scale-up和Scale-out两种模式的螺旋状上升中满足云计算的大规模提供能力的需求，因此网络在数据中心的地位同样也是非常重要的。对于数据中心的网络接入需求主要有下面几类：

(1).                 HPC/离线计算的通讯密集型：该类型主要是计算和通讯都有一定的要求，对网络的总体要求：流量是东西向多，由于大量分布式计算会有多打一的情况，因此网络尽可能的无收敛比，TOR接入大部分要求单网卡即可（除了HPC的Master节点要求双网卡接入），要求时延低，丢包率低，　不涉及虚拟机迁移（由于计算能力要求高，hypervisor还是耗资源的，暂时没有跑在虚拟机上面），由于一般情况下是TOR直接是三层网关，因此对于ARP/MAC等表项没有很大的要求。

(2).                弹性计算：弹性计算会涉及虚拟机以及虚拟机的迁移，那么网络至少要有一定的二层能力（不一定要超级大的二层），对于MAC/ARP的表项有一定的要求，对于时延和丢包相对不太敏感，流量南北向相对多，对于收敛比没有要求。

(3).                 分布式存储：对于HDFS的存储采用多份（本地一份，本机架交换机另外一个端口一份，跨机架一份），流量在TOR交换机间，不同的机架之间都很大，网络尽可能的无收敛，对于时延和丢包要求敏感，不涉及虚拟机的迁移。

3． 数据中心网络架构

传统的网络一般来说至少有三级网络，接入、汇聚和核心，每个层次的设备都有自己的职责，并且为了高可靠性和避免网络的环路大量使用MSTP/VRRP等技术，这样网络有如下明显的缺点：

(1)                  网络级数多，设备相对多，管理起来比较麻烦;

(2)                  时延相对大：设备多一级，时延肯定多一些

(3)                  收敛比不好控制：比如接入万兆，汇聚的话 40G，那么为了无收敛，核心至少100G，这个不好部署；

(4)                  通过VRRP/MSTP这样的技术虽然可以保证网络的可靠性，但是链路的利用率只有一半，CAPEX和OPEX高。

如上传统网络的诸多缺点，因此数据中心网络架构迫切需要改变，新一代的数据中心的网络架构的特点：

(1)                  扁平化的网络：尽可能简化网络的级数，最好能够二级的网络搞定；

(2)                  网络的去STP/VRRP化：从资源利用角度STP/VRRP的网络架构相对是很浪费的，因此目前的数据中心尽可能去STP/VRRP，像IRF/CSS/VSS/vPC等网络设备虚拟技术配合LACP/GR/BFD等协议既可以保证高可靠性，也可以保证网络带宽的利用率，而TRILL/SPB等大二层技术通过ECMP可以实现大二层的要求同时提高链路利用率；

(3)                  边缘网络的智能化：传统网络的边缘设备相对傻的，主要是提供服务器/PC机的接入功能而已，而当前的数据中心网络边缘越来越智能，而核心设备更加专注大流量的报文转发和流量工程控制，目前的边缘交换机（硬件交换机或者vSwitch）可以实现配合服务器虚拟化的EVB/802.1br等技术，可以支持FCOE/DCB等技术实现和FC存储网络的融合，可以实现隧道封装(TRILL/SPB/LISP的硬件交换机封装或者基于vSwitch的VXLAN/NVGRE/STT等软件层面的封装)。

4． 数据中心网络设备虚拟化技术

这里主要是网络设备自身的一些虚拟化技术（overlay的网络虚拟化放在SDN范畴）。

(1)                  网络N:1的虚拟化：这里头主要涉及的技术有H3C的IRF技术，思科的VSS以及VPC，华为的CSS，这些技术核心思想是将多台设备通过特定的级联口连接在一起，进行必要的配置后，虚拟化成一台“分布式设备”，典型的应用是通过跨设备的聚合(LACP)技术实现扩容和可靠性的保障.由于多台设备的虚拟，该技术可以实现相对大的二层（5000台服务器的二层是可以做到的）。

(2)                  网络设备1:N的虚拟化：可以实现将一台物理网络设备通过软件虚拟化成多台逻辑网络设备，这样做的好处是将不同的业务隔离，并且一个实例出现的问题（重启或者挂死）以及升级（比如打热补丁）都不影响另外一个实例的正常业务运行。主要是核心设备上用，具体的技术有H3C的MDC,思科的VDC以及华为的VS。

(3)                  服务器虚拟化的网络感知：这个勉强放在这里，主要是服务器虚拟化趋势需要网络对VM确保足够的监控，目前有IEEE标准的EVB/802.1br以及思科私有的VN-TAG等，通过边缘物理交换机或者vSwitch来对VM进行标示和转发。

5． 数据中心对网络性能要求

除了网络架构和协议上的改进外，数据中心网络的性能也需要有很大的提升，大容量，高吞吐量，大缓存以及大表项等等，主要从以下几方面说明：

(1)                  收敛比：对于通讯密集型的网络任何一级网络的上下行带宽尽可能接近1:1，这样没有收敛对于数据中心的高吞吐量是非常有必要的，同时减少网络阻塞。比如TOR接入设备接40台千兆服务器，如果上行2个万兆，那么就是1:2，如果是4个万兆，那么就是1:1无收敛。

(2)                  大表项：这里主要是涉及到共有云的弹性计算业务，比如一台物理服务器有20台虚拟机的话那么ARP/MAC表项的规模增大20倍，对于各级网络设备的表项容量是个考验；

(3)                  大缓存：对于Map-reduce业务涉及到的同时存在多个节点往一个节点打流 的情况，要求网络设备有足够的缓存，如果缓存太小的话很容易丢包，

需要的缓存大小：

Buffer=Burst*(1-1/N)      //N是收敛比

例如Map-reduce存在10台服务器打一台服务器的情况，收敛比是10，如果每台服务器瞬间突发1MB(1000个1KB字长的报文）的流量，在此期间堵塞口必须要有9MB的缓存来保证业务不丢包。10*1M*(1-1/10)=9M

(4)                  大容量，首先10GE接入在2013年的数据中心应该会逐渐普及，主要有几个原因：(a) 服务器虚拟化技术推动千兆到万兆演进；(b)数据中心的规模要求万兆接入满足大业务容量的要求；(c)随着SSD/CPU/内存的处理能力速度增强以及时延的降低，千兆网络成为瓶颈了；(d)任何一项事务的推出都是有市场规律在里面，随着交换芯片工艺的提升到28nm，万兆成本的价格逐步下降，以及10G-BAST-T的推出（成本更低），万兆普及就变成必然的事情了。  而随着万兆的接入普及，那么核心必然采用40GE，因此40GE的普及也是水到渠成的事，对于各个网络设备厂商大交换容量的竞赛已经展开，华为的12816的交换容量已经达到64T，再次刷新业界记录。

6． 数据中心的网络融合

目前计算和存储的网络是分开的，计算网主要是以太网（少量的有IB网络），而存储网络主要是FC的天下，由于FC网络自身的原因，网络发展非常慢，目前的主流还是4G/8G，而两种网络管理上麻烦以及成本高，早期的融合思路(IP-SAN)全部以太网化，但是这样还是比较激进，最终IP-SAN没有占市场多大的份额，而FCOE的思路比较好，保持现有的FC网络和存储设备，通过FCOE交换机将FC数据承载到以太网上，这样接入网络尽可能在一张网上，另外通过DCB(PFC/ETS/QCN)技术克服了以太网丢包的缺点，特别是随着万兆以太网接入的普及趋势，比较看好FCOE。

7． 数据中心大二层技术

大二层这个话题前一阵子在微博上争论的很激烈，核心的焦点在于到底需不需要大二层网络以及怎么样的场景下需要大二层网络？从个人的理解上看，大二层主要有两种应用场景：(a)虚拟机在很大的物理机集群范围内进行迁移；(b)终端节点在不同的区域漫游确保IP地址不变；

目前的数据中心网络的确大部份现网的网络是三层网络（TOR交换机直接是三层网关），这个和现在的业务模型关系比较大，当前大部分互联网公司，服务器虚拟化的规模不大（据说累计到2012年初，盛大网络只对外提供租用1万个虚拟机实例，阿里云稍多累计对外提供2万个虚拟机实例），虽然提供弹性计算会有虚拟机的迁移的需求，但是这部分网络可以是部分的2层网络（比如500～1000台物理机），需要迁移的话在这部分二层范围内迁移即可，的确不需要几万台物理机的大二层。因此大部分的网络不需要很大的二层，毕竟二层网络的广播风暴是网络架构师和运维工程师们很头疼的事情了。

但是个人认为大二层会是将来的一种趋势，有如下几个原因：

(1)                  公有云的大规模化：随着各大互联网公司的规模快速增长，腾讯的服务器超过30万台（继谷歌和亚马逊之后，全球第三），阿里百度规模也相当，这个数字还在快速增长中, 并且去年百度、腾讯以及阿里的天蝎计划共同制定机架以及数据中心基础设施的标准化，包括他们推出的自研交换机/服务器/存储等进一步降低成本，IT资源作为一种服务不再是概念了，会逐步在现实中落实，特别是对于成本很关注的中小企业而言更是会投向公有云服务，而云计算首先落实的应该是Iaas，只有Iaas发展起来之后Pass和Saas的规模化才有可能。 而Iaas比较典型的是应用是提供虚拟机服务（比如小公司的门户网站，移动互联的app服务器端，小公司的代码/编译环境服务器等），而规模一旦大起来后对于物理资源利用率以及运维可靠性等方面的考虑虚拟机会经常迁移，因此这样的网络可能需要大二层，二层足够大那么资源调度起来更加灵活，从云计算的角度来看是希望这样的。另外对于当前大量通讯密集型(典型的是hadoop分布式集群)支持的网络，比如hadoop目前都基于物理机来跑的，因此网络只要IP地址可达即可（一般是三层网络），但是目前也有人正在尝试将基于虚拟机来跑hadoop，只要hypervisor做得足够薄，这样对于计算资源利用更加的细化和充分。因此个人认为在2年左右，大二层会在公有云上逐步上商用。

(2)                  大型私有云的数据中心网络：其实有一些人对于数据中心网络是有一些误解的，认为数据中心就是腾讯、阿里以及百度这样大的互联网公司才有的，其实BAT这样的数据中心称为IDC，而更大量的数据中心是企业数据中心(EDC), 是这些企业才支撑起来很多大型网络设备商继续活下去的。比如近期微薄上提到的农行的数据中心，采购涉及144台华为的12800，个人估计该数据中心的规模至少10万台以上物理服务器的规模，和BAT这样大型互联网公司的数据中心在一个级别上，目前能源/金融等大型行业的下一代数据中心的正在规划，这些行业相比BAT这样的互联网在应用上比较大的差别在于他们用于计算密集群的应用相对少（hadoop这样的集群相对少一些），大部分的物理服务器上会跑虚拟机，以及虚拟桌面这样的应用在不少行业都已经有实际应用了，另外这些行业一般分很多不同的部门，每个部门自己要互通，部门间要隔离的要求，同时加上虚拟机迁移的需求，大二层的需求来了。举个例子算一下，比如一个大行业有100部门，每个部门2000个人，每台物理服务器跑10个虚拟机，通过虚拟桌面来运行，那么网络规划上100个部门要求100个vlan ID，每个部门2000个人要用200台物理机器，并且由于这些部门的人员坐得位置比较分散，同部门的虚拟机需要迁移，那么这个20000台物理服务器的网络是个大二层才能满足虚拟机的迁移需求的。

上面说了下对于大二层应用的个人理解，那么大二层有哪些技术? 这里只想简单提一下（详细的技术细节网上都有）。

(1)                  物理交换机实现的CT方案：a.数据中心内部：目前主要就是IETF标准TRILL以及IEEE标准SPB，还有思科私有的Fabricpath(据说软件升级可以和TRILL兼容)，b.数据中心间: 目前主要是一些私有的协议，MAC over IP封装，主要有H3C的EVI以及Cisco的OTV。

除了上面提到的外另Cisco还提出一种ip in ip的封装LISP，直接在边缘交换机通过ip in ip的隧道封装来满足虚拟机或者漫游终端的迁移。

(2)                  vSwitch实现的IT方案：主要有Cisco/Vmware主推的VXLAN(mac over udp), 微软主推的NVGRE(mac over ip)，以及nicira主推的STT。这里面看好VXLAN，是一种UDP的封装，内层的内容反馈到四层端口号上，这样目前的物理交换机可以根据四层端口号实现不同的流的负载均衡。

8． SDN

在提SDN之前我们将考虑目前网络遇到的几个问题：

(1)      当前物理三层网络多，后续的网络由于业务需求需要大二层网络，那么当前的三层物理网络如何满足需求？

(2)      数据中心（骨干网）的流量负载不均匀；

(3)      对于一家百货公司，公司平时的Web客户访问量少，到了年底促销期间客户访问量激增，需要动态租一些服务器资源，并且和客户自己现有的服务器资源要求在一个二层网络，需要二层跨广域网到运营商；

(4)      公有云数据中心的多租户的租户数量超过了4K；

(5)      公司的网络由于业务变化频繁需要更改网络的配置，有些网络设备特性无法支持，需要给网络厂家提需求，往往开发周期很长；

那我们先还是从SDN的概念开始吧，SDN(Software Defined Networking)理念

是让网络产业向软件产业靠拢，充分开放，让网络的创新就如同软件创新一样便捷、快速 。广义的SDN是满足控制转发分离、逻辑集中控制和开放API三个特征的新型网络架构和新的网络实现方法论，而不是某种具体的网络技术 。SDN的终极目标是物理网络成为一个基础平台（类似标准X86硬件平台）和资源池，而SDN基于物理网络这个资源池进行软件编程来实现客户不同的业务需求，按照业界通用的说法，SDN有三种类型（或者说通过三种不同的技术实现SDN）。

(1) Openflow: 其前身是斯坦福的用于企业集中安全控制的Ethane项目，2008年Nick Mckeown将其命名为OpenFlow， 经由斯坦福Clean State项目大力推广,目前已经发展到1.3版本，今年年初应该会发布1.4的版本。这种技术抛弃传统网络MAC/路由表，直接通过统一的流表实现转发，并且转发平面和控制平台分开，通过统一的控制器进行控制。Openflow目前比较重要的应用是可以实现负载均衡，谷歌的骨干网间的负载均衡在2012年初的时候已经商用，国内腾讯也宣布准备采用openflow来提高其骨干利用率。产品方面，HP/Cisco/NEC/Arista/Big Switch等均已经推出支持Openflow的交换机，另外开源的Open vSwitch也已经支持Openflow。

(2)                  基于虚拟化的overlay的隧道封装技术：在大二层也简单提到过的，这个技术主要是针对目前云计算部分场景要求的大二层和多租户需求，而当前的物理网络之前也提到过主要是三层的网络，那么当前的三层物理网络如何实现虚拟机迁移的要求呢？ 以思科和Vmware为首的提出了VXLAN技术，是在vSwitch上（比如N1000V）针对VM添加外层的UDP头，另外还扩展了24bit的tenent id（1600万），这样不同的租户通过物理交换机组播表项来转发，物理交换机对于这样的封装报文是不可见的。类似的技术还有微软的NVGRE，nicira的STT。 个人认为这样的技术首先会在大型的互联网公司上应用，大型的互联网公司后续的网络要求虚拟机的迁移，而当前的网络是个三层的物理网络，如果全部采用替换设备的话成本非常高，作为需要运营赚钱的OTT来说是不允许的，另外互联网公司的软件能力相对强（相比而言EDC行业的软件能力相对弱一些），他们自己玩交换机，自己玩开源的vSwitch和管理软件，这样比较容易通过overlay的虚拟化网络来满足他们自己业务需求。 而对于TRILL/SPB这样的大二层技术会先在EDC行业应用。

(3)                  私有的SDN：

一种是开放私有API接口，比如思科提供私有onePK API提供给用户进行灵活API编程是另外一个思路，SDN的本质是将网络资源化，客户既然有这样的要求那好我就将接口开放出来，比如客户要实现某种协议可以直接自己编程，调用厂家的标准接口进行设置转发表即可实现客户的需求；另外一种是控制平面的集中化，比如Juniper的QF，将控制集中在特定的私有控制器上，通过私有的协议来实现控制平面和转发平台的分离。

上述说明了目前的主流SDN技术，那么之前提到的几个问题看看是否可以解决?

(1)                  当前物理三层网络多，后续的网络由于业务需求需要大二层网络，那么当前的三层物理网络如何满足需求？—-overlay的虚拟网络

(2)                  数据中心（骨干网）的流量负载不均匀；——–openflow

(3)                  对于一家百货公司，公司平时的Web客户访问量少，到了年底促销期间客户访问量激增，需要动态租一些服务器资源，并且和客户自己现有的服务器资源要求在一个二层网络，需要二层跨广域网到运营商；—-overlay的虚拟网络

(4)                  公有云数据中心的多租户的租户数量超过了4K；—-overlay的虚拟网络

(5)                  公司的网络由于业务变化频繁需要更改网络的配置，有些网络设备特性无法支持，需要给网络厂家提需求，往往开发周期很长；——-私有SDN

注：本文的部分内容引用或者参考了 @kpang  @林仕鼎 两位业界牛人一些公开观点，特此表示感谢。

分享