Comware V7开放可编程技术白皮书

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

目  录

1 综述··· 1

2 开放性技术··· 1

2.1 RESTful 1

2.1.1 RESTful简介·· 1

2.1.2 RESTful工作机制·· 2

2.2 Tcl 2

2.3 Python· 2

2.4 NETCONF· 3

2.4.1 NETCONF协议介绍·· 3

2.4.2 NETCONF协议结构·· 3

2.4.3 NETCONF基本网络架构·· 4

2.5 Ansible· 4

2.5.1 Ansible简介·· 4

2.5.2 Ansible网络架构·· 4

2.5.3 Ansible工作机制·· 5

2.5.4 Ansible特点·· 5

2.6 Puppet 5

2.6.1 Puppet简介·· 5

2.6.2 Puppet网络架构·· 6

2.6.3 Puppet特点·· 6

2.7 Chef 7

2.7.1 Chef简介·· 7

2.7.2 Chef网络架构·· 7

2.7.3 Chef特点·· 8

2.8 gRPC· 8

2.8.1 gRPC简介·· 8

2.8.2 gRPC协议栈·· 9

2.8.3 gRPC网络架构·· 9

2.8.4 Dial-in模式和Dial-out模式·· 10

2.9 INT· 10

2.9.1 INT简介·· 10

2.9.2 INT采集的数据信息·· 11

2.10 Telemetry Stream·· 11

2.10.1 Telemetry Stream简介·· 11

2.10.2 Telemetry Stream运行机制·· 11

2.10.3 Telemetry Stream可监控的数据信息·· 12

2.11 ERSPAN· 12

2.12 Flow Group和MOD·· 13

2.12.1 Flow Group和MOD简介·· 13

2.12.2 Flow Group和MOD工作机制·· 13

3 参考文献··· 13

 

1  综述

随着网络的普及和新技术的涌现，网络规模日益增大，部署和维护的复杂度逐步提升。传统的人工运维和半人工半自动化运维方式已无法满足用户需求，主要表现在如下几个方面：

·     新业务上线周期长。用户如果有新的业务需求，则需要经过需求分析—功能开发—测试验证—发布等阶段，才能完成新业务上线。无法及时推出新业务，可能会导致用户错失新业务市场。

·     网络设备数量庞大时，手工配置的工作量巨大，且容易出错。

·     不同厂商设备的接口标准不同。每个厂商的SDN控制器通常只能控制和管理自己的设备，无法实现全网端到端的自动化部署。

由此可见，网络运维亟需实现自动化和智能化。而自动化和智能化运维需要依赖于网络设备的开放性，才能得以实现。

Comware V7具有良好的开放性。

·     Comware V7使用通用的Linux操作系统，提供开放的标准编程接口。开源程序或用户自行编写的程序，通过Comware V7的交叉编译环境，编译通过后，即可在Comware V7系统上运行，从而提升Comware V7系统的开放性，加快新业务上线的速度。

·     Comware V7具有可编程性，允许管理员通过第三方系统（如RESTful客户端、NETCONF客户端）来操作设备上的业务，对设备进行管理和业务部署。例如，采用RESTful、NETCONF等方式通过标准的API（Application Programmatic Interface，应用可编程接口）对设备进行管理。Comware V7的可编程框架提供了丰富的配置手段，可以适配各种自动化配置模型，提升了网络部署效率。同时，Comware V7提供对外发布的编程环境和接口，管理员可以利用编程接口开发独有的功能。

·     Comware V7支持可视化，可以通过Telemetry监控设备性能和网络运行情况。Telemetry（网络遥测）是一项监控设备性能和故障的远程数据采集技术。Telemetry可以及时获取丰富的监控数据，快速定位和处理网络故障，实现网络的可视化运维。常用的Telemetry技术包括gRPC、INT等。

本文将列举Comware V7支持的主要开放性技术，并对其进行简要介绍。

2  开放性技术

2.1  RESTful

2.1.1  RESTful简介

