IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope:Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  Grid computing  >

管理网格,第 3 部分: 监视和调度

developerWorks
文档选项

未显示需要 JavaScript 的文档选项


级别: 中级

David Medinets (david.medinets@gmail.com), 自由撰稿人, Uniserve Communications Corporation
David A. Cafaro (dac38@georgetown.edu), 计算机研究员, Uniserve Communications Corporation

2007 年 1 月 26 日

管理网格涉及众多元素,从部署网格使用的网络和硬件到安全、作业管理以及在网格执行过程中所生成的统计信息,这可以让我们更有效地对作业进行管理。在这个 4 部分的 “管理网格” 系列文章中,我们观察了网格管理过程中的一些关键因素,例如标识硬件和网络基础及其对网格处理的影响,还介绍了如何使用这些信息作为调度、预测和扩展工具。在本系列的第 3 部分中,我们将介绍网格的监视、统计信息和部署。

简介

对本地计算机上运行的程序进行监视通常都非常简单。例如,Microsoft® Windows® 提供了一个任务管理器程序,UNIX® 提供了 Top 工具。它们都可以显示在某个给定的时刻,系统中有哪些进程正在运行,它们占用了多少 CPU,还可提供诸如内存使用率之类的其他统计信息。然而,在涉及计算网格时,了解您的应用程序运行情况可能会较为困难,因为执行信息可能会分布于数百台计算机上。

本文是共分 4 部分的 “管理网格” 系列文章的第 3 部分,将介绍监视的类型,应该监视哪些内容,如何进行监视,以及这些监视可能会对您的部署决策产生什么影响。

重要的是要记住与网格有关的不同人员需要不同类型的信息。最终用户可能只关心应用程序的结果(即只有作业执行信息),而网格管理员可能会关心更具体的信息,例如磁盘空间利用率。另外,在用户和管理员之间可能会有一些联系人员,他们希望看到使用网格的多个应用程序之间达到某种平衡。

现在,我们将介绍一点身份验证和授权的内容。这两个主题都非常复杂,在本文中只能介绍一下它们的重要性,而没有足够的篇幅来详细介绍这方面的知识。要深入了解这方面的内容,请参看 参考资料

身份验证(Authentication)确定特定的用户。简单的密码保护 HTML 页面对于大部分应用程序来说通常已经非常安全了。一旦用户通过身份验证,就应被给予访问任何已授权的应用程序的权力(为所有的网格应用程序提供单点登录功能可以极大地简化用户的操作)。

授权(Authorization) 在计算网格中有自己独特的意义。除了指定每个用户可以访问哪些应用程序之外,您可能需要授权对专有硬件的访问权限,并限制磁盘存储空间的使用。每个应用程序可能具有自己的内部授权需求。





回页首


监视网格

监视网格需要全方位地考虑网格的各个方面:它们是如何相互联系的,如何使用所监视到的信息。下面是您需要考虑的部分方面(当然不是全部):

  • 用户类型 —— 最终用户需要的信息与管理员需要的信息并不相同。管理员可以分为操作系统管理员和数据库管理员。您监视的数据需要符合每类用户的需要。
  • 资源 —— 考虑构成网格的资源的类型:存储、服务器、数据库服务器、应用程序等。
  • 时间 —— 应隔多长时间收集一次特定的值。例如,如果您的应用程序不会生成大量文件,那么应该每天收集一次有关磁盘使用情况的信息。但是如果您的网格需要存储大量中间信息或计算结果,那么您可能需要每隔一个小时就对磁盘使用情况进行监视。
  • 应用程序类型 —— 网格上运行的应用程序的类型。这些应用程序是数据相关、计算相关还是服务相关?也许是它们的混合体。每种类型的应用程序都有自己的监视需求。

下一节将介绍需要监视哪些内容。





回页首


监视的内容

每方面都有着自己独特的特征,可以对其进行监视。例如,最终用户的应用程序可能有一些错误需要监视。或者您可能希望了解网格中每个服务器上的空闲磁盘空间。这些示例可分类如下:

  • 日志 —— 有关网格健康状况的错误和警告,日志可使您找到出现问题的位置
  • 性能评测信息 —— 性能和目标达成情况,这些信息可以用于调度

通常,日志是从应用程序内部生成的,而性能评测信息则是由一些监视软件在应用程序外部生成的。

日志不应该是性能相关的。它们独立于所使用的计算资源的类型。错误究竟是由单个 CPU 桌面产生的,还是由多个 CPU 的高性能服务器产生的,这个问题对于诊断和错误分析过程来说通常没有太大影响。然而,计算机的架构风格有时候会影响程序的运行方式,因此就可能会引发错误。

