基于仿生学原理的云资源自主监控系统设计与实现

摘要：为了解决现有监控系统因主控节点功能太过集中而导致某些时刻网络流量过大、系统扩展性差和无法及时应对节点失效的问题，提出了一种基于仿生自主神经系统（BANS）的新型云资源监控系统。首先，系统中引入了多级存储、分批上报的机制，将需要上报的监控信息分批次分时段上传汇总，使得在任何单一时刻系统内不会产生过大的流量和负载，保证了系统的稳定性；其次，系统中加入了类动态主机配置协议（DHCP）的主动发现机制以及定期轮询策略，使得系统在处理新节点加入，节点故障问题时，获得了类似仿生自主神经系统一样的自组织、自修复能力。实验结果表明，基于BANS的云资源监控系统实现了自组织与自修复的功能，并且可以有效降低系统内的通信流量，某些单一时刻能将流量降低到仅有原来的三分之一。

关键词：

云计算；资源监控；仿生自主神经系统；云监控；自组织；自修复

中图分类号： TP391.8 文献标志码：A

0引言

近年来，社会信息化程度越来越高，尤其是云计算技术的普及和广泛应用，促使IT领域向集约化、规模化、复杂化的方向发展[1]。监控系统在保障大规模复杂系统正常运行方面起着至关重要的作用。现有的监控系统都是借鉴分布式计算和网格计算[2]的设计经验，并不适合对云服务平台进行监控。一方面云资源具有虚拟性，除了监控物理资源外还要监控具有寄宿关系的虚拟资源；另一方面云资源具有动态伸缩性，资源按需动态加入和退出，传统监控系统无法应对；第三方面云计算是一种新型的商业计算模型，用户按需使用并支付一定的费用，要求监控系统的监控粒度细化到进程[3]。传统的监控系统无法做到，为此需要根据云计算的特点设计适合云平台的监控系统。

目前，云监控系统大多采用UC Berkeley大学发起的分布式监控系统Ganglia[4]，其可用于监控数以千计的集群节点，为云平台提供系统的性能度量数据，层次结构的设计也使其具有了良好的扩展性[5]，但这套系统在实际使用中，仍存在缺点[6]。首先，系统中众多异常状况都会汇聚到主节点进行分析，再处理，且主节点需要记录系统所有的历史信息，这会让系统在异常处理与历史信息记录的时候产生大量的网络流量，使得系统在某些特定时刻具有较大的通信负载；其次，当系统有新节点加入时，需要配置多个文件，以决定诸如Web界面的访问权限、组播地址、节点轮询顺序配置等属性，过程十分重复繁琐，不利于系统硬件设施的更新与淘汰；最后，层次型的结构会使得中间层节点发生意外宕机时，部分子节点的状态信息会无法统计，只能被动地等待宕机节点重启后，方能重新开始统计，这样会导致监控系统无法及时地发出失效警告，甚至影响到系统状态统计的准确性。

针对以上问题，本文基于仿生学原理[7-9]，设计提出了一种基于仿生自主神经系统的云资源监控系统（Cloud Monitoring System based on Bionic autonomic nervous system， BCMS）。该系统在继承现有云监控系统占用资源少、高扩展性、支持高并发等特性的同时，设计了新的信息汇总与异常上报机制，且加入了自组织、自适应的特性，从而降低了网络通信负载，赋予了监控系统智能识别新节点、自修复的能力，使得监控系统在大规模、超大规模云环境下，更加易于扩展，且具有更高的可靠性。

1BCMS整体设计

BANS类似于生物学中的自主神经系统，是一种在无意识的状态下对动物的身体机能进行控制。比如，人的手指接触到热水会无意识地迅速收回等。除此之外，动物的心跳、呼吸系统、膝反射、血压和免疫系统等都由自主神经系统控制[7]。

通过模拟生物神经系统的组织构造，BANS赋予计算机系统类似的自主能力。BANS主要由神经突轴、神经元、周围神经以及中枢神经四层构成。BCMS具备5层架构，如图1所示。

第1层人机交互层（HumanMachine Interaction， HMI）是人机交互的窗口。类似中枢神经中有意识控制的部分。

第2层中枢神经（Central Nerve， CNE）类似中枢神经系统中的无意识控制部分，进行自主决策和部分通信。监控系统中枢CNE对下层上传数据进行分析，并进行决策处理，若无法处理时，则上传至交互层HMI，借助管理员进行最终决策。监控系统中枢CNE有自己的记忆单元CMDB，存储通过神经纤维传输的周围神经（Peripheral Nerve， PN）和神经元（Cyber Neuron， CN）的历史汇总信息和异常告警信息。监控系统中枢CNE只定期接收来至周围神经PN的历史汇总和异常，减少了网络通信量。

