CN113055220A

CN113055220A - 基于云的nat环境的可缩放且鲁棒的网络管理

Info

Publication number: CN113055220A
Application number: CN202010432705.6A
Authority: CN
Inventors: R·S·德谢穆科; R·沙里夫; P·博克; G·K·马格卢鲁
Original assignee: Juniper Networks Inc
Current assignee: Juniper Networks Inc
Priority date: 2019-12-26
Filing date: 2020-05-20
Publication date: 2021-06-29
Anticipated expiration: 2040-05-20
Also published as: EP3843334A1; EP3843334B1; CN113055220B

Abstract

本公开的实施例涉及基于云的NAT环境的可缩放且鲁棒的网络管理。描述了可缩放的鲁棒的基于云的网络管理系统(NMS)。在一个示例中，一种NMS包括NMS应用的集合、设备通信管理器(DCM)池和设备操作管理器(DOM)池。DCM和DOM中的每一者由处理器作为软件容器执行。NMS包括被配置为根据被管理元件的设备标识符经由DOM所暴露的API来将来自DCM的远程过程调用(RPC)路由到DOM的API网关。DOM被配置为建立从DOM到DCM的持久性应用层通信会话的集合，并且根据与被管理元件相关联的设备标识符和与DCM相关联的网络地址之间的映射通过持久性应用层通信会话来将来自NMS应用的通信引导到DCM。

Description

基于云的NAT环境的可缩放且鲁棒的网络管理

技术领域

本公开涉及计算机网络，并且更具体地涉及用于配置和管理网络设备的网络管理系统。

背景技术

计算机网络是可以交换数据和共享资源的互连计算设备的集合。在典型的基于云的计算环境中，大量的互连服务器提供了用于执行客户网络的各种应用和服务的计算和/或存储能力。在大多数云计算环境中，存储系统和应用服务器的集群是经由高速分组交换网络互连的，该高速分组交换网络通常包括路由器、交换机、网关、防火墙和各种其他设备，以提供和支持网络通信。

网络设备(在本文中也被称为网络元件)通常包括诸如管理接口等机制，管理员能够通过该机制在本地或远程地配置设备。通过与管理接口交互，诸如人类用户、自动化脚本或网络管理系统(NMS)等各种客户端可以执行配置任务并且收集和查看被管理设备的操作数据。例如，网络管理系统通常提供集中式存储库，其存储并且向被管理设备部署配置数据和策略，例如，以配置设备的硬件组件、调节所支持的网络协议的参数、指定设备内的物理组件、修改由路由器维持的路由信息、访问驻留在设备上的软件模块和其他资源、以及执行其他配置任务。另外，网络管理系统可以通过轮询被管理设备或者通过从设备接收异步事件来接收信息。例如，被管理设备的管理接口可以由NMS用来访问当前的操作参数、系统日志、与网络连接有关的信息、网络活动或设备的其他状态信息，以允许客户端查看从设备接收的事件信息并且对事件信息做出反应。

通过NMS对基于云的计算环境进行管理提出了某些技术挑战，尤其是当这样的计算环境的规模可能大规模增长以托管成千上万个被管理网络设备时。

发明内容

总体上，本公开描述了用于使用基于云的网络管理系统(NMS)对设备进行网络管理的可缩放的鲁棒的技术和系统。该技术对于如下网络环境特别有用：其中设备发起的管理会话被利用和/或其中被管理元件的网络地址经常变化，诸如当NMS和被管理元件通过网络地址转换(NAT)服务或设备被分离时。

描述了各种示例，其中基于云的NMS利用多个NMS微服务向相应被管理网元提供NMS服务。此外，描述了其中两种类型的微服务容器协同工作以处理网络元件的管理会话的技术。每种类型的微服务可以分别被部署，并且可以独立于其他微服务进行扩展。特别地，设备通信管理器(DCM)微服务容器池负责接受和管理设备连接。设备操作管理器(DOM)微服务容器池负责为其他微服务和应用对设备执行操作提供接口。

在NMS内使用非对称通信机制。例如，REST API使用由NMS为每个被管理元件(例如，UUID)定义的唯一设备标识符作为HTTP cookie或HTTP报头对API网关的调用用于将通信从DCM路由到DOM，以传递到更高层级的NMS应用，从而通过API网关相对于UUID建立会话亲和力(affinity)。在相反的方向上，NMS应用在DOM上调用REST API，以将管理元件的唯一标识符(UUID)传递到HTTP报头或HTTP cookie中。由于会话亲和力，由于UUID被构造为作为HTTP cookie或HTTP报头的REST调用的一部分，API网关将REST调用自动路由到适当的DOM。也就是说，对于相同的UUID，API网关将REST调用路由到会话管理职责最初被路由到的同一后端DOM容器。在NMS内使用持久性通信会话(例如，HTTP2会话)来绕过API网关，并且改为将具有唯一cookie的通信从DOM直接路由到DCM，以便将命令和指令从NMS应用传递到被管理元件。

