正在阅读：畅谈数据中心网络运维自动化畅谈数据中心网络运维自动化

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

　　由于业务发生变更，需要为一个 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。