第3层PN代表宿主节点，其功能类似于周围神经，多个PN构成了周围神经系统（Peripheral Nerve System， PNS），每个独立的周围神经系统域内会选举出一个PN作为管理节点，记为MPN（Manage Peripheral Nerve），负责该周围神经系统内所有信息的收集，接受神经元CN的查询和传达高层CNE的指示，每个周围神经PN中运行数据采集器（Collector Worker， CW），用于收集本节点的监控数据。周围神经PN，也有自己的记忆单元PNDB（Peripheral Nerver DataBase），作为二级存储，存储周围神经PN自身的监控信息以及运行在该周围神经PN上的寄主神经元CN的历史汇总信息。当历史信息容量到达某一设定值，或接收到中枢神经CNE指令的时候，PN会上报历史信息汇总到CNE。另外，该层的存在，有分治的思想，系统故障的预诊断处理由该层负责，而最终的决策交给中枢CNE。

第4层CN，寄宿在节点之上的虚拟机（Virtual Machine， VM）类似于神经元，VM模块具备数据传输和基础数据分析的功能。每个神经元VM都隶属于某个周围神经PN。神经元VM通过下层神经突轴（Cyber Axon， CA）进行监控数据采集，并对采集信息进行分析、处理和汇总，完成和宿主PH的交互通信。VM具备有限的记忆单元VMDB（Virtual Machine DataBase），作为三级存储，存储历史汇总或异常信息，随后定期上报给上层节点，减少了网络通信负载。

第5层CA，其主要功能为感知和反射，它负责收集监控信息并执行上层下发的命令。CW类似神经突轴，CW包含各个插件，每个插件都完成某项采集任务，如CPU、Memory、Disk和NetIO。CW对监控信息进行搜集；同时可以接收上层下传的指令，执行相应的动作，如改变收集频率或预警阈值等。

2BCMS关键特性设计

2.1自组织

考虑到云平台内资源的动态增加和减少，对于小规模的集群这些资源的改变通过手动去改动配置是可行的；但是对于大规模的集群，靠手工去更改配置，将极大地降低管理员的工作效率，因此BCMS引入了一种机制去自动感知资源的动态增加和减少。受局域网的动态主机配置协议（Dynamic Host Configuration Protocol， DHCP）启发，在BCMS中设计了一种动态发现资源机制[10]。模仿DHCP网络协议，中枢神经CNE就是DHCP服务器。网络环境中新增的节点被视为新增的资源，以PN的身份加入到整体系统中，PN通过组播的机制向CNE获取监控中心节点的IP、自身资源类型、宿主关系等初始化信息。当然也可以像设置静态IP一样，手动地去添加这些信息，这样一来就增加了灵活性。对于资源的退出，监控中心节点通过心跳机制来感觉。当资源加入到云平台中后，资源就会以一定的频率去组播自己的心跳信息，当监控中心节点在一定的超时时间内无法检测到心跳信息，将自动从数据库中删除该资源的记录。

2.2自修复

自主监控系统在运行过程中，针对故障的特点，采取主动的应对措施可以通过自我修复能力一定程度地排除故障，恢复正常运行[11-12]，达到自修复的目的。对以下几种故障，本文设计了相应的故障修复策略。首先，当域内的MPN节点失效时，区域内的PN在设定的时间内，接收不到MPN的心跳信息，则会判定MPN失效，随后在这个区域内的PN会通过简单的选举机制，选出一个PN作为新的MPN。此外，当PN由于异常导致汇总数据失真，也可以通过域内的MPN的历史汇总数据去反馈给PN，随后PN下载新的插件并比较现有插件的MD5码，比较判断后，更新、修复自身插件；最后，当某神经元CN的宿主节点，被篡改了IP地址，影响了宿主虚拟机单元的服务提供，但由于其域内的MPN保存有宿主机的历史信息，所以可以通过反馈比较，进而复原更新此CN所在PN的IP地址。

3BCMS各组成部分实现方法

3.1PN和MPN的实现

PN运行在被监控的资源之上，而MPN是PN的升级版，它只是比PN多了一个发言人的模块，用于管理域内的其他PN，其余功能和PN一样。

PN/MPN加入系统后会启动4个线程，其工作流程描述如下。

1）主进程启动，读取配置文件，解析出配置参数，启动动态资源发现机制的客户端操作，组播请求加入监控请求，若动态资源发现机制失败，每隔2min重新组播请求，尝试10次，若还失败，则程序停止运行。