在一个示例中，一种网络管理系统包括被配置为在一个或多个处理器上执行的一个或多个网络管理系统(NMS)应用的集合。NMS还包括设备通信管理器(DCM)池，每个DCM由处理器作为软件容器执行，并且每个DCM被配置为接受和管理与网络内的多个被管理元件之一的管理会话。NMS还包括设备操作管理器(DOM)池，每个DOM由处理器作为软件容器执行，并且每个DOM被配置为呈现用于根据被管理元件的设备标识符来对被管理元件执行操作的应用程序编程接口(API)。NMS的API网关被配置为根据如在来自DCM的远程过程调用(RPC)内指定的被管理元件的设备标识符，以经由DOM公开的API来将RPC路由到DOM。DOM被配置为建立从DOM到DCM的一组持久性应用层通信会话，并且根据与被管理元件相关联的设备标识符和与DCM相关联的网络地址之间的映射以通过持久性应用层通信会话来将来自NMS应用的通信引导到DCM。

在另一示例中，一种方法包括：从被管理元件接收与设备通信管理器(DCM)池中的第一DCM建立管理会话的请求，每个DCM由NMS的一个或多个处理器作为软件容器执行。该方法包括作为响应，经由应用程序编程接口(API)网关将来自第一DCM的远程过程调用发布给由NMS的一个或多个处理器执行的设备操作管理器(DOM)池中的第一DOM，每个DOM由NMS的处理器作为软件容器执行，并且每个DOM被配置为呈现用于根据被管理元件的设备标识符来对被管理元件执行操作的API。该方法还包括与第一DOM建立从第一DOM到第一DCM的持久性应用层通信会话；利用第一DOM并根据与被管理元件相关联的设备标识符和与DCM相关联的网络地址之间的映射，以通过持久性应用层通信会话来将来自一个或多个NMS应用的集合的命令引导到第一DCM；以及经由管理会话以将来自所述第一DCM的命令发布给被管理元件。

在一些示例中，一种计算机可读存储介质包括指令，该指令在被执行时引起网络管理系统的处理器实现本文中描述的方法。

一个或多个示例的细节在附图和以下描述中阐述。根据说明书和附图以及根据权利要求书，其他特征、目的和优点将很清楚的。

附图说明

图1是示出示例性的基于云的计算环境的框图，其中网络管理系统(NMS)管理大量网络元件；

图2是示出用于图1的网络管理系统的一组示例组件的框图；

图3是示出用于图1和2的网络管理系统的组件的处理流程的框图；以及

图4是示出根据本文中描述的技术的用于网络管理系统的示例操作的流程图。

具体实施方式

图1是示出示例计算环境2的框图，该示例计算环境2包括使用管理网络18的基于云的网络管理系统(NMS)10来管理的被管理网络4的元件。网络2的被管理元件14A-14G(统称为“元件14”)包括经由通信链路互连以形成通信拓扑以便交换资源和信息的网络设备。元件14(通常也称为网络设备或远程网络设备)可以包括例如路由器、交换机、网关、网桥、集线器、服务器、防火墙或其他入侵检测系统(IDS)或入侵防御系统(IDP)、计算设备、计算终端、打印机、其他网络设备、或这样的设备的组合。虽然在本公开中被描述为传输、传达或以其他方式支持分组，但是网络2可以根据由任何其他协议定义的任何其他离散数据单元(诸如由异步传输模式(ATM)协议定义的信元(cell)或由用户数据报协议(UDP)定义的数据报)来传输数据。互连元件14的通信链路可以是物理链路(例如，光、铜等)、无线链路或其任何组合。

通常，管理员12使用一种或多种设备管理协议与NMS 10交互以管理网络元件14。例如，管理员12与NMS 10交互以远程监测和配置元件14。例如，管理员12可以从NMS 10接收关于任何元件14的警报、查看元件14的配置数据、修改元件14的配置数据，向网络2添加新的网络设备、从网络2中删除现有网络设备、或者以其他方式操纵网络2和其中的网络设备。用于NMS 10与网络元件14之间的通信的一种示例设备协议是简单网络管理协议(SNMP)，其允许NMS 10遍历和修改在每个被管理元件14内存储配置数据的管理信息库(MIB)。SNMP协议的其他细节可以在从http://tools.ietf.org/html/rfc3411可获取的2002年12月的网络工作组的互联网工程任务组草稿的Harrington等人的RFC 3411“描述简单网络管理协议(SNMP)管理框架的架构”中找到，其全部内容通过引用并入本文。

