技术盛宴丨畅谈数据中心网络运维自动化

首先，让我们假想一个场景：

由于业务发生变更，需要为一个POD 里面的几十台交换机修改QoS 配置。作为网络运维人员，应该怎样处理这项工作呢？

如果需要变更的对象是整个数据中心几百台甚至几千台交换机，又该怎样处理这项工作呢？

当下，互联网行业已经普遍采用DevOps 的体系流程。靠人力去一台设备一台设备的更改配置，已经不再是正确的思维方式。原因不仅仅是浪费时间——要知道，人如果要长时间保持注意力集中，大脑需要耗费大量的能量，很难保证不出现遗漏或者错误。而机器却不会。

因此，正确的方法是利用DevOps 的流程，让机器来完成这项工作。例如采用基于Python 的SSH 库Paramiko 或Netmiko，以及Ansible 或SaltStack 等自动化工具编写运维脚本。

Netmiko 库和Ansible 等运维工具虽然可以通过程序化的脚本对网络设备实现批量管理，但仍然需要运维工程师对网络设备的CLI 很熟悉，预先在脚本中建立需要被执行的Command 列表。

CLI

CLI 最大的问题就是在不同厂商的设备之间，甚至在不同版本之间存在较大差异。比如在某C 厂商交换机上配置边缘端口，不同的OS 版本命令并不相同：

而对于另一些厂商，配置命令则差异更大。例如在某E 品牌交换机上配置边缘端口的命令为：

这意味着：如果设备版本升级，就可能需要更改运维脚本的代码。为了避免厂商绑定，网络内通常也会同时存在多个厂商的设备，相应地，也可能需要准备多种运维脚本或者让运维脚本变得很复杂——先判断设备型号和版本号，再运行相应的Command-list。

所以CLI 并不适合用来作为一种API。虽然采用自动化工具处理Commands 可以节省网络运维人员的工作量，但是技术门槛和维护成本都比较高。SNMP 似乎是一种更好的选择。

SNMP

▲SNMP Overview

SNMP 的历史很悠久，第1 个与之相关的RFC 1065 发布于1988 年，距今已有30 年。在SNMP 架构中，一个网络设备以守护进程的方式运行SNMP Agent，而NMS（网络管理系统）和网络运维人员所使用的各种SNMP 管理工具则称为SNMP Manager。SNMP Agent 能够响应来自SNMP Manager 的各种请求信息。

SNMP Agent 会维护一个MIB（管理信息库），里面保存着大量的OID （对象标识符）。一个OID 是一对唯一的Key-Value，SNMP Manager 向SNMP Agent 查询或修改若干Key 所对应的Value，就可以实现信息采集或者网络设备的配置修改。

▲MIB-Example

上图是一个MIB 示例，请注意标黄色的部分。OID 1.3.6.1.2.1.2.2.1.5 用来以bps 为单位评估接口流量，它属于RFC 1213 标准MIB，名称为ifSpeed，只读。因为这个MIB 并不是我从正在运行的设备上取下来的，所以当前的Value 为空。

需要注意的是，SNMP Manager 侧的MIB 并不是必需的。如果使用数字OID 1.3.6.1.2.1.2.2.1.5，SNMP Manager 可以直接从SNMP Agent get 接口流量带宽，而不需要安装完整的MIB。

现在SNMP 在网络监控领域已经被广泛使用，利用Zabbix、Nagios、Cacti 等开源的SNMP 管理工具采集网络设备接口流量带宽和其他设备信息，同时也有大量的基于Python 的SNMP 库用来实现运维开发，例如PySNMP、EasySNMP、Net-SNMP等等，并且它们都可以集成到Ansible 和SaltStack 等自动化运维工具上。

看上去还不错，但实际上SNMP 仍然不是一个合适的API，因为它存在几个问题：

○太古老，并发性能不好

○基于UDP 协议传输，比较不可靠。虽然在应用层有Response 机制保证丢包之后的重复get/ set，但代价就是性能和运行时间都受到影响

○致命的问题是，各厂商都大量的使用私有MIB，却不存在一个可以自动发现网络设备当前所采用的MIB 的机制。网络运维人员必须分别向设备厂商索取网络设备的MIB，耗费大量的时间整理自己需要的OID，再手工导入到自动化运维平台或者脚本当中

所以SNMP 仍然只适合用来做信息采集，提供告警和可视化报表，但自动化运维的API 则需要考虑其他的选项。站在网络运维人员的角度，这个API 应该满足以下要求：

○容易使用—— Usability 是所有产品的核心价值

○需要能够清晰地区分“配置数据”，“设备运行状态数据”和“统计数据”

○需要能够分别从各个网络设备获取上述3 种数据，并且可以方便地对比不同设备的数据

○可以让网络运维人员统一地管理整个网络的所有设备，而不是一台一台的单独管理

○对不同厂商的设备都能够使用同一种配置方法

○配置变更对网络业务的影响要尽可能的小

○能够提供一个标准化的，对设备Pulling 和Pushing 配置文件的流程，以满足对设备配置的备份和恢复的业务需求

○能够很方便地，持续地，检查设备配置文件的一致性

○能够提供基于文本的配置方式，并且不会导致配置的乱序，例如不能搅乱ACL 规则的顺序

能够满足这些要求的网络设备的北向API 接口就是Netconf。

Netconf

Netconf 是IETF 发布的标准协议，它的全称是Network Configuration Protocal。从名字就可以看出来，Netconf 的作用是基于网络来安装、操作和删除设备的配置。在Netconf 的架构中，网络设备充当Netconf Server 的角色，而运维人员的这一侧则是Netconf Client。此外，和OSI 标准模型一样，Netconf 也是分层结构。

▲Netconf 4 Layers

它有4 个层次，从下到上依次为：

• 安全传输层

安全传输层在Netconf Client 和Netconf Server 之间提供安全的端到端连接。与SNMP 采用非面向连接的UDP 协议不同，Netconf 采用面向连接的TCP 协议，通常是SSH 协议，保证连接的可靠性和安全性。

• 消息层

消息层也称为RPC（远程过程调用）层。Netconf Server（网络设备）上面部署了Netconf 应用，Netconf Client 需要调用Server 上的应用所提供的函数/方法，但由于Client 和Server 不在同一个内存空间，无法直接调用，所以需要通过网络来表达调用的语义，并传达调用的数据。这个过程，称为RPC。它提供了一个简单的，与安全传输层无关的机制来封装操作层和内容层的数据：

○RPC 调用： 元素所封装的消息

○RPC 结果： 元素所封装的消息

○事件通知： 元素所封装的消息