2）根据服务器端返回的信息，决定是否将自己升级为MPN，若是则启动发言人线程，若不是，则启动感知发言人线程。感知发言人线程与发言人线程是实现BCMS自组织与自修复功能的核心线程。

3）启动PN和MPN共有的度量采集线程和接受指令线程。

感知发言人线程是PN特有的线程，PN根据心跳信息来判断MPN是否存活。心跳信息有两类：一类是正常的心跳信息，另一类是新的MPN掌权的通知信息。正常情况下，MPN定期组播掌权心跳信息，区域内的其他PN会接受该心跳信息，并重置超时时间；异常情况下，某个PN在3个超时间隔过去后，还没有收到MPN的心跳信息，此时它认定MPN宕机，准备接手MPN的工作，加载MPN所需的模块，并通知区域内其他PN，在此过程中为了保证顶替PN的唯一性，PN的超时间隔随机产生，从而减小区域内所有PN在同一时刻发现MPN宕机的概率，避免冲突。

发言人线程是MPN特有的线程，它主要完成PN作为发言人需要完成的任务，包括定期向CNE组播区域存在心跳并这两句不太通顺，请作相应调整。、定期向区域内所有PN组播掌权心跳包括定期向CNE组播区域存在的心跳，以及定期向区域内所有PN组播掌权心跳，接受来自CN的轮询请求，并向其提供区域内资源的性能信息，接受来自CNE的指令，并逐一发送给区域内的所有PN，接收来自PN的异常告警信息，根据异常的类型，决定是立即处理还是向CNE报告。

度量采集线程是监控系统最基本的功能，该线程主要有两大功能：性能信息的采集和采集信息的接收和发送，采集宿主服务节点的性能信息，并将该信息通过网络组播给区域内其他资源，接收区域内其他资源组播的信息，并存储在内存中，而不是马上发给主节点，这样可以减少通信负载。组播后，经过一个sleep时间，线程开始继续监听组播地址。sleep时间是根据主进程读取的配置文件中的采集频率计算得来，在计算的过程中还要考虑程序的执行时间，对sleep的时间稍作微调。在每次性能信息收集完成之后还要和性能的阈值进行比较。若超过阈值，则会启动异常处理线程，将异常信息上报，这样也将进一步降低通信负载，随后会根据反馈的结果进行相应的处理。

指令执行线程则负责接收上层下达的指令，分析下达的指令，并创建进程去执行指令，若指令要求返回数据，还应将数据返回。

3.2CNE的实现

CNE运行在监控中心节点之上，和PN/MPN一样，它也是采用多线程技术实现。CNE初始化读取配置文件后，依次启动存活心跳检测线程、动态资源发现机制服务器端线程、自主分析决策线程、与HMI的交互线程、轮询数据获取线程五个线程来完成CNE的功能。动态资源发现机制服务器端线程和存活心跳检测线程共同负责资源域存活列表的维护，资源域存活列表是进程中的一个链表结构，每一个链表节点对应一项记录，一项记录是对某个资源域的描述包括资源域的标示、资源域的描述、资源域的发言人信息、超时计数等信息，动态资源发现机制服务器端线程向存活列表添加记录，存活心跳检测线程更新存活列表。

存活心跳检测线程初始化后，启动另一线程负责接收心跳信息；同时自身以一定的频率去遍历存活列表这一链表结构。负责接受心跳信息的线程创建阻塞式监听套接字，根据到来的心跳信息判断是否是新的发言人掌权通知信息。

CNE的动态资源发现机制线程实现了监控系统自组织功能在服务器端的响应机制，其流程如图2所示，初始化时，创建监听套接字，进入监听状态，如果有请求信息到来，解析请求信息，根据解析的信息去云平台CC数据库中查询是否有对应资源域的记录项（CC数据库是云平台的管理程序维护的数据库，CC数据库中存储了资源上线时的信息包括MAC地址、宿主关系、所属资源域等，但该数据库内的信息是静态的，即写入后不会动态变化）。若不能查到对应记录，则返回查询失败信息，若能查到对应记录还应该判断发送请求的资源是否是新增资源域中的第一个资源，如果是还应去资源域存活列表结构中添加一项新的资源域记录项，判断结束后，将查询到的信息包括资源的类型、宿主关系、所在资源域名字、所在资源域的发言人联系方式等返回给发送请求的资源。

自主分析决策线程初始化时根据主进程读取的配置文件，随后，提取监听端口等信息，创建监听套接字，进入监听状态等待异常到来，其处理流程如图3所示。

