云资源监控系统研究与实现

2024-07-06 来源：伴沃教育

电子科技大学

UNIVERSITY OF ELECTRONIC SCIENCE AND TECHNOLOGY OF CHINA

专业学位硕士学位论文

MASTER THESIS FOR PROFESSIONAL DEGREE

（电子科技大学图标）

论文题目云资源监控系统研究与实现

专业学位类别工程硕士学

号 201122230136

作者姓名常建华指导教师向艳萍副教授

分类号密级

UDC注1

学位论文

云资源监控系统研究与实现

（题名和副题名）

常建华

（作者姓名）

指导教师向艳萍

副教授

电子科技大学成都

（姓名、职称、单位名称）

申请学位级别

硕士专业学位类别工程硕士

2014.04.23

年 6月29日

提交论文日期2014.03.25论文答辩日期学位授予单位和日期电子科技大学 2014答辩委员会主席

评阅人

注1：注明《国际十进分类法UDC》的类号。

RESEARCH AND IMPLEMENTATION

OF MOINTORING SYSTEM FOR CLOUD RESOURCE

A Master Thesis Submitted to

University of Electronic Science and Technology of China

Major: Software Engineering Author: Jianhua Chang Advisor: Yanping Xiang

School : School of Software Engineering

独创性声明

本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示谢意。

作者签名：日期：年月日

论文使用授权

本学位论文作者完全了解电子科技大学有关保留、使用学位论文的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。

（保密的学位论文在解密后应遵守此规定）

作者签名：导师签名：

日期：年月日

摘要

自从云计算的概念被提出以后，近几年来得到了极大的推广和发展，业界厂商关于云计算的战略、观点和产品层出不穷，云计算的关键技术研究也呈现百花齐放的局势。云计算是一种新型的商业模型，融合了网格计算和虚拟化技术的优势具有动态伸缩性和灵活性。云计算技术将充斥在其中的资源封装成对外提供的服务，用户通过互联网络按需使用并根据实际情况支付一定的费用。

随着云计算平台规模的扩大，其管理和部署的成本越来越高同时系统的稳定性面临着严峻的挑战。如何保障云平台的稳定运行，有效的管理云平台、简化部署流程，提高云平台的安全性和可靠性成为当前云计算研究领域的一个热门课题。云资源监控系统是云平台的主要组成部分之一，在保障云平台的安全和服务质量方面起着重要的作用，因此对监控系统的研究是非常有意义的。

首先，本文对云计算和云监控系统的体系结构进行研究，分析了设计云资源监控系统时所面临的关键性问题。通过对现有监控系统的分析，本文着重从实现云资源监控系统的扩展性、系统故障诊断和报警、监控数据的处理三个方面进行深入分析并提出了自己的解决思路和观点。

然后，本文通过对云服务层次结构进行分析以及对监控实体进行抽象，掌握了设计云资源监控系统的需求。根据需求分析和监控数据的实时性要求，本文借鉴仿生自主神经系统(BANS)的思想对云资源监控系统的整体架构进行了设计同时对该系统的通信架构、通信协议、命令行界面和数据库进行了详细的设计并实现了云资源监控系统。

最后，本文将云资源监控系统部署在实验室的CAOS云平台中进行了测试和结果分析。通过对云资源监控系统的功能、页面设置和记忆数据存储三个方面进行测试，验证该系统的可靠性和实用性。

通过对云平台资源监控系统的研究与实现，探讨了云资源监控系统在实际开发中的缺点和不足，与此同时对将来的商业化云监控系统起到一定的借鉴和指导作用。

关键词：云计算平台，云监控，资源监控，虚拟机，服务层次

ABSTRACT

Since the concept of cloud computing have been proposed , it has been a great promotion and development in recent years. Many Industry vendors come out not only strategies,ideas and products of cloud computing one after another,but also the key technologies of cloud computing presents a flourishing situation. Cloud computing is a new business model.Combined the advantages of grid computing and virtual technology, cloud computing has the characteristics of dynamic scalability and flexibility. The resources, packaged in cloud computing,has been provided as a service for users. The terminal user can get cloud resources via the internet and pay a fee based on the actual situation.

With the expansion of cloud computing platform scale, not only has its management and deployment costs been increasing,but the stability of the system has been facing serious challenges.It is a hot research topic about how to keep the stable operation of the cloud platform,manage it effectively,simply its deployment process and improve its safety and reliability. Cloud resource monitoring system is one of the main components of the cloud platform and plays an important role in ensuring the safety and quality of service of the cloud platform,so the research about cloud resource monitoring system is very meaningful.

Firstly, I did research on the architecture of cloud computing and cloud monitoring system and analyzed the key issues when design cloud resource monitoring system .Through analysis of the existing monitoring system, I am in-depth focused on three aspects analysis of cloud resource monitoring system and put forward mine own ideas and perspectives to solve. The three aspects is salability of cloud resource monitoring system, fault diagnosis and alarm systems ,surveillance data processing. Secondly, In order to master the demand of cloud resource monitoring system ,I has analyzed the cloud service hierarchy and abstracted monitoring entities of cloud platform. According to the demand of cloud resource monitoring system and real-time requirements about monitoring data ,I draw lessons from Bionic Autonomic Nervous System(BANS) to design the whole structure of cloud resource monitoring system.At the same time, I has also been designed the communication architecture and protocols,command-line interface and the Database of this system in detail. In the last , I

ABSTRACT

implement the cloud resource monitoring system .

Finally, I has deployed the cloud resource monitoring system in CAOS cloud platform ,tested this system in lab and analyzed the test results. Through the tree tests of the cloud resource monitoring system functions,page setup and memory data storage, it has verified the reliability and usefulness of the system.

Through research and implementation of cloud resource monitoring system, I has discussed the shortcomings of the cloud resource monitoring system and deficiencies in the actual development.It will play a reference and guidance effect on future commercialization of the cloud monitoring system.

Keywords: cloud platform, cloud monitoring, resource monitoring, virtual machine, service levels

III

第一章绪论 .................................................................................................................. 1

1.1 课题背景和研究意义 ........................................................................................ 1 1.2 课题研究现状 .................................................................................................... 2 1.3 本文的研究内容 ................................................................................................ 3 1.4 论文组织结构 .................................................................................................... 4 第二章课题相关理论研究 ............................................................................................ 5

2.1 云计算 ................................................................................................................ 5

2.1.1 云计算的定义 .......................................................................................... 5 2.1.2 云计算系统结构 ...................................................................................... 5 2.2 云监控体系结构 ................................................................................................ 6 2.3 仿生自主神经系统 ............................................................................................ 9 2.4 本章小结 .......................................................................................................... 10 第三章云资源监控系统关键问题研究 ....................................................................... 11

3.1 监控系统可扩展性 .......................................................................................... 12

3.1.1 动态加载技术 ........................................................................................ 12 3.1.2 基于动态加载技术的监控系统可扩展性设计 .................................... 13 3.2 监控系统故障诊断 .......................................................................................... 14

3.2.1 多值决策图 ............................................................................................ 14 3.2.2 基于多值决策图的报警模型 ................................................................ 15 3.3 监控系统数据处理 .......................................................................................... 18

3.3.1 推拉模型分析 ........................................................................................ 18 3.3.2 即时反馈 ................................................................................................ 19 3.3.3 监控数据处理方案 ................................................................................ 20 3.4本章小结 ........................................................................................................... 22 第四章云资源监控系统设计与实现 .......................................................................... 23

4.1 需求分析 .......................................................................................................... 23

4.1.1 云计算服务层次结构 ............................................................................ 23 4.1.2 监控实体抽象 ........................................................................................ 24 4.1.3 监控需求分析 ........................................................................................ 25 4.2 总体设计 .......................................................................................................... 27

4.2.1 云平台总体架构 .................................................................................... 27 4.2.2 云资源监控系统总体架构 .................................................................... 29 4.2.3 云资源监控系统通信架构 .................................................................... 32 4.2.4 通信协议设计 ........................................................................................ 33 4.2.5 统一命令行设计 .................................................................................... 36 4.3.6 数据库设计 ............................................................................................ 37 4.3 详细设计与实现 .............................................................................................. 41

4.3.1 数据采集器的设计与实现 .................................................................... 41 4.3.2 资源监控器的设计与实现 .................................................................... 46 4.3.3 配置文件自动化设计与实现 ................................................................ 50 4.3.4 终端注册设计与实现 ............................................................................ 53 4.2.5 插件管理设计与实现 ............................................................................ 55 4.4 本章小结 .......................................................................................................... 57 第五章云资源监控系统测试与结果分析 .................................................................. 58

5.1 测试环境设置 .................................................................................................. 58 5.2 云资源监控系统功能测试与结果分析 .......................................................... 58

5.2.1 云资源监控系统服务启动测试 ............................................................ 58 5.2.2 监控系统页面管理及结果分析 ............................................................ 62 5.2.3 云资源监控系统数据管理展示 ............................................................ 65 5.3 本章小结 .......................................................................................................... 67 第六章总结与展望 ...................................................................................................... 68

6.1 总结 .................................................................................................................. 68 6.2 展望 .................................................................................................................. 68 致谢 ………………………………………………………………………………...69 参考文献 ........................................................................................................................ 70

第一章绪论

1.1 课题背景和研究意义

自世界上第一台电子计算机问世以来，已经经历了半个多世纪。在这几十年里，计算机已经深入应用在各个行业中并改变着人们的生活，大多数企业开始建立数据中心向社会提供信息服务。进入21世纪以后，数据中心处理的数据急剧增加，社会上各个行业对信息化的要求越来越高。对于企业来讲，数据中心的正常运作变的非常重要。伴随着互联网技术的普及和网络规模的不断扩大，网络用户对信息服务的依赖性越来越强，大多数企业数据中心的访问量空前增加，企业的数据中心变的非常复杂[1]。在这些复杂的数据中心运营过程中，充斥在其中的计算资源，存储资源、传感设备和网络设备不可避免的会发生机器故障。如果服务器或者网络设备发生故障得不到及时的检修，数据中心的稳定性势必会造成影响，影响企业的效益和服务质量，因此各种网络监控技术和工具应运而生。

对于像分布式计算、网格计算[2]和云计算这样的系统，其规模庞大而且非常复杂，不仅要管理硬件资源而且要向外提供多种多样的服务。云计算的兴起，客观上提供了一种动态、灵活、集成的，并且为数据中心提供实时支持的IT模式。云计算技术的广泛普及和应用，必将带来第三次信息技术变革的浪潮，同时也将带来企业商业模式和人们工作方式的根本性变革[3]。未来云计算的应用可以提供一种像水和电一样的资源服务模式，为人们提供更加快捷、方便和廉价的信息服务给人们的生活、工作提供更多的便利。在云计算平台中存在多种多样的硬件资源、软件和服务，同时这些资源呈现层次、灵活、动态伸缩性。为了提高信息服务质量，需要对这些资源进行动态的、扩展的、高效的管理和监控。然而云计算平台的规模庞大、资源呈现异构和动态性且分布不受地域限制，因此云资源监控系统实施起来非常困难而且不可避免的要对云平台的运行造成干扰。怎样降低对云平台系统运行状态的影响，以最低最少的系统资源实现最大程度的监控力度是当前一个很值得研究的领域。

云资源监控是保障云计算运营管理平台自动化、流程化运作的关键模块。监控系统利用下层被监控模块提供的各种监控数据，进行有效的和有针对性的分析和决策后，为上层资源调度模块提供必要的参数输入，是实现资源负载均衡、资源优化、部署和调整的基础。此外资源监控可以屏蔽底层硬件的差异，通过对被监控资源的信息通过采集、预处理、分析提供报警功能，方便系统管理员和用户管理云平台。因此对于系统管理员和用户来讲，云资源监控系统是非常重要的。

电子科技大学硕士学位论文

云资源监控系统不仅要实现高效和对云平台干扰程度低的指标，同时要具有灵活和扩展性，方便用户自定义监控插件和指标，实现对特定任务的监控需求。此外云平台中使用用户计算机水平具有差异性，监控系统应该具有简易部署和通用性，以满足不同用户的使用需求。

目前，在现有的监控系统中，大多数云资源监控系统不是基于网络技术模式的监控就是针对自己的云计算产品的监控，只是在单个方面具有监控优点不具有通用性、也不方便进行二次开发。因此设计一套具有扩展性、通用性、简易部署的云资源监控系统对云平台中的计算资源、存储资源、网络资源以及各种软件和服务进行高效的监控是非常紧迫和有意义的事情。

1.2 课题研究现状

云计算是分布式计算、网格计算和虚拟化技术发展的产物[4]，是一种分布式的商业计算模型。因此大部分云资源监控系统架构都是借鉴以往分布式计算和网格计算的设计经验。国内外有很多软件用于云资源监控比如：IBM公司的NetView、HP公司的OpenView等等[5]，此外还存在许多开源软件比如：Ganglia、Nagios等等[6]。

网格监控架构（GMA）于2002年由全球网格论坛[7]提出，是网格计算中比较流行的监控标准，主要有消费者、生产者和目录服务三种角色。消费者使用生产者提供的监控信息；生产者负责被监控端运行状态信息的收集的工作；目录服务负责生产者和消费者的定位工作同时辅助双方通信。

大多数类型的网格监控系统是居于网格监控框架（GMA）设计和开发的。网格天气服务（NWS）采用分布式的设计模式，提供非入侵的、便捷式的性能监控，支持动态资源分配和调度。Monitoring and Discovery System（MDS）是一种信息服务组件，应用在Globus Toolkit中，提供可以使用资源的状态和信息[8]。

Ganglia[9]是一个分布式监控系统，具有高效、可扩展和跨平台的特性。它使用XML数据代表、RRDtool用于数据可视化和存储、便捷数据传输等技术，分层设计。目前Ganglia已经被移植到主流的处理器架构和操作系统上，用来连接大学校园和世界各地。Ganalia可以并发处理2000多个节点，节点之间的并发度非常低。Ganglia的核心由gmond、gmetad和一个web前端构成，主要用来监控系统性能比如：cpu利用率、内存利用率、硬盘使用情况、IO负载、网络流量情况等等，同时Ganglia允许自定义的插件检查特定服务的运行状态。通过WEB可视化界面可以很清楚的看到每个节点当前的工作状态，同时对系统负载均衡、合理调整、分配资源，提高系统整体性能起到关键性的作用。Gmond守护进程运行在每台服务

第一章绪论

器上用于收集和发送监控数据，同时接收其他主机gmond进程发送的监控信息。Gmetad进程可以部署在任何一台服务器上负责将收集的监控信息进行整合，并使用RRDTool工具进行数据处理、生成显示图像，以WEB页面的形式直观的提供给用户。

Nagios[10]是一款免费、开源的网络监控工具，可以运行在各个主流的操作系统中比如：windows、Linux和Unix等完成监控功能，同时可以监控交换机和路由器等网络设备的状态。同时提供一个可选择的基于浏览器的web界面方便用户或者系统管理员查看系统问题、日志以及网络状态。Nagios监控任务由配置文件指定，同时提供报警功能。Nagios简单的插件设计可以使用户方便的扩展服务检查方式同时可以定义一些处理程序，当主机或者服务出现故障时起到预防的作用。