在某些示例中，管理员12使用NMS 10或本地工作站以通过相应管理会话15(例如，安全外壳(SSH)会话或其他这样的通信会话)直接与元件1交互。也就是说，元件14通常提供用于直接交互的接口，诸如命令行接口(CLI)、基于网络的接口、图形用户界面(GUI)等，用户可以通过该接口与设备交互以直接发布(issue)命令。例如，这些接口通常允许用户根据定义的语法与设备直接交互以提交命令。另外，管理员12还可以创建可以由NMS 10提交给任何或所有元件14的脚本。例如，除了CLI接口，元件14还提供用于接收脚本的接口，该脚本根据脚本语言来指定命令。在某种意义上，脚本可以由NMS 10输出以在被管理元件14上自动调用对应的远程过程调用(RPC)。脚本可以符合例如可缩放标记语言(XML)或另一种数据描述语言。

管理员12使用NMS 10来将元件14配置为指定某些操作特性，从而进一步实现管理员12的目标。例如，管理员12可以为元件14指定关于以下的特定操作策略：安全性、设备可访问性、流量工程、服务(QoS)质量、网络地址转换(NAT)、分组过滤、分组转发、速率限制或其他策略。NMS 10使用被设计用于管理被管理网络元件14内的配置数据以执行配置的一种或多种网络管理协议，诸如SNMP协议或网络配置协议(NETCONF)协议或其派生协议，诸如Juniper设备管理接口。通常，NETCONF提供用于配置网络设备的机制，并且对配置数据使用基于可缩放标记语言(XML)的数据编码，该配置数据可以包括策略数据。NETCONF在从tools.ietf.org/html/rfc4741可获取的2006年12月的网络工作组的RFC 4741的Enns的“NETCONF配置协议”中描述。NMS 10可以与一个或多个元件14建立NETCONF会话。

在图1的示例中，NMS 10是通过网络地址转换(NAT)设备12与被管理元件10分离的基于云的网络管理系统。通常，NAT设备10对与管理会话15相关联的分组流的分组内的网络地址(IP地址)进行转换。例如，在分组流经NAT设备10时，NAT设备10可以将被管理网络4的私有网络地址转换为可路由到管理网络18的公共网络地址。术语“分组流”、“业务流”或简单的“流”是指源自特定源设备并且被发送到特定目的地设备的分组集合。出站(源自网络元件14之一)或入站(目的地为网络元件14之一)方向上的单个分组流可以通过例如5元组来标识：<源网络地址，目的地网络地址，源端口，目的地端口，协议>。一对出站分组和入站分组(即，分组流)可以是同一通信会话(诸如一个或多个管理会话15)的一部分。该5元组通常标识所接收的分组与之相对应的分组流。n元组是指从5元组中提取的n个项目。例如，分组的2元组可以是指分组的<源网络地址，目的地网络地址>或<源网络地址，源端口>的组合。

在一些示例实现中，NMS 10提供基于云的可缩放的鲁棒的NMS系统，其中多个NMS微服务22中的每个向与多个管理会话15中的每个相关联的相应被管理元件14提供NMS服务。也就是说，每个NMS微服务22作为相应管理会话15的端点进行操作，并且向与特定管理会话15相关联的被管理元件14提供NMS服务。例如，在一个示例中，每个被管理元件14可以通过向NMS 10输出SSH会话请求来发起管理会话15。NMS微服务22在由NMS 10通告给被管理网络4的相应端口上侦听SSH会话请求，并且处理每个SSH会话请求以建立新的管理会话15。

为了提供可缩放性，NMS 10可以将NMS微服务22维持为复制的低开销的虚拟容器。当NMS 10被配置为管理大量被管理元件14时，NMS 10复制容器NMS微服务22，以便为每个端口提供相应NMS微服务池，从而提供水平缩放。NMS应用26通过API网关24与被管理元件14通信，以通过被管理元件14连接到的特定NMS微服务22来取回配置、部署更新后的配置或者以其他方式执行操作命令。例如，NMS应用26可以通过在远程过程调用(RPC)内传递被管理设备14之一的特定设备标识符和要在被管理设备上执行的一个或多个操作来在特定NMS微服务22(例如，容器)上调用RPC。在一个示例中，NMS应用26可以通过以HTTP请求的形式向API网关24发布RPC调用并且构造HTTP请求以包括唯一设备标识符作为HTTP cookie或作为HTTP报头的一部分来调用NMS微服务22。

本文中描述的技术提供了针对可能在基于云的NMS系统2中以其他方式存在的各种技术挑战的技术解决方案。例如，这些技术使得能够在基于云的NMS 10中对被管理设备14进行可靠的管理，包括针对以下挑战的技术解决方案：

o水平缩放——当要管理的被管理元件14的数目增加时，可以动态地添加新的微服务22(例如，容器)，并且新的被管理元件开始连接到这些新添加的微服务(例如，容器)。

o微服务崩溃——如果NMS微服务22(例如，容器)崩溃，则与该容器的所有被管理元件14连接都可能丢失。此外，当最初连接到崩溃的微服务的管理元件14重新连接时，会话15可以被分配给不同的NMS微服务22，因此其他微服务获知的关于该被管理元件与原始NMS微服务22之间的关联的信息不再有效。