轮询数据获取线程初始化时读取配置文件获取轮询间隔，设定轮询频率，接着遍历存活，依次和存活列表中的发言人进行通信，获取发言人所代表资源域的性能信息，解析收到的信息并存储到数据库中。

与HMI交互线程根据主进程读取的配置文件，创建监听套接字，进入监听状态等待Web界面发送指令。

3.3HMI的实现

HMI界面的实现涉及到PHP（Hypertext Preprocessor）、HTML（Hyper Text Markup Language）、CSS（Cascading Style Sheets）、JavaScript等网页制作技术。HMI界面主要分为三大部分：云平台总览、状态监控、集中控制。云平台总览用于展示平台一系列的资源信息；状态监控实时曲线显示资源的性能信息，能显示各个资源域的资源性能情况；集中控制提供下达指令接口，负责将用户输入的指令传输给后台处理程序。

状态监控实时曲线显示的原理是根据存储的数据产生png图片，将png图片显示在Web界面，为了能实时显示曲线的变化，需要按一定频率产生png图片显示在Web界面上。当监控页面打开后，页面会按一定的频率去向CN请求数据，一次请求就会生成一张png图片并显示在Web界面，当请求的频率足够小就能达到一种实时的效果。

4云资源监控系统测试结果分析

本次实验分别对自组织功能、自修复功能、云资源监控系统的监控效率和监控数据的准确进行了分析和验证。实验采用2台DELL高密服务器（具有4个计算节点），每个计算节点配置为：CPU为16 Core； Memory为128GB；Disk为3TB； Bandwidth为1000Mb/s。运行KVM虚拟机，配置：CPU为2 core； Memory为4GB； Disk为50GB； Bandwidth为1000Mb/s。服务器采用Debian 6.0.5，虚拟机采用Windows Sever 2008操作系统。

计算节点的分布和配置情况如表1所示。节点N1作为控制节点，是云监控系统的中枢神经CNE。N2、N3、N4作为从属节点加入到系统中。N1、N2同属A服务器，N3、N4同属B服务器。因N1属于控制节点，因此仅负载10个虚拟机在其上运行，其他节点都各自负载30个虚拟机。每个节点作为一个单独的域，其中所属的所有虚拟机组成一个独立的周围神经系统PNS。

4.1自组织功能测试

实验如下，首先配置好N1，作为控制节点启动，待所属虚拟机全部启动，系统网络数据传输量稳定后；同时启动N2、N3、N4节点，指定每个节点的1号虚拟机作为周围神经的管理节点MPN，待3个节点虚拟机建立完毕，网络数据传输曲线趋于稳定后，实验结束。在实验中，将记录N2、N3、N4启动后各个时间点的网络数据传输量，以及每个节点成功启动的虚拟机的数量（MPN收到虚拟机作为PN发出的确认信号后，即判定此虚拟机成功启动），随后绘制曲线。

由图4可知，在节点启动后，一段时间内，新虚拟机的建立与加入使得系统内流量大大增加。流量的增加来至于此句不通顺，请作相应调整。系统的类DHCP自组织功能的实现流量的增加来自于系统内DHCP自组织功能的实现，在虚拟机加入系统时，会自动与控制节点CNE与域控制节点MPN进行信息交互，并下载配置信息。因而在此阶段，系统网络中存在大量的信息交互。此外，图5反映了虚拟机加入过程中，整个系统的总虚拟机数。值得一提的是，在虚拟机数量图中，N2节点的虚拟机建立速度，明显快于N3和N4。分析可知，N2与控制节点N1同属一台服务器A，因此，网络信息的传递更快。

4.2自修复功能测试

实验环境描述如下，部署好所有节点和虚拟机，且系统正常运行（周期性地收到监控信息）后，选取节点N2包含的周围神经系统PNS作为实验域。

首先，绘制一段时间内，N2节点域内的网络流量信息曲线，如图6所示。

因MPN会周期性地要求域内的PN上报监控信息，且PN也会根据阈值自动上传信息，因此可以得到如图6所示的一段时间内，N2节点内部的通信流量。由图6可以看出存在明显的周期性特征。

随后，人为地关闭N2节点中，作为域控制节点MPN的1号虚拟机。一段时间后，获取1号虚拟机关闭前后一段时间内N2节点域内的流量数据，绘制如图7所示。

根据图6所展示的监控流量时间周期、流量大小信息，以及图7所展示的失效时间内系统监控流量的变化可知，从9s处开始，流量传输出现了异常状况，而根据流量数据的摘取时间范围属于关闭1号虚拟机前后的时间段来看，正好可以判定，此时MPN节点出现了异常。随后从时间17s处开始，N2节点域内恢复了正常的监控流量传输。由此可以说明，系统很好地实现了自修复功能，且能在MPN节点出现状况后在较短时间内选出新的主监控节点，使系统恢复正常的监控状态。

