云基础设施的集中管理、配设和监控的制作方法

云基础设施的集中管理、配设和监控
1.相关申请的交叉引用
2.本技术要求2020年2月28日提交的美国临时申请号62/983,000和2020年2月28日提交的美国临时申请号62/982,778的权益，这些申请的全部内容通过引用方式并入本文。
技术领域
3.本公开涉及云基础设施的管理、配设和监控。


背景技术：

4.开放标准云计算平台，例如云管理软件平台，主要在公共云和私有云中提供基础架构即服务(iaas)，其中虚拟服务器和其他资源可供用户使用。此类平台可由相互关联的组件组成，这些组件控制整个数据中心的处理、存储和网络资源的各种多供应商硬件池。用户可以通过基于web的仪表板、命令行工具或restful web服务来管理此类实施。
5.许多移动网络运营商打算分布具有数千个远程位置的电信云网络，用于部署更靠近订户/用户设备的应用程序，例如多路访问或移动边缘计算、虚拟化无线电接入网络、内容交付网络等。这些位置可能包括可能非常小并且可能容纳小型数据中心的远程位置。
6.随着云实施规模和地理范围的扩大，可能会遇到配设和监控开放标准云计算平台的挑战。需要针对这些挑战的解决方案，特别是在设备和电力使用方面成本低且高效的解决方案。
附图说明
7.图1示出了根据示例实施例的示例网络功能虚拟化基础设施(nfvi)交付点(pod)配置。
8.图2是根据示例实施例的布置在第一和第二数据中心中的多个云pod的框图。
9.图3是根据示例实施例的用于利用广域网(wan)的多个云pod的集中管理节点的布置的框图。
10.图4是根据示例实施例的用于利用局域网(lan)的多个云pod的集中管理节点的布置的框图。
11.图5是示出根据示例实施例的用于提供云pod的集中配设和管理的网络拆分的框图。
12.图6a和图6b示出了根据示例实施例的与实现云网络的集中管理节点相关联的示例呼叫流程的第一呼叫流程图。
13.图7示出了根据示例实施例的与实现云网络的集中管理节点相关联的示例呼叫流程的第二呼叫流程图。
14.图8是示出根据示例实施例的与由集中管理节点进行的制品部署相关联的示例细节的框图。
15.图9是示出根据示例实施例的用于实现云网络的集中管理的处理流程的流程图。
16.图10是示出根据示例实施例的在管理节点和虚拟基础设施管理器(vim)pod配置内包括vim-监控(mon)功能的系统的框图。
17.图11是示出根据示例实施例的在高可用性(ha)配置中包括vim-mon的系统的框图。
18.图12是示出根据示例实施例的用于由vim-mon-ha监控的pod分组的框图。
19.图13是示出根据示例实施例的vim pod配置内的度量收集和报告代理放置和抓取功能的框图。
20.图14是示出根据示例实施例的使用vim-mon-ha从各个位置抓取度量的方法的呼叫流程图。
21.图15是示出根据又一示例实施例的包括具有注册服务器的vim-mon堆栈的系统的框图。
22.图16是示出根据示例实施例的从各种远程计算实体收集性能数据的第一方法的流程图。
23.图17是示出根据示例实施例的从各种远程计算实体收集性能数据的第二方法的流程图。
24.图18是根据示例实施例的计算设备的硬件框图，该计算设备可以执行与结合图1-图17中描绘的技术的任何操作组合相关联的功能。
具体实施方式
25.概述
26.在独立权利要求中陈述了本发明的各方面，在从属权利要求中陈述了优选特征。一个方面的特征可以单独地或与其他方面结合地应用于任何一个方面。
27.根据示例实施例，提供集中云基础设施配设和管理。根据这样的示例实施例，在集中管理节点上执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第一映像文件，其中第一映像文件包括第一引导配置文件或第一内存虚拟盘文件中的至少一者。在集中管理节点上执行的第二虚拟机将第二映像文件提供给布置在与第一交付点不同的第二交付点内的第二计算实体。第二映像文件包括第二引导配置文件或第二内存虚拟盘文件中的至少一者。在集中管理节点上执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第三映像文件。第三映像文件包括第一操作系统安装文件。在集中管理节点上执行的第二虚拟机向布置在第二交付点内的第二计算实体提供第四映像文件。第四映像文件包括第二操作系统安装文件。
28.示例实施例还提供对云基础设施的集中监控。根据这样的示例实施例，集中管理节点向第一控制器节点提供第一请求。第一请求用于从布置在第一交付点内的第一计算实体获得第一性能数据。集中管理节点向第二控制器节点提供第二请求。第二请求用于从布置在与第一交付点不同的第二交付点内的第二计算实体获得第二性能数据。从第一控制器节点获得具有第一计算实体的第一性能数据的第一响应。最后，从第二控制器节点获得具有第二计算实体的第二性能数据的第二响应。
29.示例实施例
30.云基础设施设备的安装程序，例如安装程序，用于使用自动化工具在裸机服务器上部署云基础设施服务。此类安装程序通常使用一个或一组服务器作为“安装程序数据库服务器”，并且这些节点通常在交付点(pod)(例如openstack pod)中被称为“管理节点”。由于cobbler、延迟和/或安全问题，当前的云架构(包括openstack)不支持管理节点的集中化。因此，如图1所示，体现为openstack pod 100的典型pod 100配置有各种节点，包括管理节点105、控制器节点110a-c、存储节点115a-c和计算节点120a-x(一些示例具有多达128个计算节点)。
31.pod中管理节点的主要目的是部署虚拟基础设施管理(vim)云，然后管理pod。然而，在部署之后，管理节点的使用通常限于收集统计信息并将这些信息转发到集中位置。图2是示出涉及中央、区域和边缘网络功能虚拟化基础设施(nfvi)云部署场景的典型移动提供商的示例pod部署的框图。
32.如图2的系统200所示，中央数据中心202a和202b可以包含许多openstack pod 205a-f，每个都包括一个管理节点105a-f。中央数据中心内的pod数量可能达到数万。例如，中央数据中心202a可以包括2000或更多组中心(gc)pod 205a、100个或更多个区域数据中心(rdc)pod 205b和/或1000个或更多个nano-pod 205c。类似地，中央数据中心202b可以包括2000个或更多个gc pod 205d、100个或更多个rdc pod 205e和/或1000个或更多个nano-pod 205f。
33.对于某些位置，例如多路访问或移动边缘计算(mec)位置(例如gc位置)，虚拟化无线电接入网络(vran)工作负载可以托管在(例如，与中心和/或gc pod相比)具有较小占用空间的nfvi pod中，但可能涉及许多位置(例如，数千或数万个)。在这样的部署中，由于功率和空间限制，在每个mec/vran pod处部署管理节点可能效率低下。
34.因此，在大规模的边缘云部署中，可能有2000-4000个pod(例如，布置在边缘的组中心每个位置可能包含1-5个pod)。在这样的部署中提供的管理节点105a-f的数量可以计算如下：
35.云的数量*1＝完整部署的管理节点的数量。
36.因此，包含数千个pod的部署也将包含数千个一一对应的管理节点。涉及每个pod管理节点的部署可能会给网络运营商带来很大的成本，因为管理节点105a-f可能被认为是安装程序跳箱，这可能不会产生收入。此外，当前的每个pod管理节点架构可能会增加部署的复杂性。因此，在操作上，由于备份过程和专用监控，涉及每个pod的管理节点的架构可能效率低下。维护云下架构的高可用性(ha)可能会进一步增加开销。
37.根据本公开的技术，可以对openstack数据中心进行重新架构，使得可以在主数据中心或集中数据中心实现集中管理节点。该集中管理节点可以包括管理在不同位置地理部署的数千个vim pod(边缘或其他)的能力。这种架构的示例实施例在图3中示出。
38.参考图3，其中描绘了系统300的框图，其中根据本公开的技术的示例实施例实现集中管理节点305。本公开的系统和方法提供了可以连接到数据中心302a和302b的pod 310a-f的集中管理节点305。在一些实施例中，可以使用第2层(l2)或第3层(l3)广域网(wan)320来提供连接；然而，在一些实施例中，可以通过l3局域网(lan)交换机制来提供连接，如图4的系统400所示。如图4的系统400所示，集中管理节点305提供与图3的集中管理节点类似的功能，但是通过lan交换410连接到中央数据中心302a和302b的pod 310a-f。
39.返回图3，在操作期间，集中管理节点305可以用于部署openstack(例如，便于分发映像和其他部署过程)或另一种形式的云基础设施，并且在部署之后，管理节点305可以使用各种工具来监控部署。在各种实施例中，集中管理节点305可以基于云资源的可用性被部署为虚拟机(vm)或微服务。由集中管理节点305提供的特征的非详尽列表包括：
40.1.为每个云基础设施确定集中管理节点305的尺寸的系统和方法。在对管理节点映像大小、消息队列和网络实施进行试验之后，在一些实施例中，每个计算服务器和/或每个1万亿字节(tb)硬盘具有大约10个管理节点实例可能是最佳的。
41.2.使用安全远程引导前执行环境(pxe)引导映像分发进行自动计算节点部署的系统和方法。在操作期间，此类过程可以从来自正在部署的计算服务器的动态主机配置协议(dhcp)请求开始。在至少一个实施例中，该请求可以通过wan传送，该wan可以使用来自诸如架顶式(tor)交换机和/或路由器之类的中间设备的dhcp中继。在至少一个实施例中，操作系统(os)的映像引导可以被分割成两个映像(例如，“stage1.img”和“stage2.img”)，其中两个映像都可以通过wan来引导。
42.3.可以提供操作系统(os)映像证书验证以确保云部署的安全性。这种映像安全证书验证可以使用证书颁发机构(即，“root ca”)证书层次结构来部署。
43.为了给每个pod 310a-f提供管理特征，管理节点305可以被配置为执行管理虚拟机(vm)325a-f。根据该示例实施例，每个虚拟机325a-f执行针对pod 310a-f中的相应一个pod对应于图1的管理节点105a-f的功能。换言之，如果本公开的技术应用于图1的pod 100，管理节点105将作为vm在集中管理节点上执行，例如图3的集中管理节点305。类似地，图2的管理节点105a-f将作为vm在一个或多个集中管理节点上执行，例如图3的集中管理节点305。
44.参考图5，其中描绘了框图500，其示出了根据示例实施例的与用于实施集中管理节点的管理和配设网络拆分相关联的其他示例细节。图5示出了集中管理节点505、多个控制器节点510a-c、多个存储节点515a-c和多个计算节点512a和512b。集中管理节点505经由wan边缘路由器540a和540b通过wan 520向多个控制器节点510a-c、多个存储节点515a-c和多个计算节点512a和512b提供数据并且从多个控制器节点510a-c、多个存储节点515a-c和多个计算节点512a和512b获得数据。
45.如通过网络参数550和555所示，提供管理和配设功能的集中管理节点505使用网络拆分来做到这一点。通过比较配设网络参数550与管理网络参数555，可以看出配设操作使用与管理操作所使用的网关、子网和虚拟局域网(vlan)不同的网关、子网和vlan。
46.现在参考图6a和图6b，其中描绘了呼叫流程图600，其示出了用于通过集中管理节点305在节点上安装操作系统(os)的消息交换。更具体地，呼叫流程图600示出了在dhcp客户端上安装os，其体现为布置在区域数据中心内的计算服务器或pod，例如布置在图3的区域数据中心302a的pod 310a内的计算节点。根据图6a和图6b的示例，os映像可以被分成两个映像，分别包括第一和第二阶段映像文件“stage1.img”和“stage2.img”。“stage-1.img”文件的内容可以根据服务器硬件和固件配置来选择。例如，“stage1.img”映像文件可能包含以下文件的非详尽列表中的一个或多个：引导加载程序文件、引导配置文件、flinuz文件和随机存取存储器(ram)或内存虚拟盘文件。“stage2.img”映像文件可能包括要安装在服务器上的实际os文件(例如，windows、linux等)。特别地，呼叫流程图600示出了与第一设计
选项相关联的示例细节，包括使用“stage1.img”映像文件在wan上引导pxe的操作以及使用证书认证执行“stage2.img”映像文件的安全链加载的操作。
47.与呼叫流程图600相关联的各种特征可以包括以下消息和操作的非详尽列表。呼叫流程图600开始于操作651，其中与pod相关联的vm机器在集中管理节点305处启动。换言之，集中管理节点305作为vm安装在集中位置。当新的裸机服务器为计算服务器610上线并准备好进行服务器安装时，计算服务器610的基本输入/输出系统(bios)615发送广播dhcp pxe引导请求652。换言之，计算服务器610用作呼叫流程图600中所示的消息和操作的dhcp客户端。
48.引导请求652通过tor交换机605转发，该交换机被配置为dhcp中继代理。更具体地，tor交换机605通过wan网络将dhcp pxe引导请求652广播到中央管理节点305(在本文中也可互换地称为中央管理节点vm)，该中央管理节点305可以被配设有/充当dhcp服务器。
49.在接收到dhcp pxe引导请求652后，与中央管理节点305相关联的vm可以发送dhcp引导响应653。dhcp引导响应653通过tor交换机605转发到计算服务器610，并包括以下参数：
50.管理节点305的互联网协议(ip)地址；
51.普通文件传输协议(tftp)服务器地址；和
52.pxe引导加载程序文件名(例如，prelinux0)。
53.具体地，集中管理节点305可用作tftp服务器、超文本传输协议安全(https)服务器或本领域技术人员已知的允许计算服务器610下载文件作为通过呼叫流程图600所示配设过程的一部分的另一类型的文件服务器。
54.在接收到dhcp引导响应653后，计算服务器610重新编码dhcp引导响应653并将通过发送引导加载程序文件请求654来请求引导加载程序文件(即，“prelinux0”)。引导加载程序文件请求654发起交换，该交换包括集中管理节点305通过操作655的消息将引导加载程序文件发送到计算服务器610，并且计算服务器610以引导配置文件请求656进行响应。在操作657中，计算服务器610使用“prelimux0”文件来确定通用唯一标识符(uuid)、媒体访问控制(mac)地址、大写十六进制(capital hex)的ip地址和/或本领域技术人员已知的其他信息。
55.在操作657完成后，计算服务器610在操作658从集中管理节点305接收引导配置文件，并在操作659请求内核和内存虚拟盘文件，在操作660在计算服务器610接收内核和内存虚拟盘文件。在操作662中，ram和内核被加载到os 620中。在操作662完成时，计算服务器610已加载与第一映像文件“image1.img”相关联的文件。
56.在操作663中，集中管理节点305下载可用于加载“stage2.img”映像的服务提供商签名映像。更具体地，集中管理节点305将从持续集成/持续交付(ci/cd)目录加载签名的映像。
57.在操作664中，计算服务器610开始链加载请求(例如，请求签名的“stage2.img”映像文件和“rootca”证书)，并在操作665中接收链加载响应。操作665的链加载响应包括签名的“stage2.img”映像文件和映像的“rootca”证书。在操作666中由计算服务器610使用签名的“stage2.img”映像文件的“rootca”证书来执行证书验证。
58.如果证书验证成功，则计算服务器610在操作667中请求kickstart文件(例如，有
助于os安装的文件)，并且集中管理节点305在操作668中发送kickstart文件和bash包。计算服务器610在操作669中使用接收到的文件安装os。一旦os安装成功，计算服务器610的bios 615在操作670中向加载的os 620发送去激活pxe。此步骤用于限制任何欺诈性服务器第二次进行pxe引导计算服务器610。在操作672中，加载的os 620禁用pxe引导。
59.最后，在操作674和676中，计算服务器610的监控由集中管理节点305执行，这将在下面更详细地描述。以上参考图6a和图6b描述的操作可以针对第二pod服务器设备重复，该第二pod服务器设备利用在集中管理节点305上执行的相同或不同虚拟机被布置在相同或不同pod内。
60.现在参考图7，其中描绘了用于引导加载第一和第二映像文件“image1.img”和“image2.img”的第二设计选项。更具体地，图7包括呼叫流程图700，其示出了根据示例实施例的与实施用于电信云网络的集中管理节点相关联的呼叫流程。特别地，呼叫流程图700示出了与第二设计选项相关联的示例细节，其中映像可以被分解为“stage1.img”映像文件，该文件包括捆绑在数字视频盘(dvd)国际标准化组织(iso)文件中的引导加载程序文件和引导配置文件。“stage2.img”映像文件包括要安装的os文件。通过wan从集中管理节点305请求内核和内存虚拟盘。
61.在操作730之前，“stage1.img”映像文件可以是小型dvd iso，小型dvd iso可以通过虚拟dvd映射到集中管理节点305上。在操作730中，“stage1.img”映像文件dvd iso被映射到计算服务器710。到计算服务器的ip地址通过“stage1.img”映像文件dvd iso本身安装。通过操作732重新引导服务器并安装“stage1.img”映像文件。
62.计算服务器710在请求734中从集中管理节点305请求内核和内存虚拟盘文件，并且在操作736中，内核和内存虚拟盘文件从集中管理节点305返回到计算服务器710。
63.在操作736中，集中管理节点305将内核和内存虚拟盘文件提供给计算服务器710，并且计算服务器710从https服务器路径“/var/www/http”中的ci/cd存储库下载服务提供商签名的映像。
64.剩余的步骤可以使用与上面针对图6a和图6b所讨论的类似的操作来执行，因此，相似的附图标记用于指代相似的操作。在操作662中，ram和内核被加载到主机os 720中。在操作662完成后，计算服务器610已加载与第一映像文件“image1.img”相关联的文件。
65.在操作738中，集中管理节点305下载服务提供商签名的映像，该映像可用于加载“stage2.img”映像文件。更具体地，集中管理节点305将从ci/cd目录加载签名的映像。
66.在操作664中，计算服务器710开始链加载请求(例如，请求签名的“stage2.img”映像文件和“rootca”证书)，并在操作665中接收链加载响应。操作665的链加载响应包括签名的“stage2.img”映像文件和映像的“rootca”证书。证书验证在操作666中由计算服务器710使用签名的“stage2.img”映像文件的“rootca”证书来执行。
67.如果证书验证成功，则计算服务器710在操作667中请求kickstart文件(例如，有助于os安装的文件)，并且集中管理节点305在操作668中发送kickstart文件和bash包。计算服务器710在操作669中使用接收到的文件安装os。一旦os安装成功，计算服务器710的bios 715在操作670中向加载的os 720发送去激活pxe。此步骤用于限制任何欺诈性服务器第二次进行pxe引导计算服务器710。在操作672中，加载的os 720禁用pxe引导。
68.最后，在操作674和操作676中，计算服务器710的监控由集中管理节点305执行，这
将在下面更详细地描述。以上参照图7描述的操作可以针对第二pod服务器设备重复，该第二pod服务器设备利用在集中管理节点305上执行的相同或不同虚拟机被布置在相同或不同pod内。
69.因此，本文描述的技术可以提供在pxe引导期间提供链引导安全的能力。例如，充当dhcp客户端的计算服务器或pod可以启动链加载请求(例如，请求签名的“stage2.img”映像文件和“rootca”证书)。充当dhcp服务器的集中管理节点可以发送链加载响应(例如，签名的“stage2.img”映像文件和“rootca”证书)，并且充当dhcp客户端的计算服务器或pod可以使用签名的“stage2.img”映像文件的“rootca”证书执行证书验证。
70.图8是示出根据示例实施例的与由集中管理节点进行的制品部署相关联的示例细节的框图800。一旦映像被部署在计算服务器/pod中，本文的实施例可以提供执行选择性制品载入(artifact onboarding)的方法。
71.例如，通过例如vm的集中管理节点可以使用如图8所示的步骤选择性地识别可以在其上部署openstack制品的多个计算服务器，这可以通过pod制品的选择性载入来提供空间优化。在传统的管理节点中，来自计算资源的所有制品都由管理节点下载。然而，由于本文中的技术提供集中管理节点vm架构，因此可以提供cobbler优化以便仅从计算节点下载特定制品。
72.例如，在操作期间，一个集中的编排平台可能会在一个vim上开始部署openstack。步骤的执行可以通过管理节点发生以选择性地部署制品(例如，安装映像、存储库和技术人员已知的其他制品)。可以从在线存储库或通过离线存储库下载制品。在至少一个实施例中，管理节点vm可以基于输入意图文件中限定的特征来执行选择性制品下载。该优化可用于降低管理节点vm的大小。
73.如图8所示，vim制品805被下载。然后，与管理节点相关联的vm将依次提供输入验证810、提供裸机安装815、提供通用设置820、提供开源存储825(例如，ceph存储)、提供openstack服务830，并最终提供验证和监控835。
74.现在参考图9，其中描绘了示出根据本公开的技术的处理流程的流程图900。流程图900的处理流程开始于操作905，其中在集中管理节点上执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第一映像文件，其中第一映像文件包括以下各项中的至少一个：第一引导加载程序文件、第一引导配置文件、第一内核文件或第一内存虚拟盘文件。因此，操作905可以针对布置在第一pod内的设备体现为图6a和图6b的操作655、658和/或660中的一个或多个。操作905也可以针对布置在第一pod内的设备体现为图7的操作732和/或736中的一个或多个。
75.在操作910中，在集中管理节点上执行的第二虚拟机将第二映像文件提供给布置在第二交付点内的第二计算实体，其中第二映像文件包括以下各项中的至少一个：第二引导加载程序文件、第二引导配置文件、第二内核文件或第二内存虚拟盘文件。因此，操作910可以针对布置在第二pod内的设备体现为图6a和图6b的操作655、658和/或660中的一个或多个。操作910也可以针对布置在第二pod内的设备体现为图7的操作732和/或736中的一个或多个。
76.在操作915中，在集中管理节点上执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第三映像文件。第三映像文件包括第一操作系统安装文件。因此，操作915
可以针对布置在第一pod内的设备体现为图6a和图6b的操作665和/或668。操作915也可以针对布置在第一pod内的设备体现为图7的操作665和/或668中的一个或多个。
77.最后，在操作920中，在集中管理节点上执行的第二虚拟机向布置在第二交付点内的第二计算实体提供第四映像文件。第四映像文件包括第二操作系统安装文件。因此，操作920可以针对布置在第二pod内的设备体现为图6a和图6b的操作665和/或668。操作915也可以针对布置在第二pod内的设备体现为图7的操作665和/或668中的一个或多个。
78.总之，管理节点的集中化可以优化资源、提高云安全性和/或运营效率，和/或还提供扩展电信云(telcocloud)部署的能力。对于较大的部署，对于企业/服务提供商而言，节省的费用可能非常可观。因此，本文提出的技术可以促进企业/服务提供商的快速云部署。
79.在至少一个实施例中，可以通过分两个阶段引导pxe映像来提供用于计算安全的链引导。第一阶段可能涉及引导内核映像。可以是实际安装映像的第二映像可以由服务提供商的“rootca”证书签名，并且dhcp客户端(例如，计算服务器)可以实施引导映像的证书验证。
80.在至少一个实施例中，集中管理节点安装可以涉及优化在wan上从计算资源下载的制品。可以在dhcp客户端上实施优化技术以减少下载的制品数量。
81.在至少一个实施例中，由于从集中管理节点到计算资源的应用程序编程界面(api)请求是通过wan，在集中管理节点和计算资源之间可能存在安全令牌交换以用于下载制品和资源。
82.一旦pod被建立和配设，管理员可能会寻求监控pod和pod内的各个节点的性能。具体地，对于企业或服务提供商而言，网络的边缘可能是相对的，因为它可能取决于物理限制，例如订户人口密度、wan传输可用性、机架空间、电力、空调和其他本领域技术人员已知的考虑因素。随着移动边缘计算(mec)的创新，可能需要企业/服务提供商边缘来服务于较小的偏远地区以及中小型城镇。为了确保适当的性能和优化各种云(例如，vim实例)的性能，可以由位于中心位置的各种监控组件执行监控。
83.图10是示出包括具有管理节点1010和虚拟基础设施管理器(vim)pod 1020配置的vim-监控(mon)架构1000的系统的框图。也就是说，为了部署电信云移动核心网络，移动网络运营商可以使用开源软件，例如openstack。vim pod 1020可以将openstack用于分布式telcocloud部署和企业云。因此，vim pod 1020中包括计算节点1022a-n、存储节点1024a-c和控制器节点1026a-c。实际的节点数量取决于特定的部署。vim pod 1020可以使用云/nfvi pod级别的监控机制。监控机制可以使用事件监控服务器1011，该服务器可以体现为prometheus服务器，并且被托管在管理节点1010上。
84.具体地，vim监控是使用名为vim-mon的轻量级pod级监控解决方案执行的，该解决方案基于开源prometheus、telegraf、grafana(ptg)堆栈。vim-mon架构1000采用基于安装在vim pod 1020中所有节点上的度量收集和报告代理的基础设施级度量收集。度量收集和报告代理1030a-j用圆圈中的“t”表示，因为它们可以体现为telegraf代理。此外，vim-mon架构1000将度量聚合应用到安装在管理节点1010上的时间序列数据库(tsdb)1012中。vim-mon架构1000还提供集成在管理节点1010中的警报管理器1013和具有为vim定制的预定义仪表板的监控图形界面1014。可以使用诸如grafana的可视化应用程序1016来可视化统计数据。可以通过统一计算系统监视器1060提供裸机警报。
85.当启用vim-mon架构1000的选项时，vim-mon架构1000可以通过由vim安装程序部署的多个容器和进程来实现。如上所述，度量可以由度量收集和报告代理1030a-j收集。vim pod 1020中的每个节点有一个度量收集和报告代理1030a-j。大多数度量都是本地的；使用远程api收集一些度量(例如，管理节点1010上的度量收集和报告代理1030a使用openstack api收集openstack度量)。这些度量然后由在管理节点1010上运行的事件监控服务器1011以规则间隔(例如，15秒的默认抓取间隔)读取(“抓取”)。被抓取的度量在管理节点1010上被接收，然后被存储在本地tsdb 1012中。
86.事件监控服务器1011还使用这些传入度量来评估警报规则(这些规则是基于使用可编程表达式的度量值并且存储在配置和警报规则数据库1015中的规则)。当警报规则变为活动状态时，会在未决状态下创建警报。当未决的警报在一定时间内保持未决状态时，它将被触发(firing)。然后将触发警报发送到管理节点1010中的警报管理器1013以供进一步处理。警报管理器可以向警报接收器1040中的一个或多个提供各种触发警报。简单网络管理协议(snmp)警报可以通过snmp代理1050发送，并且它们可以利用snmp陷阱1052和snmp管理器1054。
87.vim pod架构可支持多达256个计算节点1022a-n，然而，可能存在影响性能和监控系统的限制。例如，如果存在任何故障/过载，则管理节点1010可以停止从vim pod 1020中的计算节点1022a-n收集所有度量。此外，管理节点1010从所有计算节点1022a-n收集统计关键性能指标(kpi)并将收集到的数据存储在tsdb 1012中。使用事件监视服务器1011执行对收集的数据的处理。事件监控服务器1011需要按每个站点运行以收集和处理数据。每个站点都有一个事件监控服务器1011在操作上管理起来很复杂。此外，vim并非普遍部署，这意味着并非所有pod 1020都具有相同的大小，并且它们的部署取决于客户配置。对于中小型位置，硬件资源有限，并且每个站点都有运行专用事件监视服务器1011的专用管理节点1010可能非常昂贵。
88.此外，当管理节点1010不可用时(例如，由于拥塞、过载、硬件故障和软件故障等)，vim-mon架构1000可以停止监视性能数据。这会导致pod级别的tsdb隔离。此外，在vim-mon架构1000中，管理节点1010可能不可扩展以监控大型部署(例如，包括部署在多个位置的数百个计算节点1022a-n的部署)。此外，tsdb 1012可以被限制为度量保留时间(例如，十五天)，这导致自动删除旧度量。此外，边缘pod可能需要专用计算节点1022a-n来监控管理节点1010。这样的要求也可能导致操作复杂性。
89.因此，在本公开的示例实施例中，可以部署不依赖于用于管理的特定硬件的可扩展的vim监控架构。也就是说，集中vim被部署在可以处理云的各种不同故障场景的高可用性(ha)配置的中心位置。集中vim ha或监控节点监控多个云(vim实例)。集中vim ha监控分布式云部署，其可能包括每个位置的多个计算节点、多个存储节点和多个控制器节点。集中vim ha除了监控各种边缘站点外，还监控中央数据中心和可能大小不同的各种其他pod站点，包括nano-pod站点。节点的实际数量取决于特定的部署。因此，在各种示例实施例中，提供了一种集中监视解决方案(集中vim-mon-ha)，它允许监视大规模电信工作负载，而不会影响速度并且不会遭受开源度量收集工具的各种缺点，例如上面提到的那些。
90.图11是示出根据示例实施例的包括vim-mon-ha 1110的系统1100的框图。在图11中，系统1100包括多个远程计算实体。多个远程计算实体可以包括边缘数据中心或组中心
mon堆栈由运行在kubernetes集群1245上的一组容器化应用程序组成，并且如参考以上图11的kubernetes集群1145所描述的。集中解决方案的一个挑战是将度量从可能非常大量的服务器传输到中央事件监控服务器。在示例实施例中，度量以良好的速度从各个位置传输到中央事件监控服务器，同时避免了上述开源度量收集工具的缺点。
98.图13是示出根据示例实施例的vim pod配置1300的框图。例如，vim pod 1305可以是图11的pod 1105a-c或图12的pod 1205a-d中的一个或多个的更详细视图。因此，vim pod 1305包括四个节点、控制器节点1325a-c和非控制器节点1325d。非控制器节点1325d可以是计算节点或存储节点中的一个或多个，例如计算节点1130a和1130b或存储节点1135，如图11所示。
99.每个控制器节点1325a-c包括ha代理1320a-c以及度量收集和报告代理1310a-c。包括在每个度量收集和报告代理1310a-c中的是度量收集和报告代理(t-代理)1330a-c和伴随的t-代理端口1332a-c、具有伴随端口1337a-c的事件监控输出插件1335a-c、以及高速缓存1350a-c。每个度量收集和报告代理1310a-c还包括一个或多个输入插件1355a-i。非控制器节点1325d包括具有伴随端口1337d的事件监控输出插件1335d以及高速缓存1350d。度量收集和报告代理1310d包括一个或多个输入插件1355j和1335k，但缺少t-代理及其伴随端口。非控制器节点1325d也缺少ha代理。
100.集中vim-mon架构依赖于基于在每个节点1325a-c上运行的轻量级t-代理1330a-c的2级分层收集系统。这种设计是使用两级prometheus服务器的传统prometheus联合设计与简单的单级中央prometheus设计之间的混合方法。
101.如上所述，控制器节点1325a-c上的度量收集和报告代理1310a-c包括t-代理1330a-c。t-代理1330a-c是提供额外的代表性状态传输(rest)端口或t-代理端口1332a-c(其是指定端口9283的服务端口)的特殊插件。t-代理1330a-c为来自ha代理1320a-c后面的事件监控服务器1340的抓取请求提供服务。ha代理1320a-c选择一个控制器节点1325a-c来处理所有rest请求，在示例图3中的控制器节点是控制器节点1325a，而其余两个控制器节点1325b和1325c在备用模式下运行。也就是说，ha代理1320a提供了一个高可用性负载平衡器，以及一个用于跨多个服务器传播请求的基于tcp和http的应用程序的代理服务器。存在ha代理1320a-c在每个控制器节点1325a-c上运行，但只有ha代理1320a是活动的，其余的ha代理1320b和1320c处于备用状态。在活动控制器节点1325a上运行的t-代理1330a从中央事件监控服务器1340接收rest请求。在示例实施例中，ha代理1320a选择接收rest请求的活动控制器节点1325a。ha代理1320a对活动控制器节点1325a的选择是内部消息收发过程。
102.如上所述，在活动控制器节点1325a上运行的度量收集和报告代理1310a通过其t-代理1330a服务点为事件监控抓取请求提供服务。t-代理1330a从在端口9273处的pod(包括本地度量收集和报告代理1310a)中的每个度量收集和报告代理1310a-d中运行的事件监控输出插件1335a-d收集所有度量。当接收到来自中央事件监控服务器1340的请求时，该收集被按需触发。因此，中央事件监控服务器1340控制抓取请求的频率。在收到rest请求后，t-代理1330a会同时调度各个节点的抓取(到端口9273)。节点抓取从高速缓存1350a-d中提取值，缓存中已填充来自输入插件1355a-k的数据。服务请求的时间可以受从事件监控输出插件1335a-d的任何节点事件监控输出插件高速缓存1350a-d收集度量的最长时间限制。由于这些度量是从内存高速缓存(即插件高速缓存1350a-d)中读取的，因此为事件监控请求提
供服务的时间很快，并且可以随着pod大小的增加而很好地扩展。
103.如图13所示，t-代理1330a可以将对rest请求的响应作为诸如zip文件1360之类的压缩数据文件返回。zip文件1360的内容可以存储在tsdb 1370中以供分析。
104.现在参考图14，其中描绘了根据示例实施例的示出使用vim-mon-ha从各个位置抓取度量的方法的呼叫流程图1400。更具体地，呼叫流程图1400包括在集中vim-mon 1410和布置在pod 1406内的节点1425a-d处和之间发生的操作和消息交换。呼叫流程图1400的方法开始于操作1405a-d，其中将度量从pod的输入插件推送到输出插件的高速缓存。例如，操作1405a-d可以体现为输入插件1355a-k将度量数据推送到图13的高速缓存1350a-d。操作1432包括从集中vim-mon 1410向pod 1406的活动控制器节点1425a进行的度量抓取rest调用。在操作1434a-d中，控制器节点t-代理1430a向节点1425a-d的输出插件1435a-d发送节点抓取请求，每个输出插件以操作1436a-d的相应节点抓取响应进行响应。
105.在操作1438中，t-代理1430a编译操作1436a-d的节点抓取响应并且在操作1438中向t-代理1430a的输出接口提供事件监控抓取响应。在操作1440中，收集的度量被提供给集中vim-mon 1410。一旦被集中vim-mon 1410接收到，度量就可以存储在tsdb中，例如图13的tsdb 1370。图14示出了集中vim-mon 1410从单个区域的单个城域内的单个pod接收度量的方法，例如从图12的区域1215内的城域1210a的pod 1205a接收度量。因为集中vim-mon 1410是集中的，所以它被配置为接收来自相同或不同城域和相同或不同区域内的其他pod的度量。例如，图12的集中vim-mon 1220可以使用类似于图14所示的方法从每个pod 1205a-d接收度量。
106.现在参考图15，其中描绘了示出包括vim-mon-ha 1505的系统1500的框图。vim-mon-ha中所包括的是kubernetes集群1506，它类似于图11的kubernetes集群1145和图12的kubernetes集群1245。与kubernetes集群1506一起执行的是vim-mon堆栈1507。更具体地，vim-mon-ha 1505是集中vim-mon-ha，例如图11的集中vim-mon-ha 1110或图12的集中vim-mon 1220。vim-mon堆栈1507包括警报规则数据库1520(其类似于图10的警报规则数据库1015)和事件监视服务器1525(其类似于图11的事件监视服务器1011)。vim-mon堆栈1507还包括注册服务器1510。集中vim-mon-ha 1505被配置为从vim pod 1530中提取度量数据，该vim pod 1530被布置在区域1540的城域1535内。因为集中vim-mon-ha 1505是集中的，所以它也可以被配置为从与vim pod 1530相同或不同的城域和/或区域内的其他vim pod提取度量数据。
107.如图15所示，注册服务器1510(在vim-mon堆栈1507中的kubernetes集群1506中运行)以以下工作流程运行：
108.1.每个被监控的vim pod 1530通过rest界面向注册服务器1510注册。
109.2.注册服务器1510更新事件监控服务器1525的事件监控配置文件中的目标列表，并通过helm更新推送新文件。
110.3.事件监控服务器1525在检测到文件已经改变时重新加载新的配置文件。
111.4.事件监视服务器1525以配置的间隔从新的vim pod 1530中抽取度量。
112.包括需要中央监控的vim pod 1530的每个vim pod具有监控注册客户端，该客户端负责与中央注册服务器1510交互以将自己注册为监控目标，并最终在需要时通知任何安全凭证的变化。注册客户端可以作为当前度量收集和报告代理中的新插件运行，继承度量
收集和报告代理的ha设计及其vim配置工作流程，如图13所示。
113.注册服务器1510在容器中运行，该容器在kubernetes集群1506的任何节点上运行。它受制于简单的ha(例如，如果注册服务器1510出现故障，则由kubernetes集群1506重新启动)。注册服务器1510可以设置有基本认证和传输层安全(tls)。用于实施认证和tls的密码和证书文件在初始化注册服务器1510之前被适当设置，并连同注册服务器1510的统一资源定位符(url)被配置在注册客户端侧上。
114.现在参考图16，其中描绘了流程图1600，其示出了根据示例实施例的从各种远程计算实体收集性能数据的第一方法。流程图1600的处理流程开始于操作1605，其中由远程控制实体处的活动控制器获得抓取请求。抓取请求被配置为向多个远程计算实体请求性能数据，并且抓取请求是由活动控制器从中央服务器获得的。例如，操作1605可以体现为t-代理1330a从集中vim-mon-ha获得抓取请求，如参考图13和图14所描述的。
115.在操作1610中，活动控制器提供对多个远程计算实体的性能数据的多个单独请求。多个远程计算实体包括由活动控制器管理的第一组实体和由另一个控制器管理的第二组实体。操作1610可以体现为从活动控制器节点1325a的t-代理1330a向节点1325a-d的度量收集和报告代理1310a-d提供单独的抓取请求。操作1610也可以体现为t-代理1430a提供单独的抓取请求1434a-d，如图14所示。
116.在操作1615中，活动控制器获得具有多个远程计算实体的性能数据的多个单独响应。例如，操作1615可以体现为t-代理1330a从图13中的事件监控输出插件1335a-d接收度量数据和/或图14的操作1436a-d的节点抓取响应。
117.最后，在操作1620中，活动控制器向中央服务器提供响应，该响应包括从多个单独响应获得的聚合的性能数据。操作1620可以体现为t-代理1330a向事件监控服务器1340提供聚合的度量数据，如图13所示，和/或t-代理1430a通过消息1440向集中vim-mon 1410提供收集的度量，如图14所示。
118.现在参考图17，其中描绘了流程图1700，其示出了根据示例实施例的从各种远程计算实体收集性能数据的第二方法。流程图1700的处理流程开始于操作1705，其中从集中管理节点向第一控制器节点提供第一请求，该第一请求用于从布置在第一交付点内的第一计算实体获得第一性能数据。因此，操作1705可以体现为将操作1432的消息从集中vim-mon 1410发送到t-代理1430a，其中t-代理1430a被布置在第一pod内，如图14所示。
119.在操作1710中，从集中管理节点向第二控制器节点提供第二请求，该第二请求用于从布置在第二交付点内的第二计算实体获得第二性能数据。因此，操作1710可以体现为将操作1432的消息从集中vim-mon 1410发送到t-代理1430a，其中t-代理1430a被布置在第二pod内，如图14所示。
120.在操作1715中，从第一控制器节点获得具有第一计算实体的第一性能数据的第一响应。因此，操作1715可以体现为从t-代理1430a发送到集中vim-mon 1410的操作1438的消息，其中t-代理1430a被布置在第一pod内，如图14所示。
121.在操作1720中，从第二控制器节点获得具有第二计算实体的第二性能数据的第二响应。因此，操作1720可以体现为从t-代理1430a发送到集中vim-mon 1410的操作1438的消息，其中t-代理1430a被布置在第二pod内，如图14所示。
122.综上所述，上述监控技术提供了集中vim-mon-ha的集中监控解决方案，包括针对
监控大规模电信工作负载的行业问题的创新解决方案，同时不影响开源度量收集工具的速度和缺点。
123.现在参考图18，其中描绘了计算设备1800的硬件框图，该计算设备1800可以执行结合图1-图17在此提及的任何服务器或计算实体的功能。应该理解，图18仅提供了一个实施例的说明并且不暗示关于可以实施不同实施例的环境的任何限制。可以对所描绘的环境进行许多修改。
124.如图所示，设备1800包括总线1812，其提供(一个或多个)计算机处理器1814、存储器1816、永久存储装置1818、通信单元1820和(一个或多个)输入/输出(i/o)接口1822之间的通信。总线1812可以用设计用于在处理器(例如微处理器、通信和网络处理器等)、系统存储器、外围设备和系统内的任何其他硬件组件之间传递数据和/或控制信息的任何架构来实施。例如，总线1812可以用一个或多个总线来实施。
125.存储器1816和永久存储装置1818是计算机可读存储介质。在所描绘的实施例中，存储器1816包括ram 1824和高速缓存存储器1826。通常，存储器1816可以包括任何合适的易失性或非易失性计算机可读存储介质。集中管理、配设和监控软件1825的指令可以存储在存储器1816或永久存储装置1818中以供(一个或多个)处理器1814执行。
126.一个或多个程序可以存储在永久存储装置1818中以供一个或多个相应的计算机处理器1814通过存储器1816中的一个或多个存储器执行。永久存储装置1818可以是磁性硬盘驱动器、固态硬盘驱动器、半导体存储设备、只读存储器(rom)、可擦除可编程只读存储器(eprom)、闪存或能够存储程序指令或数字信息的任何其他计算机可读存储介质。
127.永久存储装置1818使用的介质也可以是可移动的。例如，可移动硬盘驱动器可用于永久存储装置1818。其他示例包括插入驱动器中的光盘和磁盘、拇指驱动器和智能卡，以传输到也是永久存储装置1818的一部分的另一个计算机可读存储介质上。
128.在这些示例中，通信单元1820提供与其他数据处理系统或设备的通信。在这些示例中，通信单元1820包括一个或多个网络接口卡。通信单元1820可以通过使用物理和无线通信链路之一或两者来提供通信。
129.(一个或多个)i/o接口1822允许与可以连接到计算机设备1800的其他设备输入和输出数据。例如，i/o接口1822可以提供到外部设备1828(例如键盘、小键盘、触摸屏和/或一些其他合适的输入设备)的连接。外部设备1828还可以包括便携式计算机可读存储介质，例如数据库系统、拇指驱动器、便携式光盘或磁盘以及存储卡。
130.用于实施实施例的软件和数据可以存储在这种便携式计算机可读存储介质上，并且可以通过(一个或多个)i/o接口1822加载到永久存储1818上。(一个或多个)i/o接口1822也可以连接到显示器1830。显示器1830提供了一种向用户显示数据的机制并且可以是例如计算机监视器。
131.本文描述的程序是基于在特定实施例中实施它们的应用程序来识别的。然而，应当理解，本文使用任何特定的程序命名法仅仅是为了方便，因此实施例不应限于仅用于由这种命名法识别和/或暗示的任何特定应用中。
132.与本文描述的操作相关的数据可以存储在任何常规或其他数据结构(例如，文件、数组、列表、堆栈、队列、记录等)中，并且可以存储在任何期望的存储单元(例如，数据库、数据或其他存储库、队列等)。实体之间传输的数据可以包括任何所需的格式和排列，并且可
以包括任何数量的任何类型的任何大小的字段来存储数据。任何数据集的定义和数据模型可以以任何期望的方式(例如，计算机相关语言、图形表示、列表等)指示总体结构。
133.当前实施例可以使用任何数量的任何类型的用户界面(例如，图形用户界面(gui)、命令行、提示等)来获取或提供信息，其中该界面可以包括以任何方式排列的任何信息。界面可以包括设置在任何位置的任何数量的任何类型的输入或驱动机制(例如按钮、图标、字段、框、链接等)，以通过任何合适的输入设备(例如鼠标、键盘等)输入/显示信息并启动所需的操作。界面屏幕可以包括任何合适的致动器(例如，链接、选项卡等)，从而以任何方式在屏幕之间导航。
134.当前实施例的环境可以包括任何数量的计算机或其他处理系统(例如，客户端或终端用户系统、服务器系统等)以及以任何期望的方式布置的数据库或其他储存库，其中可以应用当前实施例到任何所需类型的计算环境(例如，云计算、客户端-服务器、网络计算、大型机、独立系统等)。当前实施例所采用的计算机或其他处理系统可以由任何数量的任何个人或其他类型的计算机或处理系统(例如，台式机、膝上型电脑、pda、移动设备等)来实施，并且可以包括任何商业上可获得的操作系统以及商用和定制软件(例如机器学习软件等)的任何组合。这些系统可以包括任何类型的监视器和输入设备(例如，键盘、鼠标、语音识别等)来输入和/或查看信息。
135.应当理解，当前实施例的软件可以以任何期望的计算机语言来实施，并且可以由计算机领域的普通技术人员基于包含在说明书中的功能描述和附图所示的流程图来开发。此外，本文中对执行各种功能的软件的任何引用通常是指在软件控制下执行这些功能的计算机系统或处理器。当前实施例的计算机系统可以替代地由任何类型的硬件和/或其他处理电路来实施。
136.本文描述的每个元件可以通过接口和/或通过提供可行的通信路径的任何其他合适的连接(有线或无线)相互耦合和/或互动。本文讨论的互连、接口及其变体可用于提供系统中的元件之间的连接和/或可用于提供可在系统中直接或间接连接的元件之间的通信、互动、操作等。可以为这里描述的元件提供接口的任何组合，以便促进如针对本文描述的各种实施例所讨论的操作。
137.计算机或其他处理系统的各种功能可以以任何方式分布在任何数量的软件和/或硬件模块或单元、处理或计算机系统和/或电路中，其中计算机或处理系统可以在彼此本地或远程设置，通过任何合适的通信介质(例如，lan、wan、intranet、互联网、硬线、调制解调器连接、无线等)通信。例如，当前实施例的功能可以以任何方式分布在各种终端用户/客户端和服务器系统和/或任何其他中间处理设备之间。以上描述的和流程图中示出的软件和/或算法可以以任何方式修改，该方式实现本文描述的功能。此外，流程图或描述中的功能可以按任何顺序执行，该顺序实现所需的操作。
138.当前实施例的软件在固定的或便携式程序产品装置或设备的非暂态计算机可用介质(例如，磁或光介质、磁光介质、软盘、cd-rom、dvd、存储设备等)上可用，以供与独立系统或通过网络或其他通信介质连接的系统一起使用。
139.通信网络可以由任何数量的任何类型的通信网络(例如，lan、wan、互联网、intranet、vpn等)来实施。当前实施例的计算机或其他处理系统可以包括任何传统或其他通信设备，以通过任何传统或其他协议在网络上进行通信。计算机或其他处理系统可以利
用任何类型的连接(例如，有线、无线等)来访问网络。本地通信介质可以由任何合适的通信介质(例如，局域网(lan)、硬线、无线链路、intranet等)来实施。
140.该系统可以采用任何数量的任何常规或其他数据库、数据存储或存储结构(例如，文件、数据库、数据结构、数据或其他储存库等)来存储信息。数据库系统可以由任何数量的任何常规或其他数据库、数据存储或存储结构(例如，文件、数据库、数据结构、数据或其他储存库等)来实施以存储信息。数据库系统可以包括在服务器和/或客户端系统内或耦合到服务器和/或客户端系统。数据库系统和/或存储结构可以在计算机或其他处理系统远程或本地，并且可以存储任何期望的数据。
141.当前实施例可以采用任何数量的任何类型的用户界面(例如，图形用户界面(gui)、命令行、提示等)来获取或提供信息，其中该界面可以包括以任何方式排列的任何信息。界面可以包括设置在任何位置的任何数量的任何类型的输入或驱动机制(例如按钮、图标、字段、框、链接等)，以通过任何合适的输入设备(例如鼠标、键盘等)输入/显示信息并启动所需的操作。界面屏幕可以包括任何合适的致动器(例如，链接、选项卡等)，从而以任何方式在屏幕之间导航。
142.所呈现的实施例可以采用各种形式，例如任何可能的技术细节集成级别的系统、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质(或媒介)，其上具有计算机可读程序指令，用于使处理器执行本文所呈现的方面。
143.计算机可读存储介质可以是可以保留和存储指令以供指令执行设备使用的有形设备。计算机可读存储介质可以是例如但不限于电子存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或前述的任何合适的组合。计算机可读存储介质的更具体示例的非详尽列表包括以下内容：便携式计算机软盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或闪存)、静态随机存取存储器(sram)、便携式光盘只读存储器(cd-rom)、数字多功能磁盘(dvd)、记忆棒、软盘、机械编码设备，例如其上记录有指令的穿孔卡或凹槽中的凸起结构，以及前述的任何适当组合。如本文所用，计算机可读存储介质不应被解释为暂态信号本身，例如无线电波或其他自由传播的电磁波、传播通过波导或其他传输介质的电磁波(例如，光脉冲通过光纤电缆)或通过电线传输的电信号。
144.本文描述的计算机可读程序指令可以从计算机可读存储介质下载到相应的计算/处理设备，或者经由网络下载到外部计算机或外部存储设备，例如互联网、局域网、广域网和/或无线网络。该网络可以包括铜传输电缆、光传输光纤、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或网络接口从网络接收计算机可读程序指令并且转发计算机可读程序指令以存储在相应计算/处理设备内的计算机可读存储介质中。
145.用于执行当前实施例的操作的计算机可读程序指令可以是汇编指令、指令-集-架构(isa)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、集成电路的配置数据、或以一种或多种编程语言的任何组合编写的源代码或目标代码，包括面向对象的编程语言，例如python、c 等，以及过程编程语言，例如“c”编程语言或类似的编程语言。该计算机可读程序指令可完全在用户的计算机上执行，部分地在用户的计算机上执行，作为独立的软件包执行，部分地在用户的计算机上并且部分地在远程计算机上执行，或完全在远
程计算机或服务器上执行。在后一场景中，可通过任何类型的网络(包括局域网(lan)或广域网(wan))将远程计算机连接至用户的计算机，或者该连接可以建立至外部计算机(例如，通过使用互联网服务提供商的互联网)。在一些实施例中，包括例如可编程逻辑电路、现场可编程门阵列(fpga)或可编程逻辑阵列(pla)的电子电路可以通过利用计算机可读程序指令的状态信息来执行计算机可读程序指令以个性化电子电路，以便执行本文提出的方面。
146.参考根据实施例的方法、装置(系统)和计算机程序产品的流程图说明和/或框图，本文描述了当前实施例的方面。应当理解，流程图说明和/或框图中的每个框，以及流程图说明和/或框图中的框的组合，可以由计算机程序指令来实施。
147.这些计算机可读程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器以产生机器，使得经由计算机的处理器或其他可编程数据处理装置执行的指令创建用于实施流程图和/或框图的一个或多个框中指定的功能/动作的装置。这些计算机可读程序指令也可以存储在计算机可读存储介质中，该计算机可读存储介质可以引导计算机、可编程数据处理装置和/或其他设备以特定方式运行，使得其中存储有指令的计算机可读存储介质包括实施流程图和/或框图的一个或多个框中指定的功能/动作的方面的指令的制品。
148.计算机可读程序指令也可以被加载到计算机、其他可编程数据处理装置或其他设备上，以使得一系列操作步骤在该计算机、其他可编程装置或其他设备上执行以产生计算机实施进程，使得在该计算机、其他可编程装置、其他设备上执行的指令实施在流程图和/或框图的一个或多个框中指定的功能/动作。
149.附图中的流程图和框图示出了根据各种实施例的系统、方法和计算机程序产品的可能实施方式的架构、功能和操作。在这点上，流程图或框图中的每个框都可以表示模块、片段或指令的一部分，其包含用于实现(一个或多个)特定逻辑功能的一个或多个可执行指令。在一些替代实施方式中，框中标注的功能可能不按图中标注的顺序发生。例如，取决于所涉及的功能，连续示出的两个框实际上可以基本上同时执行，或者框有时可以以相反的顺序执行。还应当注意，框图和/或流程图说明中的每个框，以及框图和/或流程图说明中的框的组合，可以通过执行所详细描述的功能或动作的基于专用硬件的系统来实施，或通过专用硬件和计算机指令的组合来实施。
150.此外，诸如“发送”和“接收”之类的术语在本文中广泛用于指代用于在网络环境中提供和获得数据的技术。例如，可以通过经由网络发送和接收的分组来提供和获得数据。还可以通过经由带外信令或网络环境中使用的控制信道传送的数据来提供和获得数据。
151.总之，本文提供了用于集中管理和配设的方法，包括：从在集中管理节点上执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第一映像文件，其中第一映像文件包括第一引导配置文件或第一内存虚拟盘文件中的至少一者；从在集中管理节点上执行的第二虚拟机向布置在与第一交付点不同的第二交付点内的第二计算实体提供第二映像文件，其中第二映像文件包括第二引导配置文件或第二内存虚拟盘文件中的至少一者；从在集中管理节点上执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第三映像文件，其中第三映像文件包括第一操作系统安装文件；以及从在集中管理节点上执行的第二虚拟机向布置在第二交付点内的第二计算实体提供第四映像文件，其中第四映像文件包括第二操作系统安装文件。
152.根据所公开方法的某些示例实施例，第一交付点包括第一openstack交付点，并且第二交付点包括第二openstack交付点。
153.此外，根据所公开的方法的某些示例实施例，第三映像文件还包括第一证书文件，该第一证书文件被配置为使第一计算实体能够执行第一操作系统安装文件的证书验证。
154.根据所公开方法的示例实施例，第一计算实体包括控制器节点、计算节点和/或存储节点中的至少一者。
155.根据所公开的方法的其他示例实施例，第一虚拟机被配置为用于第一交付点的第一管理节点；并且第二虚拟机被配置为第二交付点的第二管理节点。
156.根据所公开方法的又一示例实施例，将第一映像文件提供给布置在第一交付点内的第一计算实体包括经由广域网提供第一映像文件。
157.在所公开方法的又一示例实施例中，将第一映像文件提供给布置在第一交付点内的第一计算实体包括经由局域网提供第一映像文件。
158.所公开方法的具体示例实施例还包括：在集中管理节点处获取第一动态主机配置协议请求，其中第一映像文件被响应于获取第一动态主机配置协议请求而提供给第一计算实体；以及在集中管理节点处获得第二动态主机配置协议请求，其中第二映像文件被响应于获取第二动态主机配置协议请求而提供给第二计算实体。
159.本公开的集中管理和配设技术还提供了装置。该装置包括一个或多个网络接口和一个或多个处理器。一个或多个处理器被配置为：经由一个或多个网络接口从通过一个或多个处理器执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第一映像文件，其中，第一映像文件包括第一引导配置文件或第一内存虚拟盘文件中的至少一者；经由一个或多个网络接口从通过一个或多个处理器执行的第二虚拟机向布置在与第一交付点不同的第二交付点内的第二计算实体提供第二映像文件，其中第二映像文件包括第二引导配置文件或第二内存虚拟盘文件中的至少一者；经由一个或多个网络接口从经由一个或多个处理器执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第三映像文件，其中第三映像文件包括第一操作系统安装文件；以及经由一个或多个网络接口从通过一个或多个处理器执行的第二虚拟机向布置在第二交付点内的第二计算实体提供第四映像文件，其中第四映像文件包括第二操作系统安装文件。
160.根据所公开的装置的具体示例实施例，第一交付点包括第一openstack交付点；并且第二交付点包括第二openstack交付点。
161.根据所公开装置的其他示例实施例，第三映像文件还包括第一证书文件，第一证书文件被配置为使第一计算实体能够执行对第一操作系统安装文件的证书验证。
162.根据所公开装置的又一示例实施例，第一计算实体包括控制器节点、计算节点和/或存储节点中的至少一者。
163.根据所公开装置的具体示例实施例，第一虚拟机被配置为用于第一交付点的第一管理节点；并且第二虚拟机被配置为用于第二交付点的第二管理节点。
164.根据所公开装置的又一示例实施例，一个或多个处理器被配置为通过经由广域网提供第一映像文件来将第一映像文件提供给布置在第一交付点内的第一计算实体。
165.同样根据本公开的管理和供应技术的是一个或多个有形非暂态的计算机可读介质。一个或多个计算机可读介质用指令编码，当由一个或多个处理器执行时，这些指令可操
作用于：从在集中管理节点上执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第一映像文件，其中第一映像文件包括第一引导配置文件或第一内存虚拟盘文件中的至少一者；从在集中管理节点上执行的第二虚拟机向布置在与第一交付点不同的第二交付点内的第二计算实体提供第二映像文件，其中第二映像文件包括第二引导配置文件或第二内存虚拟盘文件中的至少一者；从在集中管理节点上执行的第一虚拟机向布置在第一交付点内的第一计算实体提供第三映像文件，其中第三映像文件包括第一操作系统安装文件；以及从在集中管理节点上执行的第二虚拟机向布置在第二交付点内的第二计算实体提供第四映像文件，其中第四映像文件包括第二操作系统安装文件。
166.根据所公开的一个或多个有形非暂态计算机可读介质的特定示例实施例，第一交付点包括第一openstack交付点；并且第二交付点包括第二openstack交付点。
167.根据所公开的一个或多个有形非暂态计算机可读介质的特定示例实施例，第三映像文件还包括第一证书文件，该第一证书文件被配置为使第一计算实体能够执行第一操作系统安装文件的证书验证。
168.根据所公开的一个或多个有形非暂态计算机可读介质的特定示例实施例，第一计算实体包括控制器节点、计算节点和/或存储节点中的至少一个。
169.根据所公开的一个或多个有形非暂态计算机可读介质的又一示例实施例，第一虚拟机被配置为用于第一交付点的第一管理节点；并且第二虚拟机被配置为用于第二交付点的第二管理节点。
170.根据一个或多个有形非暂态计算机可读介质的附加示例实施例，可操作以将第一映像文件提供给布置在第一交付点内的第一计算实体的指令还可操作以通过广域网提供第一映像文件。
171.根据本公开的集中管理技术的方法包括：从集中管理节点向第一控制器节点提供用于从布置在第一交付点内的第一计算实体获得第一性能数据的第一请求；从集中管理节点向第二控制器节点提供用于从布置在与第一交付点不同的第二交付点内的第二计算实体获得第二性能数据的第二请求；从第一控制器节点获得具有第一计算实体的第一性能数据的第一响应；以及从第二控制器节点获得具有第二计算实体的第二性能数据的第二响应。
172.根据所公开方法的具体示例实施例，第一交付点包括第一openstack交付点；并且第二交付点包括第二openstack交付点。
173.根据所公开方法的其他示例实施例，获得具有第一计算实体的第一性能数据的第一响应包括从第一交付点的第一活动控制器节点接收第一性能数据，其中第一交付点包括第一活动控制器节点和第一备用控制器节点；并且其中获得具有第二计算实体的第二性能数据的第二响应包括从第二交付点的第二活动控制器节点接收第二性能数据，其中第二交付点包括第二活动控制器节点和第二备用控制器节点。
174.根据所公开方法的又一示例实施例，第一计算实体包括第一控制器节点。
175.根据所公开方法的具体示例实施例，第一计算实体可以包括备用控制器节点、计算节点和/或存储节点中的至少一者。
176.在又一些示例实施例中，所公开的方法还可以包括：从集中管理节点提供用于从布置在第一交付点内的第一计算实体获得第三性能数据的第三请求；以及从第三控制器节
点获得具有第一计算实体的第三性能数据的第三响应，其中响应于第一控制器节点的故障从第三控制器节点接收第三性能数据。
177.根据所公开方法的其他示例实施例，提供用于从布置在第一交付点内的第一计算实体获得第一性能数据的第一请求包括提供用于获得用于布置在第一交付点内的多个计算实体的第一性能数据的第一请求。
178.本公开的集中监控技术还提供了装置。该装置包括一个或多个网络接口和一个或多个处理器。一个或多个处理器被配置为：经由一个或多个网络接口向第一控制器节点提供用于从布置在第一交付点内的第一计算实体获得第一性能数据的第一请求；经由一个或多个网络接口向第二控制器节点提供用于从布置在与第一交付点不同的第二交付点内的第二计算实体获得第二性能数据的第二请求；经由来自第一控制器节点的一个或多个网络接口获得具有第一计算实体的第一性能数据的第一响应；并且经由来自第二控制器节点的一个或多个网络接口获得具有第二计算实体的第二性能数据的第二响应。
179.根据所公开装置的具体示例实施例，第一交付点包括第一openstack交付点；并且第二交付点包括第二openstack交付点。
180.根据所公开装置的其他示例实施例，一个或多个处理器被配置为通过从第一交付点的第一活动控制器节点接收第一性能数据来获得具有第一计算实体的第一性能数据的第一响应，其中第一交付点包括第一活动控制器节点和第一备用控制器节点；并且一个或多个处理器被配置为通过从第二交付点的第二活动控制器节点接收第二性能数据来获得具有第二计算实体的第二性能数据的所述第二响应，其中第二交付点包括：第二活动控制器节点和第二备用控制器节点。
181.根据所公开装置的特定示例实施例，第一计算实体包括第一控制器节点。
182.根据所公开装置的其他示例实施例，第一计算实体包括备用控制器节点、计算节点和/或存储节点中的至少一者。
183.根据所公开装置的附加示例实施例，一个或多个处理器还被配置为：经由一个或多个网络接口提供用于从布置在第一交付点内的第一计算实体获得第三性能数据的第三请求；并且经由一个或多个网络接口从第三控制器节点获得具有第一计算实体的第三性能数据的第三响应，其中响应于第一控制器节点的故障从第三控制器节点接收第三性能数据。
184.根据所公开装置的附加示例实施例，一个或多个处理器被配置为通过提供用于获得用于布置在第一交付点内的多个计算实体的第一性能数据的第一请求，而提供用于从布置在第一交付点内的第一计算实体获得第一性能数据的第一请求。
185.同样根据本公开的集中监控技术的是一种或多种有形非暂态的计算机可读介质。一个或多个计算机可读介质用指令编码，当由一个或多个处理器执行时，该指令可用于：从集中管理节点向第一控制器节点提供用于从布置在第一交付点内的第一计算实体获得第一性能数据的第一请求；从集中管理节点向第二控制器节点提供用于从布置在与第一交付点不同的第二交付点内的第二计算实体获得第二性能数据的第二请求；从第一控制器节点获得具有第一计算实体的第一性能数据的第一响应；并且从第二控制器节点获得具有第二计算实体的第二性能数据的第二响应。
186.根据所公开的一个或多个有形非暂态计算机可读介质的其他示例实施例，第一交
付点包括第一openstack交付点；并且第二交付点包括第二openstack交付点。
187.根据所公开的一个或多个有形非暂态计算机可读介质的又一示例实施例，用于获得具有第一计算实体的第一性能数据的第一响应的指令可操作以从第一交付点的第一活动控制器节点接收第一性能数据，其中第一交付点包括第一活动控制器节点和第一备用控制器节点；并且操作以获得具有第二计算实体的第二性能数据的第二响应的指令可用于从第二交付点的第二活动控制器节点接收第二性能数据，其中第二交付点包括第二活动控制器节点和第二备用控制器节点。
188.根据所公开的一个或多个有形非暂态计算机可读介质的特定示例实施例，第一计算实体包括第一控制器节点。
189.根据所公开的一个或多个有形非暂态计算机可读介质的附加示例实施例，第一计算实体包括备用控制器节点、计算节点和/或存储节点中的至少一者。
190.在所公开的一个或多个有形非暂态计算机可读介质的附加示例实施例中，可操作以提供用于从布置在第一交付点内的第一计算实体获得第一性能数据的第一请求的指令可操作以提供用于获得布置在第一交付点内的多个计算实体的第一性能数据的第一请求。
191.总之，在集中管理节点上执行的第一虚拟机将第一映像文件提供给布置在第一交付点内的第一计算实体。第一映像文件包括第一引导配置文件或第一内存虚拟盘文件。第二虚拟机向布置在与第一交付点不同的第二交付点内的第二计算实体提供第二映像文件。第二映像文件包括第二引导配置文件或第二内存虚拟盘文件。第一虚拟机向第一计算实体提供第三映像文件。第三映像文件包括第一操作系统安装文件。第二虚拟机向第二计算实体提供第四映像文件。第四映像文件包括第二操作系统安装文件。
192.以上描述仅旨在作为示例。尽管本文以一个或多个具体示例来说明和描述这些技术，但并不意在局限于所示的细节，因为可以在权利要求的等同物的范围和界限内进行各种修改和结构改变。