UCloud 大规模数据中心网络管理系统建设之路

为了应对大规模数据中心的网络配置自动下发、运维效率提升、混合云网络实时打通等需求，UCloud 团队研发上线了物理网络编排器（以下简称编排器）。它是网络运维自动化建设的基础应用系统，为网络运维人员提供一个简单易用的网络设备配置工具，使之从繁琐的交换机命令编写中获得解放，并具备足够的准确性、稳定性和安全性。

基于此系统，数据中心建设时上万规模级别 IDC 的网络建设周期由原先的 2-3 天缩短至 2-3 小时，且上线成功率也从此前的 80%提高到 99%。上线至今，该系统已成功服务于 3000 余台交换机，维护了 100 条以上的运营商专线。其所承载的网络接入吞吐达 200G，DCI（数据中心内部互联）吞吐接近 2T 左右，并能支持混合云业务在用户控制台的网络实时打通等（物理接线除外）。

难点分析

传统网络部署主要通过人工配置的方式实现。当网络达到一定规模时，采用人力堆砌的方式效率低下不说，大量的配置命令，也容易导致较高的上线错误率。结合公司目前的情况，在分析业界开源的配置下发方案后，我们决定采用基于 Python with NAPALM (Python module)方案自建一套业务配置下发系统，这套系统的内部 Codename 为 XUANWU（中文玄武）。

NAPALM 模块底层的配置下发系统（比如 Ansible、Paramiko、Salt）虽然是通用的，但目前只有主流的厂家才支持对应的库，一些二线品牌的厂家支持的并不完善，需要自研。寄希望厂家提供丰富和标准的配置下发 API 是不太切实的奢望，我们要结合业务开发一套适用于 UCloud 的配置下发系统。

通过分析，我们发现，如果要开发一套基于业务的网络编排器，必须要解决以下障碍：

1. 同一个底层，命令不同的设备厂家提供的配置命令不一样。如创建一条静态路由，同样一个需求，锐捷的命令是“ip route 0.0.0.0 0.0.0.0 1.1.1.1”，而华为的命令是“ip route-static 0.0.0.0 0.0.0.0 1.1.1.1”；

2. 同一款设备型号，由于软件版本不同，实现同一个功能的命令组合不同。如华为的 CE6851-48S6Q-HI 设备，同样实现 tunnel 创建这功能，当版本<=V1R2 时，tunnel 口需要绑定一个 service_type 为 tunnel 的聚合口来激活，而之后的版本，就不需要绑定了；

3. 不同厂家设备，实现同一个需求的配置模式不一样。如将交换机物理口划入某聚合口配置需求下，华为只需要将物理口绑定抽象出来的聚合口即可继承聚合口下所有属性，而 H3C 则要在物理口下将聚合口的属性配置再配置一遍。

4. ……

这些形形色色、大大小小的人能解决的问题却让自动化举步维艰，要想实现网络配置自动化，首先必须将这些问题总结抽象成具体的场景，然后通过分级归类来规避差异。

编排器架构及业务模型搭建

经过内部多次的讨论和归纳，我们发现真正业务调用网络的，是一个一个具体的场景，这些场景能够实实在在满足具体需求，如一个业务的需求是打通托管到公有云的路由，那么实际上网络实现的就是静态路由的下发，静态路由下发就成了一个配置场景。

这里，需要注意的是场景是不关心设备厂家的，因此就会衍生出两个问题：1、配置命令的差异；2、配置模式的差异。我们需要将这两层抽象出来处理，经过测试和抽象，我们设计了业务模型的网络配置下发系统：

图 1：UCloud 基于场景的网络配置下发系统架构图

• 第一步：构建原子命令类。由厂商，设备型号，型号版本，版本补丁构成一个原子命令的类，该类原子命令为一个录入模板。

• 第二步：原子命令录入。先录入功能，再录入功能对应的原始设备命令。

• 第三步：创建模板。将一个或者多个原子命令拖拽构建成能对应业务需求的模板。