云计算是网格计算和虚拟化技术发展的产物，其相对于网格计算来讲，云计算具有自己的特点[11]。现有的资源监控系统，大部分是针对网格计算而设计的，因此无法完全满足云平台进行资源监控的需求。在云平台中分布着不同的用户比如：云服务提供商、云平台运营商以及一般的终端用户等等，不同层次的虚拟服务对使用用户来讲是隔离的。在平台中对使用云平台运营商提供的基础设施的云服务提供商来讲，低层次的计算资源、存储资源以及网络资源的使用情况是透明的，他们无法部署自己的监控系统来反映软件当前的运行状态，即使软件在运行过程中出现故障，对于分析故障原因也是比较困难的甚至无法分析软件运行故障。因此云平台中监控系统应该在企业服务、商务平台监控、基础设施管理以及虚拟机监控中维持良好的平衡，这对云资源监控系统来讲是一个挑战。云资源监控系统中被监控端提供的监控信息，对云服务提供商是很感兴趣的[12]。云服务提供商可以利用这些监控数据分析用户行为、浏览用户操作流程、掌握IP地址分布，根据这些数据分析和掌握终端用户的兴趣和爱好，便于对软件进行升级和改进。

1.3 本文的研究内容

本文的研究内容为云平台中的资源监控系统，通过对现有监控系统以及设计监控系统时面临的关键问题进行分析的基础之上，设计并实现了云资源监控系统。本文的主要研究点为：

1）采用仿生自主神经系统（BANS）的思想设计并实现了云资源监控系统。通过寄主虚拟机监控信息上报宿主机，宿主机监控信息和本宿主机汇总的寄主机监控信息上报中枢神经系统的方式，达到监控信息及时反馈的效果。

2）研究系统动态加载技术，使用动态加载技术实现资源监控系统可扩展性。 3）研究了云资源监控中数据传输模型。通过对传统的数据传输推拉模型优缺

电子科技大学硕士学位论文

点的分析，在此基础上采用推拉混合模型实现网络数据传输。

4）采用多值决策图对系统故障进行分析，实现云资源监控系统的报警功能。

1.4 论文组织结构

本论文共分为6章来讨论云平台中的资源监控系统，各个章节安排如下：

第一章：绪论。介绍了云资源监控系统的课题背景和研究意义，综合介绍了国内外云资源监控系统的研究现状，并在此基础上指出了本文的研究内容。

第二章：课题相关理论研究。主要介绍了云计算的基础概念以及云平台的体系结构，然后介绍了云资源监控系统的体系结构。

第三章：云资源监控系统关键技术研究。首先介绍了设计云资源监控系统时所面临的关键性问题以及本论文重点要解决的问题，然后分别详细介绍了实现云资源监控系统可扩展性、故障报警以及监控数据处理方面所使用的模型和解决方案。

第四章：云资源监控系统的设计与实现。首先通过对云服务层次结构进行分析、监控实体进行抽象，了解并掌握了云资源监控系统的需要；然后根据需求分析对云资源监控系统进行总体设计包含云资源监控系统总体架构设计、通信架构设计、通信协议设计、命令行设计依据数据库设计；其次根据云资源监控系统总体架构详细介绍了数据采集器、云资源监控器、配置文件自动化、终端注册以及插件管理的设计和实现。

第五章：云资源监控系统的测试与结果分析。包括实验环境设置、功能测试和结果分析等，功能测试包含功能模块的启动、监控页面以及数据库数据存储。

第六章：总结与展望。

第二章课题相关理论研究

2.1 云计算 2.1.1 云计算的定义

云计算这个名词诞生于2007年第三季度，直到现在业界对于云计算的定义仍

然争论不休、并不统一[13]。关于云计算的定义，美国国家标准与技术研究院（NIST）认为：“云计算是一种根据自己的需求获取服务的计算方式，在该计算方式下用户利用网络快捷方便地获取云平台中的服务和共享资源比如：存储、计算、服务、网络等，当用户使用这些服务和共享资源时并不需要太多的管理成本就可以实现对云计算中的资源迅速的部署和回收[14]”。维基百科（Wikipedia）的解释为：“云计算是一种商业计算模式，终端用户通过网络按照实际的需求申请使用云中共享的基础设施、软件、服务和信息，这种商业计算阐述了一种新的基于互联网IT服务增加、使用和交付方式，可以提供易扩展和虚拟化的网络资源[15]”。中国网格计算和云计算专家学者刘鹏认为：“大量的不受地域限制的服务器构成一个资源池，云计算可以将复杂的计算任务进行划分，然后将细分的任务部署到资源池中去执行，终端用户可以按着管理系统的需求申请使用云中的资源和软件服务[16]。”IBM的技术白皮书“Cloud Computing”关于云计算的定义为：“云计算是多年来信息化技术和商业服务消费与交付模式融合发展的产物，云计算带来了商业服务消费和交付模式的一场革命。在云计算模式中，用户可以根据自己的需要自主选择服务消费和支付模式并通过网络获取资源和软件服务[17]”。狭义的云计算是指由计算资源、存储资源、网络设备以及各种终端设备构成的IT基础设施资源池中硬件资源的交付和使用模式，这些资源具有异构、动态伸缩、按需使用的特点，用户通过互联网申请使用IT基础设施资源池中的资源；广义的云计算是指由硬件组成的IT基础设施资源池以及运行在IT基础设施资源池上的软件服务的交付和使用模式，这些服务同样具有动态伸缩、按需使用的特点，用户通过互联网申请使用硬件资源和软件服务应用资源池中的服务，广义的云计算包括狭义的云计算。

2.1.2 云计算系统结构

云平台是一个超强的互联网络，它将分布在各地的资源通过网络整合起来组成一个资源池提供巨大的计算和存储能力，同时使用虚拟技术扩充资源池中服务器的服务能力。通常使用的云平台体系结构如图2-1所示：

电子科技大学硕士学位论文

云用户端管理系统部署工具服务器集群服务目录资源监控

图2-1 通用云平台体系结构

1）云用户端

云用户端是一个类似本地桌面的图形界面，云用户使用该界面发送服务请求、获取云端发送的资源以及打开应用资源等。 2）服务目录

云端所提供的服务在服务目录中以列表的形式表示出来。云用户获得适当的权限后，可以对云端所提供的服务在服务目录中进行浏览、订阅和取消订阅等。 3）管理系统和部署工具

在云端提供管理和服务功能。管理系统对云用户进行身份认证、授权以及允许用户登入云系统等；部署工具可以对云资源进行动态部署、配置以及回收。 4）资源监控

资源监控对充斥在云端的异构资源比如：物理服务器、虚拟机、各种终端设备等进行监控，反映系统的运行状态。如果系统出现故障，及时报警通知用户进行检修。资源监控是实现云平台负责均衡、资源优化配置的基础。 5）服务器集群

服务器集群由不同厂商生产的物理服务器和各种终端设备构成，它为虚拟服务器提供基础设施。管理系统对服务器集群进行统一部署和管理，对外提供计算、存储和信息服务。

2.2 云监控体系结构

目前大部分分布式监控系统使用的体系结构有两种即：集中式的体系结构和阶梯式的体系结构。这两种不同层次的系统结构，在实际使用的不同场合中各有优缺点。

第二章课题相关理论研究

1.集中式体系结构

集中式体系结构使用传统的客户机/服务器(C/S)模式。该体系架构有两层构成即：监控服务器(Server)和监控客户端（Client）组成。集中式体系结构如图2-2所示：

监控代理监控服务器监控代理监控代理

图2-2集中式体系结构

在该结构中，每台被监控服务器或者终端设备上运行一个监控代理。监控代理负责接收监控服务器的指令并对服务器下发的指令进行翻译，根据翻译后的指令去执行逻辑操作；同时监控代理负责收集被监控端的状态信息，将状态信息通过网络上传到监控服务器端；如果被监控端出现故障，监控代理负责将故障信息反馈给监控服务器以便通知系统管理员及时检修。监控服务器是集中式系统结构的大脑，运行在一台高性能的服务器上。它主要负责接收系统管理员的指令，将命令下发到监控代理，同时接收监控代理的反馈信息。监控服务器对监控代理返回的信息进行相应的处理后存入后台数据库中。这种结构相对比较简单，适用于监控节点不多的场合。该体系结构优点如下：

 延时小。集中式体系结构能够快速的收集监控信息，通过对信息进行分析快速的了解当前系统的运行状态；同时该结构能够及时发现机器故障，在最短的时间内通知系统管理员进行故障检修，降低故障损失。

 容易部署和管理。集中式体系结构只有两类类型的节点，系统功能分类清楚明了、网络通信方式简单统一，便于系统管理员对整个监控系统进行管理和部署。

该系统结构的缺点如下：

 容易单点失效。由于监控服务器运行在一台主机上，一旦该主机死机或者出现故障，就会使整个监控系统瘫痪。系统可以采集相应的策略解决单点失效的问题比如：双机备份技术。

电子科技大学硕士学位论文

 监控节点过多导致响应不及时。集中式系统结构中监控服务器只有一个，当监控节点过多时，监控服务器就会过载导致监控信息得不到及时处理；与此同时海量的监控代理在同一时刻向监控端发送监控数据，很容易造成网络阻塞和监控系统的监控性能下降，达不到监控的目的。 2.阶梯式体系结构

阶梯式体系结构采用局部代理监控节点分散网络带宽，避免监控信息过于集中的情况。使用阶梯式体系结构可以在一定程度上改善集中式体系结构的缺点和不足。阶梯式体系结构如图2-3所示：

全局监控服务器局部监控服务器.......局部监控服务器监控代理.......监控代理监控代理.......监控代理

图2-3阶梯式体系结构

在阶梯式体系结构中在监控服务器和监控代理之间增加了一层局部监控节点。在阶梯式系统结构中每个监控代理都属于某一个组，该组由局部监控服务器进行代理。局部监控服务器负责接收全局监控服务器的指令并将该指令进行翻译、下发到本组内所有的监控代理节点上；同时负责该组内监控代理反馈的监控信息的汇总工作，将汇总结果上传到全局服务器上。全局监控服务器负责接收系统管理员下发的指令同时汇总局部监控服务器的上传信息。监控代理负责接收局部监控服务器下发的指令，同时将监控信息上传到本组内的局部监控服务器上。

该结构的优点如下：

 分担主节点负载。监控代理收集的监控信息首先上传到本组内局部监控服务器上，局部服务器进行信息汇总后上传到全局监控服务器上。这样的信息流程可以分担全局监控服务器的负载，避免过多的监控代理将监控信息同时上传到全局监控服务器上出现网络阻塞而导致系统吞吐量下降。

 故障隔离。监控代理分组后，当某一个监控代理出现故障时，造成的影响仅仅局限在该组之内，不会扩散到整个监控系统而对整个系统造成影响。该结构的缺点如下：

 阶梯式体系结构由于多了一层局部监控节点，结构变得比较复杂且系统的

第二章课题相关理论研究

 管理和部署变的困难；同时不易于系统扩展。

 延时长。由于监控代理将监控信息上传到局部监控服务器上，因此监控数据传输时间就会变长，当系统出现故障时，故障时间变长。

2.3 仿生自主神经系统

计算机界的学者受生物学界的自主神经系统启发，提出仿生自主神经系统 (Bionic Autonomic Nervous System, BANS)的概念。生物的身体机能虽然受大脑的控制和指导，但是对于一些不太重要的外部刺激和信息生物可以不必将信息传输给大脑，而是由周围神经系统自主解决，这是一种动物几乎在无意识的状态下控制机体活动的行为。比如：在寒冷的冬季我们的手一触摸到冰块，就会无意识的不加思考的迅速收回到口袋中；在天气炎热的夏天，我们的身体一靠近火堆，就会不自觉的远离等等。除此以外，动物的心跳、呼吸、血压、体温、免疫、反射等系统都由自主神经系统控制。生物的自主神经系统具有超强的自主特性，BANS通过效仿生物的自主神经系统，使得像云计算，网络计算等大规模的复杂系统具有类似的自主决策能力。仿生自主神经系统由中枢神经、周围神经、神经元以及神经轴突组成，其结构如图2-4所示。

Central Nervous SystemLocal WorkerWorkerCCCCCCCCCCCCCCLocal WorkerPeripheral NerveCCentral nervousCyber NeurouLocal WorkerCyber AxonHost Machine

图2-4 仿生自主神经系统BANS的架构

动物的中枢神经系统由大脑和脊椎构成，其主要是对动物的机体行为进行有意识的思考和指导。复杂的外部信号通过周围神经系统或者神经元进行传导，进

电子科技大学硕士学位论文

入中枢神经系统，中枢神经系统对信号进行分析并预测可能的危险，并将分析结果反馈给身体各个部分去执行。BANS中的中枢神经系统功能类似于此。

周围神经系统主要完成无意识的身体机能行为，比如人的呼吸、心跳以及膝反射等功能。其主要功能是通信和本地自治。周围神经系统可以跟中枢神经系统和神经元进行信息通信，完成命令的传递工作；同时周围神经系统可以在不受中枢神经系统控制的情况下完成一些无意识的机体行为，对外部信号进行分析和过滤，对本地资源进行自治，对关键信息进行本地存储。

神经元主要进行通信和基础数据分析。动物身体神经细胞或者神经元内存在神经递质，当机体受到外部刺激的时候，神经云内的神经递质就会进入神经元之间的缝隙之间，将刺激信息传递给下一个神经元。神经元接收到刺激信号后通过对信号进行基础分析，决定是否将该信息传导到其他神经元。

神经突轴主要完成动物的感知和反射功能。每个神经元都保护众多的神经突轴，每个神经突轴率属于某一个神经元。神经突轴可以感知外界的刺激信号，收到刺激信号后通知神经元；同时神经突轴执行周围神经、中枢神经、神经元下发的机体行动命令，对外界刺激做出反应。

2.4 本章小结

本章主要对云计算的基础概念和云计算的体系结构进行了介绍，然后对云计算平台中的监控系统体系结构进行介绍和分析，充分了解两种云监控系统结构的优缺点。

第三章云资源监控系统关键问题研究

资源监控系统是对云平台进行有效管理的工具之一。该系统通过对云平台中的资源进行实时监控以反映当前资源的状态和使用情况，并将这一结果显示在图形界面上便于系统管理员或者用户查看。在云平台的正常运行过程中，由于各种原因（可控的或者非可控的）系统资源故障时常发生。当云平台中的资源发生故障时，监控系统应该及时通知系统管理员进行检修，降低用户的损失。然而作为云平台的一个管理工具，云资源监控系统在保证达到一定监控力度的同时不能影响云计算平台的正常运行，因此应该尽可能降低监控工具对云平台的干扰。云资源监控系统可以采取减少监控数据采集、缩小采集范围以及降低监控数据采集频率的方式达到降低对云平台影响的目的；但是这样就会造成系统故障发现不及时甚至无法发现，不能有效真实的反映平台资源的状态和使用情况。因此设计云资源监控系统时所面对的关键问题由下面几个部分构成：

 干扰程度。云监控采集数据越多、范围越广、频率越高对云平台系统的影响就会越大，虽然这种做法达到了一定的监控力度但是消耗了过多的系统时间和系统资源；如果监控数据采集过少、采集范围过小、采集频率过低就会造成监控系统不可用，达不到资源监控的目的，因此设计监控系统需要在两者之间权衡利弊得失，做出平衡。云资源监控系统可以采用缓冲技术或者设置监控进程的优先级的策略，让低优先级的进程在系统空闲的时候收集数据存入缓冲区，来降低对被监控系统的影响。

 可扩展性。云计算资源监控系统应具有较好的扩展性，不能随着被监控资源数量的增加出现监控组件不能正常工作进而影响被监控资源数据的搜集。为了满足越来越多用户对云服务的要求，云计算平台中的软硬件资源是不断增加的呈现动态性，因此监控系统应能够适应云平台中资源不断扩张的特性。这就要求云资源监控系统具有动态伸缩性，终端用户增加新的监控逻辑时，系统管理员不需要修改监控系统框架，只要增加监控组件运行时动态加载就能满足用户的监控需求。当某些监控组件不需要运行时，可以动态的删除或者卸载监控组件。

 异构性。云计算平台中充斥着繁多的异构、动态资源。被监控的资源包括：软件，硬件、关键进程、网络使用流量以及外围终端设备等等。即使相同种类的资源，由于生产厂家不同，型号也不同，数据的传输和表示也会有所区别。云资源监控系统应该考虑如何屏蔽这些资源的异构性，通过对监控资源进行抽

