UCloud 可支撑单可用区 320,000 服务器的数据中心网络系统设计

2018 年 10 月份，UCloud 数据中心基础网络完成了 V4 新架构的落地，自此，新建的数据中心（下简称 DC ）全面升级到 25G/100G 网络，极大提升了 DC 容量和 DC 间互联的性能。V4 架构下的单可用区可提供 320,000 个服务器接入端口，是此前 V3 架构的 4 倍。并且支持无损网络特性，提供可用区资源的水平扩展和滚动升级能力。上线以来，新架构有力保障了 UCloud 福建 GPU 可用区开放、北京二可用区 B/C/D 扩容等需求。

对比云产品通过软件的灵活性来创造丰富的用户价值，公有云物理网络更注重规划的前瞻性与设计的合理性。其目标是简单、稳定、高效。通过对上层虚拟网络提供极度可靠的、一维寻址的逻辑连通面，来帮助实现上层产品“软件定义一切”的使命。下文就将详述我们秉承这种理念设计 DCN V4 架构的细节。

UCloud DCN V3 架构设计

UCloud 公有云以可用区（下简称 AZ ）为最小资源池单位对外提供服务，一个可用区由一个或多个数据中心组成。UCloud 数据中心基础网络架构（下简称 DCN ）在 2016 年升级到 V3 架构，如下图所示：

图：UCloud DCN V3 架构

V3 架构的设计目的：

全面升级到 10G 接入、40G 互连； 彻底拆掉了堆叠，避免了堆叠的种种弊端； 采用了两级 CLOS、Spine-Leaf 架构，实现了一定的水平扩展能力； 数据中心核心交换机为 Spine，提供标准的 BGP 路由接入，TOR/Border 为 Leaf ；业务服务器的网关落在 TOR Leaf 上； DC 的 Border Leaf 连接城域网 POP 机房，实现 DC 到 DC 外的互通，一个 DC 即一个可用区。 V3 解决了 V2 时代堆叠和 MC-LAG 的弊端，CLOS 架构有水平扩展能力，全网统一接入方式提升了网络部署效率。

V3 上线后，适逢 UCloud 发力建设海外节点，为首尔、东京、华盛顿、法兰克福等节点在短时间内的快速落地，提供了有效支撑。

V3 架构的新挑战

近两年，随着 UCloud 业务高速发展，以及 25G/100G 网络设备的成熟，业务对网络的性能提出了全新需求，V3 架构逐渐显示出一些不足之处，主要如下：

性能不足 分布式计算、实时大数据、NVMeoF 等的发展，要求网络提供更大的带宽和更低的时延，以及服务质量保证。

以 NVMeoF 为例，网络存储比起传统存储，在网络设备转发、传输、TCP/IP 协议栈上有额外开销。近来 RDMA 技术的成熟，极大降低了 TCP/IP 协议栈开销，提升了 IO 性能。但我们在实践中发现，V3 架构下的轻微拥塞，可能造成大量 RMDA 报文重传，占用相当带宽并造成业务性能下降，这种网络性能上的瓶颈需要突破。

容量不足 用户常希望在一个可用区有无限的资源可以扩容。V3 的两级 CLOS 架构水平扩容能力，最终受限于 Spine 设备端口数，一个 DC 网络大概能容纳的规模为一两万台服务器或一两千个机架。而一座机房可以有上万甚至上十万的机架，在 V3 架构下，需要做多个 DC 网络，DCN 之间通过 POP 互连互通，不但性能难以提升，而且成本巨大。

灵活性不足 全网统一接入方式，便于大规模上架布线部署工作，确确实实提高了效率，但同时带了灵活性下降。比如有的业务要求集群服务器二层可达，有的业务要求经典网络做 Overlay ……总之，整齐划一的网络规划不能满足所有主流的业务需求。

DCN V4 架构的设计与优化

为了解决上面的问题，2017 年底开始，团队对 DCN 架构进行重新设计、硬件选型和标准化，并于 2018 年 10 月份完成 DCN V4 整套方案并在新建数据中心落地，整体架构如下：

图：UCloud DCN V4 架构

新架构中，我们主要做了如下优化：

1. 硬件整体升级到 25G/100G 平台 2017 年底到 2018 年上半年，各商用交换机大厂的 25G/100G 网络设备逐渐成熟，25G/100G 光模块价格也趋于合理，同时 GPU、实时大数据、NVMeoF 等业务需求爆发，IO 瓶颈从服务器内部转移到了网络上。因此，我们开始着手将硬件从 10G 升级到 25G 平台。

我们从 2017 年底开始，对各主流交换机、光模块、光纤、服务器网卡厂商的主流 25G/100G 产品进行了选型、交叉测试、线上小批量，投入了 8 个月的时间，累计交叉测试超过 300 个产品组合，最终确定整套 25G/100G 硬件产品。

本月已上线的福建 GPU 可用区，利用此架构，同时支持 10G/25G 物理网络。25G 网络带来更高的集群运算效率，和普通可用区提供的 GPU 云主机相比，整体性能翻倍，这对 AI 训练这样看重绝对性能的场景非常重要。

图：GPU 物理云 10G/25G 网关集群

2. 3 级 CLOS 的设计

图：2 级 CLOS

CLOS 架构要求下一级设备需要跟上一级设备 full-mesh，因此在 V3 的 2 级 CLOS 架构下，Leaf 层的接入交换机（下简称 AS ）必须连接到所有 Spine 层的核心交换机（下简称 DS ），也就是 2 台 DS ；如果设计为 4 台 DS，那么 AS 就必须四上连到每一台 DS，复杂度直线上升。因此 DCN 整体容量取决于 DS 设备的总端口数，DS 设备的槽位数越多、单槽位端口密度越大，那么一个 DCN 可接入服务器容量就越大。