• 第四步：创建 API。为模板建立对应的 KEY 值，使其能够为灵活的以 API 的方式被业务调用。

以一个具体的 API 创建过程为例，首先录入设备的软硬件版本，将软件和硬件组合为一个单位，按照原子命令规范抽象出一层 GROUP 组，每一个 GROUP 为一个原子命令录入标准，接下来按照命令功能为单位关联一条或者多条原子命令。

具体构成关系图如下:

图 2：命令功能-原子命令-版本 group-软硬件设备对应表

图 3：API-场景-模板-命令功能对应表

场景中涉及到的命令功能创建完成后，通过前端编排创建模板，并结合实际属性自动生成场，由此 K-V 的 API 模型基本就落成了。但是此时的创建只能关联一个具体的设备类型的场景，如果其它场景有其它设备，API 就无法生效了。因此还需要将多个关联了 GROUP 组的场景加入大场景组中以大 API 的方式暴露出去，至此该 API 就能兼容多厂家的配置命令了。

设计与优化实践

考虑到现网的特殊性，需要编排器具备较高的准确性、稳定性和安全性。为满足以上特性，整个系统在架构设计、代码开发过程中也做了系列调优实践。

1. 基于 Kafka 的命令执行队列设计

编排器需要面向公司所有在用机房按照一定的业务应用场景（以下简称场景）进行交换机配置命令的下发。以 IDC 机房作为空间维度，配置命令的执行先后顺序作为时间维度，每个场景的执行必须做好时序控制，兼顾空间和时间维度。

为了保障配置指令的准确执行到位，我们采用了基于 Kafka 的命令执行队列设计，Kafka 消息队列的主题（Topic）分类特性和消息队列生产消费特性可以很好的兼顾指令下发队列模块对时序控制的需求。主题分类特性可用于处理 IDC 机房的空间维度，消息队列生产消费特性则对应指令执行的时间维度。

在实际应用过程中，通过对业务场景进行解析，将交换机配置指令按照 IDC 机房生产至对应的 Kafka 主题，同一个 IDC 机房的配置指令将以交换机为单位，按照执行的先后顺序生产至对应的主题。

图 4：基于 Kafka 的命令执行队列设计

通过利用 Kafka 的两大特性，结合系统的业务场景解析逻辑，我们最终实现了交换机配置指令的时空维度控制，确保指令的准确送达。系统上线后运行至今，未出现过配置指令误发、错发的情况。

2. 集群、主备与主主设计的应用

作为网络运维自动化建设的基础系统，后期将面向更多部门开放部分或全部功能，因此，编排器服务的稳定性尤为重要。系统考虑了在使用集群化等高可用技术上的各种环节，制定了以下稳定性提升设计方案：

1. Zookeeper 集群（基本操作）；

2. Kafka 集群（基本操作）；

3. Kafka 消费者集群：在每个 IDC 机房部署 Kafka 消费者集群，确保配置指令消息的稳定消费并执行；

4. MySQL 数据库 1 主 2 备：数据库读写分离，主库只接受写操作，从库只接受读操作，降低主库负载，提高数据库服务稳定性；

5. Webserver 主主：提供两台 web 后台服务器，通过 Nginx 代理实现负载均衡，结合数据库的双备设计，实现 API 请求及数据库读操作的均衡分配。

通过集群化、主备、主主设计，编排器提供的 Web 服务变得更加稳定，配置指令消息队列也更加可靠。系统上线后运行至今，未出现过因 web 服务器或消息队列宕机导致的服务不可用情况。

3. 权限设计

系统涉及现网交换机的变更操作，每个业务场景的执行均会对现网产生影响，适当的权限管理也非常重要。系统从 2 个层面对操作者权限进行限制，并启用后端 token 认证：

1. API 权限：涉及数据库的增、删、改、查，以及业务场景的下发（回滚）操作，通过 1 对 1 的 API 权限划分进行管理；