电子科技大学硕士学位论文

象实现统一监控。

 实时性。云平台监控系统应能够尽最大努力快速的收集数据向上呈报，反映系统当前的运行状态。如果系统出错或者资源发生故障，应该快速的报警，保证用户的任务顺利完成，因此监控系统具有实时性。

 配置简单，快速部署。在云计算平台上监控资源的种类繁多，部署监控系统的平台也是多种多样。因此如果让用户配置监控阀值或者配置监控参数，不但不友好而且容易出错。因此监控使用的配置文件应该由系统统一完成，当被监控端需要配置文件时，可以从监控端自动下载。由于云平台中存在各种操作系统，应该实现跨平台部署，部署尽量要简单快速，给用户最好的体验。  统一的命令行界面。云计算平台的使用用户是不同的。应该满足一些高级系统用户的需求。为系统管理员提供命令行，便于系统管理员查找监控组件，更好的分析监控数据。

针对设计云资源监控系统时的关键问题，现有的相关监控系统已经有了很大的改进和优化，但是还存在不足之处。本文着重从监控系统的扩展性、故障诊断、数据处理三方面进行研究。分别从下面3.1节、3.2节、3.3节对相关问题进行分析。

3.1 监控系统可扩展性

云计算平台是一个复杂的大型系统，存在大量的计算资源、存储资源以及网络资源。云计算提供各种各样的服务满足不同人群的需求，比如大型计算、大数据存储等等，因此对系统的监控指标以及监控粒度应该进行分类。用户可以根据实际情况配置需要监控的资源，即监控系统需要具有可扩展性：终端用户增加新的监控逻辑时，系统管理员不需要修改监控系统框架，只要增加监控组件运行时动态加载就能满足用户的监控需求；当某些监控组件不需要运行时，可以动态的删除或者卸载监控组件。

3.1.1 动态加载技术

在软件的运行机制中，动态链接和动态链接库起着非常重要的作用。在Linux或者Windows操作系统中，应用程序在运行时所使用的系统服务主要是由动态链接和动态链接库提供的，同时它也是多个进程或者线程进行资源共享的重要途径。除此之外，在操作系统中实现共享资源库重定向等非常重要的系统功能也是由动态链接和动态链接库实现的。动态链接主要有两个特点[18]：

1）动态加载。在程序运行过程中，动态链接库是否载入程序的代码空间视运行模块的需求而定。如果当前运行模块需要，则载入；否则不载入程序代码空间。

第三章云资源监控系统关键问题研究

2）动态解析。在主程序运行过程中，只有在实际情形下需要被调用的函数或者模板被调用的时候，才会把该函数或者模块从进程的虚拟地址空间中解析出来。

在Linux操作系统中，动态链接库文件格式为ELF，同时在Linux或者Unix操作系统动态链接库运行机制中ELF动态链接文件的分层模型作用非常的重要。Linux或者Unix动态链接机制引入了全局偏移表（GOT）和过程链接表（PLT），实现了位置无关代码（PIC）[18]。通常情况下把动态连接库文件放在若干系统目录下。这些目录包括/lib、/usr/lib、有关PAM模块的/lib/security、有关X-windows的/usr/X11R6/lib和/usr/local/lib。

Windows下的动态链接文件时dll文件，在windows下要动态的加载一个链接库需要LoadLibrary函数，他可以帮助我们加载动态模块，实现监控组件的可扩展性。

3.1.2 基于动态加载技术的监控系统可扩展性设计

由于云计算平台中存在大量的资源，多种类型的用户，每个用户使用云资源和服务的目的是不同的，即使相同类型的用户，他们使用云服务要完成的任务也有所不同。用户的任务有些是计算密集型任务，有些是IO密集型任务。针对不同的监控资源和不同的用户任务，云计算平台中被监控的节点其监控的重点也是有所不同的，有些集群中的资源需要重点监控CPU而有些需要重点监控IO或者网络使用情况。因此云计算平台监控系统需要具有动态伸缩性，当有新的监控任务时，不需要修改现有框架，只是动态的增加监控插件就可以完成监控需求；当不需要某个方面的监控时，可以动态的删除和卸载监控模块。因此作者将被监控组件设计成插件的形式，当被监控节点有新的监控需求时可以去搜索本地指定目录下是否存在该监控组件，如果存在监控组件则利用动态加载技术加载改组件到主监控模块的虚拟内存空间中，启动该指标的监控。如果指定目录中没有该监控插件，被监控节点去远端服务器下载监控组件，然后启动该组件，完成用户的监控需求和任务。

在云资源监控系统的运行过程中，根据用户的需求实现监控组件的动态加载和卸载，从而使得云资源监控系统具有可扩展性，这是云资源监控系统实现在不需要改变原有框架下增加监控任务首先要解决的问题。因为在编程语言C++中并没有动态加载技术，因此该系统的设计中借助操作系统本身提供的动态类加载技术实现监控系统的扩展性。

在面向对象编程中，动态类使用虚函数机制完成在运行过程中动态加载子类对象。一般动态类都有以下几个部分组成：

电子科技大学硕士学位论文

1）抽象接口类。该类中所有的方法定义为纯虚函数，它是所有实现子类的父类，在程序编译过程中该类作为已知类存在。

2）具体实现类。该类从抽象接口类继承，是抽象接口类的具体实现子类。抽象接口类中的方法被定义为是纯虚函数，该类封装和定义了动态类中公用的操作函数；具体实现子类必须继承自抽象接口类并实现其中的纯虚函数，在实现抽象接口后，这些具体实现子类分别被编译器编译成对外接口相同、功能不同的动态链接库[19]。

在操作系统中，正在运行的程序利用动态加载技术根据实际的需要将这些动态链接库动态的卸载或者加载到程序的代码空间中，并使用抽象接口类封装的公共操作函数访问功能不同的具体实现子类。为了便于使用，我们可以为每一个继承自抽象接口的子类设计一个通用的模板类作为代理。监控服务子程序运行时，动态加载类的实例可以由模板类的代理实例生成，该代理实例对应着具有相同接口的动态链接库中具体实现子类的实例，这样就可以实现类的动态加载。

3.2 监控系统故障诊断 3.2.1 多值决策图

在以往的可靠性分析方法中像故障树、可靠性框图等，大多数都是以两个值（成功/失败）事件来作为假设前提。但是根据现实生活中系统故障分析情况来看，过去的分析方法是不完全正确的[20]。在系统运行过程中，从系统整体到单个模块或者程序都会有多种多样的故障情况发生。比如系统可能处于正常运行、完全失败或者运行异常状态之中；系统中某个模块可能处于正常，部分异常或者运行失败等情况之中。这些故障都会对系统的正常运行造成影响，降低系统的整体性能，但是它们对系统的影响又是不同的。因此在实际的使用过程中，整个系统或者运行模块产生故障的类型是多种多样的，与此同时每种类型的故障又存在多种状态。为了便于模仿和分析系统故障，多状态系统应运而生。

在现实生活中，多状态系统的例子是很常见的比如：在电子设备、通讯网络、计算机系统等系统中都可以找到多状态系统的影子。多状态系统是指系统本身和运行于系统中的各个组件和模块，在运行过程中呈现出的多种性能层面和状态。由于多状态系统中系统和模块本身状态存在多样性，因此一般多状态系统会包含以下方面的前提假设：

1）系统的状态和系统中组件的状态用数值表示。比如：把系统的全部状态用1,2,3....,n来表示，总共表示系统的n个状态，系统在运行过程中只能处于一个状态之中；将模块的状态用1,2,3.....,m来表示，总共表示模块的m个状态，每个模

第三章云资源监控系统关键问题研究

块只能处于一种状态之中。这些状态有可能是无序的，也有可能是有序的。状态的顺序并不能表示状态之间的恶化程度，即状态的恶化程度跟状态表示的先后顺序无关。

2）互斥性。在多状态系统中，从系统本身到运行于系统中的各个组件在某一时刻都只能处于一个状态之上，不可能某个模块或者系统既处于状态X又处于状态Y。

3）独立性。多状态系统中组件和组件、模块和模块之间行为互不影响、具有独立性，其中任何一个组件或者模块的行为和状态变化都不会影响到其他组件或者模块。

4）输入参数影响分析结果。多状态系统中每个组件或者模块概率要么是已知的，直接作为已知参数输入；要么是通过对输入参数进行计算而得到。

5）连贯性。多状态系统是连贯的，具有连贯性。系统中运行的每一个组件和模块的状态都会对系统最后的运行结果造成影响。如果系统中组件都运行正常或者失效的很少，则对系统的影响就很少甚至没有影响；但是如果出错的组件很多，则整个系统就可能导致崩溃。

在一个系统中，如果我们得到了系统中所有模块处于各个状态的概率以及这些模块之间的运行关系比如：并行关系，串行关系等等。就可以利用工具通过计算求出当前系统处于各个状态时的概率值。在众多的工具当中，多值决策图不但具有很高的效率而且也可以保证有效性。

多值决策图[21]（Multiple-valued Decision Diagram MDD）是对二元决策图（Binary-valued Decision Diagram BDD）在多值上的一种补充和扩展，在可靠性分析领域中有着广泛的应用。多值决策图具有方向性而无环路，由非叶子节点、叶子节点以及分支三部分组成。在多值决策图中，叶子节点是每一个分支的最后一个节点代表系统运行的最终状态，用1,2,3....,n表示。非叶子结点代表系统中运行的各个模块或者组件，他们包含了m个分支，分别指向叶子节点即：系统运行的最终状态，用1,2,3....,m表示其值。

3.2.2 基于多值决策图的报警模型

云计算是分布式计算、网格计算、网络存储和虚拟化技术发展融合的商业模型。随着云计算平台规模的不断扩大，为人们提供的服务也越来越多，但是大规模的存储和计算资源构成的服务平台，其组件出现故障的频率也越来越高，因此保证云平台的可靠性、适用性、安全性以及故障及时诊断完成自我修复成为当前云计算的研究热点。为了向用户提供高质量可靠的服务，云平台必须由可靠稳定

电子科技大学硕士学位论文

的基础设施组成并建立起强大的故障自我诊断智能平台，诊断出故障后以邮件或者短信的方式向用户提供告警功能，促使用户及时的修正系统错误或者动态进行虚拟机迁移保持云平台负载均衡，使云计算平台保持最大的稳定性、降低由于系统故障所带来的的损失，给用户最佳的使用体验。

在故障诊断和告警模块的研究中，作者总结前人经验以实际使用情况为依托，将系统和组件的故障分为五级即：灾难级、故障级、严重级、轻微级、正常级。当系统出现故障时，及时发现故障会对用户的损失降到最少。为了满足系统故障诊断的时间要求，多值决策图用于故障诊断是最佳的选择。多值决策图是对二值决策图在多值空间的扩展和补充，可以用来解决云计算平台这种多状态空间的问题。

故障树也可以表示多状态空间，但是无法对状态空间进行求解。根据系统各个组件运行的实际情况，判断出各个组件当前的状态，根据组件的状态以及运行关系就可以得到系统的多值决策图。在得到多值决策图后计算出系统的当前状态，根据系统的运行状态进行下一步的决策。

模型构建和概率推导[22]是构建多值决策图的两个步骤。多值决策图一般由叶子节点、非叶子节点和分支构成，系统中各个组件模块构成多值决策图的非叶子节点，系统的最终运行状态构成多值决策图的叶子节点，非叶子节点向叶子节点的可能的连线构成分支。概率推导是指根据各个状态的概率，计算所有能到达此状态的路径概率之和。在这些路径概率中，最大的路径概率即是系统最终有可能到达的状态。

表3-1性能判断基准

CPU利用率系统运行正常(0) CPU利用率小于60%, 内存利用率内存利用率小于40% 系统运行良好(1) CPU利用率介于60%-75%之间或者CPU利用率小于85%并且持续时间小于5s 内存利用率介于40%-70%之间内存利用率大于70% 系统运行故障(2) CPU利用率大于90% 为了更好的描述系统故障等级诊断过程，下面针对如下图3-1表述的含有三个CPU和两个Memory的简单云计算系统进行故障等级判定。上表3-1表示性能判断标准。三个处理器的性能用P1、P2、P3来表示，两个内存的使用情况分别用M1、M2来表示，B表示总线Bus的状态。用数字0、1、2来表示系统的故障诊断级别，其中0表示正常，1表示良好，2表示故障。

第三章云资源监控系统关键问题研究

ProcessorsP1P2P3BUSM1M2Memories

图3-1 简单云计算系统

使用多值决策图对系统故障等级判定，其步骤如下所示：

1）分析系统结构，根据分析结果构造多值决策图。针对图3-1构造的多值决策图如图3-2所示，详细构造过程[23]此处省略。

2）根据预先设定的系统故障模型对预决策系统进行等级判定。比如：内存的使用在一定的范围内（如40%以下），就会被判定为系统运行正常；如果内存的使用介于一定的范围（比如40%到70%之间）,就会被决策为轻微症状。如果其使用率高于预先设定的阈值,就会被认定为某些程序的运行出现故障，占用了过多的内存，需要系统管理员进行系统检测，阈值设定可以参考[24]。

3）根据搜集到的参数计算出症状集，然后根据症状集合从多值决策图中查找系统故障等级判定的路径。比如可以参照图3-2，假设检测到的系统症状为P1中级、P2良好、P3良好，M1良好、M2良好、B严重，则进行系统故障级别诊断的多值决策图路径为图3-2中的虚线部分所示，被决策系统故障级别被诊断为2。

P1P2P2P3P3M1M2M2B012

图3-2多值决策图

电子科技大学硕士学位论文

由于已经预先建立了多值决策图以及预先确定了系统运行中相关系数的安全级别标准，因此采用多值决策图进行系统故障等级判定不仅效率高而且多值决策图扩展节点复杂度很低（常数级）。在系统运行时，如果由多值决策图判定到当前系统的运行状态正常则系统继续运行没有必要进行故障报警；但是如果判定到当前的系统运行状态为故障级别比如CPU或者内存的使用超过了设定的阀值等情况，系统就会根据多值决策图的判定情况进行报警，告知系统管理员进行系统检测，以及时的发现问题保证系统的正常运行。

3.3 监控系统数据处理 3.3.1 推拉模型分析

