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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

目  录

1 综述··· 1

2 开放性技术··· 1

2.1 RPM·· 1

2.2 容器·· 2

2.2.1 容器简介·· 2

2.2.2 Comware V9支持的容器·· 2

2.3 RESTful 3

2.3.1 RESTful简介·· 3

2.3.2 RESTful工作机制·· 3

2.4 Tcl 3

2.5 Python· 4

2.6 NETCONF· 4

2.6.1 NETCONF协议介绍·· 4

2.6.2 NETCONF协议结构·· 4

2.6.3 NETCONF基本网络架构·· 5

2.7 Ansible· 5

2.7.1 Ansible简介·· 5

2.7.2 Ansible网络架构·· 5

2.7.3 Ansible工作机制·· 6

2.7.4 Ansible特点·· 6

2.8 gRPC· 7

2.8.1 gRPC简介·· 7

2.8.2 gRPC协议栈·· 7

2.8.3 gRPC网络架构·· 8

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

2.9 INT· 9

2.9.1 INT简介·· 9

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

2.10 Telemetry Stream·· 9

2.10.1 Telemetry Stream简介·· 9

2.10.2 Telemetry Stream运行机制·· 9

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

2.11 ERSPAN· 10

2.12 Flow Group和MOD·· 11

2.12.1 Flow Group和MOD简介·· 11

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

3 参考文献··· 11

 

1  综述

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

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

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

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

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

Comware V9具有良好的开放性。

·     Comware V9运行在原生的Linux系统上，使用不做任何修改的内核，为第三方软件提供标准的Linux运行环境。用户自行开发的Linux软件、标准的Linux开源软件都可以无缝运行在Comware V9系统上，从而加速新业务的上线。Comware V9实现了完全的模块化和故障隔离，运行在Comware V9系统上的第三方软件出现故障后，不会对Comware V9系统自带的模块造成影响，Comare V9系统仍然可以正常运行。

·     Comware V9支持容器化，可以在Comware V9上部署容器，以运行第三方应用。用户可以在Comware V9设备上部署Guest Shell容器和Docker容器，运行基于Guest Shell容器的应用、基于Docker容器的应用。这些应用只需遵循Docker容器相关打包、编排、运行要求，就能在设备上运行。

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

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

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

2  开放性技术

2.1  RPM

用户可以在Comware V9系统上部署基于RPM（Red-Hat Package Manager，Red-Hat软件包管理工具）技术打包的应用。使用Comware提供的RPM接口，用户可以快速、简便地安装、运行和管理RPM应用，从而扩展设备的功能，简化用户对应用的管理和维护。

RPM应用运行在Comware系统中，和Comware系统自带的应用一样，共享Comware系统资源和网络参数，包括接口、IP地址、IP路由表和端口号等。

2.2  容器

2.2.1  容器简介

容器技术是一种轻量级的虚拟化技术。一个容器是一个标准的软件单元，它可以对应一个应用（单独提供一种服务），也可以对应一组应用（多个应用相互配合提供服务）。它包含软件运行所需的程序、环境变量、系统库、配置等数据和文件。一个宿主机上可以部署多个容器，各个容器共享宿主机内核，但容器间互相隔离，属于操作系统层面的虚拟化技术。常见的容器管理应用主要有Docker、LXC等。

Comware V9采用容器化架构。用户可以通过容器独立开发和部署新的应用，以方便快捷地补充Comware V9系统提供的功能，使得Comware的开放性显著提升。

2.2.2  Comware V9支持的容器

Comware V9支持三种容器：Comware容器、Guest Shell容器和基于Docker的第三方应用容器。不同的容器独立运行，相互隔离。某一个容器故障，不会影响其它容器的运行。

1. Comware容器

Comware容器中封装了Comware系统，提供交换、路由等基本功能。Comware系统配置管理以及核心业务运行在Comware容器中。

2. Guest Shell容器

为便于用户在Comware系统中安装和运行第三方软件，且不影响Comware容器的运行，H3C提供了另一种官方容器——Guest Shell容器。Guest Shell容器内嵌了CentOS 7系统，通过Guest Shell容器，用户可在Comware V9设备上安装基于CentOS 7系统开发的应用。例如，用户可在Guest Shell容器内安装第三方网管或控制器的代理应用，由该代理应用收集设备和网络的状态等信息，并上报给第三方网管或控制器，同时可以通过代理应用接受第三方网管或控制器下发的指令来管理和控制设备。

Guest Shell容器支持CentOS 7官方Docker镜像版本所支持的所有命令。

Guest Shell容器和宿主机、Comware容器、第三方应用容器完全隔离，用户在Guest Shell容器中安装、操作应用不会影响其它容器的运行。

Guest Shell容器与直接使用CentOS 7的镜像文件运行CentOS 7容器比较，还具有以下优势：

·     Guest Shell容器由H3C提供镜像文件，在设备上安装该镜像文件后，即能运行Guest Shell容器。

·     Comware系统对Guest Shell容器的命令行进行了封装。登录Comware系统后，用户执行简单的guestshell命令行，即可便捷地对Guest Shell容器进行管理和维护。

3. 第三方应用容器

有些应用是以容器的形式发布的。为了支持这类应用，Comware V9系统集成了Docker容器管理功能。用户使用简单的命令行，就可以在Comware V9系统上部署基于Docker的第三方应用容器，以实现信息采集、设备状态监控等用户自定义功能。例如，每台设备运行一个资源采集的Agent容器，用来实时采集设备的CPU、内存、流量等信息，并上报至监控设备统一管理。

Comware V9支持Kubernetes技术，可作为一个工作节点接受Kubernetes Master的调度和管理，实现第三方应用的大规模、集群化部署。

2.3  RESTful

2.3.1  RESTful简介

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

2.3.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.4  Tcl

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

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

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

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

2.5  Python

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

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

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

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

2.6  NETCONF

2.6.1  NETCONF协议介绍

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

2.6.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.6.3  NETCONF基本网络架构

图2 NETCONF基本网络架构

 

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

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

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

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

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

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

2.7  Ansible

2.7.1  Ansible简介

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

2.7.2  Ansible网络架构

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

图3 Ansible网络架构

 

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

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

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

2.7.3  Ansible工作机制

Ansible的工作机制为：

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

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

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

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

2.7.4  Ansible特点

Ansible具有如下特点：

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

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

·     支持批量部署。

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

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

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协议栈

图4 gRPC协议栈分层

 

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

·     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网络架构

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

图5 gRPC网络架构

 

gRPC网络的工作机制如下：

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

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

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

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

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

图6 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运行机制

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

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

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

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

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

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

¡     入接口时间戳（Rx Timestamp）

¡     出接口时间戳（Tx Timestamp）

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

图7 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 V9体系结构技术白皮书》

·     《容器技术白皮书》

·     《Telemetry技术白皮书》