集成的网格监控系统
- 格式:pdf
- 大小:63.56 KB
- 文档页数:5
栾翠菊,高俊波,王伟,等:集成的网格监控系统2009,30(17)41230引言隐藏网格环境的复杂性是众多网格系统实现的重要目标之一。
但这样做的同时带来了一个问题:用户无从了解网格内部被隐藏的操作,一旦出现系统故障或者其它的问题就难以解决,这就要依赖监控系统。
网格监控系统的作用主要包括提供被监控实体的信息、有效管理资源、任务状态及任务进展情况监控、应用程序性能分析、优化,及应用程序自我调优、资源及任务调度、分布式系统的性能分析及优化、数据复制、记账与审计。
由此可见,为了理解网格的操作、检测错误及优化性能等等,网格系统中的监控是必不可少的。
鉴于网格的特点以及网格监控系统的用途,与以前的监控系统相比,网格环境中监控系统的需求是不同的,主要包括可伸缩性、可扩展性、数据传输模式、可移植性、互操作性、低干扰性、实时性、安全性、具有时间特征等。
1网格环境中的监控对象在网格环境中,有多种实体需要监控,例如网格中的资源和执行的任务等。
本文将监控对象按属性分为两类:资源:包括网格环境中涉及的计算、网络、存储、设备等提供服务的资源,典型的是计算资源、存储资源和网络资源。
应用:指在网格环境中运行的实体,典型的是网格中执行的任务。
资源监控系统与任务监控系统存在一些本质的不同:(1)监控对象及监控范围不同:资源监控系统的监控对象包括所有可用的资源及其相关信息,其监控范围及规模很大,并且没有针对性。
任务监控系统的监控对象是运行在某些资源上的任务及其相关信息,监控范围及规模小的多,并且具有收稿日期:2008-09-05;修订日期:2009-02-19。
开发与应用41242009,30(17)计算机工程与设计Computer Engineering and Design针对性。
(2)监控信息具有一些不同的属性:资源监控信息采用复杂的数据类型;此类监控系统用户众多,理想的情况是网格中的每个用户或者需要资源监控信息的每个实体;在监控数据获取时,资源监控系统不知道谁是接收者。
任务监控信息通常使用简单数据类型表示;当监控数据获得的时候就知道了接收者,通常是请求监控数据的实体,而且接收者数量很少。
(3)用途不同:资源监控信息主要用于资源发现和资源调度,此类信息通常存储在数据库中用于静态分析。
任务监控信息主要用于操纵任务、发现并行应用程序性能瓶颈及调优,通常此类信息只在任务执行的过程中是有效的。
(4)安全级别不同:通常,资源监控信息是所有经过认证和授权的用户都可以访问的;而任务监控或者任务操纵只有任务的所有者才能执行。
鉴于网格中资源和任务监控存在以上的这些差异,有必要将这两类对象分别进行监控。
2相关研究研究人员针对于网格环境中的监控问题做了大量的研究工作,文献[1]对这些研究进行了概括性介绍。
当前已经开发的监控系统主要包括:MDS[2]、GridICE[3]、GridMon[4]、GridRM[5]、Ganglia[6]、OCM-G[7]、Mercury[8]、Netlogger[9]、R-GMA[10]、AutoPi-lot、GRM、NWS等。
在这些系统中,多数只能监控资源,有一些只能监控任务,有少部分能够同时监控资源和任务。
资源监控目前已经进行了深入细致的研究,并且成果显著,代表性的有MDS,NWS,Ganglia等。
它们能够对计算资源、网络资源、存储资源等进行有效监控,针对于资源监控中的各种问题提供了比较好的解决方法。
相对于资源监控而言,任务监控的研究有待拓展及深入。
典型的用于监控网格环境中的任务的监控系统包括OCM-G,Autopilot,GRM,Mercury,NetLogger等。
这些监控系统都能够监控应用程序,但是没有能够监控文件操作的,也就是不能监控网格中任务执行的整个过程,而这一点是绝大多数网格系统所需要的。
另外,这些系统对于将客户端提交的任务与服务器端对应进程之间的映射、监控部件的启动方式等重要问题解决的不尽完善。
能够同时监控资源与任务的系统主要有Mercury、Netlog-ger、R-GMA等。
这些系统对于资源和应用的监控没有根据两者的不同加以区分,而根据前文的分析这是必要的。
3待解决问题分析资源监控拟解决的问题:・自动发现网格资源,进行资源注册和资源信息汇集;・为不同要求的网格用户提供资源信息检索服务;・支持信息缓存与更新;・支持用户可选的检索条件限制;・实现信息服务API,为进一步的应用程序设计提供支持;・实现自定义资源信息的自动注册与分发;・提供方便友好的图形用户操作界面。
任务监控拟解决的问题:在网格环境中,当任务提交到网格平台的时候,要执行3个基本的操作,包括任务执行之前的文件操作、任务的执行、任务执行完成之后的文件操作。
为了监控整个任务,除了监控应用程序,还必须监控文件的操作。
由于任务在远程资源上是以多个进程的方式执行的,因此任务监控是针对进程的,也就是获取任务进程级的信息并在进程级进行操纵;文件操作监控除了监测错误之外,主要是获取文件传输性能数据,并据此控制文件传输方式。
为了能够在进程级别上监控任务,就涉及到一个问题:如何找到属于一个任务的所有进程,或者说如何将客户端提交的任务与其在远程资源上执行的进程进行映射。
并行任务一般都有多个进程,并且一个任务可以提交到多个资源上执行,这样,一个任务就可能存在多个分布在不同资源上的进程。
因此,需要一种安全、可靠的从任务到其进程的映射机制。
由于网格中的一个任务可以提交到多个资源执行,因此,任务监控系统必须能够监控运行在多个资源上的任务。
监控系统通常由多个监控部件构成,它们之间互相配合,共同组成一个有条不紊的体系。
在该体系中,为了能够顺利的实现监控操作,所有的监控部件在需要的时候必须处于就绪状态。
因此,就涉及到如何可靠地启动或者确保监控部件可用,并且监控系统要具有强健的容错能力,以便在监控部件发生异常的时候能够恢复运行。
此外,由于监控系统是一个多用户的系统,要处理多个用户及多个任务,为了防止非法获取监控信息及非法控制任务,针对前面分析的关于任务监控信息不同于资源监控信息的安全问题,也是需要解决的问题之一。
4监控系统体系结构集成式监控系统的体系结构如图1所示,两个监控子系统分别是资源监控子系统和任务监控子系统。
资源监控子系统负责监控网格环境中的各种资源,包括计算资源、存储资源、网络资源、软件资源、数据资源等,为网格中的其它服务提供资源发现及信息服务。
任务监控子系统负责监控网格系统中的所有任务,为网格中其它服务提供任务执行信息并控制任务的执行。
两个监控子系统分别独立监控网格中的两类对象,但是又相互合作。
例如,资源监控子系统为任务监控子系统提供资源信息,当某个任务所在节点资源紧张,任务监控系统就可以根据需要停止任务的执行,将任务迁移到合适的资源继续执行。
图1集成监控系统的体系结构任务管理数据管理…网格中的服务RMS计算资源存储资源…网络资源任务1任务2任务nJMS栾翠菊,高俊波,王伟,等:集成的网格监控系统2009,30(17)41254.1资源监控网格环境中的资源监控为用户提供资源信息,如何发现各种动态资源并将大量的动态变化的资源信息实时提供,是网格研究人员必须解决的一个问题。
MDS 是Globus 项目提出的基于网格环境的信息服务框架。
其组成包括3部分:本地资源信息服务GRIS 、网格目录服务GIIS 及信息提供者IP 。
其基本实现思想是:GRIS 将IP 提供的信息汇集过滤,向GIIS 服务器进行动态注册更新,GIIS 将各GRIS 服务结合起来,提供一个统一连贯的系统映像,为网格应用提供资源信息服务。
这种层次结构形成了资源组织和信息显示的虚拟组织。
通过它,用户能够查询到虚拟组织中的所有可用资源及其信息。
资源监控系统(resource monitoring system ,RMS )以MDS 为基础,基于LDAP 协议,利用SASL 和GSI 的安全认证体系,为上层服务提供API ,并在此基础上实现资源发现和信息检索服务,提供友好的、交互的客户端图形界面。
另外,为了满足系统特定要求,提供扩展的信息服务,并自动完成服务的注册和分发。
RMS 的结构及其与Globus 、其它服务的关系如图2所示。
RMS 主要包括3个部分:API ,GUI 图形界面和信息提供者的扩展。
APIs :在LDAP 协议的基础上,对LDAP 各种操作进行面向对象的类封装,实现网格环境下MDS 检索的数据封装和操作封装,提供统一的模块化的接口,方便其它模块和上层服务调用。
资源发现:在API 的基础上,自动发现用户所在虚拟组织的可用资源信息,并根据用户提出的资源要求对资源进行过滤,为网格任务提供资源发现和匹配服务。
GUI 图形界面:在API 的基础上提供MDS 的图形化操作。
用户通过简单的操作,可以方便快捷的查询相关资源信息。
同时,提供系统设置、自定义条件查询、自定义显示等功能。
信息提供者的扩展:Globus 提供的资源描述信息在实际应用中是不够的,为了满足网格环境中的任务需求,需要提供更全面的执行环境信息和资源信息。
针对此类服务系统提供了注册与分发机制。
4.2任务监控任务监控系统(job monitoring system ,JMS )的体系结构是基于Open Grid Forum (OGF )提出的网格监控体系结构(grid monitoring architecture ,GMA [11])。
JMS 采用了分布式的分层的结构,如图3所示。
JMS 的主要部件包括本地监控器(local monitor ,LM )、站点监控器(site monitor ,SM )、结点监控器(node monitor ,NM )、任务注册表(job register table ,JRT )和各种传感器(图3没有显示),图3中其它部件(除了AP )是参与任务执行的网格服务,它们不属于JMS ,但是与监控系统配合工作,AP 代表运行在目标系统中的应用程序。
本地监控器位于客户端,用来监控运行的任务。
LM 能够向执行任务的资源上的SM 查询或者预定任务的监控信息,还能够向SM 发送命令来操纵任务的执行。
此外,LM 能够监控文件操作:获取关于文件操作的错误检测信息,获取文件传输性能数据信息,并能够控制文件传输操作,例如改变并行度等。
LM 对于文件操作的监控是通过客户端的文件控制器来实现的。
结点监控器分布于资源的每个结点上,负责收集结点上运行的进程的信息,并将之传输到同一个资源上的站点监控器。
NM 还能够根据从SM 获得的命令来操纵进程。
在这个上下文中SM 是消费者,NM 是生产者。
站点监控器运行在每个资源上,从本地监控器接收请求或者命令,然后将其分发到本站点上相应的NM ,在从NM 接收到信息之后传输给LM 。