图：3 级 CLOS

V4 改用新的 3 级 CLOS 设计。Leaf 层的每一台汇聚交换机（下简称 CS ）需要上连到所有 Spine 层的 DS。比如一台典型的 CS 是 32 端口 100G 设备，16 口上连 DS，16 口下联 AS：

设计的 2 台 DS，1 台 CS 出 8 个口连到 DS1、8 个口连到 DS2，总共 16 个上连，每台 DS 消耗 8 个端口； 如果设计的是 4 台 DS，1 台 CS 的 16 个上连口分成 4 组，每组 4 个口分别上连到 DS1/2/3/4，每台 DS 消耗 4 个端口； 如果是 8 台 DS，那么 1 台 CS 只需要消耗 DS 的 2 个端口…… 可以看到，设计的 Spine 层的设备越多，每台 CS 需要 DS 的端口数越少，可以接入的 CS 数量就越多，在其他条件不变的情况下，整个 DCN 接入容量就越大。

我们通过 2 级 CLOS→3 级 CLOS 的架构变化，使得整个 DCN 的接入容量得以提升，理论上，随着硬件技术的发展，设计容量可以提升到无穷大。这就解决了 DCN 容量上的问题。按我们目前的设计，单 DC 容量最大可以提供 80,000 个服务器接入端口，单可用区可达到 320,000 个，是 DCN V3 时代的 4 倍，能满足 UCloud 所有地域未来几年平滑扩容的需要。

3. POD 的引入 2 级 CLOS 变为 3 级 CLOS 之后，多出了一个汇聚层，我们把一组汇聚交换机及其下连的接入交换机、以及接入交换机带的机架，总体称为一个 POD。单个 POD 提供一致的网络能力，包括：

一致的连接方式。一个 POD 里，所有 AS 到 CS 的连接方式是一样的，比如都是 1100G 单线互连或者都是 2100G ；所有服务器到 AS 的连接也是一致的，比如每台服务器 125G 连到 AS 或者 225G 连到 AS。 一致的网络特性。一个 POD 支持的网络特性是一样的，比如支持 ECMP、支持开启 QoS、支持直接接入到公网等。 这让我们可以根据业务对网络性能和特性的要求，针对性的开设 POD。

例如，当前的业务分区有公有云区、物理云区、托管云区、网关区、管理区、IPv6 区等，其中公有云区、网关区、管理区、IPv6 区对基础网络的要求基本一致，在新的 POD 设计思路下，均合并为“内网 POD ”。而大数据区、云存储区等网络 IO 极高的业务，则设置了“高性能内网 POD ”，具有每台服务器 2*25G 全线速接入的网络能力, 提供 QoS 和无损网络特性。此外，还有“综合 POD ”应对要求公网 /其他特殊网络需求的服务器接入，“混合云 POD ”提供裸金属或用户私有云接入等，满足不同的业务需求，来解决灵活性问题。

总的来说，POD 是按照网络能力设计的，满足不同业务的需求，且能避免成本浪费，控制 CAPEX，并避免按业务分区导致过多的网络分区，控制维护的复杂度。

4. DC Group UCloud 公有云资源池分为“地域”（一般是一个地理上的城市）和“可用区”（简称 AZ，两个可用区一般距离 10km 以上，基础设施隔离）两级。

一个 AZ 可以包含多个 DC，但实际上，由于 V3 架构下 DC 都是连接到 POP、与其他 DC 互通，这就需要拉光缆、架设波分，带来带宽瓶颈和时延上升。所以即使两个 DC 距离非常近，作为一个 AZ 资源池也不合适，作为两个 AZ 则与 AZ 的距离要求相悖、也不合适。

图：DC Group 产生前后对比

V4 架构提出了「 DC Group 」概念，将地理位置相近的 DC 间 full-mesh 连接起来，作为同一个 AZ 对外提供服务。带来的好处有：

网络时延低。DC Group 内的 DC 之间距离非常近，通常不超过 10km，由此带来的时延在 0.1ms 以内； 增加冗余度和带宽。由于 DC 之间距离近，光缆成本也低，我们可以增加更多的光缆连接，一方面保证足够的冗余度，另一方面增加足够的带宽； 可滚动升级。可以通过新建新一代 DC 的方式，满足新业务在原 AZ 里上线的要求，且对运行中的 DC 基本无影响。 例如，前段时间我们发布了高性能 SSD 云盘产品。在业务部署阶段，恰逢北京二可用区 D 的空闲机柜不多，如果等申请到新机柜再部署，就浪费了宝贵的时间。而如果只把产品部署在新开的可用区，就无法照顾原可用区用户的需要。

这个矛盾在 DC Group 架构下，就可以通过添加新 DC 得到良好解决。

总结

UCloud 总体网络设计中，基础网络的目标是「稳定」和「高效」。基础网络通过组织物理线路、经典网络设备和网络技术，形成了一张稳定而且高性能的网络底层，为上层业务提供 IP 连通性。基础网络下承机房基础设施、上接业务，需要解决「业务需求变化快」和「基础网络升级难」这一对永恒的矛盾。DCN 数据中心网络是基础网络最重要的一个组成部分。

图：UCloud 总体网络设计

我们过去一年所重新设计的 DCN V4 架构，令新建的 DC 全面升级到 25G/100G、支持无损网络特性、提升了 DC 容量和 DC 间的性能、提供了 AZ 资源的水平扩展和滚动升级能力。总而言之，平衡了「新需求」和「老架构」之间的矛盾，可以满足数年的发展需求。未来，基础网络会继续紧跟技术发展潮流，为各公有云产品提供更稳定、更高效的底层网络。