另外一方面,性能评测信息会受到搜集这些数据所使用的硬件和软件的影响。例如,在查看磁盘子系统的吞吐量时,了解所使用的硬件的期望性能就非常重要。一个硬件的速度可能是另外一个硬件的两倍,这类信息对于比较性能评测信息是非常重要的。有些性能评测软件可能会向正在运行的应用程序中添加检测装置,而有些性能评测软件则可能会查询操作系统或观察网络行为。

可以这样说,监视在某种程度上会从正在运行的应用程序中窃取性能。有时候,当性能对于某个给定的应用程序非常重要时,可能就需要这样一个监视系统:它能够 “向后调” 从而监视更少的内容。





回页首


日志

发往日志文件中的消息有很多类型,包括:

  • 报告消息 —— 这些消息让您能够了解发生了什么(例如,某个特定的文件已经被打开了)。这些消息可以帮助分析错误消息,因为它们提供了程序执行流中的一些参考点。
  • 警告消息 —— 虽然这些消息通常可以安全地忽略,但是了解这些消息将会非常有用。如果您突然看到某个警告消息高频度地出现,那么需要对此进行研究以解释其原因。
  • 错误消息 —— 这些消息通常意味着程序碰到了意外的情况,这些情况通常是可以确定的,例如输入错误或配置不正确。这些错误应该尽快解决,减轻或防止级联错误。当错误发生时,进行一定级别的调试和分析是必要的。要简化分析过程,系统需要能够将受影响的机器暂时从网格中移出,这样才能修正错误。请记住将机器从网格中删除会影响网格的性能,并将影响所调度的内容。

在检查日志文件时,您可以提取以下信息:

  • 作业执行 —— 跟踪所执行的作业个数及其最终状态非常重要。所有的作业都启动了吗?其执行结果是成功、失败还是出现了某种错误情况?每个作业执行时花费了多长时间?
  • 安全性 —— 网格可能要满足跟踪认证和授权的要求。这些信息可能在日志中可以找到。
  • 硬件 —— 磁盘多长时间会用完空间?它们多长时间出现一次故障?网络有故障或丢包吗?
  • 软件 —— 多长时间会出现一次错误配置的情况?作业多长时间会用光资源?软件 bug 是怎样处理的?




回页首


性能评测

关于网格和网格上的应用程序可以搜集很多性能评测数据。如果您的网格主要用于 CPU 密集型的任务,那么性能评测数据主要是 CPU 随着时间变化的情况。如果您的网格是与存储有关的,那么性能评测数据就主要是存储随着时间变化的情况。可以追踪的性能评测数据有:

  • CPU —— CPU 的使用会直接影响程序的执行时间。
  • 数据 —— 在查看数据存储时,您可以搜集有关空闲空间数量、流入和流出应用程序的字节数以及需要多少临时空间的信息。
  • 内存 —— 内存对于很多种类的应用程序来说都非常重要。与内存有关的性能评测信息包括缺页、峰值内存使用以及虚拟内存大小。
  • 节点 —— 与节点相关的性能评测信息量包括节点的运行时间、处理的请求以及事务吞吐量。
  • 网络 —— 与网络相关的性能评测信息包括延时、协议的通信开销、丢包情况以及包吞吐量。




回页首


搜集统计信息

从所监视的网格性能评测数据中,您可以获得很多信息。这些信息可以用来查看之前的网格性能,以及预测网格今后的性能。将这些信息使用某种图形化的方式呈现出来是个好主意,这样就可以快速了解网格中正在发生什么。之后,您可以使用统计分析来计算资源使用情况的今后趋势,从而来规划将来的升级,并且在问题发生之前就可以找到潜在的问题。例如:

  • 性能评测数据的图形化表示 —— 使用某种图形化的方式来表示性能评测数据是个好主意。这样可以提供一种快速简便的方法来查看当前性能和资源使用情况,以及基本的趋势报告。大部分报告应用程序都提供了一些选项来生成资源性能评测的图形化视图。
  • 基于 Web 方式产生报告和使用客户机-服务器方式产生报告 —— 二者用于不同的优先级。基于 Web 的报告可以用来快速生成当前系统性能的快照,以及显示过去资源使用情况,从而允许用户或管理员确定他们可以将自己的作业提交到什么地方,使用哪些资源可以最好地满足自己的需求。基于客户机-服务器的报告方式通常为进行详细数据分析提供更多选项,对于趋势报告和规划计算非常有用。
  • 缩放(zooming)、向下钻取(drill-down)、向上钻取(roll-up) —— 要查看性能评测数据,为它们建立并使用一个一致、结构化的分层式视图会非常有用。这样用户就可以方便地查看从高级网格信息到特定节点集群再到某个特定节点及其备份的信息。
  • 短期和长期 —— 短期趋势信息有利于向网格资源提交作业的规划。短期信息提供了系统当前负载情况的一个概貌。长期趋势信息有利于规划将来的资源需求情况。通过把长期趋势信息和已知将来项目结合到一起来看,您就可以更加轻松地预测自己最需要在哪些地方来扩展网格基础设施。下面是几个您可以在基于 Web 的图形化性能评测报告看到的内容的例子。注意您将从一个高级的视图开始,并且可以向下钻取每个资源的更详细信息。这些屏幕快照来自于 Ganglia Monitoring System,它是一个免费的开源项目。

