共计 5877 个字符，预计需要花费 15 分钟才能阅读完成。
摘要：如何设计一个可包容万台服务器的数据中心网络?UCloud 优刻得设计了一款数据中心网络建设零碎 —— Big Bang，实现低成本适配不同版本架构迭代、不同规模机房的小时级疾速部署指标。目前，曾经反对乌兰察布大规模数据中心网络建设开局，也为海内外多个机房的疾速、高质量交付提供技术支持。
从零建设一个可包容万台服务器的数据中心网络须要多久?
类比“要把大象装冰箱，总共分几步?”，从零开局一个数据中心，将网络从建设到交付的过程更像“垦荒”。传统依赖工程师人工编写繁琐的网络设备命令费时又费劲，且交期与品质均无奈失去保障。
为此咱们设计了一款数据中心网络建设零碎 —— Big Bang，将数据中心网络开局这一工作切分为“架构布局”–“资源分配”–“配置生成及下发”三个步骤。每一步之间耦合涣散而外部又高度内聚，实现低成本适配不同版本架构迭代、不同规模机房的小时级疾速部署指标。
Big Bang 上线后反对了自建的乌兰察布大规模数据中心网络建设开局，至今已实现海内外多个机房的疾速、高质量交付。
The Big Bang Theory : 宇宙是由一个致密火热的奇点于一次大爆炸后收缩造成的。
1. 上一代建设零碎的有余
在 Big Bang 之前 UCloud 优刻得物理网络团队已有一代数据中心建设零碎，随着业务和架构的演进，上一代零碎的一些毛病逐步裸露进去 :
对多立体的 Fabric 数据中心网络反对不够灵便
架构规定形容不灵便，网络设计版本迭代后须要再次投入大量研发人力适配，且存在须要研发了解网络业务设计的强耦合问题
原子命令库形式组织的配置模板不直观，人工难以预测其生成的配置，导致保护老本过高，且批改后无测试，容易出错
在建设海内机房时，因为网络提早过高，基于编排器的配置下发形式呈现了失败率疾速攀升的问题
通过对上述挑战和毛病的剖析不难得出推论，咱们须要这样一款建设零碎工具 :
灵便适配多版本、多状态、多立体的数据中心网络
网络架构迭代不应需研发同学染指
能够直观的批改配置模板，批改后能够自动化的低成本的进行测试
低网络依赖，弱网条件下仍然能好用
2．Big Bang 设计概要
2.1 人肉运维之痛
在谈设计之前，咱们先来谈一下人工建设一个数据中心会遇到哪些挑战?
考查一个简略的两级 CLOS 架构 : 4 个 Spine，32 个 Leaf 共 36 台设施形成一个业务专区，这在 UCloud 优刻得数据中心中是很常见的 POD 规模。
建设这样一个网络，首先须要给出设施接线表交由现场的同学进行布线。这张接线表要表白“spine01.p1 接 leaf01.p49，应用 QSFP28 100G 线缆”这样的信息。对于这个 POD 便产生了 4 * 32 = 128 个互联关系。
给出布线规定后，咱们再来思考 IP 调配的问题。
图中每一条线均须要一对互联地址，除此之外设施还须要调配治理地址、业务地址等。一个 POD 便须要 128 个互联网段、32 个业务网段、几十个治理地址。这些地址都须要工程师到 IP 管理系统中占用，并与设施 (互联关系) 一一对应。
能够看到，在 CLOS 架构下进行的互联计算、资源分配工作十分简约，并且数量会随着网元数量、接口数量的减少而急剧减少。
除此之外，还有一些要求会使这些挑战变得更加简单：局部角色指定接线规定，如何调配端口? 跨机房设备的线缆 / 模块如何选取对应物料?
至此只解决了“互联”和“资源”的问题，接下来考查理论的配置。
有些配置是所有角色共有的，如生成树配置、AAA 配置等。而有些配置又会依据设施角色的不同而有所辨别，如 DSCP 标记、三层接口等。
而当引入了多设施厂商的问题后，状况会变得更简单：接口名是 100GE 还是 HundredGigabitEthernet ? slot/interface/index 是从 0 开始还是 1 开始? 去使能某个性能的关键字是用 undo 还是 no ?
建设团队的工程师会保护多角色、多厂商配置模版文件，个别以 Excel / 文本文件的模式出现。对某一特定设施开局时须要跳转多个文件，进行一直的 copy /paste 来实现一个设施的配置编写。
如此，实现一个几百台网络设备的数据中心网络开局，可能须要 1 – 2 集体 / 周投入，这显然不能满足业务疾速扩大的需要。
2.2 Automate or die
不难发现，整个开局过程中有大量简约的计算和操作工作，诸如：
繁冗的接线调配、IP 地址调配工作
反复的配置文件的翻译工作
服务于架构角色的配置辨别
人进行这些简约的工作效率很低且容易出错，而这正是程序善于的。
2.3 零碎分层设计
回到之前的问题：就像要把大象塞冰箱，建设一个新的数据中心网络总共分几步?
对整个建设的故事进行考查和考虑，咱们将这个“万丈高楼平地起”的过程形象为如下三个过程，对应大爆炸零碎的三个组件 :
1. 布局 – 架构布局库
相似《GB 50017-2017 钢结构设计标准》，这是一个形象的施行标准
如 UCloud 优刻得可撑持单可用区 320，000 服务器的数据中心网络系统设计
2. 调配 – 资源分配器
相似有建设需要后，拿到了一块地开始计算须要哪些物料，调配各项资源
调配各种资源，并形象的生成连贯图
3. 建设 – 配置生成及刷入
相似拿着图纸进行施工，直到把楼盖好交付生成出所有设施的配置文件，刷入设施中
这样做的益处 :
- 耦合涣散，每一个模块只实现一个或几个性能，彼此通过结构化的信息进行流转，彼此屏蔽了外部细节。
- 当其中的一小部分发生变化时，只须要批改发生变化的局部。如机房现场须要更换接线表的格局，只须要公布一个新版的资源分配器，上下游不须要感知资源分配器产生了变动。
3．架构布局库
如果须要程序来帮忙咱们的计算须要的设施、互联图、IP 段等信息，首先须要思考的是:“应该如何形象的表白一个架构?”
先退一步，咱们应该如何形容一个机房的拓扑?
这要求咱们形容一个图构造 :
点：有哪些设施
线：设施物理上是怎么互联的
点及线的属性：IP
基于此，咱们再进行一次形象，把具体每个设施的形象为角色，把具体的 IP 变为可调配的 IP 段。而后失去咱们须要形容的内容：
有哪些角色(设施)
有哪些 IP 段可供调配
角色之间是如何互联的
角色自身 (如 loopback 口) 要应用哪些 IP 段
互联要应用哪些 IP 段
这五个信息点。
因为：
一个较小的 IP 段必定是由一个更大的 IP 段拆分而来，分进去的子 IP 段有关联。
咱们须要多个角色通力合作能力连同网络，角色之间有关联。
基于下面这些假如，咱们能够形象出两颗树 ———— 设施树和 IP 段树，这二棵树各自扇出(fan out)，最初在叶子节点上建设关联。
至此，咱们曾经表白了
有哪些角色
有哪些 IP 段
角色自身 (如 loopback 口) 要应用哪些 IP 段
这三个信息点。
还剩下：
角色之间是如何互联的
角色之间的互联要应用哪个 IP 段
这两个信息点。
在数据中心网络演进到多立体的 Fabric 网络后，互联关系的品种出现指数级回升。如何精确、易了解、低成本、低耦合的形容这些互联关系成为了摆在咱们背后的微小难题。
咱们想到的第一个计划：预约义套餐，即事后定义出所有可选的互联计划。将这些逻辑固化到代码中去。如：笛卡尔积式互联，距离互联，穿插互联等等。
咱们迅速否决了这个计划，因为：
极高的了解老本：工程师很难从名字和形容等处取得足够的信息，须要配套大量的文档，相当于回退到了文档形容的时代。
极高的研发老本：每当新加一种互联类型，都须要大量研发资源投入适配，也须要研发同学深刻的了解每种互联计划，再加上每种互联计划有大量的可调参数，如距离互联可调距离数量等等。
重大的跨模块耦合：当架构布局信息在“”架构布局库“和“资源分配器”之间传递时，须要为每个互联方案设计一种数据结构，相当于要求「架构布局库」和「资源分配器」都须要齐全了解每一种互联计划。
咱们从 tcpdump 工具中失去启发，当要形容特定畛域内的简单逻辑的时，能够尝试设计一种 畛域特定语言 (DSL) 来解决。咱们设计了一种形容互联的 DSL —— UCLOUD DC CONNECT LANG。语言短小精悍，阐明文档约一页，形容一种互联关系只须要 10 个左右的字符，实际中，新员工只须要大概 1 天就能够了解这个语言，这个计划齐全解决了预约义套餐产生的问题：
极低的了解和保护老本：只有了解了这个语言，就了解了所有的互联计划。
极低的研发老本：只须要实现了这个语言的逻辑，就能够笼罩所有的互联计划。所以，“资源分配器”只须要实现一次语言逻辑，一生免保护。
极低的耦合：架构布局库间接向资源分配器按 string 传递 DSL 原文即可，不再须要多种数据结构。
回到之前的“两棵树”上，给角色之间补充上互联信息和互联须要应用哪些 IP 地址段的信息。
至此，咱们通过两棵树和一个三角形曾经残缺的表白了之前提到的五个信息点。
有哪些角色(设施)
有哪些 IP 段可供调配
角色之间是如何互联的
角色自身 (如 loopback 口) 要应用哪些 IP 段
角色之间的互联要应用哪些 IP 段
当然实际上还要略微简单一些，诸如 IP 段上会有业务标签，角色上会有端口调配规定等等。但这些实质上只是各个叶子节点的其余属性，只须要简略的加到叶子节点上即可。
4．资源分配器
架构布局库的信息流转到资源分配器后，资源分配器就要来分配资源。
那么第一个问题就是：它须要调配什么资源?
咱们的答案：调配那些须要在全网资源池中获取的，与 具体架构及具体路由协定无关 的资源。
这样做的次要起因是咱们心愿资源分配器与网络架构设计齐全解耦，否则会导致：
要么，须要继续投入研发人力跟踪实现数据中心内的动静路由协定从 OSPF 到 BGP 再到分布式数据库所需的各种资源分配逻辑
开发工具的同学不见得能够低成本、疾速的了解网络设计上的细节
又或者，零碎能力限度网络架构设计，若零碎只反对 BGP AS 号调配，那架构设计只能应用 BGP 协定
那这些协定相干的逻辑资源怎么办? 咱们借鉴了“变量作用域”的概念。
资源分配器为每个角色调配一组部分 (包含但不限于数据中心内、设备组内等) 惟一的 ID 值，咱们称之为 ID 组。在下一步配置生成中再依据 ID 组计算出这些资源。
这样的设计保障了：
部分唯一性
可计算性，互联两侧角色能够依据同样的参数和算法失去同样的逻辑资源，使得路由协定能正确协商
确定了须要调配的资源后，资源分配器依据架构布局库给出的架构信息，人工给出的规模信息，从 CMDB、IPAM 等资源池中获取设施、IP 等资源，并计算出 一个形容了整个数据中心拓扑的数据文件，称为连贯图。
连贯图中的信息次要包含两类：
设施信息(点)
上文提到的 ID 组
治理 IP
…
互联信息(线)
两侧设施
两侧 IP
两侧端口
…
连贯图信息将会持续传递给配置生成器。
5．配置生成器
至此，咱们曾经有了基于架构布局库给出的规定调配好的资源 (连贯图信息)，这些信息如何转化成交换机能够了解的配置?
这就是配置生成器做的工作。
5.1 配置的生成
理论写到交换机上的命令能够分为三大类 :
- 全局统一的配置，如 AAA 配置、安全策略配置等
- 与角色本身属性无关的配置
- 角色之间的互联配置，如 BGP peer address、BGP AS、三层口 IP 等
一个配置例子：
能够发现，配置实际上是由一些固定的模板及变量组合而成的。而这些变量必定来自于资源分配器的连贯图中，点本身的属性，或者线的属性，又或者是与点连贯的另外的点的属性。所以，只须要写好模板，再遍历连贯图，咱们就能够很轻松地失去整个机房所有设施的配置。
上文的配置在模版中的表现形式：
咱们应用 jinja2 来帮忙渲染模板，jinja2 反对模板的继承和组合，能够防止在每个角色的模板中反复写很多通用配置。同时，jinja2 模板十分的直观，简洁，所见即所得。替换为 jinja2 后大幅升高了配置命令的错误率。
咱们还通过 git 治理模板，并围绕 git 构建了模板编写及批改工作流，引入了自动化测试机制，保障了对模板的批改有解释，有 review，且通过测试，根本打消模板语法错误导致的沟通老本。
5.2 临门一脚
由前述的资源分配等步骤，至此咱们曾经实现了所有设施的配置生成工作，IDC 现场的同学也按零碎给出的信息将设施实现上架、接线、开电。
至此咱们只剩整个数据中心物理网络建设的“临门一脚”，这些配置文件 (以交换机 sn 命名的 txt 文件) 如何下发到交换机上，作为 startup config 启动并运行?
这里咱们应用目前各支流厂商均反对的“零配置启动”性能 :
设施运行 ZTP 性能，能够从 U 盘或文件服务器获取版本文件并主动加载，实现设施的免现场配置、部署，从而升高人力老本，晋升部署效率。
理论运行中，咱们会在新建的数据中心部署一台 PC (一个致密火热的奇点)，这台 PC 上运行了 DHCP、TFTP 服务以及寄存了该数据中心所有设施的配置文件。
类比服务器的 PXE 装机过程，咱们利用 DHCP 服务器下发 TFTP Server 和 Bootfile，替换机会主动执行该脚本，而后从 TFTP 服务器下载其所需的配置文件。
在这里咱们之前疏忽了一个问题：同一数据中心内洽购多厂商的设施，如何解决生成 / 下发特定厂商配置文件的问题?
答案是不解决，或者说不在后期思考这个问题。
配置生成器不感知，也不在乎上架应用的具体设施型号，而是间接生成出所有可能厂商的配置文件。例如某一特定角色共有 A、B、C 三个厂商的三份配置文件。
在交换机发送 DHCP Discover 报文时携带其厂牌信息，如此奇点只有依据其厂牌返回不同的 TFTP 门路即可实现配置的下发。
通过以上几个步骤，在现场实现上架、布线等工作后，咱们能够在小时级别将整个数据中心内的配置拉起，实现开局。
5.3 one more thing
实现配置下发并不是完结，咱们还赋予了“奇点”一些其余性能：因为有了整网的连贯图，咱们能够在最终交付给业务之前做一些查看，确认咱们的数据中心网络是牢靠的。
通过对所有设施的连通性查看，确认设施均已正确上线，治理面均可达。
通过比对交换机的 startup config 与 running config，确认全副配置下发正确。
通过 ZTP 性能，咱们能够指定上线设施的版本信息，由零碎主动降级为 DCN 指定的操作系统版本。
通过比对连贯图中的 peer 关系与读取设施的 LLDP 信息，确认全副接线正确。
在咱们理论运行中此处常会检出一些谬误：人工仍然是不牢靠的，而工具能够检查和防止这种谬误。
6．总结
从零建设一个可包容万台服务器的数据中心网络须要多久?
几小时。
但比起“交付工夫压缩了多少?”，更大的价值更在于咱们将眼光聚焦在工程师善于的中央，将其从繁琐的表格、调配工作中解放出来，花更多精力去了解咱们客户的工作流和关注点，建造真正能输入业务价值的网络基础设施。
UCloud 优刻得物理网络团队将持续秉承这一理念，深信“连贯的力量”，为各私有云产品、为客户提供更稳固、更高效的网络服务。
