《技术盛宴-数据中心自动化运维技术探索之NETCONF.pdf》由会员分享，可在线阅读，更多相关《技术盛宴-数据中心自动化运维技术探索之NETCONF.pdf（15页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、技术盛宴技术盛宴 | | 数据中心自动化运维技术探索之数据中心自动化运维技术探索之 NETCONFNETCONF数据中心交换机实现运维自动化，零配置上线技术ZAM只是完成了交换机预先可知的固定配置，主要是一些基本的互通以及登录相关配置。 未来的业务是变化的，所以具体的 与 业 务 相 关 的 配 置 还 需 要 根 据 具 体 需 求 配 置 或 更 新 。 NETCONF NetworkConfiguration Protocols，网络配置协议协议提供了业务配置部署自动化的解决方案。那么 NETCONF 是如何出现的？为什么需要开发 NETCONF？NETCONF 能干什么？发展趋势又是怎
2、样的？本文将针对以上几个问题， 对数据中心运维自动化技术进行一些介绍和探讨。SNMPSNMP 的问题的问题要谈 NETCONF，SNMP 是无法绕过去的。SNMPSimple Network ManagementProtocol ，简单网络管理协议最早由IETF 在 20 世纪 80 年代晚期1980s开发，自诞生之日起，SNMP 就被用来监控如告警、性能管理网络设备，大多数专业的网络设备都有 SNMP agent 代理，这些代理被激活和配置后用于和 SNMP 管理 NMSNetworkManagement System，网络管理系统通信。一套完整的 SNMP 系统主要包括管理信息库MIB 、
3、管理信息结构 SMI及SNMP报文协议。MIBMIBMIB，管理信息库，汇总存储着资源与OID 的唯一对应关系，NMS 根据查询的资源在MIB 中找到对应的 OID，通过 SNMP 查询报文将读取的 OID 信息发送至网络设备，网络设备根据 OID 查询对应的资源信息，最终封装为SNMP 响应报文发送给 NMS。如图一所示，查询资源OID 即。图一 ：MIB 树形层次结构SMISMISMI，管理信息结构，是 SNMP 中定义被管理的网络实体即网络设备中特定数据的语言。定义了数据类型、对象模型，以及写入和修改管理信息的规则等内容。SNMPSNMP 报文报文SNMP 规定了 5 种协议数据单元 P
4、DUSNMP 报文 ，用来在管理进程和代理之间的信息交换。如图二所示：get-request，用于从代理进程处提取一个或多个参数值；get-next-request，用于从代理进程处提取紧跟当前参数值的下一个参数值；set-request，用于设置代理进程的一个或多个参数值；get-response，用于代理向管理进程返回的一个或多个参数值；trap，代理进程主动发出的报文，通知管理进程有某些事件发生。图二：SNMP 五种报文操作从 SNMP 协议设计中可以看出， 尽管具有一些配置的功能， 但 SNMP 本身并不是面向配置的协议，也不适合开发用于配置的客户端应用。大量的运维实践也证明，SNMP
5、 更多是作为网络设备状态监控的工具，而在配置管理层面，SNMP 还不具备成为一个成熟工具的能力。而且即便在网络设备监控层面，SNMP 也还存在着其他的问题，比方：性能差，效率低；基于 UDP 协议传输，可靠性较差，只能依靠本身机制保证可靠性，影响性能；私有 MIB 导致多厂家设备统一管理难度大。正是由于 SNMP 的各种不足和缺陷，才导致了NETCONF的产生。NETCONFNETCONF的由来的由来在 2001、2002 年，IABInternet Architecture Board，互联网架构委员会 ，组织了几次关于网络管理的专题工作会议， 将网管以及协议开发者组织起来针对当时的主流网管
6、协议SNMP、CLI 等存在的问题进行了讨论，会议结果最终形成了RFC 3535。在这份文档中，针对当时网络管理中存在的问题，提出了14 项需求，其中最关键的几项有：易用性；明确区分配置数据、描述操作状态的数据和统计数据；面向服务和网络的配置管理，而不是单个设备的管理；配置数据的导入导出脱离原始人员操作；基于文本进行配置；标准化数据模型等等。针对 RFC 3535中罗列的需求，2003 年成立了 NETCONF工作组，NETCONF的设计遵循 RFC 3535。2006 年 NETCONF核心 RFC 4741发布，2011 年更新版的 RFC 6241发布废除 RFC 4741 。NETCO
7、NFNETCONF简介简介NETCONF 协议，顾名思义是安装、编辑和删除网络设备配置的标准协议。从上文NETCONF由来也可看出， NETCONF主要解决的问题之一就是网络设备的配置管理、 下发、更改等问题。NETCONF 如何来实现对网络设备配置的管理，我们先来看下 NETCONF 的架构设计。NETCONFNETCONF架构架构NETCONF使用 C/S 结构，面向连接，协议报文使用XML 格式。图三：NETCONF 协议架构从图三中可以看出 NETCONF 协议内部分为 4 层，由下至上分别是安全传输层，消息层，操作层和内容层。安全传输层安全传输层NETCONF 所具备的一大优势在于从
8、协议层面就规定其传输层必须使用带有安全加密的通信协议，如 SSH，TLS 等。比照其他明文传输协议，NETCONF协议层面就对数据安全性做了保障。由于NETCONF 协议规定必须要支持SSH，所以目前 SSH 是NETCONF使用最广泛的传输层协议。消息层消息层消息层提供了一种简单的、不依赖于传输协议的RPC 和通告封装机制。client 采用元素封装操作请求信息， 并通过一个安全的、面向连接的会话将请求发送给服务器，而服务器将采用元素封装 RPC 请求的响应信息即操作层和内容层的内容 ，然后将此响应信息发送给请求者。另外，服务器可以采用元素向客户端通告事件。操作层操作层操作层是承载在消息层上
9、的具体操作内容，这些具体操作仅能承载在 和消息上，消息无操作层内容。NETCONF协议规定了 9 种简单的 RPC 操作，如表一所示：基本操作基本操作说明说明获取配置数据或状态数据。获取配置数据。修改配置数据包括合并、替换、创建、删除等操作 。用一个完整数据库替换目标数据库。删除数据库，库不能被删除。锁定设备配置数据库，独占数据库修改权限，以免多用户操作情况发生。取消设备配置数据库锁定，只能取消本用户的锁定。请求正常中止 NETCONF会话。强制中止 NETCONF会话，需管理员权限。表一：RPC 基本操作除了以上 9 种基本操作，NETCONF也支持用户自定义 RPC 操作，这里不做展开描述
10、。内容层内容层内容层主要用来描述网络管理所涉及的配置数据和通知数据等。但是 NETCONF 并没有对于内容层的数据结构模型做标准化定义， 那如何来描述内容层的相关数据呢， 2006年，在 NETCONF首个版本 RFC 4741 发布的同时，一种专门为NETCONF准备的数据建模语言 YANGRFC 6020也同时发布。目标是对NETCONF数据模型、操作进行建模，覆盖 NETCONF协议的操作层和内容层。下列图即是一个 NETCONF的 RPC 报文中各层内容的示意。图四：NETCONF RPC报文例如NECONFNECONF 操作操作那在这个架构下 NETCONF到底是如何实现设备配置管理
11、的？我们来看一次 NETCONF交互的流程 ：图五：NETCONF交互流程示意在 Client 和 Server 建立 NETCONF会话后， 两端先通过报文互相通知对端本端对于 NETCONF的支持能力， 即 Capability。 同步完成后 Client 端发起 RPC 操作， Server端运行后将应答消息封装入回复给 Client 端。对于设备配置，就是在 Client端发起 RPC 配置相关的操作。NETCONF定义的 9 项基本 RPC 操作中有 4 项与配置直接相关，包括；。还剩余 2 项与配置权限相关，2 项会话关闭和 1 项状态数据查询。从这里也能看出NETCONF对于配置
12、管理的重视。可是这些好似还是没法表达NETCONF比SNMP好在哪？SNMP存在的问题如何解决的？这里不得不引出 NETCONF中另外一个重要的组成部分YANG。YANGYANGYANGYet Another Next Generation ，无法用中文给出恰当的翻译。从YANG的标准文档 RFC 6020 中，我们可以明确它的定位： A Data Modeling Language for theNetwork Configuration Protocol NETCONF ，NETCONF的数据建模语言。为什么要为什么要 YANGYANGNETCONF需要对设备的配置configuratio
13、n和状态state做操作，例如编辑配置，获取状态，而 NETCONF 的内容层并没有定义标准化的数据模型。同时操作层除了定义 9 种基本的 RPC 操作，还允许自定义 RPC，自定义的 RPC 和具体操作内容都需要进行建模，YANG就是用来完成这个建模的。YANG使用 modules 和 submodule 进行数据建模。一个YANG module，如图六所示， 定义了具有垂直结构的数据， 这些数据可以被用做基于NETCONF的操作， 包括配置、状态数据的描述，还有 RPC 操作等。它使得 NETCONF的 Client 和 Server 之间能有完整的数据描述。图六：YANG module举
14、例怎么用怎么用 YANGYANGYANG建模得到的数据具备树形结构。 其中每一个节点都有一个名字， 都有一个值或者一些子节点。YANG文件为这些节点， 以及节点之间的交互提供明确清晰的描述， 即数据模型路径。网络设备对于 NETCONF的支持，就是在设备注册 YANG的数据模型路径，使设备能够根据 YANG文件的数据模型路径获取数据或者写入配置。那么对于运维人员来说只需拿到设备厂商的YANG模型，根据 YANG模型的要求将相关的配置或数据参数填入，即可通过NETCONF发起相关 RPC 操作，完成配置或数据读取任务。通过 YANG 和 NETCONF，就实现了基于可编程技术的网络配置和管理，为
15、自动化运维提供了基础。NETCONFNETCONF与与 SNMPSNMP 比照比照介绍完 NETCONF，我们再回头看下 NETCONG与 SNMP 的简单比照：SNMPSNMPDefined in MIBsNETCONFNETCONFDefined in YANGData modelsData modelsData modelingData modelingSMILanguageLanguageYANGManagementManagementSNMPOperationsOperationsNETCONFRPC ProtocolRPC ProtocolBERXMLSSHTransport St
16、ackTransport StackUDPTCP表二：SNMP&NETCONF比照相比 SNMP，NETCONF具备以下优势：简单易用，YANG模型简单易学，可读性好，且可直接映射到XML；清晰区分配置数据和状态数据，对于不同数据，存储在不同数据库中，互相区分明确；可以统一管理整个网络所有设备，而不再是基于单台设备管理；自动化的配置下发和数据收集，降低人工误操作几率；标准化数据模型建模语言 ；扩展性好，除了标准操作，还可以自定义操作，实现独特管理功能；基于 SSH 协议，提供配置锁定等机制，数据安全性高。NETCONFNETCONF问题问题NETCONF协议因其良好的易用性和扩展性，已经随着S
17、DN 技术的逐步落地得到了越来越广泛的使用，主流设备厂商设备均可以支持NETCONF功能。但是这样是否就解决了网管运维面临的问题呢？答案显然是否认的。原因在于：各厂商设备支持 NETCONF 基本都使用私有 YANG 模型， 不同厂商设备不能识别其他厂商 YANG文件；对于使用 NETCONF 运维平台的使用者，需要学习熟悉各厂商的 NETCONF 文档和YANG文件；NETCONF YANG Model整体的标准化进程十分缓慢。为了解决这些现实问题，业界的设备使用者们推出了另外一种标准化方案。OpenConfigOpenConfig为了屏蔽使用 NETCONF 时不同厂商设备的差异，由 Go
18、ogle 发起，AT&T，BritishTelecom，Facebook，Apple，Microsoft 等参与成立了 OpenConfig 工作组，希望能创建一个与设备厂商无关的开放模型， 用于网络配置和策略。 目前国内许多互联网巨头公司也已经加入了 OpenConfig 工作组。OpenConfigOpenConfig 标准化标准化OpenConfig 的目的是基于实际案例的操作需求，使用 YANG 语言编译一组中立的通用数据模型，以最终实现基于可编程技术的网络自动化运维。OpenConfig 具备以下几个主要特征：沿用 NETCONF协议框架；使用 YANG作为建模语言；不修改底层数据传
19、输，只关注上层的数据表达和数据建模。也就是说 OpenConfig 更多的是要成为一个建模的标准。OpenConfig 本身是基于标准化的NETCONF协议框架和建模语言 YANG来开发，在YANG Model维度进行标准化，相当对于YANG模型做了标准，需要各厂家设备全部需要能够识别 OpenConfig YANG Model的 YANG文件，这样，不同厂商的设备就可以通过统一模型的 YANG文件来管理，不同的只是YANG文件中填入的参数。通俗的理解，OC OpenConfigYANG就是希望做成一种类似公有的YANG模型，如图七所示。图七：OC YANG模型OpenConfigOpenCo
20、nfig 生态情况生态情况目前 OpenConfig 还不是一个官方标准组织，甚至还不是一个正式的组织，很多的成员还都是通过邮件邀请的。 它由 Google 倡导，Microsoft、AT&T、英国电信等都是它的拥护者，国内互联网巨头均已加入。OpenConfig 目前还没有发布标准 RFC，但已经成为 NETCONF 的下一个发展趋势，各大网络设备厂商都已经开始了OpenConfig 的开发工作。目前，由于在网络管理、配置下发以及开放性等方面的优势， NETCONF基本已经成为实现数据中心运维自动化的主流协议。同时各大网络设备厂商也纷纷将 NETCONF 加入功能支持列表里。 虽然由于私有 YANG的问题导致在实际应用中还存在一些问题， 但 OpenConfig已经为解决这些问题提供了明确可行的思路。随着 OpenConfig 的逐步落地，数据中心自动化运维技术将迎来新一波浪潮。锐捷网络的数据中心交换机产品， 包括 RG-N18000-X系列核心交换机、 RG-S6510 系列 25G TOR、RG-S6220-H系列万兆 TOR都已支持 NETCONF和 OpenConfig YANG。2018 年上半年发布的 OpenConfig YANG 模型也已全部完成适配，目前正在配合国内公有云提供商进行测试。