如何建设一个云原生数据中心的网络？_云计算

如何建设一个云原生数据中心的网络？

干我们这行免不了要阅读大量资料，但这个行业又存在大量细分的领域，我们的时间是有限的，现代人能投入读书的时间更是少之又少，一个问题是我们到底应该深入阅读还是广泛阅读?

最近读到 Shopify 某个开发团队前负责人 Simon Eskildsen 的采访[1]。Simon Eskildsen 只是一个高中生，却在 gap year 加入创业期的 Shopify 并跟随公司一同成长为技术管理者。没有任何学位的他表示，自己是靠着大量阅读来学习计算机和管理的知识。Simon Eskildsen 在采访中提到自己努力成为T 型人才：在一个领域深入，但在多个领域有广博的知识面。

之前的文章中，我们聊过分布式计算、存储、协调等主题，唯独网络方面没有谈过。在《SRE：Google运维解密》中有一句令我影响深刻的话：“UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。”

本身我的网络知识也比较薄弱，恰好最近工作设计一些网络架构相关的知识，于是从10月开始我停了下来，开始阅读一些现代数据中心网络架构的知识。读者可以和我一起思考，如果新的数据中心网络架构让你来设计，你会怎么做?

这在 O'REILLY 的新书《Cloud Native Data Center Networking》(中文《云原生数据中心网络》)中有解答。我本来读的原版，可是没法理解书中一些英文网络词汇。最近中文版出版，正好找来对照着读一下，并记此笔记。

为什么需要一个新的网络架构

如果应用一层不变，那我们就没有必要进行讨论了。我们谈云原生数据中心网络，那这个架构就是要为现代云原生应用而设计的。所以，现代云原生应用有什么特点?

书中提到，“应用-网络”架构的演进经历了如下图的四个阶段。

如何建设一个云原生数据中心的网络？

1.单体应用

运行在大型机上
网络流量小，协议是私有的

2.客户端-服务器(C/S)架构

工作站和 PC 兴起
LAN 开始崛起，网络流量增加，以太网、Token Ring 和 FDDI 是最流行的连接，速度最高为 100Mbps。最后，以太网和 TCP/IP 赢了

3.Web 应用

随着计算能力不断提高，CPU 性能过剩，应用开始运行在虚拟机中，Windows 成为主流，Linux还不够成熟
千兆以太网成为企业网络互联标准

4.微服务

Google 分布式系统带来历史性转变，南北向(客户端和服务器之间)流量主导转变成东西向(服务器之间)流量主导。Linux 成熟，云的兴起，进入微服务和容器时代
万兆网成为主流，网络速度不断提高

可见，分布式应用发生巨变，网络被打了个措手不及。传统网络为什么“跟不上节奏”?

如何建设一个云原生数据中心的网络？

上图是传统网络，这种网络设计被称为“接入-汇聚-核心(access-aggregation-core)”架构。计算机连接到接入交换机，之上是一对分布式的汇聚交换机，汇聚交换机连接到核心网络，从而使接入层连接到外网。

“接入-汇聚-核心”网络严重依赖于桥接(Bridging)技术，原因有三：

数据转发芯片的出现，这种硬件技术最初仅支持桥接
企业专有的网络软件栈，除 IP 协议外还有别的协议
交换网络零配置的承诺，路由网络相对桥接网络来说很难配置，而人为配置错误不是导致网络故障的第一大原因，就是第二大原因

路由和桥接的区别：桥接工作在 OSI 网络模型第二层即链路层，交换机或网桥根据 MAC 地址来交换数据，链路层交换的是数据帧(frame)。路由工作在 OSI 第三层即网络层，路由器根据 IP 地址来找到目标地址，网络层交换的是数据包。

尽管传统网络取得很大成功，但桥接网络依然有以下限制：

广播风暴和生成树协议(STP)的影响
泛洪带来负担
IP 层的冗余设计，为了使汇聚交换机高可用，需要支持两台交换机使用同一个IP地址，但同一时间只有一台路由器支持，为此又发明了 FHRP 协议来支持。

在转发网络中，每个数据包都携带两个 MAC 地址：源地址和目标地址。网桥会在自身的 MAC 地址表中查找目标 MAC 地址。如果不知道，它将数据包发送到除接收数据包的接口以外的所有其他接口。当网桥在自身的 MAC 地址表中找不到待转发数据包的目的 MAC 地址，而向所有端口发送该数据包的行为称为泛洪(flooding)。

“接入-汇聚-核心”很适合客户端-服务器应用架构这种南北向流量为主的模式，如今服务器-服务器架构越来越多，应用规模显著变大，“接入-汇聚-核心”存在以下问题：

1.不可扩展性

泛洪(Flooding)不可避免
VLAN 最多为 4096 个的限制
ARP 的负担，汇聚交换机需要应答大量ARP，导致CPU过高
交换机和STP的局限。理论上增加汇聚交换机能够提升东西向带宽，但是STP不支持两个以上的汇聚交换机

2.复杂性。桥接网络需要很多协议支持：STP、FHRP、链路失效侦测、供应商私有协议(如 VTP)