o连接掉线——如果特定管理会话15掉线，则当被管理元件14重新启动连接时，该会话可以被分配给不同的NMS微服务22，因此，其他微服务获知的关于该被管理元件与原始NMS微服务22之间的关联的信息不再有效。

o新应用——新部署的NMS应用26(在一个或多个被管理元件14被连接之后)通常被迫通过低效地查询负责管理设备连接的每个NMS微服务24(这在大型网络中效率不高)或者通过查询设备到容器映射的集中维持高速缓存(这在维持集中高速缓存方面提出了自己的挑战)来获知给定NMS微服务24与被管理设备14之间的会话映射。

图2是示出根据本发明的原理的用于图1的NMS 10的示例架构的框图。如该示例中所示，NMS 10的NMS微服务22包括串联操作的两种类型的微服务：设备通信管理器(DCM)50和设备操作管理器(DOM)52。DCM 50和DOM 52中的每一者都可以由硬件处理器39在虚拟环境中作为软件容器来执行，并且处理器39可以表示一个或多个服务器或设备。

DCM 50负责通过管理会话15以及在该示例中通过NAT设备10与被管理元件14通信。DCM 50例如可以被配置为一个或多个容器的池，其任务是侦听来自相应端口上的被管理元件14的连接请求。DOM52负责为其他微服务和NMS应用26对被管理元件设备14执行操作提供接口。各个DCM 50和DOM 52可以根据当前加载条件是否需要而被分别部署为具有彼此独立地扩展的能力。

如下面进一步描述的，该技术利用API网关24内的基于HTTP报头和/或基于HTTPcookie的会话亲和力机制。例如，DCM 50和NMS应用26被配置为通过经由API网关24调用远程过程调用来与DOM 52通信，其中给定RPC调用指定在NMS 10内为给定被管理元件维持的唯一设备标识符。唯一设备标识符通常不是与管理会话15相关联的公共网络地址(考虑到NAT设备12的存在)，而是在NMS10的配置数据库中针对每个设备而使用的唯一ID，诸如被管理元件14的设备UUID。

DOM 52被配置为建立从DOM到DCM 50的持久性应用层通信会话53(例如，HTTP2连接，诸如gRPC)的集合。也就是说，每个DOM 50建立与DCM 52的持久性应用层通信会话53以用于与分配给DOM的特定管理元件14通信。在从被管理元件14与之建立新的管理会话15的DCM 50接收到RPC时，接收DOM 52标识与在RPC50中指定的DCM 50之一相关联的容器主机名，并且将该主机名解析为IP地址作为应用层通信会话53的目的地地址。

为了将主机名(容器名称)解析为IP地址，DOM 52可以例如向协调器55发布请求，协调器55负责在NMS 10的虚拟化环境中部署、重新启动和终止容器，容器包括NMS微服务22。也就是说，在一些示例中，容器服务协调器53提供了一种机制来将容器名称解析为虚拟环境内的IP地址。DOM 52被配置为根据与被管理元件相关联的设备标识符(例如，UUID)和与DCM的容器主机名相关联的网络地址之间的映射，以通过持久性应用层通信会话53将从来自NMS应用26的通信(经由RPC接收的)引导到DCM 50。

API网关24用于根据在由RPC调用携带的HTTP报头或Cookie内指定的设备UUID值来提供会话亲和力。例如，通过API网关24的RPC调用可以采取具有唯一的cookie或报头的基于HTTP的REST调用的形式。如本文中描述的，当在RPC的cookie或报头内设置了相同的设备UUID值时，API网关24将请求路由到相同的端点，即，该类型的微服务的相同的特定容器。

作为一个示例，API网关24可以是用于Kubernetes的NGINX入口控制器，它是一种用于容器化应用的自动化部署、缩放和管理的开源系统。在该示例中，Kubernetes入口策略可以按照以下方式被配置为在被管理元件14的设备ID与由API网关24选择为接收RPC调用的特定DOM 52之间提供自定义的基于cookie的会话亲和力，从而允许API网关将具有相同设备ID的后续RPC调用引导到相同的DOM52。

在上面的示例中，包含相同的cookie X-Device-UUID值的任何请求都将由API网关24路由到同一端点。如果未设置X-Device-UUID cookie，则ngnix生成X-Device-UUIDcookie并且将其返回到客户端。如果在第一次调用中已经设置了X-Device-UUID cookie，则ngnix将使用由客户端设置的值来生成一致的哈希值和端点选择。

作为另一示例，API网关24可以是Ambassador网关，它是开源的Kubernetes-native微服务API网关。Ambassador网关可以通过以下方式被配置来提供基于HTTP报头的会话亲和力：

-apiVersion:v1

kind:Service

metadata:

name:dom-service

annotations:

getambassador.io/config:|

---

apiVersion:getambassador.io/v1

kind:Mapping

name:dom_service_api_gateway