图 1 给出了网格资源的一个概述图。最上面是对所有网格资源的一个总结,后面是对每个网格资源集群的概述。


图 1. 网格资源概述
网格资源概述

通过点击资源的主机名,您可以获得给定集群计算资源使用情况的更详细视图,包括单个主机的信息。


图 2. 集群计算资源使用情况的详细视图
集群计算资源使用情况的详细视图

通过点击集群上的物理视图链接,您可以看到集群中有哪些资源是可用的,以及每个节点资源上有哪些资源是可用的。


图 3. 集群的物理视图链接
集群的物理视图链接

通过点击单个主机,您可以获得有关特定机器的详细信息,包括使用情况的统计信息。


图 4. 详细信息,包括使用情况的统计信息
详细信息,包括使用情况的统计信息

通过点击单个主机,您可以获得有关物理/软件特性的信息:


图 5. 信息和物理/软件特性
信息和物理/软件特性





回页首


使用性能评测数据

获得这些数据之后,您必须确定如何才能最好地使用这些数据。根据您是资源用户还是管理员,以及您是否正在规划下一次作业提交或是将来的网格使用和扩展,使用性能评测数据的方式也会有所不同。例如:

  • 终端用户 —— 终端用户所关心的是自己的作业能被网格接受并及时完成。短期系统/网格使用情况的性能评测数据对于终端用户来说最为重要。这可以帮助他们确定应该将作业提交到哪些资源上,或者请求使用哪些资源。这还可以让用户检查自己当前工作所发生的事情的状态。
  • 管理员 —— 管理员可能会对短期和长期性能评测数据都感兴趣。短期性能评测数据可以帮助发现资源中的瓶颈,以及目前可能会影响短期/近期作业提交和小型维护的尚未充分使用的资源。性能评测的长期趋势可以帮助规划自动作业提交模式,以及长期资源分配和扩展规划。

使用性能评测数据进行资源管理

使用性能评测数据进行资源管理是进行良好网格管理的基础。关于资源的性能评测数据提供了一些信息,有助于建立任务提交规则、追踪系统优化以及规划将来的扩展或资源重新分布。下面是使用不同类型的性能评测信息的几个例子:

  • 当前数据趋势 —— 这对于规划作业提交和处理近期任务中的瓶颈问题非常有用。通过观察短期趋势,用户可以收到资源紧缺的警告,并采取相应的操作。在查看存储性能评测数据时,您可以快速了解您的作业所需要的存储空间是否可用。重要的是要记住您的应用程序中任务数据对于临时存储和长期存储的需要不同。
  • 当前处理趋势 —— 了解这些性能评测数据可以帮助您确定自己的任务可以使用哪些资源。您可以确定目前哪些系统是空闲的,或者尚未充分利用,可以用来提交短期执行的任务。它还提供了有关系统健康状态的信息。多个故障的节点或不匹配的 CPU 利用率可能预示着一些基本问题,这些问题应该在提交任务之前解决。
  • 长期数据趋势 —— 这对于规划自动作业提交,以及规划资源的未来扩展和重新分布非常有用。记住您需要分别来看临时存储(暂存空间)和长期存储。通过查看长期趋势,您可以确定哪些资源已经超负荷了,从而相应地修改自动负载管理。它还让您可以更加容易地确定哪些系统需要更多资源(或从总是未充分利用的系统中重新分配)。
  • 长期处理趋势 —— 这最适合用来规划自动作业提交和今后资源的增长。在查看这些性能评测数据时,您可以对自动作业执行进行更好的调度,从而更好地利用尚未充分使用的系统。它还为规划扩展和系统硬件到特定资源的重新分配提供了一些信息。




回页首


使用性能评测数据进行调度管理