在传统分布式资源监控系统中，根据数据交互启动过程中启动策略的不同，监控节点与被监控节点之间数据传输模式分为Push模式和Poll模式[25]。如图3-3所示，监控系统由三部分组成即：生产者、消费者、目录服务。生产者负责监控信息的收集工作，一般放在被监控组件中运行。消费者使用生产者产生的监控信息以可视化易于理解的方式呈现给系统管理员。目录服务便于系统管理员查找生产者和消费者，同时协助两者通信。

生产者推拉模型消费者目录服务

图3-3监控系统

在推（Push）模式中，数据传输的主动者是生产者。当系统的状态改变并达到或者超过一定的阀值时，被监控节点主动向监控组件汇报系统当前资源负载情况，其工作原理如图3-4左侧部分所示，各个被监控节点Node主动向Monitor Node 节点汇报当前系统负载情况。在拉（Poll）模式中，数据传输的主动者是消费者。消费者使用定时查询的策略从生产者那里得到当前系统的负载情况。如图3-4右侧部分所示，Monitor Node节点主动询问Node节点，得到系统资源的信息。

第三章云资源监控系统关键问题研究

Node 1Node 2Monitor NodeNode 1Node 2...Node n图3-4推拉模型

Monitor Node

Node n

在某些特定的情况下进行监控数据传输，推模式具有一致性好、效率不高的特点。每当系统资源使用和负载发生变化的时候，被监控节点向监控节点推送监控的负载信息。但是如果监控配置信息设置偏低，导致被监控节点频繁向监控组件汇报信息，就会造成网络阻塞；如果监控配置信息设置偏高，就会导致云平台监控失效，当系统资源负载很重或者出故障时，被监控节点仍然没有向监控节点汇报信息。因此推模式适合用于设置阀值越界报警的场合。

在监控数据传输过程中，基于拉模式的一致性虽然不如推模式的一致性好，但是拉模式数据传输时工作效率很高，在定期查询的场合有很大的用途。定期轮询策略，自适应轮询策略以及Slacker轮询策略都是基于Poll模式[26,27]，旨在最大化监控组件和被监控资源直接的数据一致性。如果“拉”的频率高，导致监控系统频繁的收集监控信息，势必会占用过多的系统时间和消耗过多的系统资源，对被监控系统造成很大的负担同时频繁的传输监控数据就会占用过多的网络带宽，造成网络拥塞；如果“拉”的频率低，虽然可以很少的影响监控系统，使用不多的网络带宽，但是其势必会在“拉”的周期内会造成消费者比较敏感的信息丢失，达不到云平台监控的效果。

3.3.2 即时反馈

传统的大多数监控系统都是在收到系统管理员或者用户的监控需求指令后，将监控指令通过网络下发到被监控端，被监控端根据指令进行信息收集反馈给系统管理员或者用户。在这种情况下，被监控端对信息进行收集需要占用一定的时间同时信息通过网络传输占用一定的时间。随着云平台规模的扩大，被监控组件就会相应的增加，极易出现被监控组件收集信息不稳定或者占用过多的时间造成用户长时间等待监控数据。为了及时反馈给用户监控信息同时保障监控数据稳定可靠，监控系统需要在监控端记忆各个被监控端当前的运行状态信息同时动态的进行更新。当系统管理员和用户首次发送指令后，从监控端记忆系统中取出数据反馈给用户。

电子科技大学硕士学位论文

3.3.3 监控数据处理方案

由于拉模式数据传输效率很高，但是监控节点和被监控节点缺乏一致性；推模式可以使得监控节点和被监控节点之间保持数据的较高一致性，但是数据传输的效率不高。因此单独的推拉模式不适合在云计算平台上对各种异构，动态资源进行监控。为了保证监控系统的稳定可靠以及用户的任务顺利完成，同时又保障监控信息的实时传输，尽最大可能降低监控系统对云计算平台以及网络的影响[28]。

作者对数据传输的推拉模型进行了认真的研究，结合推拉模型各自的优势、避其所短，在云资源监控系统中采用推拉混合模型实现监控数据的传输。在推拉混合模型中，以推模型为主导，当在规定的时间内监控端没有收到监控信息时，监控端采用拉模式从被监控端索取数据。

在被监控端运行推模式算法，用户或者系统管理员可以根据实际情况设置不同的信息收集时间值，比如：20s表示每隔20秒被监控端向监控端上传监控数据。设置不同的时间值可以满足不同用户的监控需求，调节监控粒度。如果用户需要比较准确的监控数据以观察系统的运行状态，可以设置的时间值比较短；如果用户并不需要比较精确的监控数据，可以设置的时间值长一点。监控端以配置文件的形式将管理员设置的时间值下发给被监控端，如果被监控端的配置文件版本号和收到的配置文件的版本号相同，则不更新当前的配置文件；如果下发的配置文件的版本号比较新，则更新配置文件；如果是新开启的系统，则安装被监控组件后，主动向监控端下载配置文件，被监控端根据配置文件中的时间值定时向监控组件上传监控信息。

在监控端运行拉模式算法程序。在监控端设置一个定时器，当在规定的时间内监控端没有收到监控信息，则主动向被监控端索取监控信息，以保证监控端和被监控端持续通信。如果监控端拉模式没有收到消息包，则被监控端出现了网络中断或者死机，导致监控信息没有上传到监控端，此时应该及时的反馈给用户或者系统管理员进行故障检修。为了更好的描述该算法，使用interval表示设置的时间值、delayTime表示信息收集和网络传输时间值、queryTime表示查询时间值。其伪代码表示如下：

While(true) -- time;

If(收到监控信息）

queryTime = interval + delayTime; time = queryTime; End if;

第三章云资源监控系统关键问题研究

If(0 == time) 启动pull程序 End if; End while;

云计算系统中充斥着大量的异构资源，众多的物理服务器，在每台服务器上可能存在上百个虚拟机，因此在平台中被监控的节点是极其繁多的。为了减少网络通信量和网络拥塞，缓解主监控节点的负载，作者借鉴自主仿生神经系统思想设计出分布式的具有自主特性的监控系统[29]，如图3-5所示：

大脑中枢神经cacscsdbcpm1周围神经pmdb1cpm2pmdb1cpm...pmdb神经元cvm1vmdb1cvm2vmdb2cvm3vmdb2cvm...vmdb 图3-5基于BANS的监控系统逻辑图

其中：

 监控指令操作页面（CA）看做人的大脑，下发指令。

 监控端（CS）看做中枢神经系统，传导指令。它是BANS的顶层有自己的数据记忆系统CSDB，存储通过神经纤维传输的宿主物理服务器和寄主虚拟机的节点信息；同时汇总宿主机的历史统计信息。

 CPM是周围神经系统，对应宿主物理服务器。每个宿主机有自己的数据记忆系统PMDB，用于存储本地的监控信息以及寄主虚拟机的汇总历史信息。周围神经系统包含神经元。

 CVM是神经元，对应寄主虚拟机。它有自己的记忆数据系统VMDB，用于存储本机监控信息。

寄主虚拟机将本地最新最近的一条监控信息上传到宿主物理服务器，每个宿主物理服务器将本地最新最近的一条监控信息以及汇总的本机中的寄主机监控信息上传到监控端（中枢神经系统）。当用户或者系统管理员需要监控信息时，第一次直接从监控端得到即时反馈用户，用户不需要等待；然后根据用户的监控需求

电子科技大学硕士学位论文

从物理服务器或者虚拟服务器中取得监控信息，这样可以带给用户最好的效果体验。

3.4本章小结

本章首先分析了设计云资源监控系统架构时所面临的关键性问题；然后作者重点从实现云资源监控系统的扩展性、故障报警以及监控数据处理三个方面进行了深入的分析；最后提出使用系统动态加载技术解决监控系统扩展性问题，通过多值决策图对被监控系统进行决策、判定系统的故障等级、根据故障等级进行报警，以及采用推拉混合模式和仿生自主神经系统思想解决云监控系统中数据处理问题。

第四章云资源监控系统设计与实现

4.1 需求分析

云计算平台的服务模式与传统行业的交付使用模式是一脉相承的，都是通过动态伸缩服务量，按需为不同层次的用户提供层次化的IT资源。云计算平台的不同层次由计算资源、存储资源、应用资源池、平台、物理服务器以及虚拟资源池等组件构成，因此云计算平台具有虚拟化、动态、伸缩的特点。

面对众多的资源和服务，我们必须了解掌握云计算平台的服务层次结构，对充斥在平台中的组件和服务进行抽象，从而更好的达到监控的目的。

4.1.1 云计算服务层次结构

现有的大多数云计算平台都建立在某个数据中心基础之上，如图4-1所示。云计算平台服务层次结构一般有四层构成即：数据中心（Data Centers）、基础设施服务层（IaaS）、平台服务层（PaaS）以及应用服务层（SaaS）[30]。

云计算服务层次结构应用服务层平台服务层基础设施服务层数据中心

图4-1云平台服务层次结构

其中：

 数据中心层(Data Centers)由众多厂商生产的硬件资源构成，比如：物理服务器、网络设备、存储设备等。数据中心一般坐落能源充足、自然和人为灾害比较少的偏远地区。

 基础设施服务层(Infrastructure as a Service)建立在数据中心基础之上，它

电子科技大学硕士学位论文

对硬件资源进行抽象、虚拟化，为用户提供资源租赁和订购服务。基础设施服务层只提供虚拟化的硬件资源，并没有提供特定的软件，一般给用户提供虚拟机镜像（VM），该镜像跑在虚拟服务器上被调用。用户可以根据项目实际的需要，按需向云平台索取资源，当用户的任务完成以后再将使用的资源交还给云平台。因此基础设施服务层具有动态伸缩的特点。

 平台服务层（Platform as a Service)在基础设施服务层提供的虚拟机镜像中提供服务，一般由中间件或者服务器组成的开发平台。不同的用户可以在平台服务层中协同部署和开发应用程序。平台服务层可以被看做是一个完整的虚拟化平台，它包括特定的操作系统、软件栈、一个或者多个服务器以及应用程序构成。

 应用服务层（Software as a Service）将所有的应用软件安装在云服务器端，终端用户通过网络使用云平台中的服务。不同的终端用户可以使用一个服务，多个服务可以被用户共享。同时用户可以将自己开发的软件上传并运行在云平台中，为其他的终端用户提供服务。

4.1.2 监控实体抽象

云平台中的资源是异构的。因此将云平台中的资源进行抽象，不仅可以屏蔽被监控资源的异构性而且可以使监控设计简化[31]。针对上节对云平台服务层次结构的分析，作者从云平台的四个服务层次对监控实体进行抽象。

 数据中心由底层硬件构成，它的运行状态直接关系到云平台的稳定，因此对它的监控是极其重要的。比如：cpu的利用率，内存的使用情况，网络和硬盘的使用等等。

 基础设施服务层对底层的硬件资源进行虚拟化，平台服务层在虚拟机镜像中提供服务，被看做是一个完整的虚拟化平台。因此需要对虚拟化平台进行监控，比如：虚拟机的类型，虚拟机的cpu利用率，物理机上有多少虚拟机在运行以及对外提供的服务。

 应用服务层上有各种各样的服务，因此需要对这些服务进行监控，比如：该服务占用多少cpu、内存，占用的端口号等等。

 云平台的终端用户是不同的，需要对他们与平台的交互行为和方式进行监控，比如：云服务提供商的操作、终端用户的操作、IP地址的分布、在平台中的浏览情况以及停留时间等等。

第四章云资源监控系统设计与实现

4.1.3 监控需求分析

随着云计算技术的不断发展和广泛应用，云计算平台的规模越来越大，使用的用户也越来越多同时带来的问题也越来越复杂（比如：单台服务器访问量过载、服务器死机导致服务中断等等）因此对云平台中的资源进行有效监控和合理利用越来越迫切。然而传统的监控系统部署过于复杂，可扩展性不强、监控数据的传输和处理无法满足云资源监控系统的需求。因此云资源监控系统的部署以及架构设计对云计算平台来讲是一个具有挑战性的课题研究。

云平台中的资源具有动态伸缩性、资源异构性，系统运行时产生的交互数据极其繁多而且错综复杂[32]。通过对云平台服务层次结构的分析和监控实体的抽象，云资源监控系统需要从以下几个方面考虑：

1）云计算平台是由众多不同厂商生产的物理服务器构成的。它们的产品型号、性能等等各个方面都存在差异，因此对这些厂商生产的服务器进行集中监控是非常复杂的，需要中间层屏蔽这些差异。

2）云计算平台中的资源是动态的。云计算平台是一个开放的平台，一些资源随时有可能坏掉被用户或者系统管理员拿走，也有一些资源随着用户的需要或者项目规模的扩大，被加入到云计算平台中，因此对云资源进行监控必须具有灵活性和扩展性。

3）云计算平台中的虚拟平台是不同的。有windows平台、android平台、linux平台等等，在平台中运行的用户软件也是不同的。因此云计算平台中产生的数据是错综复杂的。相比其他监控软件，云资源监控需要更多的监控功能。

4）云平台中的监控组件极其繁多，产生的监控信息也是数不胜数。因此应该控制云资源监控的规模，不能占用太多的云平台资源。

5）云平台的使用用户不同。云资源监控系统的部署和使用应该尽量的简单、实用，以满足不同水平的用户的使用。

由以上分析可知云资源监控系统应该在资源监控粒度和系统资源开销方面做出平衡，使用最少的云平台系统资源达到最大的监控能力。因此云资源监控系统应该在架构设计、数据收集、数据处理、数据传输方面做出努力，以保证给用户最好的体验。

此外在云计算平台中有众多的物理服务器、虚拟机、软件、服务以及基础硬件设施构成。云资源监控既要监控硬件资源也要监控软件资源，如果没有统一的管理界面而是让系统管理员逐个去检测软硬件的运行状态，势必会造成系统管理员极大的工作负担而且极易出错。因此一个统一的管理界面对云资源监控系统来讲是必须的。

电子科技大学硕士学位论文

云平台中的软硬件每时每刻都会产生大量的交互数据。云资源监控系统不仅要处理这些实时交互数据，而且要存储历史交互数据。存储历史数据有利用系统管理员预测云平台软硬件运行状态的走向，便于系统管理员对预将出现故障的软件或者硬件提前进行检修。同时历史数据便于系统管理员对云平台中的软硬件资源常见的故障进行集中分析和管理，存储终端用户的登入、操作和浏览信息便于用户分析终端用户的行为，了解用户的IP分布，根据用户的喜好更好的改进软件吸引更多的用户。存储历史监控数据后，当系统出现故障时便于系统管理员或者用户进行日志查询，查找问题的根源提高系统的可靠性。

当云平台中的软硬件资源出现故障后，需要系统管理员及时的检修，因此云资源监控系统需要根据用户的需求具有多种报警功能。云平台中的软硬件资源在实际的运行过程中，由于现实中不确定的因此随时都有可能出现故障。系统故障轻则导致用户的服务受到影响甚至终止服务，重则影响云平台中其他服务的运行导致整个服务器瘫痪，云平台所提供的多种服务都无法满足用户的使用。因此及时发现云平台中的软硬件运行错误，通知系统管理员进行检修是保障云服务可靠性非常关键的一环。云资源监控不仅要监控各种软件和服务的运行状态，而且要确保软件和服务出现故障后，及时的通知系统管理员和用户。

