云计算平台下资源监控系统的设计与开发

陈燕

摘 要： 传统的集群监控软件无法识别虚拟机虚拟化层的存在，同时，环境的伸缩、虚拟机的频繁增减也对监控系统提出新的需求。针对上述问题设计并实现了CloudMonitor，即一种面向云计算环境的监控系统，提出了一种多级监控服务器结构，解决主机之间不能相互访问的问题；另外，每个机群都有一个机群监控服务器，机群监控服务器负责处理机群中节点的监控信息，减轻了中心服务器的负担，有效增加了整个监控系统的监控规模。系统在开源监控系统Nagios的基础上结合传统机群监控软件的优点和虚拟化技术的特点，可以监控云计算环境下的各类资源。CloudMonitor已在实验性云基础平台上集成运行，并验证了其设计目标。

关键词： 云计算； 资源监控； 机群管理； 虚拟机群

中图分类号： TN911?34； TM417 文献标识码： A 文章编号： 1004?373X（2016）09?0057?04

Abstract： The traditional cluster monitoring system can′t identify the virtualization level of the virtual machine， so the new requirement for monitoring system is put forward due to the change of environment and virtual machine quantity. For the above problems， CloudMonitor， a monitoring system based on cloud computing environment was designed and implemented. A multistage monitoring server structure is proposed to solve the mutual access problem among host computers. Each machine cluster has a cluster monitoring server to deal with the node monitoring information in the cluster， which can alleviate the burden of the center server， and effectively enlarge the monitoring scale of the whole monitoring system. On the basis of the open?source monitoring system Nagios， the advantages of the traditional cluster monitoring software and virtualization technology are integrated in the system to monitor various sources in cloud computing environment. The CloudMonitor was operated on the cloud computing platform， and its design target was verified.

Keywords： cloud computing； resource monitoring； cluster management； virtual cluster

0 引 言

云计算作为全新的计算模式，是下一代信息技术的焦点，具有不言而喻的重要性，将给整个产业乃至全社会带来重大变革。在国内产业界，中兴在实践中开发了一种海量数据云存储技术，以较低的成本 解决了高速、海量的数字内容存储以及后续运算的问题[1]。目前在中兴内部，培训系统、 人员档案甚至MTV存储都使用这样的技术。云计算对网络架构提出了新的要求，其中虚拟化交换、统一交换、透明化交换、超高速交换将是未来网络架构发展的四个方面[2]。

成为“合格”的云应用，服务架构自身的体质是最重要的，可扩展性，或者说弹性、可伸缩性，追求的是当服务节点规模增加时，服务能力也可以线性或近似线性地提升[3]。这就需要服务请求可以被良好地、互不干扰地分配到多个节点上执行[4]。结合虚拟机的特点，基于Nagios监控框架，构建一套云计算环境下物理机群和虚拟机群监控系统CloudMonitor。系统不同于传统监控系统之处在于可以监控部署物理机上的虚拟机以及虚拟机群，并给出物理机虚拟机性能数据的对应关系[5]。

1 系统需求分析

1.1 问题概述

云计算平台中虚拟网络保证了虚拟机群网络的高效构建，给用户带来了极大的便利。但是对监控系统提出了新的问题[6]：

（1） 网络无法互通问题。不同的虚拟网之间由于网络隔离等需要常常是无法通信的，如果无法通信，就无法获取被监控节点的监控信息，这对监控系统的监控信息传输提出了新的要求。

（2） 被监控机器频繁变动问题。这造成了在一个虚拟网络内部节点的数目可能会经常变动。用户常常是一次性创建或销毁一个虚拟网络以及网络内的全部机器。

1.2 物理机监控需求

云计算平台的监控系统需求可以从两个方面阐述：物理机监控需求和虚拟机监控需求。其中物理机监控与传统机群监控类似，虚拟机监控需求则有一些新特性[7]。

从监控的角度看，云计算平台的物理机基础设施与传统的机群系统没有太大差别。基础设施都是物理机，相对于虚拟机来说，数目不会过于频繁的改变。仅需要将物理机所属的区标记出来即可。云计算平台的基础设施图就可以简化成如图1所示。图1中表示了所有的被监控物理机，其数量、配置及IP设置等都基本不变[8]。

