读RFC一般是很无聊的事情，但是偶尔也让我兴趣盎然，比如2016年的RFC7938。这篇RFC给我的感觉更像一篇介绍如何设计大规模数据中心的指南，非常浅显易懂，不像我们曾经读过的传统协议定义的RFC。本文以阅读笔记的形式，按照我对此文和相关技术理解，和大家一起学习RFC7938原文。

 

当我2014年从国内集成商离职来欧洲留学的时候，国内的传统企业网数据中心还是以二层（传统Vlan）为主，Overlay的协议如Vxlan, Trill刚刚开始兴起。但是随着移动互联网兴起，大数据，BI, AI的热潮，数据中心和传统设计也面临挑战和转变。

 

接受过网络体系学习的网工可能都能说出路由协议分为IGP,EGP, IGP用于域内互联，EGP用于不同的自治系统之间连接这样来自圣经(TCP/IP 卷1卷2)的理论。传统的网络用自治域划分区域，内部IGP自治，外部BGP（属于EGP）跨域互通。

 

那么Facebook为何选择只使用BGP构建数据中心，结合顺着这篇RFC的思路，让我们一起学习。最重要的是需求分析和设计方法，因为这种设计并不是适用于所有的数据中心。

 

赏心悦目的设计，5级CLOS架构（图片来源于Facebook)

 

这篇文章主要就是针对对大规模数据中心，或者是下一代数据中心还没有认识或者感兴趣的网工和企业。同时我因为离开一线已经4年，也不是开发出生，可能看事情和解读的角度会和一些兄弟有些不一样。

 

一、Network Design Requirements

 

首先我们先看大规模网络数据中心的新需求，对于一个大规模数据中心，如何应对扩张（scale up）肯定是核心主题，有那些需要关注的地方呢：

 

Bandwidth and Traffic Patterns （带宽和流量模型）

 

传统数据中心内，以南北向流量为主。什么是南北向流量，就是从数据中心外的一个host访问数据中心内server的流量，最简单的例子就是打开一个网页。但随着大数据的发展，越来越多的大规模数据中心内的主要流量模型从南北向变为了东西向。大量的数据不再是从数据中心出去，而是在数据中心内部流通。

 

东西向流量最好的例子就是HADOOP，大量的数据在服务器集群之间流通或者是虚拟机迁移的需求。

 

CAPEX Minimization （减少资本性支出）

 

减少网络组件的CAPEX途径，作者提出两点：

 

1、统一网络中组件的硬件软件，通过大宗采购相同的网络设备减少运维成本，拿到好的折扣；

 

2、使用不同的网络设备，通过厂商之间的竞争减少支出。

 

如果使用第二种方法，那么对于一个数据中心设计来说，就必须是需要的软件feature最少、最通用，比如不能使用厂家特定的协议如EIGRP，通过使用公有协议来提高网络设备选型的灵活度。

 

OPEX Minimization （减少运营成本）

 

大规模数据中心的运维成本无疑是很大的。如何减少这项开支呢，作者给出的答案，也很显而易见：简化设计。

 

通过精简failure domain（故障域）的大小来达到这项目的。举个例子，以太网（Ethernet）中广播风暴会对广播域内的设备的性能和可用性都有影响，那么用路由协议隔离广播域就是有效的精简Failure domain的手段。（但是使用路由协议又引入了新的控制平面的故障。）

 

还有其他的手段比如说，使用相同协议，相同版本的软件来减少对运维人员的培训成本，和测试成本。

 

Traffic Engineering （流量工程）

 

传统网络中，负载均衡（Load-balancer）作为专用设备，在南北向流量的转发路径上，当网络流量升级的时候，就需要扩展更多的负载均衡设备。我们通过更好的TE设计，比如通过anycast实现流量分担而不需要借助专用设备。

 

这里举个例子，对anycast（任播）没有概念的同学可以理解一下，可能不太恰当和准确。比如某网站首页，需要应对大量的访问请求。我们可以在网络中部署有同样IP(anycast)的多台运行同样应用的服务器，使用anycast+BGP宣告到网络中，当edge路由发现有访问请求时，会从这些有着同样anycast IP但是不同下一跳的服务器中选一个离源最近的服务器让用户访问，从而分担流量。同时anycast的方案也可以提供冗余的服务。

 

通过以上章节，我们总结出5点设计大规模数据中心的需求：

 

1.选择一个拓扑可以通过“横向”扩展节点而不需要升级现有设备；

 