云资源监控系统监控数据从数据采集器收集后上传到云资源监控器、云资源监控器统一将监控数据进行汇总并上传至系统管理页面。由于云平台中的硬盘分布不受地理限制，因此监控数据的传输很大程度上是在局域网或者互联网上进行传输。网络传输势必会带来时延，因此如何有效的跟用户交互，减少用户的等待时间需要监控系统在保证监控数据安全可靠性的基础之上进行认真的考虑。

云平台中被监控资源众多，监控组件运行在被监控的资源之中，因此监控组件是极其繁多的。众多的监控组件在完成数据收集和故障检测时需要配置文件和判断标准，这些配置信息是由用户或者系统管理员进行配置的。如果系统管理员需要逐一对被监控组件进行配置，势必会造成系统管理员负载极重甚至无法完成。因此云资源监控系统需要统一对被监控组件进行配置，判断标准进行统一下发，当用户需要新的监控需求或者改变监控策略时，只需要在页面进行统一的配置或者管理，然后向监控控制器下发修改指令，由监控器向被监控端传输系统管理员新的监控策略和判断标准，这样可以大大的减轻管理员的管理任务，节约管理成本和时间。

第四章云资源监控系统设计与实现

4.2 总体设计 4.2.1 云平台总体架构

云资源监控系统属于云平台整体架构的重要组成部分，它为云平台的资源调

度、动态虚拟机创建、虚拟机动态迁移、负载均衡等提供数据支持，同时也是整个云平台安全运行的保障[33]。本论文实现的云资源监控系统应用在协同自主计算实验室的项目CAOS云操作系统中，改善了CAOS云平台的监控性能。

CAOS云操作系统的实现采用MVC模型，使得用户操作页面和云平台的业务处理分开，这样降低了系统模块的耦合度，提高了代码的内聚性。系统功能模块如图4-2所示：

系统管理员(CA)数据库集群（DB）云资源监控器（CS）云平台控制器（CC）数据采集器（CW）数据采集器（CW）数据采集器（CW）图4-2 CAOS云平台功能模块图

其中：

 CA页面采用WEB技术为系统管理员提供的可视化操作界面，便于云平台系统管理员管理CAOS云操作系统。

 CS是云资源调度与监控模块。负责接收系统管理员的命令及对命令进行解析，根据用户的需求完成监控任务

 CW运行在被监控端，负责数据的收集和持久性存储。

 DB 是CAOS云操作系统的数据库集群模块，负责云平台的数据存储。  CC 是CAOS的云控制器模块。它是云平台的核心部分，主要完成应用资源池管理、云脑管理、虚拟机管理、用户管理以及存储管理功能。 CAOS云平台逻辑架构如图4-3所示：

电子科技大学硕士学位论文

表示层展示页面（CA）软终端（CT）业务逻辑层云控制器（CC）云脑管理云脑实例管理虚拟机管理虚拟机实例ISO镜像云监控器（CS）配置中心管理物理机监控虚拟机监控日志查询应用管理应用发布虚拟机分配用户组用户管理应用审核用户访问日志系统运行日志告警模块接口模块服务器管理接口虚拟机管理接口被监控端（CW）信息整合插件管理信息处理通信模块数据持久层服务器集群KVM虚拟机Hyper-V虚拟机

图4-3 CAOS云操作系统逻辑架构图

第四章云资源监控系统设计与实现

4.2.2 云资源监控系统总体架构

云平台中的资源呈现层次，异构性分布，网络吞吐量比较大并且监控实体繁多。因此需要统一配置和管理。CAOS云平台中的监控系统基于仿生自主神经系统，采用阶梯式的体系结构。云资源监控系统总体架构如图4-4所示：

CA大脑数据请求数据反馈CS数据请求数据反馈记忆信息中枢神经CWPH数据请求VM数据反馈记忆信息周围神经记忆信息神经元

图4-4 云资源监控系统总体架构

其中：

 CA页面是系统管理员的登入和操作界面，便于系统管理员管理云平台。管理员从CA页面下发指令给云监控控制器CS。

 云监控控制器CS从CA页面接收用户的指令。通过对用户指令的解析和翻译，向相应的功能模块下发指令，并对下层上传的监控数据进行整合。在CS这一层中存储了整个云平台物理机和虚拟机最近最新的监控数据，在CA页面首次查询监控数据的时候，从CS端数据库中获得。在空闲时间内，CS端监控数据库中的数据时刻进行更新。

 被监控端CW模块分别运行在物理服务器和虚拟机中，用来完成监控功能。

电子科技大学硕士学位论文

虚拟机VM是以物理服务器为载体的。每个物理服务器被看做一个神经突轴，运行在该服务器上的虚拟机向物理服务器汇报监控信息。在每台物理服务器中都存有该服务器上所以虚拟机最新最近上报的监控信息，用以反映该服务器上所有虚拟机的运行状态。虚拟机运行在某台物理服务器中，被看做一个神经元。在虚拟机上的监控模块负责本虚拟机的信息采集和上报工作，同时对监控信息进行本地存储。

云资源监控器（CS）运行在服务器端，是云资源监控系统的核心模块。它负责接收系统管理员或者用户的监控指令，对指令进行翻译完成监控任务。其功能模块如图4-5所示：

CS配置中心终端注册日志查询故障报警物理机监控虚拟机监控访问日志运行日志

图4-5 云资源监控器功能模块图

各个模块功能描述如下：

 配置中心主要根据用户的监控需求，调节监控粒。云监控控制器CS对配置文件进行统一管理，无需终端用户进行配置，从而简化了云监控系统的部署和配置过程，简化了云监控系统的使用。

 终端注册模块主要完成被监控终端注册功能。被监控终端安装监控模块后，会主动和云监控控制器进行交互，完成注册功能，同时从监控端下载配置文件。

 日志查询。日志查询分为用户访问日志查询和系统运行日志查询。用户访问日志可以记录用户访问云系统的时间、浏览过的服务以及IP分布，便于云

第四章云资源监控系统设计与实现

服务提供商改善服务。系统运行日志包括物理机运行日志和虚拟机运行日志。记录系统运行日志便于用户或者系统管理员查看以往系统运行信息。  故障报警。报警模块是云监控系统的重要部分。根据多值决策图的分析，当云平台运行出现故障时，被监控端就会向上层进行报警，提示用户或者系统管理员及时对系统进行安全检查。云监控端将报警信息上传给CA云系统管理员。

 物理机监控模块主要负责对物理服务器监控信息的整合和处理。对物理服务器进行监控是云平台提供可靠服务的保障，同时可以根据监控信息进一步优化系统资源。物理机监控主要包括对CPU、内存、网络、硬盘、关键进程和服务等多项指标。

 虚拟机监控模块主要负责对虚拟机的监控信息的整合和处理。虚拟化是云计算平台的主要特点。云服务提供商和应用服务提供商的大多数服务都运行在虚拟服务中，因此对虚拟机进行监控是非常重要的。

数据采集器（CW）运行在被监控端即客户端。它是监控数据收集的核心模块，是云资源监控系统的重要组成部分。CW接收云资源监控器（CS）端的指令，通过对监控指令进行翻译和分析，调用相应的插件完成信息收集工作。CW完成数据收集后，调用相应模块进行数据整合并通过网络将数据反馈给CS，同时将监控数据存入数据库中，便于日志查询。当被监控端发现系统或者监控资源异常时，主动向CS进行报警。数据采集器CW功能模块如图4-6所示：

CW指令处理任务分配信息整合通信模块数据库操作插件管理告警模块监控器模块

图4-6 数据采集器功能模块图

各个模块的功能描述如下：

 指令处理模块。负责接收云监控器（CS）端下发的指令，对指令进行翻译和处理。将处理后的命令以参数的形式传送给任务分配模块。

电子科技大学硕士学位论文

 任务分配模块。负责接收指令处理模块的参数，根据参数调用相应的服务子程序，完成CS下发的任务。

 信息整合模块。负责监控数据的整合，将整合后的数据以相应的形式交给通信模块和数据库操作模块

 通信模块。负责和云资源监控器（CS）的通信。将命令或者监控数据进行上传和下载。

 数据库操作模块。负责和sqlite数据库的通信，将监控数据从数据库中取出或者存入。

 插件管理模块。负责插件的管理，对插件进行配置、加载、卸载、启动和关闭。

 告警模块。负责被监控端的告警功能，该模块根据性能判断标准采用多值决策图对被监控系统进行故障等级评定，根据评定结果判断是否需要向CS端报警。

 监控器模块。维护和云监控控制器（CS）的心跳。通过定时ping控制器（CS）判断和监控器的通信状态。

云平台中的监控实体具有层次性、多样性、动态性的特点。因此监控系统的数据采集采用插件模式实现。插件模式具有可扩展性，当需要某项监控指标时可以动态加载插件；当不需要某项指标时可以动态卸载该插件以释放监控系统占用的平台资源。由此可见插件模式不仅可以满足云资源监控系统动态伸缩性的特点，还可以减少监控系统对云平台的干扰程度，使用最少的系统资源达到最大的监控力度。

4.2.3 云资源监控系统通信架构

传统的网络通信方式分为TCP通道和UDP通道。TCP通道可以保证监控数据的安全、可靠，但是TCP通道需要建立网络连接和拆除连接，因此占用的网络资源比较大；UDP虽然不需要建立网络连接和拆除连接，但是其发送的数据包是不可靠的甚至发生丢包现象。云监控系统采用TCP和UDP双通道的方式，完成数据传输。首先监控端和被监控端采用UDP方式进行通信，当管理员接收不到监控信息时可以切换成TCP方式向被监控组件索取数据。云资源监控系统通信架构如图4-7所示：

第四章云资源监控系统设计与实现

CATCP信息通道CSPOPEN通道CallProc(被调子程序)HOST配置文件CS子进程中心服务程序道道通息息通P信P信DUTCUO BRPDSCADATCW(DOWN)CW(UP)POPEN通道GetInfo 图4-7 云资源监控系统通信架构

云监控系统内部大致可以分为三种通信类别。

 UDP常规广播。UDP广播由CSSC子进程发出，信息内容来源于host.cnf配置文件。该文件主要用于CW的配置。

 CW主动信息上报。此通道现包含告警与终端信息注册两类通信，都是有CW主动向CS发送信息完成。

 普通查询通道。首先由CA于CSSC建立TCP通道，然后CA发送指令给CSSC，CSSC收到指令后去掉通信协议的头部，然后调用相应的程序(POPEN实现)。然后被调用程序将指令进行翻译与转发，并等待信息回收与整理。最后CSSC程序将信息发回并拆除TCP连接。

4.2.4 通信协议设计

云平台中监控实体繁多而且呈现层次、差异性的分布特点。由于众多的监控实体的存在，云资源监控系统的监控组件数量很多而且分布在不同的物理机集群或者虚拟机集群中。为了方便和简化云资源监控系统内部程序之间调用的规范操作，更好的翻译和理解云系统管理员或者调度器的指令，作者根据CAOS云平台监控系统的实际需求设计出一套内部通讯协议。

CAOS云平台监控系统内部程序约定如表4-1所示：

电子科技大学硕士学位论文表4-1 云监控系统内部程序名约定

