中国 KubeCon + CloudNativeCon + Open Source Summit 虚拟大会

12 月 9 日至 10 日

https://www.lfasiallc.com/kubecon-cloudnativecon-open-source-summit-china/

标准票和免费票｜选定合适门票马上注册！

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

最近读到 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》（中文《云原生数据中心网络》）中有解答。我本来读的原版，可是没法理解书中一些英文网络词汇。最近中文版出版，正好找来对照着读一下，并记此笔记。

本书作者 Dinesh G. Dutt 是 VXLAN 协议的设计者，在网络行业有着多年丰富经验。

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

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

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

1. 单体应用

• 运行在大型机上

• 网络流量小，协议是私有的

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

• 工作站和 PC 兴起

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

3. Web 应用

• 随着计算能力不断提高，CPU 性能过剩，应用开始运行在虚拟机中，Windows 成为主流，Linux还不够成熟

• 千兆以太网成为企业网络互联标准

4. 微服务

• Google 分布式系统带来历史性转变，南北向（客户端和服务器之间）流量主导转变成东西向（服务器之间）流量主导。Linux 成熟，云的兴起，进入微服务和容器时代

• 万兆网成为主流，网络速度不断提高

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

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

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

1. 数据转发芯片的出现，这种硬件技术最初仅支持桥接

2. 企业专有的网络软件栈，除 IP 协议外还有别的协议

3. 交换网络零配置的承诺，路由网络相对桥接网络来说很难配置，而人为配置错误不是导致网络故障的第一大原因，就是第二大原因

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

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

1. 广播风暴和生成树协议（STP）的影响

2. 泛洪带来负担

3. 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. 不可预测性。许多组件会导致网络变得不可预测，增加故障定位难度

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

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

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

Clos 拓扑

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

上图中：

• spine 交换机。目的只有一个：连接不同的 leaf 交换机，计算节点永远不会连接到 spine 交换机

• leaf 交换机。服务器通过 leaf 交换机连接到网络，leaf 之间不直连，而是通过 spine 交换机互相连接

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

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

• 增加 spine 交换机扩展带宽

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

深入探讨 Clos 架构

Clos 架构还有以下特性：

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

2. 路由作为基本的互连模式

• 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 拓扑结构带来如下影响：

1. 重新思考故障和排错。交换机固定且单一，故障类型简单，可以直接替换故障交换机

2. 布线。Clos 拓扑需要管理大量线缆，可以使用线缆验证技术：PTM 或 Ansible 来验证线缆

3. 固定样式的交换机可以简化库存管理

4. 由于存在大量交换机，不再可能手动配置网络，网络自动化必不可少

Clos 拓扑的一些最佳实践：

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

• spine 交换机只用于连接 leaf 节点，额外的工作会使spine交换机收到超过预定流量份额的流量（保持简单是优势而不是劣势）

• spine 和 leaf 使用同样的盒式交换机，不要使用端口更多的框式交换机作为spine节点，原因：1、不好扩展成3层Clos；2、资产管理变得复杂；3、故障原因更复杂。

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

文章转载自多颗糖。点击这里阅读原文了解更多。

CNCF概况（幻灯片）

扫描二维码联系我们！

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。 

CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。