2. 菜单权限：涉及菜单层级的 UI 界面操作，对前端操作页面的菜单项进行权限划分和管理；

3. Token 认证：后端调用 API 时将进行 Token 认证，Token 与操作者一一对应，责任到人。

图 5：token 认证流程

通过权限认证，可以规范了使用者的操作习惯，强化使用者的安全意识，最终提高整个系统的安全性。

4. 指令下发实时反馈

传统人工配置模式下，每一位网络运维工程师必须要登录到对应的交换机才能进行配置指令下发，同时观察交换机回显信息进行指令执行结果确认。为了重现这一过程并提供更友好的信息提示效果，系统集成了指令执行结果实时展示功能，并提供执行结果详细信息查询，供网络运维工程师参考决策。

具体实现方式为，编排器前端界面在业务场景执行过程中，系统提供两种方式的执行结果信息展示：

1. 执行状态：将每一条指令的执行状态分为下发成功、下发失败、即将回滚、回滚成功、回滚失败以及登录失败 6 种，并在业务场景下发过程中通过不同边框颜色进行实时展示。

图 6：指令执行状态说明

图 7：指令执行状态显示界面

2. 指令执行回显信息：大部分指令执行之后交换机都会有回显信息提示，系统自动抓取交换机回显信息并反馈到前端，为操作者提供参考。

图 8：指令执行回显信息展示

这种图形颜色及回显信息展示，可以实时反馈配置指令的执行效果，为网络运维工程师提供参考，在提高自动化水平的同时提升操作反馈体验。

5. 原子命令库的建立

公司在用交换机主要有 HW、H3C 和 RUIJIE 三大品牌，各大品牌交换机之间配置指令存在较大差别。同时，每个品牌下面的交换机又可分为若干型号，不同型号之间部分指令也存在一定的区别。

为了兼容公司在用的所有交换机，需要对所有交换机型号进行统一管理，同时根据不同交换机型号进行配置指令录入，做好分类管理。基于以上背景及需求，系统搭建了原子命令库，原子命令库包括以下几个子库：

a. 交换机设备库：以厂商、型号、版本、补丁为分类字段，将公司在用的所有交换机进行归类整理；

b. 交换机设备组库：在交换机设备库的基础上进行分组，将配置指令相同的设备划分到同一组；

c. 原子命令库：基于交换机设备组进行原子命令录入，同时从原子命令功能维度进行分类；

d. 原子命令功能模板库：用于录入交换机命令的功能模板；

e. 原子命令参数模板库：用于录入交换机命令的各类参数模板。

通过建立原子命令库，可以将公司所有在用交换机及其适用的配置指令进行了统一分类管理。而交换机组的设计，可以将配置指令相同的交换机归入同一组，同组设备共享原子命令，极大减少了录入原子命令的工作量。此外，通过建立原子命令功能、参数模板库，可以将原子命令录入方式标准化，为业务场景编排打好基础。

6. API 开放和二次开发

系统提供了原子粒度的交换机操作 API，不仅支持现有的网络运维操作，也可作为外部调用组件支持相关的二次系统开发。同时，通过提供统一且精细分类的 API 入口，可以实现现网交换机操作的集中管理，提高现网安全性。目前已为盘古系统（UCloud 服务器自动交付系统）、UXR 项目提供底层调用 API，支撑系统开发及相关业务开展。

最后

经过联调测试，我们已将该系统应用到多个业务场景中，且都有不错的表现。通过网络自动编排系统，我们将数据中心建设业务中，上万规模级别 IDC 的网络建设周期从原先的天缩短为小时。此外，上线成功率也从原先的 80%提高到 99%。在混合云业务打通中，虚拟网络的业务逻辑也能通过用户的控制台操作实时打通（物理接线除外）。

本文转载自公众号 UCloud 技术（ID：ucloud_tech）。

原文链接：

https://mp.weixin.qq.com/s/pfzlhumDHGuQM8WzM7VX3w