2.选择一个“狭窄”的协议组来提高可供选择的网络设备厂家/软件；

 

3.选择一个“简单”的路由协议；

 

4.减小故障域；

 

5.流量工程设计，尽量不要借助专用设备。

 

以上5点是后续章节所讨论的基础，也是大规模数据中心和一般网络数据中心的区别，下文的设计和逻辑均是为了满足以上5点需求的数据中心。

 

二、网络拓扑

 

传统数据中心拓扑

 

传统数据中心的树形三层冗余结构的可扩展性非常差。核心-汇聚-接入层的网络需要进行扩展时必定需要更大量的线卡和交换矩阵。以一台9槽位数据中心交换机来说，如果说除去引擎还有7个槽位，每个槽位提供48个口的接入能力来说的话，双核心（冗余链路接入）的最大接入能力就是336个汇聚设备接入。有限的接入能力注定了三层的树形结构的扩张能力是有制约的。

 

CLOS结构(Spine/Leaf)

 

搞交换的同学对CLOS（有翻译为多级交换网）和CrossBar（单集交换网）可能都不会陌生，如果不熟悉的同学可以google/baidu一下。下面有图可以非常容易理解一下。

 

CLOS的应用有很多种，有时候CLOS也被称作为Fat-Tree（胖树）。关于与三层结构的对比，数学计算，超比分等等其他问题，在这里不再赘述因为网上有很多介绍。这里着重归纳一下我自己理解的CLOS对于大规模数据中心的好处。

 

1.满足上一章的需求1，水平扩展，并且有利于需求2的选择（因为功能层减少）。

 

2.服务器到服务器（东西向流量）的流量可以用ECMP负载均衡，因为每个服务器到其他服务器的跳数是等价的，并且相比较于传统三层树形结构，跳数减少了，只需要leaf-spine-leaf

 

3.可以用5级CLOS架构扩展多个pods（使用Edge switch连接多个pods)

 

因为现在所有厂商在数据中心都在推荐这种方案，在这里就不展开讨论CLOS的其他好处和扩展（5级CLOS,如前文Facebook数据中心图所示）了，放一张图体会一下就很一幕了然。

 

图片来源于Facebook

三、路由概述

 

纯二层设计

 

最传统的网络数据中心，当然是用以STP为主的防环拓扑。当然受那个时候的制约，很多数据中心交换机要么不支持3层协议，要么需要额外的license。尽管各种增强型的STP被开发和用在纯二层网络中，STP协议本身还是制约了网络的规模扩张（需求1）和造成更大的故障域（需求4）

 

当然，这里需要说M-LAG（跨机箱链路聚合）和TRILL（多链路透明互联）等技术的出现让纯二层数据中心得以维持和扩展。基本上可以说解决了STP里的很多问题，能使用多路径转发并提高了收敛时间等，但是，如果你拉到上面，你就会发现使用TRILL就和需求2，需求3，需求4都有冲突，原因也在之前的需求分析里说了。

 

混合二/三层设计

 

不讨论了，在核心或者核心加汇聚启用三层协议，类似于二层设计，对于之前的需求分析来说，二层/三层一起用违背了需求2（没错！这都违背了他们的需求2），和需求4.

 

纯三层设计

 

首先，区别于混合二/三层设计，接入层（leaf/access）运行三层协议和汇聚（Spine)互联。这种设计首先满足了需求1和2，然后简化了网络（？看你怎么解读简化了）。作者在这里一笔带过了对于二层通信的需求（虚机迁移等应用），提到网络的可靠性和稳定性才是最重要的，因为现在有各种隧道技术和之前提到的anycast来克服。

 

反正，以上的内容都是为了引入后面的重点内容，为何以及如何使用eBGP构建纯IP Fabirc的大规模网络数据中心。

 

总结：我觉得到目前为止，作者的需求分析和引导确实是值得一读和回味，然后有些过度稍有牵强（但是如果从Facebook的出发点去理解就会好很多，下回再说）。不过因为没有完美的网络设计，只有最合适的设计，所以一切从需求出发，分析好需求，那么很多问题都能引刃而解。不过我觉得这种切入点十分适合抱有如下疑问的人开始接触如何只使用BGP构建数据中心网络：

 

1. BGP不是用在广域网上的么？ASN怎么办？

 

2. BGP收敛速度不是更慢么？

 

3. 用三层协议，IGP（OSPF)不是配置更简单么？

 

4. BGP都不能自动发现邻居，还得手工配。

 

5. 纯3层？没有二层？

 

这些问题都会在之后的章节解答。