因此，对于基础设施的监控需求就是监控物理机的各个物理资源指标及机器上运行的服务和系统的运行情况，并对异常情况进行预警。

1.3 虚拟机监控需求

虚拟化技术主要是一种隔离与监视技术，让不同的虚拟机分享同一套物理机（主要指CPU/内存子系统）而彼此隔离、互不干扰，同时，为虚拟机代理访问网络、磁盘I/O等共享的外部资源。由于虚拟化技术对CPU/内存子系统工作的干扰很少，因此，计算能力方面很少有开销，相比之下，I/O性能受到的影响会略大一些，但也可以接受。虚拟机和虚拟机群的出现对监控系统也提出了新的问题：虚拟机随用户的操作经常性的建立和销毁；不同应用类型的虚拟机有不同的服务；用户定制的虚拟机个性化强，并不限于一种操作系统。

结合上述特点得出监控系统需求：计算环境中各个分节点部署独立的监控系统。

1.4 系统功能需求

数据采集模块运行在所有的被监控节点上，包括物理机和虚拟机。在创建出新的虚拟机时，自动将采集模块安装到新建的虚拟机中，采集模块支持Windows和Linux操作系统。本模块需要解决数据跨域传输的问题和数据安全性和及时性的问题。

监控数据存储模块接收监控数据并进行结构化存储。监控系统一方面向用户提供监控视图，另一方面提供监控数据API，供其他应用模块使用。系统还应提供预警功能，系统出现错误时，通知用户。同时，监控模块应具有较强的稳定性，长时间（两个月）运行不崩溃。可以在Linux常见版本和Windows系统上运行。可以灵活地添加和删除监控项。如果要添加另外的特殊监控项，也可以通过更改系统配置实现。在所有节点上的监控代理，平均每5 min读一次系统性能数据，对系统性能及网络带宽的影响不能超过5%。

2 系统总体设计

2.1 功能模块设计

系统从功能上可以分为5个功能模块：监控数据获取模块、监控数据传输模块、监控数据管理模块、预警模块、系统管理模块，如图2所示。

2.2 系统架构设计

系统为分布式架构，分为监控服务器和监控代理。监控代理用于收集本地信息，与监控服务器通信。监控服务器用于接收监控代理发来的数据，存储管理数据，执行预警策略，提供监控数据访问接口。监控代理部署在每一个被监控物理机和虚拟机上，每个被监控域中指定一台作为监控服务器，在上面部署监控服务器程序。在被监控系统中的计算设备层和公共计算资源层中的所有服务节点和存储节点等设备上部署监控代理。具体的，在设备上收集虚拟机监控信息、主机监控信息、虚拟网络监控信息、虚拟存储监控信息、公共服务监控信息等。在服务器端收集监控代理传来的信息，最后呈现给管理员。

2.3 系统层次设计

系统分为四层，自下而上分别是数据采集层，数据处理层，数据汇集层和监控应用层。图3为云计算平台的系统层次结构图。

在数据采集层系统的所有节点上，包括物理机虚拟机和系统的各个应用服务器上部署监控代理，监控代理用于在本地收集机器的监控信息。在监控数据处理层，由于网络防火墙等原因可能出现主机之间不能直接访问的情况，因此监控模块中加入了本层，同一机群的机器监控数据先在机群头节点上收集，最后再传递到总监控服务器上。

监控应用层包括监控展示界面和监控数据API。监控展示界面提供区视图、物理机视图、虚拟机视图三个视图的监控界面。向用户展示实时监控信息和历史监控信息。

3 系统详细设计

3.1 监控数据采集模块

Windows环境下，系统使用GetSystemTimes通过APT获取CPU占用率，使用GlobalMemoryStatusEx和GetPerformanceInfo获取内存使用情况，使用 GetProcessMemoryInfo获取某一个程序的内存占用情况。使用 Win32_PerfFormattedData_PerfDisk_LogicalDisk获取磁盘监控数据。在Linux环境下，在/proc/对应的文件中获取数据，在/proc/meminfo中获取内存使用情况，cat/proc/meminfo；从/proc文件系统获取CPU使用情况，cat/proc/stat；从/proc文件系统获取网络使用情况，cat/proc/net/dev。另外，还使用一些系统工具获取资源使用情况，如用iostat获取磁盘I/O情况。