REST（Representational State Transfer，表象化状态转变）是一种面向资源的轻量级、跨平台、跨语言的程序架构，具有结构清晰、易于管理和扩展等特点。RESTful是遵循REST程序架构的一种应用。Comware设备提供了RESTful API接口，用户可以通过RESTful功能操作RESTful API接口，从而实现对Comware设备进行配置和维护。

2.1.2  RESTful工作机制

如图1所示，RESTful采用C/S模型。RESTful客户端为使用Python、Ruby或Java等编程语言开发出的RESTful客户端程序或脚本。RESTful服务器为网络设备。通过RESTful功能配置和维护设备的过程为：

(1)     客户端向服务器发送HTTP/HTTPS请求报文，通过HTTP的方法来操作指定的RESTful API接口。RESTful支持的HTTP操作方法包括GET、PUT、POST和DELETE。

(2)     服务器根据HTTP/HTTPS请求报文，完成对指定RESTful API接口的操作后，通过HTTP/HTTPS应答报文将操作结果返回给客户端。

在HTTP/HTTPS请求和应答报文中，请求和应答数据均采用JSON格式进行编码。

图1 RESTful功能示意图

 

2.2  Tcl

Comware V7系统内嵌了Tcl（Tool Command Language，工具命令语言）解析器，支持直接在设备上执行Tcl脚本命令，以实现通过Tcl脚本配置设备。

在用户视图下执行tclsh命令，会进入Tcl配置视图。为兼容Comware配置方式，在Tcl配置视图下，用户可以直接输入Tcl脚本命令，也可以输入Comware系统的命令。命令输入完成后，直接回车即可执行。

Tcl配置视图下，支持Tcl8.5版本的所有命令。

对于Comware系统的命令，Tcl配置视图相当于用户视图，配置方式同用户视图下的配置。

2.3  Python

Python是一种简单易学、功能强大的编程语言，它有高效率的高层数据结构，简单而有效地实现了面向对象编程。Python简洁的语法和对动态输入的支持，再加上解释性语言的本质，使得它在大多数平台上的许多领域都是一个理想的脚本语言，特别适用于快速的应用程序开发。

在Comware V7系统上可以采用如下方式使用Python：

·     通过python命令执行Python脚本进行自动化配置系统。

·     进入Python shell，使用Python2.7版本的命令、标准API或扩展API对设备进行配置。其中，扩展API是Comware对Python进行的扩展，用来方便用户进行系统配置。

2.4  NETCONF

2.4.1  NETCONF协议介绍

NETCONF（Network Configuration Protocol，网络配置协议）是一种基于XML的网络管理协议，它提供了一种可编程的、对网络设备进行配置和管理的方法。用户可以通过该协议设置属性、获取属性值、获取统计信息等。这使得它在第三方软件的开发上非常便利，很容易开发出在混合不同厂商、不同设备的环境下的特殊定制的网管软件。

2.4.2  NETCONF协议结构

NETCONF协议采用分层结构，分为内容层（Content）、操作层（Operations）、RPC（Remote Procedure Call，远程调用）层和通信协议层（Transport Protocol）等。

表1 XML分层与NETCONF分层模型对应关系

NETCONF分层	XML分层	说明
内容层	配置数据、状态数据、统计信息等	被管理对象的集合，可以是配置数据、状态数据、统计信息等 NETCONF协议具体可读写的数据请参见《NETCONF XML API 手册》
操作层	<get>,<get-config>,<edit-config>…	在RPC中应用的基本的原语操作集，这些操作组成NETCONF的基本能力 NETCONF全面地定义了对被管理设备的各种基础操作
RPC层	<rpc>,<rpc-reply>	为RPC模块的编码提供了简单的、传输协议无关的机制。通过使用<rpc>和<rpc-reply>元素分别对NETCONF请求和响应数据（即操作层和内容层的内容）进行封装
通信协议层	非FIPS模式下：Console/Telnet/SSH/HTTP/HTTPS/TLS FIPS模式下： Console/SSH/HTTPS/TLS	为NETCONF提供面向连接的、可靠的、顺序的数据链路 非FIPS模式下： ·     NETCONF支持Telnet、SSH和Console等CLI登录方式/协议，即NETCONF over SSH、NETCONF over Telnet和NETCONF over Console ·     NETCONF支持HTTP和HTTPS协议，即NETCONF over HTTP和NETCONF over HTTPS ·     NETCONF支持封装成SOAP（Simple Object Access Protocol，简单对象访问协议）报文后通过HTTP或HTTPS协议传输，即NETCONF over SOAP over HTTP和NETCONF over SOAP over HTTPS FIPS模式下： ·     NETCONF支持SSH和Console等CLI方式/协议，即NETCONF over SSH和NETCONF over Console ·     NETCONF支持HTTPS登录协议，即NETCONF over HTTPS ·     NETCONF支持封装成SOAP报文后通过HTTPS协议传输，即NETCONF over SOAP over HTTPS

 