程序 CSSC GETET(et代表实体） ESTIMATE CREATE_CLUSTER DB_OP CWINFO GET_INFO GETLOG 内部程序名 cssc getet estimate creclu dbop cwinfo getinfo getlog 本次通讯协议的设计采用“@”为一级分隔符，“,”为二级分隔符，“#”为三级分隔符。协议格式描述如下：

NAME=X1,PARAM=X2,CALLBACK=X3,@NAME=Y1,PARAM=Y2,CALLBACK=Y3,@.... 协议字段的说明如下表4-2所示：

表4-2协议字段说明

字段 NAME 功能接收程序内部程序名（由接收程序内部维护，但是发送者预先知道该名称。） PARAM(可省略) 传递给接收程序的参数信息，有接收该指令的进程读取。 CALLBACK(可省略) 该字段指定接收程序的回调程序，由接收程序调用。 CALLBACK=getph, CALLBACK=#getph#getvm#, CALLBACK=unknown, 用法说明（举例） NAME=cssc,(暂时只支持这种用法） NAME=#cssc#cc#, NAME=#getph#getvm#estimate#, PARAM=getphinfo， PARAM=#infotype=getph#estimate=0#, 上述协议的设计有以下几点值得注意：

1）请勿在指令中包含“!”等有歧义的特殊字符。

2）由于云系统管理页面CA只与CSSC（云监控端主程序）进行交互，且CA没有给CSSC的额外参数，所以CA所发指令基本固定为NAME=cssc,CALLBACK=Y1,@NAME=Y1,PARAM=#...#....#,CALLBACK=Z1,@ 画线部分根据实际需要进行更改。特殊情况：对于如下指令

NAME=estimate,PARAM=#state=ok#clustername=xxx#memory=xxx#vmtpl=xxx#vms=vmhost,num,total,used;vmhost,num,total,used;....;#，@

画线区域中的“,”自动失去二级分隔符的含义。若三级分隔符以下还需进行分隔，可有程序员之间协商定义。

第四章云资源监控系统设计与实现

协议的实际使用举例如下：

NAME=cssc,CALLBACK=estimate,@NAME=estimate,PARAM=#infotype=getph#estimate=0#,CALLBACK=unknown,@

该指令的大致含义为：CA让后台程序给出所有物理机的一个初始信息。由cssc接收该指令，然后比较第一个NAME值。如果本程序为cssc,则继续执行，否则，丢弃该指令。因为CA没有传递给cssc的参数，则第一部分没有PARAM字段。CALLBACK=estimate是由CA指定给cssc的，让其调用名为estimate的外部程序。Cssc程序取出该值后直接调用名为estimate的外部程序即可。Cssc调用estimate程序时需将第一部分指令进行剥离(类似于IP头部分离),剥离后的指令如下： NAME=estimate,PARAM=#infotype=getph#estimate=0#,CALLBACK=unknown,@ Estimate程序接收该指令后进行类似于cssc的前面的操作进行指令解析。有两点值得注意：

1）只是PARAM参数不为空，而且有多个参数，需要使用#三级分隔符隔开。 2）CALLBACK=unknown的实际意义为CA并不知道estimate会调用什么外部程序进行评估工作，所以就将该字段指定为unknown。这样做一来可以简化CA构造指令的工作，而来可以对其屏蔽一些底层细节，加强了安全性。对于CALLBACK=unknown的指令，接收程序需要根据PARAM的具体含义进行外部程序调用。(对于一些复杂的、危险的程序，建议指定CALLBACK为unknown) 日志查询命令举例如下：

NAME=cssc,CALLBACK=getlog,@NAME=getlog,PARAM=#hostip=[值]#infotype=[time/top]#[argv]#range=X1-X2,CALLBACK=unknown,@

[IP]是指需要查询主机的IP地址。Infotype=time为按时间查询；Infotype=top为按最近历史数量查询，只可选其一。Argv这个附加参数根据infotype的值来设定。比如：infotype=time,则argv=2012-02-21 11:20:06~2012-02-22 12:00:00；Infotype=top，则argv=10(具体数值)。range参数，为本次请求范围，X1为起始值，X2为结束值。建议MAX（X2-X1）=10。

在实际开发过程中，为了便于定位错误提高云资源监控系统的健壮性。程序的返回值规范如表4-3所示：

电子科技大学硕士学位论文表4-3程序返回值规范

返回值 OP_TIMEOUT#REPORTER=XXX# OP_CALLBACK_ERROR#REPORTER=XXX# OP_PARAM_ERROR#REPORTER=XXX# OP_FAILED#REPORTER=XXX# 操作超时回调程序错误参数解析错误操作失败（有待进一步细分）意义其中：

 错误返回由发生错误的程序返回。

 在返回错误时请加上本程序的内部程序名，即将REPORTER=innername。返回值实际使用举例如下：

OP_CALLBACK_ERROR#REPORTER=cssc# 代表cssc程序执行回调程序发生错误。此时CA收到这个返回值可以检查指令中的CALLBACK项是否正确，或则提示管理员查看CS的CALLBACK程序是否完好。

4.2.5 统一命令行设计

现有监控系统中缺乏统一的命令行接口，应该为管理员或者网络高级用户提供统一的命令行接口，方便用户进行单一监控数据的提取和分析。命令行是一个独立的外壳程序类似于Linux操作系统的shell，它接收用户的命令和参数，调用相应的服务器上的监控插件进行数据收集，并将查询结果返回给当前用户。根据CAOS云平台的实际需求，作者对云资源监控系统命令行格式的设计如表4-4所示：

表4-4云资源监控系统命令行设计表

命令参数 -ip -a getCupInfo -n -t -p -u

参数说明用户要查询的服务器ip地址查询cpu的所有信息查询cpu的核数查询cpu的类型查询cpu的主频查询cpu的当前使用率 36

第四章云资源监控系统设计与实现表4-4云资源监控系统命令行设计表

-ip -a getMemInfo -f -u -s -ip -a getDiskInfo -name -s -ip -a getDiskIOInfo -m -w -r -ip -a getNetIOInfo -n -w -r -name -ip -a getSysInfo -max -s -b

用户要查询的服务器ip地址查询memory的所有信息查询memory剩余空间大小查询memory使用率查询memory总的大小用户要查询的服务器ip地址查询硬盘的所有信息查询指定盘符下硬盘剩余空间大小查询硬盘总的大小用户要查询的服务器ip地址查询硬盘IO的所有信息查询硬盘最大的IO速度查询硬盘写入速度查询硬盘读出速度用户要查询的服务器ip地址查询网络IO的所有信息查询网卡数量查询所有网卡的上传速度查询所有网卡的下载速度查询指定网卡的所有信息用户要查询的服务器ip地址查询服务器的所有信息查询服务器的MAC地址查询操作系统类型查询系统是物理机还是虚拟机 4.3.6 数据库设计

在CAOS云平台中资源监控系统中使用了两种类型的数据库系统，分别为MySQL-Cluster数据库集群和SQLite数据库。

为了兼容云平台其他模块的数据存储需求，云资源监控系统中监控端（CS）将CW上报的监控信息存入MySQL-Cluster数据库中。MySQL-Cluster[34,35]允许在无共享体系结构的系统中部署基于内存的数据库集群，该集群对服务器的性能以

电子科技大学硕士学位论文

及软硬件无特殊要求，每个组件都有内存和存储设备，因此可以避免单点失效保证数据的安全性。同时MySQL-Cluster采用NDB存储引擎，NDB引擎包含完整的数据集可以进行负载均衡选项配置以及多种故障切换，存储数据具有高可用性和一致性。

在虚拟机以及各种软终端上安装的被监控组件CW将定时收集的监控信息存入SQLite数据库中。SQLite数据库[36]是遵守ACID的轻量级关系型数据库系统，它占用的系统资源少，非常适合在嵌入式设备中安装使用。在实际的开发过程中，考虑到虚拟机以及各种ARM终端设备的性能差异很大，因此在虚拟机和终端设备中使用SQLite数据库存储监控数据，尽最大可能降低监控系统对整个系统的干扰程度。

被监控端（CW）SQLite数据库的名字为MonitorInfo，按照信息改变频率数据库中的信息分为：动态信息和静态信息，分别存储在动态信息表（autoInfo）和静态信息表（staticInfo）中。

监控端CS中MySQL-Cluster 数据库的名字为cs。CS端数据库主要提供仿生自主神经系统（BANS）中枢神经信息记忆功能。数据库表ph_list记录宿主物理机（PH）的部署信息；表ph_history记录宿主物理机（PH）汇报的历史监控信息，其中每个宿主机保留最新最近的一条监控信息；表vm_list记录寄主虚拟机（VM）所在的宿主机的情况以及寄主虚拟机最新最近的一条监控信息。表node_abnormal记录宿主机和寄主机的报警信息。表ph_history和表vm_list为了后期统计信息的扩展，CPU、内存、网络和硬盘四个字段采用组合形式表示。表TermInfo由于记录终端或者组件注册信息。

1）Ph_list表结构说明如表4-5所示：

表4-5 Ph_list表结构

字段 id Ph_id Ph_ip Ph_mac state service 类型 int int Varchar(16) Varchar(20) Varchar(8) Varchar(32) 备注主键，自增字段物理机ID 物理机IP地址物理机MAC地址物理机开机状态物理机提供的服务 2）Ph_history表结构如表4-6所示：

第四章云资源监控系统设计与实现

表4-6 Ph_history表结构

字段 id Ph_id cupinfos meminfos diskinfos netinfos time 类型 Int int Varchar（64） Varchar(16) Varchar(128) Varchar(128) datatime 备注主键、自增字段外键、物理机ID Cpu组合信息内存组合信息硬盘组合信息网络组合信息监控信息记录时间 3）vm_list表结构如表4-7所示：

表4-7 vm_list表结构

字段 id Vm_id Vm_ip Vm_mac state Ph_id cupinfos meminfos diskinfos netinfos time services 类型 int int Varchar(16) Varchar(20) Varchar(8) int Varchar(64) Varchar(16) Varchar(128) Varhcar(128) datatime Varchar(128) 备注主键、自增字段虚拟机ID 虚拟机IP地址虚拟机MAC地址虚拟机开机状态外键、宿主物理机ID Cpu组合信息内存组合信息硬盘组合信息网络组合信息监控信息记录时间虚拟机提供的服务 4）autoInfo表的结构如表4-8所示：

表4-8 autoInfo表结构

字段 id Ip_id Cpu_used_per Mem_free Mem_used_per Disk_used_per Disk_free Disk_write_io Disk_read_io Net_recv_io

类型 int Varchar(16) Varchar(10) Varchar(10) Varchar(10) Varchar(8) Varchar(10) Varchar(8) Varchar(8) Varchar(8) 39

备注自增字段 IP地址当前cpu使用频率当前内存剩余量当前内存使用百分比磁盘使用百分比磁盘剩余量当前磁盘写速度当前磁盘读速度当前网卡下载平均速度电子科技大学硕士学位论文表4-8 autoInfo表结构

Net_send_io time

Varchar(8) datatime 当前网卡上传平均速度监控信息记录时间

5）staticInfo表结构如表4-9所示：

表4-9 staticInfo表结构

字段 id Vm_ph Mac_id Os_type Cpu_type Cpu_cores Cpu_freq mem disk Disk_detail Net_type Net_cores 类型 int Varchar(5) Varchar(20) Varchar(10) Varchar(10) int float float float Varchar(10) Varchar（10） int 备注自增字段，主键物理机虚拟机标志位 Mac地址操作系统类型 Cpu类型 Cpu核数 Cpu主频内存大小硬盘大小硬盘分区情况网卡类型网卡数量 6）Node_abnormal表结构如表4-10所示：

表4-10 node_abnormal表结构

字段 id Cpu_alarm Mem_alarm Disk_alarm Ip Node_type time Is_read type 类型 Int Boolean Boolean Boolean Varchar(16) Varchar(4) Datatime Boolean Varchar(32) 备注主键、自增字段 Cpu报警内存报警硬盘报警报警机IP地址判断是物理机还是虚拟机报警记录时间报警信息是否已读报警信息描述 7）TermInfo表结构如表4-11所示：

第四章云资源监控系统设计与实现

表4-11 TermInfo表结构

字段 id name ip mac location flag type 类型 int Varchar(20) Varchar(16) Varchar(20) Varchar(64) boolean Varchar(16) 备注主键、自增字段设备或组件名字组件所在服务器IP地址组件所在服务器MAC地址组件所在服务器位置区分组件或设备组件类型 4.3 详细设计与实现

4.3.1 数据采集器的设计与实现

数据采集器（CW）运行在被监控端，根据云资源监控器下发的指令在被监控端完成相应的任务。根据实际的需求，在CAOS云平台中CW主要实现对物理服务器、虚拟机和RAM软终端的资源监控；由于操作系统的不同，CW的实现主要有windows端CW和Linux端CW，这两种平台的CW设计和实现相同。数据采集器（CW）的设计架构分为三个层次，逻辑结构如图4-8如下：

Contoller Layer指令处理任务分配信息整合通信模块插件管理告警模块监控器模块数据库模块Plugin LayerCPUPluginMemoryPluginDiskPluginNetPluginSystemPluginProcessPluginServicePluginBasic Library LayerLinux CommandWindows APIOthers

图4-8 CW逻辑结构图

其中：

 Controller Layer 负责接收云资源监控器（CS）的命令，通过对命令的解析分发给不同的模块去完成任务，并将执行结果返回CS端。

 Plugin Layer 插件模式具有动态伸缩性，可以动态加载和卸载。根据CAOS

电子科技大学硕士学位论文

的实际需求，对各个数据采集使用插件形式完成，同时用户可以根据实际需求自定义插件完成监控任务。

 Basic Library Layer 插件使用操作系统平台的本地库或者命令，完成数据收集工作。

1.数据采集器（CW）主进程

数据采集器（CW）的实现采用多进程的编程方式。主进程（cwinfo）常驻内存中，接收CS端的命令，接收到CS端的指令后通过命令处理模块（CommHandler）进行处理，然后将处理后的命令以参数（struct Command）的形式发送给任务分配（TaskDispacher）模块，任务分配模块采用popen的方式调用相应的模块完成任务，并等待结果返回。CW主进程程序流程如图4-9所示：

开始初始化创建子进程配置文件子进程主进程告警子进程监控子进程否计时器到时否监听数据端口41000CS指令下发是指令合法是指令处理任务分配否反馈CS是创建子线程日志查询数据库操作信息采集插件管理信息收集数据整合通信模块

图4-9 CW主进程程序流程图

第四章云资源监控系统设计与实现

CW主进程程序流程描述如下：

1) CW主程序Cwinfo启动，完成初始化工作。

2) CW创建子进程配置文件子进程（Config）、监控子进程（Monitor）、告警子进程（Alarm)

3) Cwinfo进程监听41000端口，等待CS下发指令。

4) 判断CS指令是否到达。如果到达进入步骤六；反之进入下一步。 5) 判断计时器是否到时。如果到时进入步骤七；反之返回步骤三。 6) CS指令校验，校验成功进入下一步；反之进入步骤三

7) 对CS指令根据通信协议约定进行预处理或者对计时器到时发出的信息收集指令进行处理，填充指令结构体参数Command传递给任务分配模块。 8) 任务分配模块根据指令参数采用popen技术，调用相应的服务子程序完成任务。

9) 服务子程序任务完成后，将数据传递给数据整合模块 10) 数据整合后传递给通信模块，CW将处理结果反馈CS 11) Cwinfo主进程进入下一次循环，返回步骤二。 2.数据采集器（CW）配置文件子进程（config）

配置文件子进程监听控制端口41001，当系统管理员或者用户修改监控配置文件后，云资源监控器CS向该端口传输数据，CW根据传输的数据修改本地监控策略。Config进程程序流程如图4-10所示：

开始监控控制端口41001否数据到达是翻译控制信息更新配置文件返回

图4-10 config进程程序流程图

电子科技大学硕士学位论文

Config进程程序程序流程描述如下：

1) Config 进程启动，监控41001端口

2) 判断控制信息是否到达，到达进入下一步；反之进入步骤一 3) 对控制信息进行解析和翻译。

4) 根据解析后的信息更新本地监控策略。 5）Config 进程进入下一次循环，返回步骤一。 3.数据采集器（CW）监控子进程（Monitor）

监控子进程由主进程创建，在该进程中设置一个定时器定时检测告警进程和配置文件子进程的存活状态。当发现其中某一个子进程死掉后，就会重新启动该进程。Monitor进程程序流程如图4-11如下：

开始初始化首次检测否是计时器到时配置文件进程检测是告警进程检测否启动配置文件进程否启动告警进程返回

图4-11 Monitor进程程序流程图

Monitor进程程序程序流程描述如下：

1) Monitor 进程启动，完成初始化工作。

2) 判断Monitor进程是否为首次启动。如果是则设置首次启动标志位(firstStart=false)进入步骤四；反之进入下一步。

第四章云资源监控系统设计与实现

3) 判断计时器是否到时。如果是进入下一步；反之进入步骤一

4) 检测配置文件子进程是否存在。如果该进程不存在进入下一步；反之进入步骤六。

5) 启动配置文件子进程。

6) 检测告警子进程是否存在。如果不存在进入下一步；反之进入步骤八 7) 启动告警子进程。

8) Monitor 进程进入下一次循环，返回步骤一。 4.数据采集器（CW）报警子进程（Alarm）

告警子进程利用插件定时收集服务器的系统信息、分析系统当前的运行状态，并将收集的监控信息存入数据库中方便用户进行日志分析；同时利用配置文件中设置的系统性能判断标准对系统当前的状态进行故障等级评定，如果系统出现故障则向CS进行报警。Alarm报警子进程程序流程如图4-12所示：

开始读取配置文件定时器到时信息收集数据库操作故障等级分析否否故障信息整合通信模块报警返回

图4-12 Alarm报警进程程序流程图

Alarm进程程序程序流程描述如下：

1) Alarm进程启动，读取配置文件信息。

电子科技大学硕士学位论文

2) 判断定时器是否到时。如果是进入下一步；反之进入步骤一。 3) Alarm进程和插件管理模块进行通信，利用插件服务子程序完成信息收集工作。

4) 收集的监控信息存入sqlite数据库。

5) 根据配置信息，利用多值决策图对监控数据进行故障等级判定。 6) 判断系统当前运行状态是否故障如果故障进入下一步；反之进入步骤一。 7) 将监控信息进行整合。

8) 整合后的监控数据传递给通信模块 9) CW向CS报警。

10) Alarm进程进入下一次循环，返回步骤一。

4.3.2 资源监控器的设计与实现

云资源监控器（CS）是云监控系统的核心部分。它负责接收CA系统管理员的监控指令，将指令按着通信协议进行封装下发给被监控端（CW），同时接收CW反馈的监控信息或者报警信息。

CS的实现采用多进程编程模型。其进程关系如图4-13所示：

CSCSSCAlarmReg_boxGet_ET

图4-13 CS进程关系图

其中：

 CS进程为云资源监控器的核心进程，常驻内存。它是云资源监控系统的信息转发中心，主要负责监控系统内部信息的收集、整理、转发工作。  CSSC子进程由CS进程派生，常驻内存。它主要负责在局域网内广播配置信息与实时信息，正是由于该进程的存在实现了被监控端（CW）无需配置本地监控策略，大大减轻了系统管理人员和用户的工作同时简化了系统的部署。  Alarm子进程由CS进程派生，常驻内存。它是云资源监控系统的报警中心核心进程，主要负责监控系统中各种报警工作。

 Reg_box子进程由CS进程派生，常驻内存。它是云资源监控系统中各种

第四章云资源监控系统设计与实现