对于公共服务，使用netstat监控其端口号，看该端口号是否处于监听状态，通过调用工具进行模拟访问，查看返回结果。对于用户私有服务，监控其进程状态。将/proc下的所有文件遍历一变，判断当中 的哪个进程名与用户私有服务的进程名相同，然后可以取得对应的进程pid，然后查看该进程的状态。

3.2 监控数据传输模块

监控数据传输使用拉模式，原因是在云计算环境下被监控机的规模无法估计，伸缩性较强，系统设计了弹性监控数据拉取策略。当虚拟机数量正常时，则监控服务器在阈值周期内拉数据；当虚拟机数量很大时，监控服务器根据自己的处理能力，在规定阈值范围内，自动增长拉数据的周期。这样设计是为了防止监控数据的传输占用太多带宽。监控服务器周期性的向各个监控代理发送数据请求，监控代理收到请求后执行本机上的监控脚本并将监控脚本的返回内容传回给监控服务器。使用推模式来推送新添加的被监控节点自动注册的信息和注销信息。

3.3 监控数据管理模块

实时监控数据在本系统中被定义为最近48 h所产生的监控数据。系统使用RRDTool数据库（RoundRobinDatabase）存放近期的监控数据。监控服务器接收到监控数据后，将数据解析出来，格式化的存储到数据库中。监控系统的存储方式是：为每个被监控节点建一个目录，在目录中有多个.rrd文件，每个.rrd文件中存储一个监控项的数据。监控系统对外提供监控数据接口，外部应用程序可以通过API读取监控数据。监控数据以两种方式存在：数据库中存储的int型或String型的监控数据值；某一段时间的监控数据绘制的曲线。

3.4 预警模块

监控服务器中有一个邮件发送模块，可以使用邮件服务器向指定邮箱发送邮件，机群静态信息中存有机群管理员的邮件地址。当某个被监控节点的监控项数据超过阈值范围，调用邮件发送模块，给管理员发送邮件。预警事件处理模块，在当某被监控机器出现问题时，服务器可以在被监控机器上运行指定的脚本来恢复预警情况，或者通过重启被监控机器解决。预警恢复部分预先在被监控机器上写好事件处理脚本，当监控服务器发现被监控机器出现问题时，通过调用事件处理脚本来恢复预警情况。预警通知子模块提供邮件通知、短信通知两种通知方式。

3.5 系统管理模块

本模块包括配置文件管理子模块设计，监控机器自动注册子模块设计，监控机器自动注销子模块设计。从用户创建虚拟机群开始，机群中的机器可能会频繁添加或者减少，这给集群监控服务器的管理提出了新问题。在虚拟机群创建的时候，用户指定头节点，头节点虚拟机在创建的时候自动安装有监控服务器程序，其他节点安装有监控代理程序。当某个虚拟机被销毁时，执行被销毁虚拟机中的destroy脚本，在集群监控服务器的配置文件中注销本机。当添加某个虚拟机时，向本机群监控服务器注册本机及本机监控项。

3.6 监控代理和监控服务器

本模块包括两部分：第一部分是客户端程序，运行于机群监控服务器，负责将本机群的监控数据送到全局服务器上去；另一部分是守护进程，它既可以独立地运行于守护服务也可以注册到inetd里作为一个inetd客户程序提供监听联接。从机群服务器收到监控信息后，守护进程将结果提交给全局监控服务器，实际上是模拟了从一台被监控机器上传输监控信息的一个过程，从全局监控服务器的视角看，从机群监控服务器传来的数据和直接从被监控节点上传来的数据没有差别。

4 实验测试与结果分析

4.1 监控服务器响应测试

监控服务器： CPU@2.0 GHz/2GMemory/160GHD，被监控机器： CPU@2.0 GHz/2GMemory/160GHD。

