技术领域
[0001] 本
发明属于云计算技术领域，涉及大型网络架构，尤其是一种云平台下的资源监控方法。
背景技术
[0002] 随着大家对云计算概念的不断探索与实践，“云”的理念已经对技术发展有了深刻而远大的影响，同时也成为学术界和产业界的一大热点。当“云”作为一种服务提供给用户，目标是可以帮助服务供应商提高资源的利用率，从而能够用更低的成本提供服务，达到“物美价廉”的目标。但是，想要尽可能满足用户的需求，现有的设计方案和技术实现方法往往差强人意，需要对其进行思考并创新。
[0003] 目前，在云平台上并没有一种规范的监控标准或
原型系统，特别是对于大规模设施及超大型网络，如何近实时地对云环境中的各种资源，包括物理设备及虚拟系统的CPU利用率、内存利用率、带宽使用量等等指标数据进行提取、监控和实时展示，将是一个极富挑战性和亟待解决的问题，也是一个十分有意义的工作。通过实时监控得到的数据信息，管理员可以更直观地判断平台的状态，进而推测服务提供的情况。有了数据，便可以对整个平台，某个集群，某台物理机甚至某部分虚拟系统的状态进行评估和预测，通过系统保存的已执行数据，可以判断过去某段时间的系统状态；通过动态图表呈现的实时数据，可以更直观更及时地发现系统问题；通过对过去及现状的数据进行总结分析，可以对系统的未来态势进行预测。这一系列工作将会为平台的
稳定性和可靠性提供保障，同时，也将会大大提高云服务的
质量及用户的满意程度。
[0004] 云监控服务是各个云服务商提供给云计算用户的监控服务，监控内容也比较广泛。云监控的目的是保障云计算用户的任务可以稳定安全地运行，一旦发生故障，管理员可以及时了解情况并采取措施进行解决，进而降低损失。传统的
监控系统或方法，比如collect技术，端口扫面技术等，很难对大型
计算机网络进行这方面的处理，随着平台规模的扩大或主机数量的增加，监控系统
服务器的负荷会增加，传统监控方法在效率和实时性能上的弊端也将会更清楚地呈现，甚至为这整个平台带来故障，影响平台的稳定性。
[0005] Ganglia作为伯克利开发的一个集群监控
软件，可以监控和显示集群中的
节点的各种状态信息，比如：cpu、mem、
硬盘利用率、I/O负载、网络流量情况等，同时可以将历史数据以曲线形式通过php页面呈现。它在设计理念和操作上与传统的监控系统有所不同，它不仅可以轻松地扩展到超大型的网络上，还可以无缝集成到传统的监控系统中，弥补传统监控系统在试试监控和性能上的不足。但是，对于大规模集群，Ganglia的默认拓扑结构会导致系统的CPU资源的浪费，频繁的交互也可能造成系统网络的混乱。于是，在Ganglia默认的架构上针对大规模集群进行改进，实现简化和定制，使监控系统可以准确实时地为管理员提供平台的资源信息及态势情况。在此
基础上，考虑在得到监控数据后如何利用其庞大的信息进行分析，以得到结论性的价值数据，帮助
定位系统问题的同时，为平台的态势评估提供参考。
发明内容
[0006] 本发明的目的在于克服
现有技术的不足和
缺陷，提供一种单发/单收多播拓扑的基于Openstack的分布式可扩展云平台下的系统资源监控及态势评估实现的云平台下的资源监控方法，该方法以适应大规模集群下的资源监控需求，避免不必要的CPU等资源的浪费。
[0007] 为了实现上述目的，本发明所采用的技术方案包括以下步骤：
[0009] 1.1)对平台进行层次上的划分；
[0010] 1.2)对于集群外的节点，设置一个用于整合监控结果，并安装RRD文件的服务器，同时，提供监控结果查询和展示的UI系统；
[0011] 1.3)集群中的多数节点，安装监控数据的采集模块；
[0012] 1.4)在只负责单发的节点中安装监控模块；
[0013] 1.5)安装后
修改其配置信息，将监控数据的传输目的IP更改为本集群中用于完成“单收”任务的节点；
[0014] 1.6)对于集群以外用于汇总监控数据信息的守护
进程，增加部署RRDtool意外，并安装监控模块；
[0016] 2.1)对于虚拟机的监控系统，将其与
操作系统一起做到虚拟机镜像之中，虚拟机开启，监控系统同步开始发挥监控功能；
[0017] 2.2)安装后修改其配置信息，将监控数据信息传输的目的IP改成集群中用于收集的物理节点对应IP；
[0018] 2.3)在虚拟机与物理机之间设置交换机；
[0020] 3.1)数据通过网络传输至集群中用于“单收”的物理节点，该节点将维护一个XML格式的dump文件；
[0021] 3.2)集群外的总控节点通过侦听/通告协议对各个集群中的手机节点的固定端口进行侦听，以得到最新最完整最准确的监控的指标数据信息；
[0022] 3.3)在总控端，数据将会被存储至RRD文件中，通过RRDtool进行处理；
[0023] 3.4)总控端部署了
可视化的数据展示UI模块，同时为用户提供了任务提交的
接口。
[0024] 所述步骤1.1)中，将平台按照用于提供监控数据的节点和用于收集监控数据的节点进行划分。
[0025] 所述步骤1.3)中，所述采集模块依赖的库包括libconfuse、pkgconfig、PCRE和APR。
[0026] 所述步骤1.4)中，通过命令：sudo apt-get install ganglia-monitor完成监控模块的安装。
[0027] 所述步骤1.6)中，通过命令：sudo apt-get install gmetad完成监控模块的安装。
[0028] 所述步骤1.6)中，集群外用于汇总监控数据收集的守护进程包含三个模块，分别是：监控功能数据侦听/汇总模块、监控数据存储模块以及监控数据UI展示模块。
[0029] 所述监控数据存储模块采用RRD文件。
[0030] 本发明与现有技术相比，具有以下有益效果：
[0031] 现有方法中的是多发/多收多播拓扑结构，而本发明采用单发和单收参数的使得一些部署有监控模块的节点可以充当其他节点的专用汇聚器和
中继器，避免了系统中存在无意义或者重复劳动的模块。本发明“单发”节点的使用消除了大型集群的运行开销，可以有效降低系统中的CPU利用率。同时，“单收”节点帮助避免了网络交互的繁忙，使网络更加合理和通畅。
[0032] 进一步的，本发明主控端用RRD文件来存储数据，RRD文件可以用来存储更长时间的数据，有更好的可扩展性。
附图说明
[0033] 图1为本发明的系统架构图；
[0034] 图2为本发明单发/单收多播的拓扑结构图；
[0035] 图3为本发明的gmetad层次化拓扑图。
具体实施方式
[0036] 参见图1，是本发明中整个监控系统的架构图，由图可以看到，云平台下的资源监控系统分为三个模块，首先是虚拟机层的监控模块，用于监控虚拟机中的资源变化情况；其次是各个集群中物理机层的监控模块，用于监控集群中各个节点的资源变化情况；最后是总控节点的资源监控模块，用于整合指标数据信息，存储并显示数据变化状态。
[0037] 步骤一：安装部署
[0038] 图2中基本呈现了本发明中单个集群中的监控模块在物理机中的部署及数据传输方案，虚拟机中的部署是基本一致的，只是与物理机层跨域存在。那么，在不同层次中的具体部署方案如下：
[0039] (1)虚拟机层及集群
中子节点的监控模块部署方案
[0040] (1.1)虚拟机层及集群中
子节点的监控模块安装在每台需要监控的主机上，它通过与主机操作系统交互一获取指标数据，并与同一集群内的其他主机共享数据。集群内的已安装的该模块已知同一集群内其他主机所收集的数据，并默认向任意连接其端口的客户端提供整个集群状态的XML格式的dump文件。
[0041] (1.2)在大多数情况下，多发/多收多播拓扑往往已经可以满足需求，但是，在某些情形下需要制定一些特定的接收者，而不允许所有节点都接收其他节点的指标数据，以避免浪费CPU资源。于是，对默认的拓扑结构进行改进和优化，以适应大规模集群的需求，保证网络的畅通，避免交互的冗余。于是，将结构设计为单发/单收的多播拓扑。
[0042] (1.3)“单发”节点的使用消除了大型集群的运行开销。单发和单手参数的出现使得一些gmond节点可以充当其他gmond节点的专用汇聚器和中继器。单收指的是那些不传送数据的节点，它甚至不收集本节点的指标数据，但是却汇聚集群内其他gmond的指标数据。单发指的是那些不接收任何网络中指标数据，也不侦听多播成员状态信息的节点，只要它不同时是单收节点，就可以继续为其他侦听节点发送指标数据。
[0043] (2)集群外总控节点中监控模块部署方案
[0044] (2.1)总控端的监控模块是一种安装在主机上用来收集和汇聚集群中子节点和虚拟机中所收集的指标数据守护进程。它默认使用RRD文件收集和汇聚指标数据，本发明中也可以通过修改其配置信息将指标数据转送到外部系统。这一模块通过tcp端口8651侦听远程的同类模块连接，并且向授权主机提供XML格式的网格状态。它也通过tcp端口8652对交互式
请求做出应答。这种交互式功能不仅可以看到网格状态XML树的总体结构，也可以看到简单的局部内容。
[0045] (2.2)对于这一模块最简单的拓扑结构为一个进程轮询一个或者多个子节点中的进程。当然，它并不局限于轮询子节点中监控进程，也可以通过轮询另外的相同进程来创建层次化的结构。
[0047] (1)虚拟机及集群中子节点中部署的守护进程可以收集几十种系统指标：一系列与CPU、内存、磁盘、网络和进程相关的数据。使用固定指标集合的优势之一是，它可以成为一款非常简单的、独立的指标收集守护进程，而且其对主机的占用很少，不会因为自身的出现而引起指标偏差。
[0048] (1.1)总控端的监控模块通过TCP/8652进行侦听交互式查询。这种交互式查询功能使客户端程序可以用XML方式只查询某一部分的网格状态。交互式查询通过一种文本协议(类似于SMTP或HTTP)来完成。是一种以正斜线“/”开始的层次化查询方式。例如，下列查询将返回整个网格状态的XML数据：
[0049] /
[0050] 如果想对查询结果进行缩减，可以通过
指定集群的方式：
[0051] /cluster1
[0052] 如果想对查询结果进行进一步的缩减，可以通过指定集群内部的主机名方式：/cluster1/host1
[0053] 可以通过添加
过滤器的方式来修改数类型。例如，可以从cluster1中请求返回概括性指标数据：
[0054] /cluster1？filter＝summary
[0055] (1.2)表1：部分gmond采集指标
[0056] 表1：部分gmond采集指标
[0057]
[0058]
[0059] 步骤三：指标数据传输
[0060] (1)每个部署了监控功能模块的节点不仅收集自身所在主机的指标数据，而且存储集群内其他节点收集的最新指标数据。真因为如此，当主节点发生故障需要切换时，集群内的任意节点有可能充当主节点，或者说是向总控端上报的节点。当然究竟选取哪个节点充当主节点，当主节点出现故障时哪些节点又将作为故障切换节点，这些都是由总控端用于汇总和整合信息的模块的配置决定的。任意的部署监控模块的节点都可以上报整个集群的指标，这正是体现监控系统高健壮性的原因。
[0061] (2)虚拟机及集群内节点，以及集群外的总控端所部属的监控守护进程都是使用XML语言、通过TCP套接字进行通信的。检测守护进程是否正常工作最简单的方法是对XML数据流进行测试，通过对守护进程所监听的端口(默认情况下，集群内节点使用8649端口，非交互式总控端使用8651端口，交互式总控端使用8652端口)运行netcat即可。
[0062] (3)UDP发送和接收的通道确定了集群内节点间的交互方式，集群的定义方式是根据UDP确定的，集群内每个节点默认通过UDP将自身指标数据多播至其他节点，同时，也会侦听其他节点的UDP多播。
[0063] 步骤四：指标数据存储
[0064] 参见图3，是总控端的监控模块在本发明中所处的
位置及发挥的作用。总控端不仅对指标数据进行汇总和整合，同时将数据存储至RRD文件，并提供指标数据的实时显示功能。
[0065] (1)总控节点的文件系统中存在一个RRD文件，其中的监控进程会将数据默认存入该文件之中，在有I/O限制的大型系统中，rrdcached充当总控端监控模块和RRD文件之间的缓存，在总控节点监控模块的配置文件的配置中，data_source属性是核心内容，每一行data_source描述其收集信息的集群或网络，所以二者的data_source语法相同。当data_source引用一个集群时，总控端将为data_source保留一整套轮询
数据库(Round Robin Database)。
[0066] (2)合法的data_source示例：
[0067]
[0068] (3)data_source由三个字段组成：唯一标识data_source的字符串；表示轮询间隔时间的多少秒的数据以及主机列表(用空格符号分开)，这些地址以IP地址或DNS主机名的形式指定，并可以添加“：端口号”形式的后缀，该端口号指明集群中被监控节点的tcp_accept_channel所在位置。如果并没有指明端口号，总控端的监控模块会尝试连接tcp/8649.
[0069] 本发明提出的单发/单收多播拓扑中，单发指的是那些不接收任何网络中指标数据，也不侦听多播成员状态信息的节点，只要它不同时是单收节点，就可以继续为其他侦听节点发送指标数据；单收指的是那些不传送数据的节点，它甚至部手机本节点的指标数据，但是却汇聚集群内其他监控守护进程的指标数据。
[0070] 以上内容仅为说明本发明的技术思想，不能以此限定本发明的保护范围，凡是按照本发明提出的技术思想，在技术方案基础上所做的任何改动，均落入本发明
权利要求书的保护范围之内。