2.4.3  NETCONF基本网络架构

图2 NETCONF基本网络架构

 

NETCONF网络主要由NETCONF客户端和NETCONF服务器组成：

·     客户端上需要安装NETCONF客户端软件（如ncclient、NetconfBrowser），或运行基于SOAP请求的脚本或程序。客户端的主要作用为：

¡     通过NETCONF协议对网络设备进行配置和管理。

¡     主动查询网络设备的状态。

¡     接收网络设备主动发送的告警和事件，以获知网络设备的当前状态。

·     服务器（即待管理网络设备）上需要运行NETCONF服务端程序，即支持NETCONF功能。服务器主要用于响应客户端的请求，并在发生故障或事件时，主动通告给客户端。

2.5  Ansible

2.5.1  Ansible简介

Ansible是基于Python开发的自动化运维工具，集合了众多运维工具的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。该工具使用SSH（Secure Shell）协议与网络设备建立连接，实现对网络设备的集中配置管理。

2.5.2  Ansible网络架构

如图3所示，Ansible系统由管理端和设备端组成。

图3 Ansible网络架构

 

·     管理端（Manager）：指安装了Ansible环境的主机。关于Ansible软件的安装，请参见Ansible的官方网站。

·     设备端（Device）：设备端仅需支持作为SSH服务器，无需安装任何客户端代理软件。设备端和管理端建立SSH连接后，自动执行管理端下发的配置。

Comware设备支持作为Ansible系统的设备端。

2.5.3  Ansible工作机制

Ansible的工作机制为：

(1)     在管理端上编辑配置文件。

(2)     管理端和设备端建立SSH连接。管理端为SSH客户端，设备端为SSH服务器。

(3)     管理端给单个或多个设备下发配置。

(4)     设备端自动执行管理端下发的配置。

2.5.4  Ansible特点

Ansible具有如下特点：

·     管理端基于SSH与设备端建立连接、交互数据，无需在设备端上安装客户端软件，易于部署。

·     基于Python语言，易于学习和理解。

·     支持批量部署。

·     采用“推模式”配置和管理设备，即管理端将配置下发给设备端。

·     Ansible专注于精简和快速，适用于设备需要快速上线运行的场景。

2.6  Puppet

2.6.1  Puppet简介

Puppet是开源的配置管理工具，用户使用Puppet语言将需要对设备进行的配置写成脚本，并保存到服务器中，再通过服务器把这些配置脚本下发到各网络设备，实现对网络设备的集中配置管理。

2.6.2  Puppet网络架构

图4 Puppet网络架构

 

如图4所示，Puppet采用“服务器端/客户端”网络架构，服务器端称为Puppet master，客户端称为Puppet agent，Puppet master与Puppet agent之间使用通过SSL加密的连接进行通信。

1. Puppet master

Puppet master用于对Puppet agent进行集中管理，其主要功能如下：

·     以守护进程的方式运行，监听Puppet agent的请求。

·     建立连接时，Puppet master需要对Puppet agent进行认证。

·     集中保存配置脚本，并根据用户要求将配置脚本下发到Puppet agent。

关于Puppet master的详细安装和配置，请参见Puppet官方网站：https://puppetlabs.com。

2. Puppet agent

Puppet网络中，由Puppet master集中管理的设备称为Puppet agent。Puppet agent的工作过程如下：

(1)     Puppet agent启动Puppet进程，并向Puppet master发起认证请求。

