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

标签：针对   私有   需求   机房   矛盾   交叉测试   特性   实践   gpu   

对比云产品通过软件的灵活性来创造丰富的用户价值，公有云物理网络更注重规划的前瞻性与设计的合理性。其目标是简单、稳定、高效。通过对上层虚拟网络提供极度可靠的、一维寻址的逻辑连通面，来帮助实现上层产品“软件定义一切”的使命。下文就将详述我们秉承这种理念设计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资源的水平扩展和滚动升级能力。总而言之，平衡了「新需求」和「老架构」之间的矛盾，可以满足数年的发展需求。未来，基础网络会继续紧跟技术发展潮流，为各公有云产品提供更稳定、更高效的底层网络。

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

标签：针对   私有   需求   机房   矛盾   交叉测试   特性   实践   gpu   

原文地址：https://blog.51cto.com/13832960/2363768