软终端、监控实体的终端注册程序，负责被监控终端和监控组件的登记和注册。  Get_ET子进程由CS进程派生，非常驻内存之中。它是资源监控部分的核心程序，主要负责各种状态查询指令的翻译和下发以及监控数据的收集和整理工作。

云资源监控器是监控系统的核心部分，需要和CA和CW两个部件进行内部通信。在云资源监控器中使用的端口如表4-12所示：

表4-12云资源监控器端口表

内网端口 40000 41001 41002 41003 41004 41000 41010 备注 CA和CS通信端口提供CA查看和修改配置文件服务终端注册端口 CW的UDP数据端口提供CW配置文件自动更新服务终端报警端口 CW的TCP监控端口其中：

 CS和CW的监控数据传输采用UDP和TCP双通道。当用户长时间内接收不到监控数据时，可以采用TCP通道进行数据查询，因此在CW端开设41010端口用于TCP数据传输

 内部端口41001端口提供给CA查看和修改配置文件服务。当CA修改配置文件改变监控策略后，通过41001端口向CS发送指令，CS接收到指令后通过CSSC进程进行广播。内部端口41001端口用于终端配置自动化服务。当CW第一次安装启动后，主动向CS发送广播，寻找CS下载最新的配置文件。 1.云资源监控器(CS)主进程

云资源监控器（CS）主进程流程如图4-14所示：

电子科技大学硕士学位论文

开始初始化创建子进程CSSC进程Alarm进程主进程CSReg_box侦听端口监听41003端口否否监听40000端口计时器到时CW数据到达是重置计时器CA指令到达是指令合法否否反馈CA数据库操作是是指令预处理调用相关子程序调用成功是调用超时否获取子程序输出（popen）是是否进一步处理数据整理处理成功否通信模块

图4-14 CS主程序流程图

第四章云资源监控系统设计与实现

CS监控器主进程程序流程描述如下：

1) 云资源监控器（CS）被安装成功启动后，首先完成线程池的初始化工作，当被控终端CW下载配置文件时，该线程池用来接收CW的链接，并行完成任务。

2) 初始化工作完成后，CS创建子进程CSSC。CSSC子进程监听41001端口，当页面修改配置文件时，在局域网内广播数据包。同时创建Alarm进程、Reg_box进程。

3) 主进程CS在内网端口40000侦听，等待CA页面发送指令同时在41003端口接CW上报的监控信息。

4) 判断CW监控信息是否到达。如果到达进入下一步，否则进入步骤七 5) 重置计时器，忽略带有相同时间戳的UDP数据包。 6) 根据CW的监控信息中服务器的IP地址，更新数据库。

7) 判断计时器是否超时如果没有超时返回步骤三；否则进入步骤步骤十一 8) 判断CA指令是否到达。如果到达进入下一步；反之返回步骤三 9) 判断CA指令是否合法。如果指令非法返回步骤三，如果指令合法进入下一步。

10) 通过内部约定的通信协议，对合法的CA指令进行预处理。

11) 根据翻译后的指令或者CS主进程在计时器超时发送的拉数据指令，主进程采popen技术调用相应的服务子程序。

12) 判断服务子程序调用是否成功。如果成功进入下一步，否则返回第三步。 13) 判断服务子程序调用是否超时。如果超时则根据命令的需求进一步进行处理，如果处理成功进入步骤十五；否则返回步骤三。

14) 服务子程序调用未超时，通过管道接收服务子程序的输出。

15) 根据内部通信协议约定，对服务子程序或者进一步处理的结果进行整合。 16) 将整合后的数据以参数的形式发送给通信模块。 17) 通信模块将数据反馈给CA页面。 18) 主程序进入下一次循环，返回步骤三。 2.云资源监控器（CS）报警子进程（Alarm）

报警子进程（Alarm）由CS主进程创建，常驻内存之中负责接收终端设备的报警信息。Alarm进程接收到报警信息后将数据存入Node_abnormal报警表中，同时向CA页面发送报警通知，通知系统管理员或者用户及时处理错误。Alarm进程程序流程如图4-15所示：

电子科技大学硕士学位论文

开始初始化监听41000端口告警信息到达是信息处理CA告警数据库操作

图4-15 Alarm进程流程图

Alarm进程程序流程描述如下：

1) Alarm进程被启动，完成初始化工作。 2) Alarm进程监听41000端口，等待终端报警。

3) 判断终端报警信息是否到达。如果到达进入下一步；反之返回步骤二 4) 对报警信息进行进一步处理。 5) 向CA页面发送告警信息。

6) 报警信息存入数据库Node_abnormal表 7) Alarm进程进入下一次循环，返回步骤二

云平台的配置文件自动化部署、终端注册设计与实现，分别在4.3.3配置文件自动化部署的设计与实现、4.3.4终端注册设计与实现中详细描述。

4.3.3 配置文件自动化设计与实现

随着云平台规模的扩大以及被监控端CW功能的增加，其配置项目越来越多，

这给系统管理人员和带来诸多不便同时浪费大量的精力和时间比如：系统管理员为了修改一个阀值，不得不去每个被监控端修改配置文件等等。为了简化配置管理、减轻安装人员的负担，CW配置文件进行集中管理。被监控端CW在安装时完全不需要配置文件配置本地监控策略，CW在安装完成后首次启动时会自动寻找

第四章云资源监控系统设计与实现

CS地址下载配置文件。 1.配置文件自动化通信流程

被监控端CW安装并启动后，CW发送UDP广播请求CS地址信息，被监控端CSSC配置文件子进程接收到CW的广播消息后，对该消息立即做出相应；如果被监控端CW连续发送3次UDP消息包，仍然没有接受到被监控端CS发回的相应消息则CW自动结束；如果被监控端CW接受到相应消息则CW将本地配置文件的MD5值发送给CS，CS根据CW发送的MD5值判断CW是否需要下载配置文件。配置文件下载完成后，被监控端CW向CS发送配置文件下载状态，CS将本次配置文件下载状态存入数据库中。

配置文件自动化过程中，CW和CS通信流程图如图4-16所示：

CW启动发送广播寻找CS否接收中心信息重试超过3次是结束否接收成功是建立TCP连接下载配置文件回发下载状态执行其他任务接收连接交付子进程通信完成拆除连接状态记录UDP reply发送配置信息CS配置文件管理中心UDPCS子进程监听TCPTCP DATAUDP reply

图4-16 CW和CS通信流程图

2.配置文件自动化程序实现

云资源监控器（CS）端CSSC进程是CS的服务子进程，负责局域网内广播配置信息以及接受被监控端CW请求配置文件下载UDP广播消息。CSSC子进程程序流程如图4-17所示，

电子科技大学硕士学位论文

开始初始化侦听端口监听41001端口监听41004端口否CA指令到达是CW下载是下载指令校验是等待下载否否否指令校验是局域网广播否广播次数<3是返回空闲线程否线程数图4-17 CSSC子广播子进程程序流程图

CSSC子进程监听端口有两个分别为:41001和41004，采用异步IO技术select实现。端口41001用于监听CA对配置文件的修改指令，其流程描述如下：

第四章云资源监控系统设计与实现

1) CSSC进程启动，完成初始化工作。

2) CSSC进程侦听41001端口，接收CA系统管理员指令。 3) CA指令到达进入下一步，反之返回步骤二。

4) CA指令校验，校验成功进入下一步；反之返回步骤二。 5) CSSC进程在局域网内广播配置信息，并计数广播次数。

6) 判断广播次数是否大于3，如果大于进入下一步；反之返回步骤五 7) CSSC进入下次循环，返回步骤二。

端口41004用于侦听CW下载配置文件指令，CW第一次启动后首先发送广播自动发现CS的位置，下载配置文件信息。其流程描述如下：

1) CSSC进程侦听41004端口，等待CW下载指令 2) CW下载指令到达进入下一步；反之返回步骤一

3) CW下载指令校验，校验成功进入下一步；反之返回步骤一 4) CW排队等待下载。

5) 判断线程池是否有空闲线程，如果有进入下一步；反之进入步骤七 6) 空闲线程被占用，标志位设置为Busy状态。空闲线程和CW进行通信，传输配文件。

7) 线程池总线程数是否大于设置的MAX值，如果小于进入下一步；反之进入步骤九。

8) 创建新线程加入线程池，用于配置文件传输。

9) 线程池中并无空闲线程并且MAX值大于预期设置值，CW下载需要等待，进入步骤四。

10) 判断CW配置文件是否完成。如果完成进入下一步；反之进入步骤六。 11) 空闲线程拆除连接并修改标志位为空闲Idle状态，返回线程池。

12) CSSC进程进入下一次循环中，返回步骤一。

4.3.4 终端注册设计与实现

终端注册进程（Reg_box)由主进程CS派生，常驻内存之中负责软终端和监控组件的登记和注册功能。Reg_box接收到被监控端或者监控组件的注册信息后，将信息进行整合存入数据库终端表TermInfo。Reg_box进程程序流程如图4-18所示：

电子科技大学硕士学位论文

开始数据库操作初始化组件是否存在是是监听41002端口否等待下载指令到达是指令处理否线程空闲是下载组件否否线程数>MAX否创建线程任务分配下载完成是终端注册监控组件注册监控组件下载拆除连接线程标记空闲数据库操作反馈CA返回

图4-18 Reg_box进程程序流程

终端注册进程（Reg_box)程序流程描述如下：

1) Reg_box进程启动，完成初始化任务。 2) 进程监听41002端口，等待指令到达。

3) 判断指令是否到达。如果到达进入下一步；否则返回步骤二。 4) 指令预处理。

5) 根据指令的内容，进行任务分配。

6) 终端注册或者组件组成任务，进入下一步；否则进入步骤八 7) 数据库操作，将注册信息写入termInfo表。 8) 数据库操作，查询组件信息以及存储位置。

9) 判断组件是否存在。如果存在进入下一步；否则进入步骤十七。 10) 加入任务队列，等待下载。

11) 判断线程池是否有空闲线程。如果没有进入下一步；否则进入步骤十三。

第四章云资源监控系统设计与实现

12) 创建新线程，加入线程池，设置线程空闲标志位为busy。 13) 组件传输，将组件下载给需要的被监控端。

14) 判断下载是否完成。如果完成进入下一步；否则返回步骤十三。 15) 拆除连接，回收资源。 16) 设置线程标志位为Idle。 17) 反馈CA页面

18) Reg_box进程进入下一次循环，返回步骤二。

4.2.5 插件管理设计与实现

被监控端CW采用插件模式对云计算平台中的各个监控实体进行监控。插件可以在需要的时候动态加载，当使用完成后根据系统资源使用情况可以动态的卸载，具有动态扩展性。插件通过调用第三方库或者本地库对被监控系统进行信息采集，控制其运行状态，实现动态配置，同时用户可以自定义插件，完成特定任务的监控需求。

系统管理员或者用户可以通过CA页面下发监控指令，CS接收监控指令后根据通信协议进行封装通过网络传送给被监控组件CW。CW接收监控信息进行预处理、任务分配，通过插件管理模块进行插件检测、插件下载、信息收集，将信息收集进行整合反馈CS，CS接收到反馈信息上报CA页面。插件管理程序流程如图4-19所示：

开始初始化指令处理插件检测是调用插件（popen）信息收集信息返回（popen输出）否通信模块下载插件下载完成是反馈CS拆除连接结束

图4-19 插件管理程序流程图

电子科技大学硕士学位论文

插件管理程序流程描述如下：

1) 管理程序（pluginManager）完成初始化工作。 2) 对任务分配指令进行处理。

3) 插件检测判断插件是否存在。如果不存在进入下一步；否则进入步骤九 4) 和CS终端注册模块进行通信。 5) 下载插件

6) 判断插件下载是否完成。完成进入下一步，否则返回步骤四 7) 反馈CS，插件下载完成。 8) 拆除连接，资源回收。

9) Popen创建子进程和管道调用插件收集信息。 10) 信息收集

11) 接收popen输出，完成信息收集工作 12) 结束

在插件管理模块的实现过程中，采用动态类加载技术实现插件的高可扩展性。在系统的运行过程中，用户可以按照标准格式自定义插件完成新的监控功能。在该功能实现过程中定义了5个类。分别描述如下：

 设计CWServer类封装C类动态加载函数dlopen,dlsys,dlerror 等linux动态链接库函数；它维护CWBase类的实例视图同时提供插件动态加载函数(Load)，动态卸载函数unload 等函数来管理这些实例对象。

 设计CWBase抽象接口类，它是所有插件实现类的父类。它定义了插件的公共操作函数比如：插件运行(run)、停止(stop)、收集信息(getMessage)、发送消息(sendMessage)等函数。这些函数被定义为纯虚函数，所有具体插件类必须实现该类。

 设计模板类CWBaseDaemo，该模块类是对CWBase的通用实现。  设计CWInfo以及子类，定义数据结构和监控变量，并定义对数据的操作函数

 设计CWInfoMonitor以及子类，用CWBaseDaemo以及CWInfo实现，生成动态库比如：CWInfoCPUMonitor.so

如果用户新增资源监控模块，只需要定义子类继承CWInfo和CWInfoMonitor生成动态链接库，同时将该链接库放入相应的目录下向终端注册模块进行监控组件注册即可。当被监控端CW自检发现本地缺少监控插件时，插件管理向CS终端注册端口41002发送消息进行插件下载。

第四章云资源监控系统设计与实现

4.4 本章小结

本章主要介绍了云资源监控系统的设计和实现。首先对云资源监控系统进行需求分析；然后根据需求分析结果对云资源监控系统进行总体设计包括总体架构设计、通信架构设计、通信协议设计、统一命令行以及数据库的设计；最后对云资源监控系统进行详细设计和实现。

电子科技大学硕士学位论文

第五章云资源监控系统测试与结果分析

5.1 测试环境设置

在当前情况下，实验室由于硬件设备有限无法组建大规模云计算数据中心。此次云资源监控系统测试环境由2台刀片服务器以及运行在刀片服务器上的KVM虚拟机组成，云资源监控器（CS）安装在其中一台刀片服务器上，其他物理机和虚拟机中安装数据采集器CW。测试机器配置如表5-1所示：

表5-1 测试机器配置表

虚拟机刀片服务器设备配置信息操作系统：Debian 6.0.5 CPU: Intel(R) Xeon E3-1240 v2 3.40GHz 5路4核内存: 32G 硬盘: SATA 1T x 3 硬盘: SSD 512G x 1 千兆网卡 x 3 电源模块 x 2 操作系统：Windows 7，XP，2003，2008 CPU：双核内存：1G 硬盘：100G 5 2 数量 5.2 云资源监控系统功能测试与结果分析 5.2.1 云资源监控系统服务启动测试

在云平台中，云资源监控器（CS）运行在Linux服务器上。为了简化部署过程，CS使用Shell脚本从服务器上下载并启动。

数据采集器（CW）根据监控平台的不同分为三个版本：Linux版本、windows版本以及ARM版本。Linux版本和ARM版本CW使用Shell脚本从服务器上下载并启动；Windows版本CW已经被制作成安装包，可以采用图形化的界面安装并启动相应的监控服务。

1.云资源监控器（CS）启动流程

1）运行update脚本，从服务器上下载云资源监控器（CS）并安装。

第五章云资源监控系统测试与结果分析