在LoadRunner中，设定25个User，每个User重复访问服务器读取监控数据，并进行5次点击查看操作。运行9 min的过程中，重复了2 031 844次操作，共有2 031 844次成功返回结果。图4为响应时间曲线，在并发数为20的情况下，最大响应时间为0.004 s。

最后报告成功了21 901 245次，平均19 004.8 /s，失败1次，系统工作良好。在频繁查询的情况下可以正常的返回结果。

4.2 应用规模及系统占用资源测试

测试目的：总监控服务器共可以支持的下级服务器数目，每个下级服务器可以支持监控节点的数目；监控系统对机器性能的影响。监控服务器端性能影响，监控代理对被监控节点的性能影响，此处的性能影响主要是指对节点的CPU负载，内存占用的情况。

测试环境同上，在监控服务器上添加100个被监控主机，每个监控主机有五个监控项，监控项总数是502项，如图5所示。

CPU占用率不超过3%，内存使用率不超过0.5%，实际间隔为2 min。在监控服务器上添加300个被监控主机，每个监控主机有五个监控项。CPU占用率为3%，峰值不超过7%。内存占用率不超过0.5%。CPU负载较100个节点的时候有所上升：0.9vs.0.5。进程数目增多：160vs.70，实际间隔为5 min。连续工作6天，从其自身的监控数据来看，一切工作正常，监控服务器性能状况如图6所示。

在监控服务器上添加500个被监控主机，每个监控主机有5个监控项，监控项总数是2 468项。在此情况下，机器负载有所上升。CPU占用率为3%，峰值不超过10%。内存占用率不超过0.5%。CPU负载较100个节点的时候有所上升：1.45vs.0.5。进程数目增多：240vs.70。定义的监控检查时间间隔为1 min，但是实际间隔为10 min。

测试结论：CPU占用率在10%以内，内存使用在1%以内，实时性要求较高，则监控规模应控制在100以内。从性能角度来考虑，监控规模应控制在300以内。

5 结 论

基于虚拟机群、基础设施共享的云计算环境与传统机群有着不同的特点，现有的机群监控系统不能满足规模扩展与云互联的需求。为此，提出了CloudMonitor，一种面向云计算环境的监控系统。系统基于开源监控框架Nagios结合传统监控系统和云计算环境的新特点，既能准确获取监控信息又能适应虚拟网络、虚拟机群的特点。

分析了云计算环境下监控的问题，同时给出了云计算平台下资源监控系统的总体设计和详细设计，对监控数据的采集、传输、存储、读取接口、监控服务器的结构及管理等方面都进行了详细说明，给出了系统的测试过程和测试结果，证明了系统在功能上的完备性，并通过测试得到了总监控服务器共可以支持的下级服务器数目，每个下级服务器可以支持监控节点的数目以及监控系统对机器性能的影响。本文提出了一种多级监控服务器结构，解决了主机之间不能相互访问的问题。

参考文献

[1] 陈康，郑纬民.云计算：系统实例与研究现状[J].软件学报，2009，20（5）：1337?1348.

[2] 许丞，刘洪，谭良，等.Hadoop云平台的一种新的任务调度和监控机制[J].计算机科学，2013，40（1）：112?117.

[3] 方薇，崔超远，王儒敬，等.Eucalyptus开源框架下云平台的构建与性能分析[J].计算机系统应用，2012，21（6）：1?5.

[4] 成静静.基于Hadoop的分布式云计算/云存储方案的研究与设计[J].数据通信，2012（5）：14?18.

[5] 张尧学，周悦芝.一种云计算操作系统TransOS：基于透明计算的设计与实现[J].电子学报，2011，39（5）：985?990.

[6] 冯登国，张敏，张妍，等.云计算安全研究[J].软件学报，2011，22（1）：71?83.

[7] 罗军舟，金嘉晖，宋爱波，等.云计算：体系架构与关键技术[J].通信学报，2011，32（7）：3?21.

[8] 穆俊.基于云平台的并行关联规则挖掘算法分析[J].现代电子技术，2015，38（11）：123?125.