(2)     Puppet agent默认会周期性（缺省为2分钟）检查认证是否通过，认证通过后，Puppet agent与Puppet master建立连接。

(3)     Puppet agent与Puppet master建立连接后，Puppet agent周期性（缺省为30分钟）向Puppet master发送请求获取最新配置。

(4)     Puppet agent获取到最新配置，并将最新配置与设备当前运行的配置进行对比，如果设备当前运行配置与获取的配置不同，则运行最新配置。

(5)     Puppet agent完成配置后，向Puppet master反馈配置结果。

Comware设备中，Puppet以Puppet agent方式运行，版本为3.7.3。

2.6.3  Puppet特点

Puppet具有如下特点：

·     出现较早，较为成熟和稳定。

·     采用“服务器端/客户端”网络架构，客户端上需要安装客户端软件，部署复杂。

·     使用Puppet域特定语言（Puppet DSL），不易于学习。

·     采用“拉模式”配置和管理设备，即客户端主动从服务器端获取最新配置。

·     Puppet主要面向系统管理员。

·     Puppet适用于异构网络。

2.7  Chef

2.7.1  Chef简介

Chef是开源的配置管理工具，用户使用Ruby语言将需要对设备进行的配置写成脚本，并保存到服务器中，再通过服务器把配置脚本下发到各网络设备，实现对网络设备的集中配置管理。

2.7.2  Chef网络架构

图5 Chef网络架构

 

如图5所示，Chef采用“服务器端/客户端”网络架构，由Chef server、Chef client和Workstation构成。

1. Chef server

Chef server用于对Chef client进行集中管理，其主要功能如下：

·     集中保存配置脚本（Cookbook），并根据用户要求将配置脚本下发到Chef client。

·     为Chef client和Workstation分别创建后缀为.pem的密钥文件。密钥文件分为用户密钥文件和组织密钥文件：

¡     用户密钥文件：该文件用来保存Chef client/Workstation的用户认证信息，Chef client/Workstation与Chef server进行通信前，用户需要将该文件分别下载到Chef client/Workstation上，Chef server使用该文件验证Chef client/Workstation的合法性。

¡     组织密钥文件：该文件用来保存用户所在组织的认证信息。用户需要将该文件分别下载到Chef client/Workstation中。为方便对不同的Chef client/Workstation设备进行区分管理，可以将具有同一类属性的Chef client/Workstation划分到同一个组织中。Chef client/Workstation与Chef server进行通信前，Chef server使用该文件验证用户所在组织的合法性。

关于Chef server的详细安装和配置，请参见Chef官方网站：https://www.chef.io。

2. Workstation

Workstation提供了用户与Chef server交互的接口。用户需要在Workstation上创建、编辑配置脚本，并将配置脚本上传到Chef server。

Workstation可以与Chef server安装在同一台服务器上。

关于Workstation的详细安装和配置，请参见Chef官方网站：https://www.chef.io。

3. Chef client

Chef client即为被Chef server管理的网络设备。Chef client从Chef server获取并运行配置脚本，配置脚本运行完成后，设备使用新下发的配置运行。

Comware设备中，Chef以Chef client方式运行，版本为12.3.0。

2.7.3  Chef特点

Chef具有如下特点：

·     采用“服务器端/客户端”网络架构，客户端上需要安装客户端软件，部署复杂。

·     基于Ruby语言，不易于学习。

·     采用“拉模式”配置和管理设备，即客户端主动从服务器端获取最新配置。

·     Chef主要面向开发人员。

·     Chef适用于异构网络。

2.8  gRPC

2.8.1  gRPC简介

gRPC（Google Remote Procedure Call，Google远程过程调用）是Google发布的基于HTTP 2.0协议承载的高性能开源软件框架，提供了支持多种编程语言的、对网络设备进行配置和管理的方法。通信双方可以基于该软件框架进行二次开发。

目前，应用最为广泛的Telemetry技术是基于gRPC的Telemetry。它是一种模型驱动的Telemetry技术，提供protobuf定义文件。第三方软件可以直接使用gRPC与Comware通信，也可以使用基于gRPC封装的H3C SDK接口与Comware通信。