4.3监控系统效率分析

云平台A采用一台DELL并部署Ganglia（Ganglia3.0.3）监控软件；云平台B部署BCMS。平台A、B各选取1个计算节点作为监控中枢，启动gmetad服务和Ncontrol等相关服务进程。各选取余下3个计算节点，并启动30台虚拟机，均部署gmond服务和Nagent/Nspeake数据采集服务。

在云平台A和B中每台虚拟机上运行测试程序，分别在监控中枢服务器上使用tcpdump命令测试网络通信带宽，并将30min内的网络通信流量结果保存到指定文件中。测试结果如图8所示（横轴表示时间，单位为分钟；竖轴表示网络通信量，单位为：kb/s）。

在基于BANS的云资源监控系统中，监控中枢的网络流量总和=f（历史数据汇总+异常报警信息）；在安装Ganglia监控系统中，网络流量总和=f（实时数据）。从图4可以看出基于BANS的云资源监控系统，由于各层具有自主决策能力，减少了不必要数据的传输，对比发现，在某些单一时刻，流量最多能降低到原来的1/3左右。

4.4监控系统数据验证

在云平台A和B中，分别在一台虚拟机上运行测试程序，记录30min内虚拟机上CPU利用率的情况。测试结果如图9图9中横轴的单位为秒，而此处文字描述的单位为min？到底以哪个为准？请明确。所示。

从图9可以看出，BCMS和Ganglia系统的监控结果是基本吻合的，由此可知，该监控系统提供数据的真实、有效，反映了实际状况。

5结语

本文针对现有监控系统网络负载过重、扩展繁琐、低可靠性问题进行了改进，提出了基于BANS构造的云资源监控模型，通过分级存储，分批上报机制，降低了系统的网络负载；同时引入新的发现与轮询机制，赋予了监控系统自主能力，使得系统中的节点具有本地自治与自修复能力。后续工作可根据不同的监控特征划分不同的周围神经系统，进行按任务为导向的动态区域监控，并增加对历史数据的进一步挖掘分析，实现更多自主决策机制，进一步扩展模型。

参考文献：

[1]

MA S. A review on cloud computing development [J]. Journal of Networks， 2012， 7（2）： 305-310.

[2]

GAO J， XIAO Y， LIU J， et al. A survey of communication/networking in smart grids [J]. Future Generation Computer Systems， 2012， 28（2）： 391-404.

[3]

ACETO G， BOTTA A， DE DONATO W， et al. Cloud monitoring： a survey [J]. Computer Networks， 2013， 57（9）： 2093-2115.

[4]

MASSIE M L， CHUN B N， CULLER D E. The Ganglia distributed monitoring system： design， implementation， and experience [J]. Parallel Computing， 2004， 30（7）： 817-840.

[5]

SACERDOTI F D， KATZ M J， MASSIE M L， et al. Wide area cluster monitoring with ganglia [C]// Proceedings of the 2003 IEEE International Conference on Cluster Computing. Piscataway， NJ： IEEE， 2003： 289-298.

[6]

YANG C T， CHEN T T， CHEN S Y. Implementation of monitoring and information service using Ganglia and NWS for grid resource brokers [C]// Proceedings of the 2nd IEEE AsiaPacific Service Computing Conference. Piscataway， NJ： IEEE， 2007： 356-363.

[7]

HINCHEY M， DAI Y S， RASH J L， et al. Bionic autonomic nervous system and selfhealing for NASA ANTSlike missions [C]// Proceedings of the 2007 ACM Symposium on Applied Computing. New York： ACM， 2007： 90-96.

[8]

KEPHART J O， CHESS D M. The vision of autonomic computing [J]. Computer， 2003， 36（1）： 41-50.

[9]

CARAFFINI F， NERI F， PICINALI L. An analysis on separability for memetic computing automatic design [J]. Information Sciences， 2014， 265： 1-22.（无期）

[10]

DROMS R. Stateless Dynamic Host Configuration Protocol （DHCP） Service for IPv6 [EB/OL]. [20150920]. http：///html/rfc3736.

[11]

HUEBSCHER M C， MCCANN J A. A survey of autonomic computing―degrees， models， and applications [J]. ACM Computing Surveys， 2008， 40（3）： Article No. 7.

[12]

MARSHALL T， DAI Y S. Reliability improvement and models in autonomic computing [C]// Proceedings of the 11th International Conference on Parallel and Distributed Systems. Piscataway， NJ： IEEE， 2005： 468-472.