prefix:/dom/

service:dom-service:80

resolver:endpoint

load_balancer:

policy:ring_hash

header:X-Device-UUID

在上面的示例中，包含相同的X-Device-UUID值的任何请求都将被路由到同一端点。

图3是示出图1和2的NMS 10的组件的示例处理流程的框图。如图3所示，被管理元件14通常发起与NMS 10的出站SSH连接(例如，REST调用)，API网关24将其引导到负责基于特定端口来接受连接的DCM容器50之一(步骤1)。

接下来，处理管理会话请求的DCM 50经由网关24调用DOM 52，例如，经由被公开作为服务的REST API。例如，当API网关24是nginx-ingress-controller时，DCM 50可以进行以下调用：

POST:https://<gateway-ip>/dom/connection-up

COOKIE:{‘X-Device-UUID’:<uuid-of-connected-device>}

BODY:

{Hostname:Container-Name(or POD-Name in case of Kubernetes)}当API网关24是ambassador API网关时，DCM 50可以进行以下调用：

POST:https://<gateway-ip>/dom/connection-up

HEADER:{‘X-Device-UUID’:<uuid-of-connected-device>}

BODY:

{Hostname:Container-Name(or POD-Name in case of Kubernetes)}在这些示例中，“hostname”表示在其上建立连接的容器的名称(或者在Kubernetes的情况下为POD-Name)(在图3的示例中为DCM-A或DCM-B)。被管理元件14的UUID是NMS 10用来标识被管理元件的唯一标识符。

通常，当被管理元件14与DCM 50建立管理会话15时，该唯一标识符由被管理元件14传递。例如，在一种示例设备配置中，被管理设备14在出站连接请求中发送设备ID如下：

client EMS-47b47bf5-d62e-4bff-a099-1b51f968c0a8{

device-id 908a5a66-1ac4-4d44-a104-a329195dba66.JUNOS；

secret"$9$KUV8LNbs2ZGiY24ZDjq"；##SECRET-DATA

keep-alive；

services netconf；

<mgmt-ip>port<mgmt-port>；

}

接下来，响应于接收DCM 50的REST API调用，DOM微服务53中的一个(诸如图3中的DOM-A或DOM-B)打开持久性HTTP2连接53，例如通过向与由处理DCM 50传入的主机名相对应的特定IP地址发布远程过程调用(例如，gRPC)(步骤3)。例如，容器协调器53可以用来将容器的IP地址解析为主机名。例如，Kubernetes协调器提供API以使用POD的名称来取回特定POD的细节。所取回的这些细节包括POD的IP地址。作为一个示例，假定demo-deployment-744c659497-f5kdl是DCM-A的POD名称。可以通过以下API调用来解析主机名称：curl-khttps://<kube-apiserver-svc-ip>/api/v1/namespaces/default/pods/demo-deployment-744c659497-f5kdl。在将主机名解析为移交给被管理设备的DCM 50的特定IP地址之后，DOM 52打开与该DCM的持久性连接。在一个示例实现中，DOM 52为每个DCM打开一个单个连接53。如果DOM 52与给定DCM 40之间的连接53已经打开，则DOM不会打开新的连接。

通常，DCM 50和DOM 52中的每一者都维持类似于下面的映射，以保留关于持久性连接的信息(例如，HTTP2连接的gRPC连接ID)和设备ID映射，其中每个设备UUID表示特定的被管理元件14，并且每个连接ID表示用于向被管理元件14提供NMS服务的DCM 50之一与DOM52之一之间的特定持久性连接53。示例映射如下：

device-uuid1←→connection-1

device-uuid2←→connection-1

device-uuid3←→connection-2

device-uuid4←→connection-2

为了对被管理元件14执行操作(步骤4)，任何NMS应用26发布包含处理(handing)DCM 50最初传递DOM 52的X-Device-UUID(例如，作为cookie或报头)的RPC调用。这确保了来自NMS应用26的请求被API网关24引导到DOM 52(的实例)中的特定一个，其先前已经建立与特定被管理元件14连接到的特定DCM 52的持久性连接。

例如，当使用nginx-ingress-controller作为API网关24时，NMS应用26可以调用以下示例调用，包括唯一设备标识符：

POST:https://<gateway-ip>/dom/execute-cmd

COOKIE:{‘X-Device-UUID’:<uuid-of-connected-device>}

BODY:

{

“cmd”:<get-system-information></get-system-information>

“format”:“XML”

}

作为另一示例，当使用ambassador api网关时

POST:https://<gateway-ip>/dom/execute-cmd

HEADER:{‘X-Device-UUID’:<uuid-of-connected-device>}

BODY:

{

“cmd”:<get-system-information></get-system-information>

“format”:“XML”

}