gRPC支持Dial-in和Dial-out两种模式。采用基于gRPC的Telemetry技术时，设备自动读取各种统计信息（CPU、内存、接口等），根据采集器的订阅要求对采集到的数据进行Protocol Buffer编码后，将其通过gRPC协议上报给采集器，实现了比传统监控方式更加实时、高效的数据采集功能。

2.8.2  gRPC协议栈

图6 gRPC协议栈分层

 

gRPC协议栈分层如图6所示。自下而上各层的含义为：

·     TCP传输层：TCP提供面向连接的、可靠的数据链路。

·     TLS（Transport Layer Security，传输层安全）传输层：该层是可选的，设备和采集器可以基于TLS协议进行通道加密和双向证书认证，实现安全通信。

·     HTTP 2.0应用层：gRPC承载在HTTP 2.0协议上，利用了该协议的首部数据压缩、单TCP连接支持多路请求、流量控制等性能增强特性。

·     gRPC层：定义了RPC（Remote Procedure Call，远程过程调用）的协议交互格式。公共RPC方法定义在公共proto文件中，例如grpc_dialout.proto。

·     内容层：用于承载编码后的业务数据。业务数据的编码格式包括：

¡     GPB（Google Protocol Buffer）：高效的二进制编码格式，通过proto文件描述编码使用的数据结构。在设备和采集器之间传输数据时，该编码格式的数据比其他格式（如JSON）的数据具有更高的信息负载能力。

业务数据使用GPB格式编码时，需要配合对应的业务模块proto文件才能解码。

¡     JSON（JavaScript Object Notation）：轻量级的数据交换格式，采用独立于编程语言的文本格式来存储和表示数据，易于阅读和编写。

业务数据使用JSON格式编码时，通过公共proto文件即可解码，无需对应的业务模块proto文件。

设备和采集器通信时，双方的proto文件必须保持一致才能解码。

2.8.3  gRPC网络架构

如图7所示，gRPC网络采用客户端/服务器模型，使用HTTP 2.0协议传输报文。

图7 gRPC网络架构

 

gRPC网络的工作机制如下：

(2)     服务器通过监听指定服务端口来等待客户端的连接请求。

(3)     用户通过执行客户端程序登录到服务器。

(4)     客户端调用.proto文件提供的gRPC方法发送请求消息。

(5)     服务器回复应答消息。

H3C设备支持作为gRPC服务器或者gRPC客户端。

 

2.8.4  Dial-in模式和Dial-out模式

设备支持以下两种gRPC对接模式：

·     Dial-in模式：设备作为gRPC服务器，采集器作为gRPC客户端。由采集器主动向设备发起gRPC连接并订阅需要采集的数据信息。

Dial-in模式支持以下操作：

¡     Get操作：获取设备运行状态和运行配置。

¡     gNMI（gRPC Network Management Interface，gRPC网络管理接口）类操作，具体包括：

-     gNMI Capabilities操作：获取设备的能力集。

-     gNMI Get操作：获取设备运行状态和运行配置。

-     gNMI Set操作：向设备下发配置。

-     gNMI Subscribe操作：向设备订阅数据推送服务，包括事件触发类数据和周期采样类数据。该操作实现的功能与gRPC Dial-out模式类似。

¡     CLI操作：向设备下发命令行。

Dial-out模式：设备作为gRPC客户端，采集器作为gRPC服务器。设备主动和采集器建立gRPC连接，将设备上配置的订阅数据推送给采集器。

2.9  INT

2.9.1  INT简介

INT（In-band Telemetry，带内遥测）是一项从设备上采集数据的网络监控技术。如图8所示，报文传输路径上的首节点和中间节点将采集到的数据添加到报文中，尾节点通过报文获取到采集数据后，将其上送给采集器，部署在采集器上的网管软件对监测数据进行分析、提取有用信息，以达到对网络设备的性能及网络运行情况进行监控的目的。

图8 INT运行机制示意图

 

2.9.2  INT采集的数据信息