如果了解网格的性能,您应该可以确定如何才能最好地调度自己的任务在网格上执行。您可以使用过去的历史记录为特定作业分配大概的执行时间。使用这些性能评测数据,您可以根据作业的需求在不同资源上调度并发作业来支持多个同时进行的项目。

可以将计算密集型的作业发送到具有大量 CPU 的高性能集群上执行,而将数据密集型的作业调度到另外一个具有足够存储的资源上运行。性能评测信息让您可以了解这些资源并最好地利用它们。下面是需要记住的几个问题:

  • 突发性任务和连续任务 —— 在查看网格性能评测数据时,考虑在资源上执行的任务的种类非常重要。突发性任务或高强度的短期作业可能会更适合使用专用于这种任务的网格或计算资源进行处理,这样就能快速调度并完成这些作业;而那些执行时间更长的连续性作业则可能在其他资源上处理更为合适。在规划将来扩展时考虑这一点也非常重要,因为从长期平均分析来看,可能并不会经常使用系统。但是从一小段时间内的增加情况来看,可能系统的负载会很重。
  • 自动调度和手工调度 —— 自动调度可以让您集中精力于保持网格运行上,但是如果您有一个紧急的作业需要运行,或者出现严重故障,或者没有考虑作业是如何分发和使用的,那么网格的响应能力可能就会降低。手工调度需要进行更多工作,您需要手工设置作业执行的顺序;不过这也为您提供了更多的控制能力,让您可以调度一个小作业在一个大作业之前执行。还可以调度多个更小的作业同时执行。自动调度通常都是顺序处理的,这可能无法最好地利用网格。
  • 异构环境中的调度 —— 在由不同机器、不同环境以及由之而来的不同性能所构成的混合系统中,您可以考虑构建或开发一系列网格分组,这样就可以根据不同环境的功能或能力对作业进行调度了。例如,如果您有一个 CPU 密集型的作业,其指令主要都是整数计算,那么在一个基于 RISC 的 CPU(例如 SPARC)上运行这个作业可能效率更高,而浮点计算则可能在使用专用 FPU(Intel®/AMD 或 PowerPC® 及其 Altivec 单元)的环境中执行会更好。




回页首


结束语

分享这篇文章……

digg 提交到 Digg
del.icio.us 发布到 del.icio.us
Slashdot 提交到 Slashdot!

在本文中介绍了网格监视、统计信息以及部署的问题。我们了解了网格中需要进行监视的不同方面 —— 用户、资源、时间和应用程序类型,以及如何通过日志和性能评测数据来监视这些因素的方法。我们还介绍了如何使用这些信息更有效地对网格进行管理。

在本系列文章的第 4 部分中,我们将对一天之内网格中可能发生的典型任务和事件进行概述。我们将介绍系统故障/还原、日常监视和过程以及如何为处理今后的作业和需求而制订规划。



参考资料

学习

获得产品和技术
  • Ganglia 是一个开源项目,它为高性能计算系统(例如集群和网格)提供了一个免费的可扩展分布式监视系统。

  • IBM 试用版软件 构建您的下一个开源开发项目,这些软件可以从 developerWorks 上直接下载。


讨论


作者简介

David Medinets 从 1980 年开始就一直从事编程方面的工作,当时他首先接触的是 TRS-80 Model 1。他现在依然记得那段连好键盘后在显示器上创建有趣字符的快乐时光。从那时开始,他就开始将时间花在调试 UNIX 机器上的 Emacs 文本编辑器、在 VAXen 上工作以及构建最先进的 Web 应用程序(想像一下 1999 年的 Toys "R" Us 和它的 7,000 名同步用户)。David 与 Kathryn 结婚后居住在弗吉尼亚州的 Fairfax。他负责 Eclectic Consulting 公司的运转,并且编写了一些有关 Perl、PHP 和 BASH 的书籍。他还管理 CodeBits.com 站点。


David A. Cafaro 目前在 Georgetown University 的 Advanced Research Computing(ARC)组工作,在这里他为 Linux 和开源技术的使用提供计算研究支持,他是一名 Red Hat 认证的工程师。另外,他还是 Program Committee for LinuxWorld Expo and Summit 的一员,为开发内容跟踪和热点技术提供帮助。他还是 Tresys Technology 的一名安全分析师,着重于 SELinux 策略方面的工作。他在开源社区和 Linux 社区中都非常活跃,是 Tux.org Board of Directors 的一员。




对本文的评价

太差! (1)
需提高 (2)
一般;尚可 (3)
好文章 (4)
真棒!(5)

建议?




回页首


IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可,请勿转载。如果您希望转载,请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM 隐私条约 联系 IBM 使用条款