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资源的水平扩展和滚动升级能力。总而言之,平衡了「新需求」和「老架构」之间的矛盾,可以满足数年的发展需求。未来,基础网络会继续紧跟技术发展潮流,为各公有云产品提供更稳定、更高效的底层网络。

转载于:https://blog.51cto.com/13832960/2363768

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

  1. 数据中心网络高可用架构

    文章不错,转来了 http://www.h3c.com.cn/Solution/Operational/DataCenter/Solutions/201003/802841_30004_0.htm 相 ...

  2. UCloud可用区的设计理念及功能图文详解

    导读 过去的几个月内,UCloud对自身的云计算基础架构进行了全面升级,于日前宣布基础架构全面支持地域和可用区,并将可用区项目命名为Sixshot.通过这两层的设计架构来组织云服务,可以为用户提供高可 ...

  3. 玩转ECS第6讲 | 弹性计算Region化部署和跨可用区容灾介绍

    简介:本次分享由阿里云弹性计算架构负责人李钟(谢顿)为大家介绍阿里云region化部署和跨可用区容灾的实践经验,说明多Region部署场景中使用阿里云弹性计算的最佳实践,并结合弹性计算的实践经验探讨如 ...

  4. 腾讯云Elasticsearch集群多可用区容灾实现原理及最佳实践

    导语 | 为了进一步满足腾讯云 Elasticsearch 客户对服务稳定性.集群高可用性等容灾能力的要求.腾讯云 ES 产品提供了跨可用区部署的解决方案,本文将为大家介绍实现原理与实践案例.文章作者 ...

  5. Redis如何实现多可用区?

    在如今的业务场景下,高可用性要求越来越高,核心业务跨可用区已然成为标配.腾讯云数据库高级工程师刘家文结合腾讯云数据库的内核实战经验,给大家分享Redis是如何实现多可用区,内容包含 Redis主从版. ...

  6. aws高可用mysql实现_Amazon RDS 的高可用性(多可用区) - Amazon Relational Database Service...

    Amazon RDS 的高可用性(多可用区) Amazon RDS 使用多可用区部署为数据库实例提供高可用性和故障转移支持.Amazon RDS 使用几种不同的技术来提供故障转移支持.用于 Maria ...

  7. 多可用区部署与只读副本

    Amazon RDS 多可用区部署对 Amazon RDS for MySQL.MariaDB 和 PostgreSQL 的只读副本进行了补充.虽然这两项功能均能保留数据的第二个副本,但两者有所不同: ...

  8. 云原生 - 负载均衡(SLB)多可用区

    在创建负载均衡实例时,您可以选择将负载均衡创建在支持多可用区的地域,提高服务的可用性. 什么是多可用区? 云产品的可用区指的是一套独立的基础设施,不同的可用区之间基础设施(网络,电力和空调等)相互独立 ...

  9. 关于阿里云香港Region可用区C服务中断事件的说明

    北京时间2022年12月18日,阿里云香港Region可用区C发生大规模服务中断事件.经过复盘,我们在这里向大家进一步说明故障情况.问题分析和改进措施. 处理过程 12月18日08:56,阿里云监控到 ...

  10. AWS RDS多可用区部署与只读副本的区别

    Amazon RDS 多可用区部署对 Amazon RDS for MySQL.MariaDB 和 PostgreSQL 的只读副本进行了补充.虽然这两项功能均能保留数据的第二个副本,但两者有所不同: ...

最新文章

  1. Android 弱网测试(小米手机切换3g和2g)
  2. 后处理程序文件大小的变量_【每日一题】(17题)面试官问:JS中事件流,事件处理程序,事件对象的理解?...
  3. 如何看待和评价浙江大学18级硕士研究生齐俏两年发14篇论文,获浙大最高层次奖学金?...
  4. 趣味程序之古典与经典问题系列
  5. Mac系统下安装Homebrew后无法使用brew命令
  6. random.next_Java Random next()方法与示例
  7. java字符串常量池——字符串==比较的一个误区
  8. MySQL 存储过程参数:in、out、inout
  9. 谈谈中兴捧月大赛决赛以及总结
  10. Vmware Workstation虚拟机规划
  11. jquery on()方法绑定多个选择器,多个事件
  12. java删除文件和文件夹
  13. python处理pdf 层_Python处理PDF及生成多层PDF
  14. 微信公众号开发:账号申请与接入
  15. MHL接口的静电保护方案
  16. WIN下静默安装MSI文件
  17. ie6, ie7兼容性问题以及处理办法汇总
  18. Unity发布内嵌网页的PC客户端
  19. 小鱼的航程(两种解决方法)
  20. (持续更新)Ubuntu22.04双系统的安装、扩容、重装及配置

热门文章

  1. java从字符串中提取数字的简单实例
  2. eclipse maven 导出项目依赖的jar包
  3. 优先队列/oriority queue 之最大优先队列的实现
  4. git学习笔记(2)
  5. VueJS 组件参数名命名方式和前台显示
  6. activemq部署
  7. ArcGIS Engine开发前基础知识(3)
  8. bzoj4093: [Usaco2013 Dec]Vacation Planning
  9. oracle一步一步01
  10. 薛家德(帮别人名字作诗)