INT主要用来采集报文经过的路径和报文传输时延等数据平面信息。INT监控粒度为单个数据包，可以实现完整的网络状态实时监控。通过INT技术，可以监测到报文转发路径上每台设备的入出端口和队列信息、入出设备的时间戳信息、队列的拥塞信息等。

2.10  Telemetry Stream

2.10.1  Telemetry Stream简介

Telemetry Stream是一种基于报文采样的网络流量监控技术，主要用于对流量传输路径和传输时延进行精确定位。在实时性要求较高的网络中，需要能精准定位出哪台设备的哪个端口上转发报文最耗时。网络设备带有支持Telemetry Stream的芯片时，可以采集报文在本设备上的入/出端口、报文入/出设备的时间戳信息并主动上报给采集器，使网管软件能监测到报文在网络中的传输路径和传输时延，从而可以针对性地下发配置来优化网络架构，降低网络延迟。

2.10.2  Telemetry Stream运行机制

以图9中的Device B为例，Telemetry Stream工作机制如下：

(1)     所有参与测量的设备使用PTP达到纳秒级时间同步。

(2)     设备在入接口通过ACL筛选原始报文，对命中规则的报文，按设定的采样率抽取部分报文进行复制。

(3)     设备为复制的报文封装如下报文头：

¡     Telemetry Stream填充头（记录原始报文的入端口和出端口）

¡     UDP头和二三层头（记录采集器的端口号和MAC/IP地址）

¡     入接口时间戳（Rx Timestamp）

¡     出接口时间戳（Tx Timestamp）

(4)     设备将采样报文发送给采集器。采样报文的入接口时间戳和出接口时间戳中包含了报文所属的设备信息（设备ID）。

图9 Telemetry Stream工作机制示意图

 

多个节点均各自向采集器上送采集信息，采集器就可以根据收集到的采集信息进行路径和时延计算：

·     流量经过指定设备的传输时延 = 该设备的出接口时间戳 – 该设备的入接口时间戳

·     流量经过多台设备的传输时延 = 出接口所在设备的出接口时间戳 – 入接口所在设备的入接口时间戳

2.10.3  Telemetry Stream可监控的数据信息

Telemetry Stream可监测的数据信息为：设备ID、流量入接口及其时间戳、流量出接口及其时间戳。其中，设备ID是配置Telemetry Stream功能时指定的Device ID，用于唯一标识报文传输路径上的设备。

2.11  ERSPAN

ERSPAN（Encapsulated Remote Switch Port Analyzer，封装远程端口镜像）是一种三层远程镜像技术，通过复制指定端口、VLAN或CPU的报文，并通过GRE隧道将复制的报文发送到远程数据监测设备，使用户可以利用数据监测设备分析这些报文（称为镜像报文），以进行网络监控和故障排除。

用户可以根据实际需求定义待镜像的报文，例如镜像TCP三次握手报文以便监控TCP连接建立情况、镜像RDMA信令报文以便监控RDMA会话状态。

ERSPAN支持端口镜像和流镜像两种实现方式。

2.12  Flow Group和MOD

2.12.1  Flow Group和MOD简介

MOD（Mirror On Drop，丢包镜像）是一种专门用来监控报文在设备内部转发过程中发生丢包的技术。一旦MOD监控到设备内部发生丢包，就会立即收集丢包发生的时间、丢包原因和丢弃报文特征，并上报给远端采集器，以便管理员及时了解设备内部发生的丢包情况。

MOD基于Flow Group建立的流表进行丢包检测。Flow Group是一种流表模板。用户可以为Flow Group指定流表的生成规则，设备依据流表生成规则提取流量特征（这里指报文头中的相关信息，例如五元组等），生成流表。

2.12.2  Flow Group和MOD工作机制

MOD基于Flow Group检测丢包的工作机制如下：

(1)     基于Flow Group生成流表。

(2)     基于MOD的相关配置，设备对命中流表项的流量进行丢包监控。

(3)     如果发生丢包，则设备将丢包原因和丢弃报文的特征（即被丢弃报文所匹配的流表表项）上送给采集器。

3  参考文献

·     《Comware V7体系结构技术白皮书》

·     《Telemetry技术白皮书》