CNTXJ.NET | 通信界-中国通信门户 | 通信圈 | 通信家 | 下载吧 | 说吧 | 人物 | 前瞻 | 智慧(区块链 | AI
 国际新闻 | 国内新闻 | 运营动态 | 市场动态 | 信息安全 | 通信电源 | 网络融合 | 通信测试 | 通信终端 | 通信政策
 专网通信 | 交换技术 | 视频通信 | 接入技术 | 无线通信 | 通信线缆 | 互联网络 | 数据通信 | 通信视界 | 通信前沿
 智能电网 | 虚拟现实 | 人工智能 | 自动化 | 光通信 | IT | 6G | 烽火 | FTTH | IPTV | NGN | 知本院 | 通信会展
您现在的位置: 通信界 >> 工业自动化 >> 技术正文
 
技术盛宴|畅谈数据中心网络运维自动化
[ 通信界 | 华为技术 | www.cntxj.net | 2018/11/18 11:16:51 ]
 

首先,让我们假想一个场景:

由于业务发生变更,需要为一个 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 的历史很悠久,第 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 示例,请注意标黄色的部分。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 是 IETF 发布的标准协议,它的全称是 Network Configuration Protocal。从名字就可以看出来,Netconf 的作用是基于网络来安装、操作和删除设备的配置。在 Netconf 的架构中,网络设备充当 Netconf Server 的角色,而运维人员的这一侧则是 Netconf Client。此外,和 OSI 标准模型一样,Netconf 也是分层结构。

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

●安全传输层

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

●消息层

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

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

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

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

●操作层

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

用来对设备进行取值操作

用于配置设备参数

和是在对设备进行操作时,为防止并发产生混乱的锁行为和用于结束一个会话操作

●内容层

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

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

什么叫“配置结构”呢?

假如我们现在要将交换机的 10# 端口划入 VLAN 20。从上面两个配置示例可以发现锐捷交换机和 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 到网络设备里面,以修改设备的配置文件。

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

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

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

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

IETF 已经为 Netconf 和 YANG Model 发布了很多 RFC,从 2006 年的 Netconf RFC 4741,2010 年的 YANG Model RFC 6020,到现在已经超过 10 年。而最新的一个 RFC 在什么时候呢?就在几天之前的 2018 年 4 月 3 日,3 家设备厂商联合提交了一个 OSPF YANG Model 的草案 —— 标准化的进展太慢了。

也许,这就是问题所在 —— Netconf 标准是由网络设备厂商推动的,内耗太大。各个设备厂商都希望在软件定义网络的时代继续保持硬件设备的重要性,并且能够体现自己公司产品的差异化优势。

但是从网络运维者的角度考虑,这显然不合理,因为设备厂商所推动的 Netconf 标准并不是他们真正想要的。所以 Google,AT&T,British Telecom,Facebook,Apple,Microsoft 等互联网服务提供商成立了 OpenConfig 工作组,希望提供一个中立于设备厂商的标准 API。目前国内的腾讯、百度和阿里等互联网服务提供商也已经加入了 OpenConfig 工作组。

OpenConfig 沿用了 Netconf 的协议框架,但是它不太关注底层的数据传输,而是更关注上层的数据表达和数据建模。这意味着:不管是 A 厂还是 B 厂,所有的数据都必须符合 OpenConfig YANG Model,并且 Key-Value 都必须是 OpenConfig 所规定的标准格式!

OpenConfig 的另外一个核心要点是:虽然网络设备可能支持丰富的功能特性,甚至是设备厂商私有的功能特性,但是 OpenConfig 只关心与互联网行业用户通用的运维工作和网络设计工作相关的功能,例如 BGP、OpenFlow、Telemetry 等等。OpenConfig 不会为设备厂商的私有特性定义 YANG Model,也不会为设备厂商所特有的 Key-Value 做定义,所以不会出现不兼容的情况。

但反过来讲,OpenConfig 也不会为了兼容某些设备厂商而让 YANG Model 过于简单,所以设备厂商需要让自己的功能满足 OpenConfig YANG Model 的要求,具备 Model 所定义的所有的 Key,并且能够为所有的 Key 提供对应的 Value。

在 Key-Value 格式固定之后,网络运维人员对数据的解析工作就非常方便了。只要网络设备支持标准的 OpenConfig YANG,NAPALM 就可以对原始数据进行解析,不再依赖第三方 Module 就可以管理多厂商多 OS 的网络,进而实现真正的网络自动化

使用 OpenConfig 的另一个好处就是可以简化 SDN 网络架构,用户使用一个控制器集群就可以同时控制多个厂商的网络设备,不再需要使用设备厂商的商用控制器做中继。

OpenConfig 工作组在 2015 年已经向 IETF 提交了 2 个 YANG 标准草案,虽然目前还没有标准的 RFC 发布,但是它现已成为网络自动化技术的发展趋势,因此各大网络设备厂商都开始了 OpenConfig 的开发工作。锐捷的数据中心交换机支持 Netconf YANG 和 OpenConfig YANG,目前正在国内配合公有云提供商进行标准化 SDN 的测试工作。

 

1作者:华为技术 来源:华为技术 编辑:顾北

 

声明:①凡本网注明“来源:通信界”的内容,版权均属于通信界,未经允许禁止转载、摘编,违者必究。经授权可转载,须保持转载文章、图像、音视频的完整性,并完整标注作者信息并注明“来源:通信界”。②凡本网注明“来源:XXX(非通信界)”的内容,均转载自其它媒体,转载目的在于传递更多行业信息,仅代表作者本人观点,与本网无关。本网对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。③如因内容涉及版权和其它问题,请自发布之日起30日内与本网联系,我们将在第一时间删除内容。 
热点动态
普通新闻 中信科智联亮相2023中国移动全球合作伙伴大会
普通新闻 全球首个基于Data Channel的新通话商用网络呼叫成功拨通
普通新闻 中国联通:以优质通信服务 助力“一带一路”共建繁华
普通新闻 杨杰:未来五年,智算规模复合增长率将超过50%
普通新闻 长沙电信大楼火灾调查报告发布:系未熄灭烟头引燃,20余人被问责
普通新闻 邬贺铨:生态短板掣肘5G潜能发挥,AI有望成“破局之剑”
普通新闻 工信部:加大对民营企业参与移动通信转售等业务和服务创新的支持力
普通新闻 摩尔线程亮相2023中国移动全球合作伙伴大会,全功能GPU加速云电脑体
普通新闻 看齐微软!谷歌表示将保护用户免受人工智能版权诉讼
普通新闻 联想王传东:AI能力已成为推动产业升级和生产力跃迁的利刃
普通新闻 APUS李涛:中国的AI应用 只能生长在中国的大模型之上
普通新闻 外媒:在电池竞赛中,中国如何将世界远远甩在后面
普通新闻 三星电子预计其盈利能力将再次下降
普通新闻 报告称华为5G专利全球第1 苹果排名第12
普通新闻 党中央、国务院批准,工信部职责、机构、编制调整
普通新闻 荣耀Magic Vs2系列正式发布,刷新横向大内折手机轻薄纪录
普通新闻 GSMA首席技术官:全球连接数超15亿,5G推动全行业数字化转型
普通新闻 北京联通完成全球首个F5G-A“单纤百T”现网验证,助力北京迈向万兆
普通新闻 中科曙光亮相2023中国移动全球合作伙伴大会
普通新闻 最高补贴500万元!哈尔滨市制定工业互联网专项资金使用细则
通信视界
邬贺铨:移动通信开启5G-A新周期,云网融合/算
普通对话 中兴通讯徐子阳:强基慧智,共建数智热带雨
普通对话 邬贺铨:移动通信开启5G-A新周期,云网融合
普通对话 华为轮值董事长胡厚崑:我们正努力将5G-A带
普通对话 高通中国区董事长孟樸:5G与AI结合,助力提
普通对话 雷军发布小米年度演讲:坚持做高端,拥抱大
普通对话 闻库:算网融合正值挑战与机遇并存的关键阶
普通对话 工信部副部长张云明:我国算力总规模已居世
普通对话 邬贺铨:我国互联网平台企业发展的新一轮机
普通对话 张志成:继续加强海外知识产权保护工作 为助
普通对话 吴春波:华为如何突破美国6次打压的逆境?
通信前瞻
亨通光电实践数字化工厂,“5G+光纤”助力新一
普通对话 亨通光电实践数字化工厂,“5G+光纤”助力新
普通对话 中科院钱德沛:计算与网络基础设施的全面部
普通对话 工信部赵志国:我国算力总规模居全球第二 保
普通对话 邬贺铨院士解读ChatGPT等数字技术热点
普通对话 我国北方海区运用北斗三号短报文通信服务开
普通对话 华为云Stack智能进化,三大举措赋能政企深度
普通对话 孟晚舟:“三大聚力”迎接数字化、智能化、
普通对话 物联网设备在智能工作场所技术中的作用
普通对话 软银研发出以无人机探测灾害被埋者手机信号
普通对话 AI材料可自我学习并形成“肌肉记忆”
普通对话 北斗三号卫星低能离子能谱仪载荷研制成功
普通对话 为什么Wi-Fi6将成为未来物联网的关键?
普通对话 马斯克出现在推特总部 收购应该没有悬念了
普通对话 台积电澄清:未强迫员工休假或有任何无薪假
普通对话 新一代载人运载火箭发动机研制获重大突破
推荐阅读
Copyright @ Cntxj.Net All Right Reserved 通信界 版权所有
未经书面许可,禁止转载、摘编、复制、镜像