图4是示出根据本文中描述的技术的网络管理系统的示例操作的流程图。最初，NMS 10从被管理元件14中的一个接收对管理会话15的请求(100)。例如，如上所述，在其中被管理元件14在NAT设备之后操作的计算环境中，被管理元件通常通过向NMS 10发送出站SSH连接(例如，以REST调用的形式)来发起管理会话15。

在接收到对新的管理会话15的请求时，API网关24执行负载平衡操作以选择DCM50软件容器中的一个，并且将请求引导到所选择的DCM(102)。例如，API网关24可以选择具有最小当前负载(例如，最少活动会话数目)的特定DCM容器50，和/或可以将哈希方案应用于与请求的被管理元件14相关联的设备ID，以便在作为微服务池进行操作的DCM 50之间分配管理会话请求。以这种方式，API网关24通过跨DCM 50的负载平衡管理会话请求来帮助实现基于微服务的NMS的可缩放性。如本文中解释的，每个DCM 50可以由NMS10的处理器作为软件容器来执行，并且每个DCM可以被配置为接受和管理来自被管理元件14的管理会话15。

在从被管理元件14之一接收到建立管理会话15的请求时，接收DCM经由API网关24发布调用由DOM 50公开的API的远程过程调用(例如，REST调用)(103)。API网关24跨DOM 52的池(作为微服务容器来执行)对RPC进行负载平衡以选择DOM(104)中的一个，从而进一步实现NMS 10的可缩放性。如本文中描述的，每个DOM 52可以由NMS 10的处理器作为软件容器来执行，并且每个DOM被配置为呈现用于根据被管理元件的设备标识符来对被管理元件执行操作的API。

当对DOM 52的选择进行负载均衡以服务于来自DCM 50的RPC调用时(上面的步骤104)，API网关24记录或以其他方式使用由请求DCM嵌入在RPC中的设备标识符以提供关于由API网关选择的DOM 52的会话绑定。也就是说，在选择DOM 52中的一个来服务于来自请求DCM 50的RPC请求时，API网关24可以将设备标识符记录在来自DCM的初始RPC中，以用作用于指导具有与所选择的DOM相同的设备标识符的后续RPC的机制，其中这些RPC可能来自DCM50或NMS应用26。在其他示例中，API网关24将哈希函数应用于嵌入在来自DCM 50和NMS应用26的RPC中的设备标识符，以确保适当的DOM 52处理针对给定被管理元件14的RPC。

响应于从建立管理会话15的DCM 50接收到RPC，作为响应，由API网关24选择的DOM53直接建立从DOM到发布RPC的DCM的持久性应用层通信会话53，从而绕过API网关24(106)。例如，作为响应，经由API网关24接收RPC的特定DOM 52可以直接建立与对应于经由RPC接收的主机名的特定IP地址的持久性HTTP2连接53。这可能是有利的，因为绕过API网关24并且改为利用从DOM 52到DCM 50的持久性的点对点会话确保了来自DOM 52的通信流到服务于被管理元件14的正确的DCM 50并且没有跨DCM 50的负载平衡。

在操作期间，任何一个NMS应用26可以通过向由API网关24公开的DOM 52的API发布RPC调用来向被管理元件发布命令(108)。此时，API网关24利用与经由NMS应用26嵌入在RPC中的被管理元件14相关联的唯一设备标识符来将RPC引导到适当的DOM 52，即API网关将来自DCM 50的原始RPC引导到的DOM(上述步骤103、104)。以这种方式，API网关24的会话亲和力功能允许API网关基于被管理元件14的设备ID来将来自NMS应用26的RPC引导到由API网关选择的相同DOM，以服务于来自DCM 50的RPC。这样，本文中描述的技术确保了来自NMS应用26的NMS命令被引导到已经与DCM 50建立了与被管理元件14进行通信所必需的持久性会话53的DOM 52。

在从NMS应用26接收到NMS命令之后，接收DOM 52根据由DOM 52维持的、与被管理元件14相关联的设备标识符同与DCM 50相关联的网络地址之间的映射以通过持久性应用层通信会话53将命令引导到DCM(110)。进而，DCM 50从持久性连接53接收命令，并且经由管理会话将命令发布给被管理元件14。

部署缩放

通常，本文中描述的架构使得能够根据需要来部署附加的DCM50，而无需重新配置或者甚至通知NMS应用26。也就是说，当实例化DCM 50的新实例时，不需要以编程方式重新配置NMS应用26。NMS应用26仅需要将正确的报头或cookie值(即，具有设备的UUID的X-Device-UUID)传递到DOM端点。对于与UUID相关联的特定被管理元件，DOM端点预期并且负责维持与所需要的DCM 52的持久性连接。

此外，当API网关24将诸如一致性哈希等技术用作负载平衡机制时，管理会话15的重新分布会跨可用DOM 52而发生，从而允许根据需要来缩放DOM。

当缩放DOM 52时，可以在新缩放的DOM之间重新分配对被管理元件14和对应持久性会话53的责任加载。作为一个示例，以下方法可以用于恢复特定设备UUID与负责维持该特定被管理元件的持久性会话53的DOM 52之间的会话亲和力：

