技术盛宴 | 数据中心自动化运维技术探索之NETCONF
|
副标题[/!--empirenews.page--]
数据中心交换机实现运维自动化，零配置上线技术（ZAM）只是完成了交换机预先可知的固定配置，主要是一些基本的互通以及登录相关配置。未来的业务是变化的，所以具体的与业务相关的配置还需要根据具体需求配置或更新。NETCONF（Network Configuration Protocols，网络配置协议）协议提供了业务配置部署自动化的解决方案。 那么NETCONF是如何出现的？为什么需要开发NETCONF？NETCONF能干什么？发展趋势又是怎样的？本文将针对以上几个问题，对数据中心运维自动化技术进行一些介绍和探讨。 SNMP的问题 要谈NETCONF，SNMP是无法绕过去的。SNMP（Simple Network Management Protocol ，简单网络管理协议）最早由IETF在20世纪80年代晚期（1980s）开发，自诞生之日起，SNMP就被用来监控（如告警、性能管理）网络设备，大多数专业的网络设备都有SNMP agent代理，这些代理被激活和配置后用于和SNMP管理 NMS（Network Management System，网络管理系统）通信。 一套完整的SNMP系统主要包括管理信息库（MIB）、管理信息结构（SMI）及SNMP报文协议。 MIB MIB，管理信息库，汇总存储着资源与OID的唯一对应关系，NMS根据查询的资源在MIB中找到对应的OID，通过SNMP查询报文将读取的OID信息发送至网络设备，网络设备根据OID查询对应的资源信息，最终封装为SNMP响应报文发送给NMS。 如图一所示，查询资源iso.org.dod.internet.mgmt.mib.ip.ipInReceives对应的OID即为：1.3.6.1.2.1.4.3。
图一 ：MIB树形层次结构 SMI SMI，管理信息结构，是SNMP中定义被管理的网络实体（即网络设备）中特定数据的语言。定义了数据类型、对象模型，以及写入和修改管理信息的规则等内容。 SNMP报文 SNMP规定了5种协议数据单元PDU（SNMP报文），用来在管理进程和代理之间的信息交换。 如图二所示：
图二：SNMP五种报文操作 从SNMP协议设计中可以看出，尽管具有一些配置的功能，但SNMP本身并不是面向配置的协议，也不适合开发用于配置的客户端应用。大量的运维实践也证明，SNMP更多是作为网络设备状态监控的工具，而在配置管理层面，SNMP还不具备成为一个成熟工具的能力。 而且即便在网络设备监控层面，SNMP也还存在着其他的问题，比如：
正是由于SNMP的各种不足和缺陷，才导致了NETCONF的产生。 NETCONF的由来 在2001、2002年，IAB（Internet Architecture Board，互联网架构委员会），组织了几次关于网络管理的专题工作会议，将网管以及协议开发者组织起来针对当时的主流网管协议（SNMP、CLI等）存在的问题进行了讨论，会议结果最终形成了RFC 3535。在这份文档中，针对当时网络管理中存在的问题，提出了14项需求，其中最关键的几项有：
针对RFC 3535中罗列的需求，2003年成立了NETCONF工作组，NETCONF的设计遵循RFC 3535。2006年NETCONF核心RFC 4741发布，2011年更新版的RFC 6241发布（废除RFC 4741）。 NETCONF简介 NETCONF协议，顾名思义是安装、编辑和删除网络设备配置的标准协议。从上文NETCONF由来也可看出，NETCONF主要解决的问题之一就是网络设备的配置管理、下发、更改等问题。NETCONF如何来实现对网络设备配置的管理，我们先来看下NETCONF的架构设计。 NETCONF架构 NETCONF使用C/S结构，面向连接，协议报文使用XML格式。
图三：NETCONF 协议架构 从图三中可以看出NETCONF协议内部分为4层，由下至上分别是安全传输层，消息层，操作层和内容层。
NETCONF所具备的一大优势在于从协议层面就规定其传输层必须使用带有安全加密的通信协议，如SSH，TLS等。对比其他明文传输协议，NETCONF协议层面就对数据安全性做了保障。由于NETCONF协议规定必须要支持SSH，所以目前SSH是NETCONF使用最广泛的传输层协议。
消息层提供了一种简单的、不依赖于传输协议的RPC和通告封装机制。 client采用<rpc>元素封装操作请求信息，并通过一个安全的、面向连接的会话将请求发送给服务器，而服务器将采用<rpc-reply>元素封装RPC请求的响应信息（即操作层和内容层的内容），然后将此响应信息发送给请求者。另外，服务器可以采用<notification>元素向客户端通告事件。
|