2）根据提示输入y，确认安装(提示install cs ... Ok 代表cs安装成功，否则，安装失败。）如图5-1所示：

图5-1 CS安装

3）将云资源监控器启动脚本cs拷贝到/etc/init.d/目录下，同时在rc.local中添加 /etc/init.d/cs start & 命令。

4）在Linux命令行中启动云资源监控器。命令为：/etc/init.d/cs start & 5）检查云资源监控器（CS）进程启动情况。在Linux命令中运行pstree命令查看进程树，如果正确启动CS则存在红色标注的进程；反之启动失败。如图5-2所示：

图5-2 CS启动进程树

6）检查CS监听端口启动情况。在Linux命令行中使用netstat命令查看CS端口启动。如图5-3所示：

图5-3 CS启动端口

电子科技大学硕士学位论文

2.Windows端数据采集器（CW）启动流程

1）CW的安装是作为Cloud Additions for Windows .msi的一个组件安装的。 2）安装Cloud Additions for Windows .msi后，在“开始”---->“程序”----->

“Cloud Additions for Windows ”。如图5-4所示：

图5-4 CW安装组件

3）选中“Cwinfo配置”选项卡，点击“安装服务”按钮即可。如图5-5所示：

图5-5 CW安装

4）检查CW服务启动。安装完CW后，系统服务中会添加cwinfo服务，启动

类型为“自动”。在开始--->运行--->services.msc----->确定，可查看cwinfo是否已启动。如图5-6所示：

图5-6 CW服务检查

第五章云资源监控系统测试与结果分析

3.Linux端和RAM端数据采集器（CW）启动流程

1）使用update脚本将CW安装包从服务器下载到本地并安装。 2）点击y，确认安装。如图5-7所示：

图5-7 Linux CW安装

3）检测CW安装是否成功。如果安装后出现“install cw......ok”表示安装成功；否则安装失败。如图5-8所示：

图5-8 Linux CW安装

4）启动CW。启动命令是：Setsid /var/cloudos/cw/cwinfo &

5）在rc.local文件中添加开机自启动命令： /var/cloudos/cw/cwinfo & 如图5-9所示：

图5-9 添加开机命令

6）CW安装完毕后会自发现CS服务器，下载配置文件。进入/var/cloudos/cw目录查看cw.cnf配置文件是否存在，如果存在表示cwinfo启动成功；否则CW启动失败

7）检查端口启动情况。在Linux下使用netstat命令查看CW端口启动。如图5-10所示：

电子科技大学硕士学位论文

图5-10 Linux CW端口检测

5.2.2 监控系统页面管理及结果分析

云资源监控系统是CAOS云平台中的一部分。系统管理员或者用户查看物理机、虚拟机的运行状态，系统访问日志、运行日志以及报警信息，首先需要admin权限登入云平台。如图5-11所示：

图5-11 系统管理员登入页面

1.物理服务器监控

在本次测试环境设置（上节）中，使用2台刀片服务器构建云平台。云资源监控控制器CS安装在其中一台刀片服务器上，其IP地址为：172.20.12.6；另一台刀片服务器上安装数据采集器CW，其IP地址为：172.20.12.7。此刻系统运行状态如图5-12所示：

第五章云资源监控系统测试与结果分析

图5-12 172.20.12.6服务器运行状态图

在上图中可以清楚的看到两台刀片服务器的运行状态。作者在172.20.12.6服务器上使用top -a命令查看的服务器CPU和内存利用率如图5-13所示：

图5-13 172.20.12.6 CPU和内存利用率图

CPU利用率0.6% +1.1% = 1.7%，和监控值2.1%是大致吻合的。内存使用21.8G，空闲内存11G也是和监控值大致吻合的（在页面截图和Linux服务器后台截图存在操作时差，大约2s）。 2.虚拟服务器监控

在172.20.12.6台刀片服务器上开启3台KVM虚拟机，在172.20.12.7上开启1台KVM虚拟机。用户可以查询每台宿主物理服务器上虚拟机的运行状态，如图5-14所示：

图5-14 172.20.12.6 服务器上虚拟机运行状态图

电子科技大学硕士学位论文

系统管理员可以选择要查询的宿主机，如图5-14所示：

图5-14 物理机选择

172.20.12.7物理机上虚拟机运行状态如图5-15所示：

图5-15 172.20.12.7物理机上虚拟机运行状态图

作者选择172.20.12.6上第32号虚拟机(IP:172.20.250.122，操作系统：Windows 2003 server)进行监控结果分析，如图5-16所示：

图5-16 172.20.250.122 虚拟机

如下图5-17,5-18所示，此刻32号虚拟机的CPU利用率4%，物理内存大小为512M、可用数为308M。监控结果和虚拟机此刻运行状态基本是吻合的（截图操作存在时间间隔，大约2s）

第五章云资源监控系统测试与结果分析

图5-17 虚拟机CPU和内存利用率

图5-18 虚拟机内存和硬盘展示图

5.2.3 云资源监控系统数据管理展示

在云资源监控端（CS）安装MySQL-Cluster数据库，两台刀片服务器组成一个数据库集群。作者在PC机中利用Navicat工具进入MySQL-Cluster数据库，进行数据管理测试。CS数据库中表Ph_list用于记录宿主机信息，如图5-19所示：

图5-19 ph_list表数据

电子科技大学硕士学位论文

报警表node_abnormal用于记录报警信息如图5-20所示：

图5-20 node_abnormal 表数据

表ph_history记录宿主物理机监控信息汇总，如图5-21所示：

图5-21 ph_history 表数据

表vm_list用于记录寄主虚拟机监控信息汇总。如图5-22所示：

图5-22 vm_list表数据

数据采集器（CW）使用SQLite数据库存储数据，作者在172.20.12.6刀片服务器上将MonitorInfo数据库导出，利用SQLite Database browser工具进行数据管理测试。表autoInfo数据如图5-23所示：

第五章云资源监控系统测试与结果分析

图5-23 autoInfo表数据

表staticInfo数据如图5-24所示：

图5-24 staticInfo表数据

5.3 本章小结

本章主要介绍了云资源监控系统的测试过程以及对测试结果进行了分析。首先介绍了本次云资源监控测试的测试环境设置；然后对云资源监控系统进行功能测试包括服务启动、页面管理和数据库管理三个部分。在各个模块的功能测试过程中，作者通过后台进入虚拟机系统进行观测并截图进行测试结果对比和分析，验证云资源监控系统监控数据的可靠性。

电子科技大学硕士学位论文

第六章总结与展望

6.1 总结

本文通过对云计算体系结构和云资源监控系统结构的研究，分析了设计云资源监控系统时所涉及的关键性问题。根据实际使用和开发情况，本文着重从云资源监控系统的扩展性、故障报警和监控数据处理三方面进行了深入分析并提出了解决思路。本文的研究成果主要包含以下几个方面：

1) 采用仿生自主神经系统的思想，设计并实现了云资源监控系统。该系统应用在协同自主计算实验室CAOS云平台中，改善了云平台的监控性能。

2) 采用系统动态加载技术解决了云资源监控系统的扩展性问题。系统管理员和用户可以根据实际需求自定义监控插件，放入系统指定的目录下，监控系统使用动态加载技术自动加载插件，完成监控功能。

3)通过对多状态系统和多值决策图的研究，作者利用多值决策图完成云资源监控系统的故障检测和报警功能。

4) 此次云资源监控系统实现了配置文件自动化部署以及为网络高级用户提供了命令行界面，方便系统管理员对云资源监控系统进行部署、管理和使用。

6.2 展望

随着信息化社会的发展和云计算技术的成熟，人们对信息服务的要求越来越多同时也越来越高。为了满足人们的需求，更多的软硬件资源和服务被加入到云平台中来，随之而来的就是云资源监控系统的复杂度更高、管理难度更大。此次虽然完成了云资源监控系统的设计和开发工作，但由于对云计算平台的认识、代码能力以及硬件资源有限等原因，该系统还存在不足和有待改善的地方。本人下一步的开展工作主要表现在以下几个方面：

1）对监控预测模型进行研究。现有监控系统往往发现系统故障时，才向系统管理员或者用户报警，具有滞后性。云资源监控系统应该根据历史监控数据，对云平台资源的使用情况进行预测，对系统可能出现的故障提前感知。

2）配置文件实现差异化。在云计算平台中，充斥在其中的服务器存在性能差异，同时终端用户的使用的云服务也是不同的，因此对云平台中的服务器分集群监控比如：在云平台中，对运行CPU密集型任务的服务器进行监控时，配置文件的配置项需要详细的配置CPU指标，而粗略配置内存监控或者不需要配置。

致谢

首先我要感谢我的导师，***教授。在这三年的学生生涯中，向老师的细心教导使我完成了学业。向老师宽广的胸襟、敏锐的思维、丰富的知识、严谨的科学态度以及诲人不倦的使者风范使我终身受用。在这里，再次向我的导师向艳萍教授表示衷心的感谢。

其次感谢实验室的一帮哥们。在这三年里，我们互相学习、争论，在实验室的工程上一起努力，顺利的完成任务，渡过了三年美好的时光。如果没有你们的帮助，我的学业和论文也是无法完成的。

最后，我要感谢我的家人。父母为了我的学业，辛辛苦苦的工作，为了我付出了太多太多，谢谢你们的支持和信任。

电子科技大学硕士学位论文

参考文献

[1] 虚拟化与云计算小组著. 云计算宝典-技术与实践[M]. 北京：电子工业出版社，2012,4-12 [2] I.Foster,C.Kesselman. The Grid 2:Blueprint for a New Computing Infrastructure.Los

Alios:Morgan-Kaufmann,2003

[3] 雷万云. 云计算-技术、平台及应用案例[M]. 北京：清华大学出版社，2012, 7-11 [4] 百度百科. 云计算介绍[OL].http://baike.baidu.com/link?url=0j4Qj4Bbb0BCy3j0DKQ3b

ItchoBiKKquIiw2ePyl7eJISHUnzoJ3wBItNTLHeNEXC0zHD75yuTU2pNp9cSH5Ra [5] 张仲妹. 云计算环境下的资源监控应用研究[D]. 河北：北方工业大学，2013, 2-3 [6] 朱绍风. 网格环境下资源监控问题的研究[D]. 山东：山东师范大学, 2010

[7] B.Tierney, R.Aydt, D.Gunter, W.Smith, M.Swany, V.Taylor, and R.Wolski. A Grid Monitoring

Architecture.The Global Grid Forum Draft Recommendation(GWD-Perf-16-3),August 2002 [8] Monitoring and Discovery System(MDS). http://www.globus.org/toolkit/mds/[OL] [9] 维基百科. Ganglia. http://en.wikipedia.org/wiki/Ganglia_(software)[OL] [10] Nagios官网. http://www.nagios.org/about/overview/[OL]

[11] 张德丰. 云计算实战[M]. 北京：清华大学出版社，2012,20-24

[12] J.Brandt, A.Gentile, J.Mayo, P.Pebay, D.Roe, D.Thompson, and M.Wong. Resource monitoring

and management with OVIS to enable HPC in cloud computing.Proc. of the 23re IEEE International Parallel & Distributed Processing Symposium(5th Workshop on System Management Techniques,Processes,and Services), Rome, Italy. 2009

[13] 王萍，张际平. 云计算与网络学习[J]. 现代教育技术，2008, 18(11): 81-84

[14] P.Mell, T.Grance. The NIST Definition of Cloud Computing[R].Indianapolis,Indiana: Wiley

Publishing, 2009: 117-189

[15] 维基百科. 云计算[OL].http://zh.wikipedia.org/wiki/%E9%9B%B2%E7%AB%AF%E9%81

%8B%E7%AE%97

[16] 刘鹏. 云计算[M]. 电子工业出版社，2010

[17] G.Boss, P.Malladi, D.Quan, et al. Cloud computing[EB/OL]. IBM White Paper.

http://download.boulder.ibm.com/ibmdl/pub/software/dw/wes/Hipods/Cloud_computing_wp_final_8Oct.pdf. 2007

[18] 张和君，张跃. Linux动态链接机制研究及应用[J]. 计算机工程，2006, 11(22): 1-4 [19] 范勇，马梅，杨大鉴. 可扩展集群资源监控系统的设计与研究[J]. 计算机工程与应用，

2003, 26: 3-5

参考文献

[20] Aven, Terje. Reliability Evaluation of Multistate System with Multistate Components. IEEE

Transactions on Reliability, 1985, Vol.R-34(5): 473-479

[21] A.Shrestha, L.Xing. and D.W.Coit. An Efficient Multi-State Multi-Valued Decision

Diagram-Based Approach for Multi-State System Sensitivity analysis. IEEE Transactions on Reliability, 2010, Vol.59(3): 581-592

[22] Pearl J. Probabilistic Reasoning in Intelligent Systems:networks of plausible inference.Morgan

Kaufman, 1988

[23] L. Xing, J. B. Dugan. Dependability Analysis Using Multiple-Valued Decision Diagrams[C].

Proceedings of The 6th International Probabilistic Safety Assessment and Management, Puerto Rico, USA (PSAM6), June 2002

[24] M. Xie, Y. S. Dai, K. L. Poh. Computing Systems Reliability: Models and Analysis[M]. New

York: Kluwer Academic Publishers, 2004

[25] S.Zanikolas and R.Sakellariou. A taxonomy of Grid monitoring systems.Future Generation

Computer Systems, 2005, 21(1): 163-188

[26] R.Sundaresan, T.Kurc, M.Lauria, et al.Adaptive polling of grid resource monitors using a

slacker coherence model[C].In:Proceedings of the 12th IEEE International Symposium on High Performance Distributed Computing, 2003: 260-269

[27] R.Sundaresan, T.Kurc, M.Lauria, et al. A slacker coherence protocol for pull-based monitoring

of on-line data source[C].In:Proceedings of the 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid, 2003: 250-257

[28] 宋彩华. 云资源监控中数据传输模型研究[D]. 河南：郑州大学，2013, 18-20

[29] Michael Hinchey, Yuan-Shun Dai, James L.Rash, Walt Truszkowski, Madhusoodan. Bionic

autonomic nervous system and self-healing for NASA ANTS-like missions, 2007 ACM-11-59593-480-4 /07/0003

[30] Wei-Tek Tsai, Xin Sun and Janaka Balasooriya. Service-Oriented Cloud Computing

Architecture. ITNG Seventh International Conference on Information Technology. April 2010. [31] 苑文成，朱怡安，陆伟. 面向虚拟资源的云计算资源管理机制[J]. 西北工业大学学报，

2010, 28 (5): 34-39

[32] 张琪胜. 云计算平台监控系统的研究与应用[D]. 北京：北京交通大学，2011, 20-22 [33] 童端，董小社，李纪云，吴维刚. 基于WEB的远程集群监控系统的设计与实现[J]. 计算

机工程与应用，2003

[34] 维基百科. MySQL-Cluster介绍[OL].http://en.wikipedia.org/wiki/MySQL_Cluster [35] MySQL官网.MySQL-Cluster技术文档[OL]. http://dev.mysql.com/doc/refman/5.6/en/

电子科技大学硕士学位论文

mysql-cluster-installation.html

[36] 百度百科. SQLite数据库介绍[OL]. http://baike.baidu.com/link?url=KWW-lrSrYI7W

DL63qkENGPQwaTAOEWxs37QdE3ltHy0HpS5F845myA5QuA2Syt65

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文

全部栏目

云资源监控系统研究与实现