级别： 中级 David Medinets (david.medinets@gmail.com), 自由撰稿人, Uniserve Communications Corporation
David A. Cafaro (dac38@georgetown.edu), 计算机研究员, Uniserve Communications Corporation
2007 年 3 月 06 日 管理网格涉及很多元素，从部署网格使用的网络和硬件到安全、作业管理以及在网格执行过程中所生成的统计信息，这可以让我们更有效地对作业进行管理。在这个 4 部分的 “管理网格” 系列文章中，我们将来了解一下网格管理过程的一些关键因素，例如确定硬件和网络基础，以及如何使用这些信息作为调度、预测和扩展工具。在本系列最后的这篇文章中，将着重介绍网格的日常管理。
简介
如果您已经阅读了本系列文章的前面部分，那就应该对如何设计、部署和监视网格基础设施有了一个很好的了解。在前面的 3 个部分中，我们首先介绍了网络和网格软硬件方面的考虑，涉及了有关正在提供的服务和在什么环境中进行操作的内容。之后，我们探讨了在实现安全性的设计阶段应该考虑的问题以便提供一种受控的方法来管理哪些人和哪些程序可以访问您的网格资源。最后，我们探究了在对网格进行操作的过程中应该监视哪些内容来帮助您维护资源的操作状态。
第 4 部分将应用前面学到的知识，呈现一个典型的网格管理员的日常工作都会涉及到一些什么内容。我们将介绍网格管理的日常任务、问题处理、作业维护和规划。
日常任务
只要准备充分，网格管理员的日常操作与其他系统管理员的工作并没有太多区别。设计优良的网格基础设施通常都会非常稳定。惟一的问题通常都来自于硬件故障、维护更新和用户错误（可能是应用程序有问题或其他一些简单的错误）。下面是一些日常问题：
- 日志和监视 —— 日常需要做的最重要的事情是扫描日志，并查看统计信息报告。您可以使用软件来帮助扫描这些数据，并突出显示一些关键字和问题，从而使问题的发现更加容易。您还可寻找不符合规范的内容，例如日志文件中的错误和警告、统计信息中的不正常的操作或缺少某些操作，这都很可能会成为问题的根源。下面的截屏给出了一个基于日志的软件错误。
图 1. 身份认证服务的错误
- 培训和提醒 —— 密切关注所使用的技术和工具的发展动向非常重要。建议您订阅邮件列表或通过其他方式来获取对所使用软件新动向的提醒（请参看 参考资料）。通常，当您注意到正在使用的应用程序中有错误发生时，其他人可能早已注意到了相同的问题，并且已经对它展开了讨论。该问题甚至可能已经被修复或已经被解决。这些列表也可以提醒您将来可能出现的问题，并在它们变成真正问题之前帮您针对性地进行规划。
- 系统维护 —— 维护任务通常可以划分为在线任务和离线任务。在线任务通常都很简单，例如删除陈旧的临时文件、添加或删除用户以及任何不会中断运行进程的其他任务。离线任务通常会涉及到系统升级，需要通知用户某个给定系统在某段给定时间内不能使用。如果可能，它应该在正常维护时间内进行。
- 调度作业请求 —— 根据所使用的是自动调度程序还是手工调度系统，情况有所不同。使用自动调度程序，您可能需要确保作业正在运行、新作业正在排队。使用手工调度，需要参考统计数据，并为作业请求匹配适当的可用资源。
- 规划 —— 如果一切顺利，您需要面对的一个大问题是为扩充和升级制定规划。正如技术领域中的其他问题一样，人们一旦认识到某项技术的益处之后，就会要求该技术不断得到改进。
监视日志通常非常有助于解决日志中所显示的问题（系统故障、紧急维护、安全响应）。我们从邮件列表和 RSS 反馈中也可以学习到相同的东西。系统维护可能会涉及这样一些任务：复用 Java™ VM；重启大型服务，例如 HTTP；或者简单处理新网格用户。根据作业类型和网格基础设施的不同，调度作业很可能只会占用您一天内的一小块时间。接下来的几节将更详细地介绍这些相关任务。
系统故障和恢复
有时，您在查看日志、检查统计信息或 e-mail 时，很可能会发现系统出现故障。根据出现故障的系统的不同，这可能是个小错误，也可能会是个大问题。核心组件（例如非冗余路由器和交换机、计算资源上的主节点、存储以及认证系统）可能会导致网格资源的突然停止。当这类关键组件出现故障时，您很可能会不得不执行紧急维护，让资源离线。如果您可以在自己的架构中采用一些冗余性，就可能不会出现资源长时间离线的情况，甚至根本就不会出现这种情况。若计算节点或存储元素出现故障，可能不必将所有资源全部宕掉，而是可以在正常的维护窗口内或在资源使用不多的情况下就可以将故障解决。硬件故障不应该长期滞留不管，因为这些资源都是网格系统冗余性的一部分。另外，一些软件故障也需要快速解决。软件故障容易导致资源离线的情况发生。
- 主节点故障 —— 这类故障会导致网格或资源停滞，所以需要立即解决。由于主节点通常会控制在网格上执行的所有任务，因此主节点的缺失会导致所有调度和任务流控制的中断。出现这种情况时，最简单的方法是在替换或修复主节点的同时停止此受影响网格的其余部分。当网格恢复在线状态之后，所有计算机和存储节点都需要与主节点重新进行同步，最为容易的做法是冷启。您可以通过设置备用节点以便接管故障主节点来避免这类问题的发生。尽管如此，某些故障作业仍会出现，不过还好，新作业可以继续运行，由于切换而引起故障的作业在故障主节点重建并重启之后可以重新运行。
- 身份认证故障 —— 尽管身份认证故障并不像主节点故障那样严重，因为它通常不会影响当前运行的作业，但是这类故障也不容忽视，因为它会导致新作业无法提交，已完成作业的结果无法检索。这类故障通常立即就可以解决，不会导致整个网格或资源的停止。不过，新作业可能会无法启动，因为它们无法通过认证，这也就意味着它们将不能分配到资源。采用备份和冗余身份认证服务器可减少或消除新作业的宕机时间。
- 网络设备故障 —— 通常来说，网络设备故障发生的几率比其他故障发生的几率小很多。当设备故障发生时，除非网格具有足够的冗余性，否则通常就会导致整个网格的关闭。如果网络设备连接的是组织内不同的网格，则通常不需要在修复的同时关闭每个网格。当网络恢复时，这些网格会简单地重新进行同步。如果网络设备提供的是网格节点之间的骨干通信，则可能必须停止受影响的网格才能在问题修复之后干净地重启系统。
- 应用程序和作业故障 —— 这是最常见的故障。这类故障通常并不需要将网格离线，但是需要在对网格上运行的作业造成影响之前立即解决。通常，由作业或应用程序生成的运行日志会给出一些相关的信息，您可以与软件开发人员或应用程序提供商一起来诊断问题。
- 网格节点故障 —— 这可能是破坏性最小的一种故障。通常，如果主网格节点检测到某个网格节点出现故障，就可以重新分配任务，并对这个故障节点进行标记。接下来就可以修复出现故障的节点了。有时，可能网格节点已经出现故障，但是看起来却像是依然能与主网格节点一起工作。在这些情况下，您需要找出那些运行时间超过预期时间或产生错误结果的作业。这类错误不很常见，但还是需要注意一下。
发现趋势和问题
随着网格的日益流行和愈加高效，您一定会注意到自己的资源具有上限。幸运的是，使用网格系统，您不用过分担心当前网格的上限，因为可以通过添加新资源来对网格进行简单的扩展。在某些情况下，这可能只是修改何时、何地调度作业的问题。最困难的任务是跟踪何时需要进行扩展以及进行多大程度的扩展；或如何重新进行调度。此时就是统计数据发挥作用的地方了。通过分析长期统计数据，您可以发现资源的使用趋势。可以找出哪种资源最为流行以及这些资源何时使用得最多。
- 何时重新分发任务 —— 查看总体负载的快照和网格负载的平均值非常重要。网格的使用率可能显示为 50% - 60%，而感觉起来可能更接近 100%。通常，您会注意到 “突发性” 任务现总是在相同的时间定期执行。晚上和周末并没有多少人使用您的系统；系统也可能在这一周一直非常繁忙，但是下一周却基本上一直处于空闲。根据需要的不同，您可以对自己的任务负载更好地进行调度，从而更好地利用这些宕机时间。在对硬件进行升级之前，最好检查并确保您正在最大程度地利用当前资源。图 2 在左上图中给出了一个突发性任务的例子。这种系统更能从好的作业调度中获益。
图 2. 网格资源上的突发性任务
- 何时规划扩展 —— 在某些情况下，您会看到一种趋势说明网格利用率一直是 75%，或作业特点决定了重新调度是不可能的。在这些情况下，就需要确定何时需要进行升级或扩展。您希望避免系统的利用率高达 75% 。通过查看统计数据并将组织的将来规划和实现速度考虑进来，您就可以规划在系统达到某个标记值时就进行升级和扩展。这样可以减缓不可预料问题和紧急任务方面的工作。网格产生的大量统计数据对于提前进行良好规划来说非常重要。图 3 给出了一个网格资源可能需要进行扩展或升级的例子。注意左上图中系统的利用率已经接近其最大值了。
图 3. 高负载的系统
更新和升级
网格的更新非常重要，可以采用不同的方法来对网格进行更新。彻底关闭/启动会致使网格离线，但这却可以确保所有机器能同时进行升级。分阶段的升级可以让一部分机器停止操作，并对它们进行升级。虽然这种方法可能会降低网格的效率，但不会导致整个网格停止；因此在更新可能会导致整个网格关闭数天或数周的情况下，这种方法更有吸引力。
- 预定式更新 —— 理想地讲，您希望在对用户影响最小的情况下进行更新。您必须要将几件事情考虑进去，比如在出现不可预期的问题时如何访问外部协助，或者在任务过多时如何取得额外时间。尽管对用户影响最小的情况通常都发生在晚上或周末，但是这些时间也是最难获得外部协助的时候。通常，更为简单和安全的方式是在任务较少的工作日告知用户预定的宕机时间。您还应该考虑中断的数量、产生不可预期问题的几率，以及确定任务何时发生后，在需要时对外部协助的访问。
- 全面关机/更新 —— 因为这种更新会致使网格离线，所以通常最适合于在网格很少使用的情况下进行。提前确保所有参与方都了解您的计划也非常必要。这也会使更新和升级更加容易，因为在网格恢复在线后您将能够对每个组件进行验证。这种方式所导致的宕机时间最长，因此应该只有在进行主要的软硬件升级或由于严重安全问题不得不关机的情况下才能这样做。
- 分阶段关机/更新 —— 进行更新和升级的多种方法中的一种。允许您停止特定的组件，同时让其他组件继续运行。这提供了全面关机方式的大部分优点，且不会造成服务完全丢失。其不利的一面是它不太适合时间敏感型的更新，例如可能会对整个网格基础设施造成威胁的安全问题或严重的软件缺陷。
- 在线扩展 —— 增加网格节点或网格组件有时不需要进行任何形式的关机就可以完成。添加更多计算元素或其他网格存储系统可能会像使设备在线和更新其他主网格节点上的配置来提醒有新资源出现一样简单。
对于任何更新和扩展来说，提前进行测试和准备非常重要。另外，预定型更新还应考虑到使用非生产设备进行测试的时间和验证操作过程在真实事件中能否正常工作的时间。
测试和分阶段
下面是提供测试和分阶段服务所采用的一些技术的概要介绍，这样对软件进行的更新和修改就可以在应用到网格之前进行处理和组织了。虚拟机是很适合使用的一个工具，但是一个 3 节点或 4 节点的硬件设置也会非常好用。
- 硬件测试网格 —— 进行测试的一种方法是在测试实验室中创建一个小型的样例网格，其中可以包括几个已部署和计划要部署的设备。它是一种很好的用来测试构架设计以及不同硬件是如何一起工作的方法。它还可以为软件测试提供良好平台，因为它与实际网格硬件最为接近。缺点包括费用、空间、软件故障和系统恢复/映像。
- 虚拟测试网格 —— 虚拟化服务器和网络可以提供一个很好的环境用来在部署之前针对网格测试软件。很多虚拟化软件包都提供了一些简单的方法来访问保存过的系统状态、系统映像回滚，以及处理多个配置时的灵活性。这样做的缺点是网络设计和性能测试会有一些限制。图 4 给出了一个在虚拟环境中运行的网格测试环境的例子。
图 4. 虚拟测试网格
- 分阶段 —— 新设备在添加到实际的网格基础设施之前都应该在测试环境中进行一下测试。方法很简单：启动系统并去掉到实际网格的网络连接。在它与网格其他部分进行交互之前，请务必查看一下系统表现如何。您也可以通过预先在测试网格上对它进行一下测试来了解它与实际网格交互的情况如何。
结束语
现在您应该对如何让网格安全平滑地运作有一个清楚的概念了。下面我们对 “管理网格" 系列文章中的这一部分所讨论的内容进行一下归纳：
- 系统故障和恢复 —— 介绍了为防止发生大面积故障所应该考虑的一些重要问题。
- 趋势和问题 —— 每个系统都有自己的峰谷。了解趋势以便可以提前准备好网格。
- 更新和升级 —— 在分析完趋势之后，您就可以相应地对网格进行更新/升级以应对最坏的情况并确保网格的利用率低于 75% 这个标记值。
- 测试和分阶段 —— 最好能在一个不会损害系统中的敏感数据的类似“沙盒”的环境中对网格进行一下测试。如果出现故障，至少客户不会受到影响。您可以利用自己的经验和技能来修复并更新网格，并在准备好之后使其恢复正常运转。
参考资料 学习
获得产品和技术
讨论
作者简介  | | | 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 的一员。 |
对本文的评价
| 