·当来自NMS应用26的API请求被引导到特定DOM 52并且该特定DOM不再负责与管理元件所连接到的DCM 50的连接53(由于重新缩放而导致的亲和力的改变)时，DOM将在调用中所接收的X-Device-UUID写入“ORPHAN_DEVICES”表中并且开始等待来自DCM 50的调用。

·其他DOM 52定期从彼此读取孤立设备表，并且当前正在维持与该X-Device-UUID相关联的持久性连接的DOM指示对应DCM50经由API网关24发布REST调用以重新建立亲和力。这样，原始DOM将从其连接映射中删除该设备并且从孤立设备表中删除该条目。

·等待DOM从DCM接收新的REST调用并且完成由NMS应用请求的操作。

处理微服务容器/POD崩溃

如上所述，gRPC连接的双方维持设备Id与连接之间的映射。如果特定DOM 52发生崩溃，则具有来自崩溃DOM的持久性连接53的对应DOM 50可以通过为被映射到该连接的所有device-uuid发布RPC来重播REST API的日志。对于每个重播的RPC调用，API网关24随后将使用不同的DOM 52为该device-uuid建立会话亲和力。会话的重新分配可以使用上述机制来处理。

即使在DCM 50崩溃的情况下，对应DOM也会使与已经崩溃的DCM 50的连接53的高速缓存无效。被管理元件14最终将向NMS 10发布新的连接请求，并且将连接到不同DCM 50，该DCM 50将通过API网关24来调用REST API RPC调用，API网关24进而将再次为该device-uuid创建与不同DOM实例的会话粘性。

处理连接断开：在这种情况下，被管理元件14可以重新连接到DCM 50，并且DCM将REST API调用到相同的DOM 52。如上所述，API网关24将REST API引导到最初是在管理设备的相同的DOM。在所有这些故障情况下，恢复对客户端应用都是透明的。

如本文中描述的，可以在NMS 10内的REST调用中使用HTTP报头或Cookies以在设备唯一标识符和具有与该设备的连接的微服务容器之间建立会话亲和力/粘性。这个机制用于通过NMS 10建立会话粘性以管理设备。此外，用于持久性连接的远程过程调用(例如，gRPC)用于将会话粘性从低级微服务传播到应用层中的微服务。

本公开中描述的技术可以至少部分以硬件、软件、固件或其任何组合来实现。例如，所描述的技术的各个方面可以在一个或多个处理器内实现，包括一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或任何其他等效的集成或离散逻辑电路、以及这样的组件的任何组合。术语“处理器”或“处理电路系统”通常可以单独地或与其他逻辑电路系统或任何其他等效电路系统组合地指代任何前述逻辑电路系统。包括硬件的控制单元还可以执行本公开的一种或多种技术。

这样的硬件、软件和固件可以在同一设备内或在单独的设备内实现，以支持本公开中描述的各种操作和功能。另外，所描述的任何单元、模块或组件可以一起或单独地实现为离散但可互操作的逻辑设备。将不同特征描绘为模块或单元旨在突出不同的功能方面，而不一定暗示这样的模块或单元必须通过单独的硬件或软件组件来实现。而是，与一个或多个模块或单元相关联的功能可以通过单独的硬件或软件组件来执行，或者可以集成在通用的或单独的硬件或软件组件内。