3.失效域(Failure Domain)。容易发生粗粒度的失效，比如：单个链路的失效造成带宽减半

4.不可预测性。许多组件会导致网络变得不可预测，增加故障定位难度

缺乏敏捷。云计算领域，不停地有租户使用资源或销毁资源，而 VLAN 需要网络中每个节点都正确配置了 VLAN 信息才能正常工作，添加或移除 VLAN 是一个费时费力的过程。

桥接技术的支持者没有放弃，针对这些问题提出了许多解决方案，但在当代企业数据中心少有使用。

云原生数据中心基础设施想建立一个可大规模扩展的网络架构，Clos 就是这个架构。

Clos 拓扑

Clos 拓扑结构以其发明者 Charles Clos 命名，如下图所示，该拓扑也称为 leaf-spine 拓扑(或 spine-leaf 架构)。

如何建设一个云原生数据中心的网络？

上图中：

spine 交换机。目的只有一个：连接不同的 leaf 交换机，计算节点永远不会连接到 spine 交换机
leaf 交换机。服务器通过 leaf 交换机连接到网络，leaf 之间不直连，而是通过 spine 交换机互相连接

Clos 拓扑在任何两台服务器之间都有两条以上的路径，产生了一个高容量网络支持东西向流量。对比传统网络，Clos 架构还有着很好的水平扩展性：

增加 leaf 交换机和服务器来扩展系统容量
增加 spine 交换机扩展带宽

而“接入-汇聚-核心”只能换成性能更强的汇聚交换机来进行垂直扩展。

深入探讨 Clos 架构

1.Clos 架构还有以下特性：

2.leaf、spine 可以使用同类、较小的交换机来构建网络

路由作为基本的互连模式

Clos 不使用STP，只在单个机架内直接支持桥接，跨机架桥接使用更现代的网络虚拟化解决方案(例如VXLAN)

3.Clos 收敛比

1:1 收敛比的网络也称为非阻塞网络，即上行链路带宽等于下行链路带宽。如果 spine 和 leaf 都是 n 口交换机，1:1 收敛比的 Clos 拓扑可连接的最大服务器数量为 n^2/2

4.链路速率

如果交换机链路使用比服务器链路更高的速率，则可以用更少的 spine 交换机来支持相同的收敛比

5.一些现实的限制

受到制冷、机柜、散热、服务器摆放等限制，以上理论并不能原封不动落实到数据中心，单个机柜一般是20或40台服务器。导致spine端口数量较多而leaf端口数量较少，设备厂商一般会提供不同的spine和leaf交换机

6.细粒度失效域

如果有两个以上的 spine 交换机，单个链路故障不会带来灾难
leaf 到 spine 的一条链路故障，其余部分仍可以继续使用全部带宽，故障影响范围尽可能小
系统性的控制平面故障可能会影响整个网络，但不会出现”接入-汇聚-核心“网络中系统性故障(如广播风暴)

扩展 Clos 架构

如果你想要构建一个支持数万或数十万台服务器的超大数据中心，还要拓展出三层 Clos 拓扑，如下图所示，有两种扩展方法：

虚拟机箱模型(Facebook)，对应上图(b)
pod 模型(Microsoft、Amazon)，对应上图(c)

拓展后的三层 Clos 拓扑最上层交换机称为“超级 spine 交换机”。

如何建设一个云原生数据中心的网络？

两种模型的优缺点对比：

考虑应用与网络模型匹配：
- 虚拟机箱模型均为5跳，适合运行单个应用，故 Facebook 采用此模型;
- pod模型同一pod平均3跳，而到其他pod为5跳，适合提供云服务，故Microsoft 和 Amazon 采用模型;
考虑数据中心扩建，对于给定的容量两种模型所需交换机数量相同，但：
虚拟机箱模型上两层交换机数量必须满足收敛比，还要提供足够的 leaf 交换机
pod 模型如果开始流量都在 pod 内部，可以先只部署较少的超级 spine 交换机

Clos 拓扑的影响和优秀实践

Clos 拓扑结构带来如下影响：

重新思考故障和排错。交换机固定且单一，故障类型简单，可以直接替换故障交换机
布线。Clos 拓扑需要管理大量线缆，可以使用线缆验证技术：PTM 或 Ansible 来验证线缆
固定样式的交换机可以简化库存管理
由于存在大量交换机，不再可能手动配置网络，网络自动化必不可少

Clos 拓扑的一些优秀实践：

保持 spine-leaf 单链路，不要使用多个链路增加带宽，而是添加更多 spine 或 leaf 来增加带宽(例如：多个链路可能会导致 BGP 出错)

如何建设一个云原生数据中心的网络？

spine 交换机只用于连接 leaf 节点，额外的工作会使spine交换机收到超过预定流量份额的流量(保持简单是优势而不是劣势)
spine 和 leaf 使用同样的盒式交换机，不要使用端口更多的框式交换机作为spine节点，原因：1、不好扩展成3层Clos;2、资产管理变得复杂;3、故障原因更复杂。

书中提到，LinkedIn 和 Dropbox 就后悔使用不一致的交换机。

原文链接：https://mp.weixin.qq.com/s/dCmv0SdXB-ZB1Ned9tYh4A