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

2018-04-20 17:42 出处:其他 作者:佚名 责任编辑:sunziyi

Netconf

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

▲ Netconf 4 Layers
▲ Netconf 4 Layers

  它有 4 个层次,从下到上依次为:

  01安全传输层

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

  02消息层

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

  RPC 调用: <rpc> 元素所封装的消息

  RPC 结果: <rpc-reply> 元素所封装的消息

  事件通知: <notification> 元素所封装的消息

  03操作层

  操作层定义了如图所示的 9 种基础操作集,其中:

  <get>、 <get-config> 用来对设备进行取值操作

  <edit-config>、 <copy-config>、 <delete-config> 用于配置设备参数

  <lock> 和 <unlock> 是在对设备进行操作时,为防止并发产生混乱的锁行为

  <close-session> 和 <kill-session> 用于结束一个会话操作

  04内容层

  顾名思义,内容层就是用来表达配置数据和状态数据,网络运维人员只需要关注数据本身,而不需要去关注设备的相关命令。基础网络设备在内容层所采用的数据格式通常是 XML,但也有厂商的数据格式采用了 JSON。

  虽然网络运维人员不再需要关注设备的相关命令了,但仍然无法直接使用 Netconf 配置设备,还需要考虑配置结构。

  什么叫“配置结构”呢?

  假如我们现在要将交换机的 10# 端口划入 VLAN 20。锐捷交换机需要在物理端口模式下配置:

  而某 H 品牌交换机却需要在 VLAN 逻辑端口模式下配置:

  从上面两个配置示例可以发现锐捷交换机和 H 品牌交换机的配置结构有明显差异,所以无法直接使用 XML 或者 JSON 修改它们的设备配置。

  为了解决配置结构的问题,需要将 XML 和 JSON 数据格式抽象成一个统一的标准的模型,这就是 YANG。YANG 的全称是 Yet Another Next Generation,没有恰当的中文来翻译它。通俗的讲,YANG 是表达 Netconf 所操作的配置数据和状态数据的模板,它描述什么才是符合设备期望的数据。有了 YANG Model,配置结构就交给它去处理,网络运维人员就只需要做一个完形填空即可。

  填空的题目大概是这样子的:

  填空题的答案大概是这样子的:

  这个过程在逻辑上,与向SNMP的OID填充/读取Value差不多。

  Netconf和YANG Model的出现,为网络自动化带来了极大的便利。配合自动化的程序,可以实现动态向网络设备下发配置,将数据面和控制面分离,组成软件定义的网络。事实上,Netconf 也是 OpenDayLight 等开源SDN Controller所广泛使用的南向接口之一。 此外,Ansible也集成了Netconf的Module,并且可以通过 Python来扩展ncclient和nxpy等库,实现功能扩展。

  但Netconf就是我们在寻找的理想的API吗?

  站在网络运维者的角度,答案却是否定的。

  原因在于很多厂商虽然支持Netconf,但有一些Key-Value却存在差异。比如为了表达“端口”,有些厂商用 intf 作为 Key,但另外一些厂商却用 interface 作为 Key。另一个例子就是 Uptime,设备运行时间,各家厂商的设备返回的时间格式更是五花八门。这为网络运维人员处理数据的工作造成了很大的麻烦,不得不耗费大量的时间和精力去阅读设备厂商的 Netconf 文档,去编写大量的正则表达式。

  还有,虽然主流的 SDN Controller 的南向接口都支持 Netconf,但是在实际部署时,却无法用单一的 Controller 去控制多厂商的网络设备。通常都是各个厂商使用自己的 SDN Controller 控制自己的设备,然后再用 REST API 与用户的 SDN Controller 对接。

▲ 多控制器架构
▲ 多控制器架构

  上文所提到的网络运维人员所关心的 9 大问题,Netconf 几乎都能满足,但距离完全满足还有一些差距。

  有一个解决办法,就是利用 NAPALM。

NAPALM

  NAPALM 是一个 Python 库,它的全称是 Network Automation and Programmability Abstraction Layer with Multivendor support,多厂商支持的网络自动化和可编程抽象层。

  目前 Ansible 集成了 3 个 NAPALM 模块,分别是:

  napalm_parse_yang:用于从设备或文件中解析配置/状态数据

  napalm_diff_yang:用于比较 2 个 YANG 对象的差异

  napalm_translate_yang:用于将 YANG 对象转译成设备原始的配置

  从设备取出原始配置数据/状态数据之后,可以使用 NAPALM 将其翻译成标准格式的 NAPALM 数据。反之,也可以将标准格式的 NAPALM 数据翻译成设备原始配置数据,并 Push 到网络设备里面,以修改设备的配置文件。

▲ Netconf & NAPALM
▲ Netconf & NAPALM

  读到这里,也许您已经猜到我将要说什么了……

  是的,NAPALM 还是不能彻底解决网络自动化所面临的问题。

  因为各厂商 Netconf 的数据表达存在很多差异,所以 NAPALM 必须要依赖第三方的 Module 来完成原始数据的解析和翻译。如果要解析厂商 A 的某个 OS 系统的配置,就需要一个 OSA_Module;如果要解析厂商 B 的某个 OS 系统的配置,则需要 OSB_Module。所以目前 NAPALM 支持的 OS 类型还比较少,仅限于某几个国外品牌厂商的 OS 系统。

  即使是这几个国外品牌厂商,NAPALM 目前也无法实现完整的功能集。所以 Google 等网络设备的大用户一直在致力于推广一个能够替代 Netconf 的标准化接口: OpenConfig。

键盘也能翻页,试试“← →”键
本文导航
第1页:CLI和SNMP
第2页:Netconf和NAPALM
第3页:OpenConfig

为您推荐

加载更多
加载更多
加载更多
加载更多
加载更多
加载更多
加载更多
加载更多
加载更多

网络设备论坛帖子排行

最高点击 最高回复 最新
最新资讯离线随时看 聊天吐槽赢奖品