本公开中描述的技术还可以在包含指令的计算机可读介质(诸如计算机可读存储介质)中体现或编码。嵌入或编码在计算机可读介质中的指令例如在指令被执行时可以引起可编程处理器或其他处理器执行该方法。计算机可读介质可以包括非暂态计算机可读存储介质和暂态通信介质。有形且非暂态的计算机可读存储介质可以包括随机存取存储器(RAM)、只读存储器(ROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(EPROM)、电子可擦除可编程只读存储器(EEPROM)、闪存、硬盘、CD-ROM、软盘、盒式磁带、磁性介质、光学介质、或其他计算机可读存储介质。应当理解，术语“计算机可读存储介质”是指物理存储介质，而不是信号、载波或其他瞬态介质。

已经描述了各种示例。这些和其他示例在所附权利要求的范围内。

Claims

1.一种网络管理系统，包括：

一个或多个基于硬件的处理器；

一个或多个网络管理系统(NMS)应用的集合，被配置为在所述处理器上执行；

设备通信管理器(DCM)池，所述DCM中的每个DCM由所述处理器作为软件容器执行，并且所述DCM中的每个DCM被配置为接受和管理到网络内的多个被管理元件之一的管理会话；

设备操作管理器(DOM)池，所述DOM中的每个DOM由所述处理器作为软件容器执行，并且所述DOM中的每个DOM被配置为呈现应用程序编程接口(API)，所述应用程序编程接口用于根据所述被管理元件的设备标识符来对所述被管理元件执行操作；

API网关，被配置为根据如在来自所述DCM的远程过程调用(RPC)内指定的所述被管理元件的设备标识符以经由所述DOM暴露的所述API来将所述RPC路由到所述DOM，

其中所述DOM被配置为建立从所述DOM到所述DCM的持久性应用层通信会话的集合，以及

其中所述DOM被配置为根据与所述被管理元件相关联的设备标识符和与所述DCM相关联的网络地址之间的映射、以通过所述持久性应用层通信会话来将来自所述NMS应用的通信引导到所述DCM。

2.根据权利要求1所述的网络管理系统，其中所述持久性应用层通信会话是源自所述DOM中的每个DOM并且终止于所述DCM中的每个DCM的HTTP2会话。

3.根据权利要求1所述的网络管理系统，其中每个DOM和DCM被配置作为单独的NMS微服务。

4.根据权利要求1所述的网络管理系统，包括容器服务协调器，被配置为将所述DOM和所述DCM中的每一个的容器名称解析为相应的IP地址。

5.根据权利要求1所述的网络管理系统，其中所述DCM中的每个DCM被配置为将cookie嵌入在发布给所述DOM的所述RPC中的每个RPC内，其中每个cookie指定所述被管理元件的所述设备标识符中的一个。

6.根据权利要求1所述的网络管理系统，

其中所述DCM池和所述DOM池相对于作为DCM和DOM执行的软件容器的数目是动态可缩放的，

其中所述DOM被配置为维持孤立被管理元件的表，所述孤立被管理元件的表具有已经由所述DOM从NMS应用接收到其出站通信的设备标识符，所述DOM由于缩放而先前没有建立与所述特定设备标识符相关联的所述持久性应用层通信会话。

7.根据权利要求1所述的网络管理系统，

其中所述DOM被配置为扫描所述孤立被管理元件的表，并且引导与所述设备标识符相关联的所述DCM将RPC重新发布给所述API网关以用于路由到所述DOM。

8.一种由网络管理系统(NMS)执行的方法，包括：

从被管理元件接收与设备通信管理器(DCM)池中的第一DCM建立管理会话的请求，所述DCM中的每个DCM由所述NMS的一个或多个处理器作为软件容器执行；

经由应用程序编程接口(API)网关将来自所述第一DCM的远程过程调用发布给由所述NMS的所述一个或多个处理器执行的设备操作管理器(DOM)池中的第一DOM，所述DOM中的每个DOM由所述NMS的所述处理器作为软件容器执行，并且所述DOM中的每个DOM被配置为呈现用于根据所述被管理元件的设备标识来对所述被管理元件执行操作的API；

与所述第一DOM建立从所述第一DOM到所述第一DCM的持久性应用层通信会话，以及

利用所述第一DOM并根据与所述被管理元件相关联的设备标识符和与所述DCM相关联的网络地址之间的映射，以通过所述持久性应用层通信会话来将来自一个或多个NMS应用的集合的命令引导到所述第一DCM；以及

经由所述管理会话以将来自所述第一DCM的所述命令发布给所述被管理元件。

9.根据权利要求8所述的方法，还包括：利用所述API网关以根据在来自所述DCM的RPC中指定的被管理元件的设备标识符来将所述RPC路由到所述DOM。

10.根据权利要求8所述的方法，还包括：维持孤立被管理元件的表，所述孤立被管理元件的表具有已经由所述DOM中的至少一个DOM从NMS应用接收到其出站通信的设备标识符，所述DOM由于所述DOM池的缩放而先前没有建立与所述特定设备标识符相关联的持久性应用层通信会话。

11.根据权利要求10所述的方法，还包括：扫描所述孤立被管理元件的表，并且引导具有与所述表中列出的所述设备标识符相关联的被管理会话的所述DCM将RPC重新发布给所述API网关以用于路由到所述DOM，以使得所述接收DOM为具有在所述表中列出的所述设备标识符的所述被管理元件建立持久性应用层通信会话。

12.一种计算机可读存储介质，包括指令，所述指令在被执行时使得网络管理系统的处理器：

经由应用程序编程接口(API)网关以将来自所述第一DCM的远程过程调用发布给由所述NMS的所述一个或多个处理器执行的设备操作管理器(DOM)池中的第一DOM，所述DOM中的每个DOM由所述NMS的所述处理器作为软件容器执行，并且所述DOM中的每个DOM被配置为呈现用于根据所述被管理元件的设备标识来对所述被管理元件执行操作的API；

13.一种网络系统，包括：

网络内的多个被管理元件；

网络管理系统，包括：

一个或多个基于硬件的处理器；

其中所述DOM被配置为根据与所述被管理元件相关联的设备标识符和与所述DCM相关联的网络地址之间的映射，以通过所述持久性应用层通信会话来将来自所述NMS应用的通信引导到所述DCM；以及

网络地址转换(NAT)设备，位于所述NMS与所述被管理元件之间。