从 TeraGrid 中学习到的经验，第 1 部分: 管理大型地理分布的网格

      TeraGrid 项目的主要目标是让研究人员可以尽可能简单且透明地在 TeraGrid 站点内外移动作业和数据。

TeraGrid 是什么？

      TeraGrid 是美国国家科学基金会（NSF）资助的一个项目，用来为美国研究科学家提供一个集成的计算和数据基础设施。TeraGrid 现在包括 7 个资源提供者（RP）站点，每个站点都通过一条专用的 TeraGrid 网络进行连接，提供了高端的计算资源，其总体计算能力超过 50T FLOPS（每秒浮点操作次数），可用存储容量超过 600 TB。

      TeraGrid 用户可以使用网格技术来访问这些资源，从而存储数据、管理作业并在最适合这些任务的机器上执行计算操作。

      TeraGrid 站点所提供的计算平台包括 IBM IA64 集群、IBM 和 Dell IA32 集群，所有这些系统全部运行的是 Linux®；还提供了 32 处理器和 8 处理器的 IBM POWER4/AIX® 集群，一个 IBM Blue Gene®/L 系统，一个 Cray XT3，以及一些 SPARC/Solaris 节点。数据资源包括至少 6 个 IBM General Parallel File System（GPFS）系统和一些其他并行文件系统，包括基于 PVFS2（Parallel Virtual File System 2）、Lustre、Sun Microsystems 的 QFS 和 IBRIX 的文件系统，以及几个 MSS（Mass Storage System）和 HSM（Hierarchical Storage Management）系统。

     这种多样性的优点是可以满足几乎所有的计算需求或基于数据的科学研究需求。然而，拥有这 7 个地理分布的站点（如图 1 所示）所提供的众多选择之后，拥有一些工具来管理这些复杂性并简化对这些资源的访问就显得尤其重要，因为很多科学问题都具有非常复杂的多级工作流（这通常会涉及多个平台）。

      在这个项目的早期，这个组织认为对于科学研究人员来说，要完成自己的工作，使用网格技术是提供透明而简单用法的最有效方式。本文介绍了在各种资源上部署和验证网格资源的过程，同时还介绍了 TeraGrid 成员为了进一步利用网格技术而开发的几个项目。

图 1. TeraGrid 网络

Common TeraGrid Software Stack

TeraGrid 的核心思想是：作为用户，我们可以期望在所有的 TeraGrid 机器上默认可以访问相同的网格软件工具和服务器。为了实现这个目标，项目组定义了一组每个站点上都需要使用的网格软件工具，称为Common TeraGrid Software Stack（CTSS），并开发了一个可扩充的版本测试和单元测试工具Inca，它用来对所有 CTSS 组件的存在和功能进行可视化的验证。当前的 CTSS 版本是 2，它在所有的 TeraGrid 机器上进入生产应用已经有大约两年的时间了。

CTSS V2 中的以下组件对于一个生产 TeraGrid 资源来说都是必需的。有些服务器会在登录节点上运行，而有些站点则会在网格服务专用的节点上运行所有的服务器。大部分站点都运行了专用的 GridFTP 服务器节点来实现数据传输的最大性能。对于一些在大部分 UNIX® 平台上可用的工具（例如 Secure Shell，SSH）来说，启用网格的客户机必须在一个默认路径中，启用网格的服务器必须要对默认的端口进行监听。

CTSS 服务器的需求：

• Globus V2.4.3 Gatekeeper
• Globus V2.4.3 GridFTP Server
• Condor-G V6.5 或更新版本
• 启用 GSI（Grid Security Infrastructure）的 OpenSSH
• GX-Map 或其他网格-映射文件管理系统

CTSS 客户机的需求：

• Globus V2.4.3 作业提交、信息服务和 GridFTP 客户机
• Condor-G V6.5 或更新的作业提交工具
• 启用 GSI 的 OpenSSH 客户机
• MyProxy 客户机工具
• MPICH-G2 启用网格的 MPI（Message Passing Interface）实现
• Storage Resource Broker 客户机工具
• 记帐信息客户机
• 网格身份管理工具
• SoftEnv 环境管理工具

有关网格组件的注意事项

由于平台的差异，可能有些服务并不是在所有的 TeraGrid 计算机上都是需要的。标准底层工具中也可能存在一些区别。这些特例和区别介绍如下：

• 作为一个选择，我们可以在每台机器上运行 Globus V2.4.3 MDS（Monitoring and Discovery System）Information Server（它是基于 OpenLDAP 服务器的），在这种情况中，我们要配置这台服务器向一个中央 TeraGrid MDS 服务器进行汇报，后者可以对 TeraGrid 资源提供一个层次化的视图。
• MyProxy 基础设施是集中化的，它采用了一个惟一的 MyProxy 服务器，用来存储用户在所有 TeraGrid 站点上使用的证书。
• 专用的记帐和网格安全性组件在后面的 TeraGrid 帐号和分配管理一节中介绍。
• 除了网格软件组件之外，CTSS 还需要提供一个高性能的优化编译器，例如在 Power 架构机器上的 IBM xlC 编译器，或 Itanium® 架构上的 Intel icc 编译器。当然，诸如 MPI 之类的并行编程库也是必需的。尽管这些工具可能并不是网格软件，但是在配置 Globus GRAM 作业提交和执行服务时，我们的确需要考虑这些问题，要编译和使用 MPICH-G2 软件也必须使用这些工具。

---

TeraGrid 管理工具

TeraGrid 是一个大型的分布广泛的异构资源集，它具有非常严格的软件安装和配置要求。TeraGrid 项目的目标是将所有的计算机、数据和可视化资源随时简单、透明地提供给所有具有权限的研究人员使用。

除了常见的 24x7x365 可操作要求之外，这个项目还必须对所有 CTSS 软件组件自动进行周期性的版本和单元测试，这样在用户使用网格基础设施之前，项目成员就可以确定网格基础设施是否存在问题了。TeraGrid 项目要为每个用户都能在每台机器上创建一个一致的环境，这也是一个要求。最后，为了识别为用户或项目分配的资源，这个项目还需要能够将用户当作 TeraGrid 用户对待，这可能与一个对等的科学研究项目建立了关联；而不是当作某一个站点上的用户或者功能上匿名的个人对待。这需要采用一种集中机制来存储并自动分发功能数据，包括与所有 TeraGrid 项目有关的数据，与每个项目相关的主要调查人（PI）和其他用户，以及允许用户确定分配剩余计算时间和数据存储所使用的工具。

Inca 单元测试和版本测试

在当前版本的 TeraGrid software stack （基于 Globus Toolkit V2.4.3）部署过程中，我们清楚地看到一个问题：由于机器和软件组件的数量是如此之多，使得任何试图对每个组件的可用性和版本进行手工验证的努力都是不切实际的。因此，TeraGrid 项目开发了一个模块化的启用网格的版本测试和单元测试工具Inca。

Inca 是作为一组 Python 类实现的，这样我们就可以快速而简单地为各种网格组件构建一些简单的版本测试和更复杂的功能测试。这些结果可以通过一个安全的 Web 界面自动使用，如图 2 所示，这样 TeraGrid 成员就可以快速查看 TeraGrid 中每台机器的状态了，包括所安装的软件的版本，以及执行典型网格计算任务的能力，例如使用globus-url-copy 命令将一个文件从一个站点传输到另外一个站点上。

图 2. Inca 单元测试和版本测试工具

尽管最初为 Inca 开发的测试都主要着重于验证所安装的软件组件的版本；但是随着这个项目的不断成熟，Inca 项目组已经开发了更加复杂的功能测试，并且添加了存储测试历史的能力，这样我们就可以使用 Inca 来验证用户所执行的所有常见网格任务都可以正常工作。如果由于某种原因，某个测试不能正常进行，就会自动生成一条发往 TeraGrid 操作中心的 e-mail 消息并分发给出现问题的 TeraGrid 站点。

TeraGrid 帐号和分配管理

用网格术语来讲，TeraGrid 可以看作是一个虚拟组织（VO）和一个小站点的组合，每个站点又可以看作是一个 VO。TeraGrid 中的每个站点都可能有自己的帐号管理系统和机制来跟踪每个资源的使用情况。然而，对于 TeraGrid 来说，要作为一个 VO 进行操作，就必须采用这些本地管理和记帐系统与一个集中化的 TeraGrid 范围的帐号管理系统进行交互。

为了提供这种集中记帐服务，TeraGrid 与 Boston University 联合开发了 AMIE（Account Management Information Exchange）系统。AMIE 对所有 TeraGrid 项目和用户提供了一个集中的管理数据库，包括有关用户请求访问的资源的信息，以及这些资源已经分配给这些用户多长时间的信息。每个具有帐号管理系统的 TeraGrid 站点都在本地帐号管理基础设施和 AMIE 系统之间开发了一个接口。使用 AMIE 和本地帐号管理系统，就可以在添加新用户和项目时在所有的 TeraGrid 站点上自动创建帐号，这样我们就可以快速访问有关用户社区和使用 TeraGrid 资源的信息了。

用户还需要采用一些机制来访问为 TeraGrid 项目所存储的记帐数据。每次把一个计算任务提交到 TeraGrid 上执行时，这个任务所消耗的资源都对提交任务的用户进行收费，其计算单位采用一种抽象货币服务单元（SU）。有些用户同时是很多项目的成员，因此他们需要采用一些机制来查看自己所有的项目，并选择正确的项目对给定的任务进行收费。

TeraGrid 通过一个 tgusage 工具提供了这种功能，它会与一个集中的 AMIE 数据库进行交互，并基于用户请求对用户和项目进行查询。tgusage 工具还可以允许用户选择当前项目，或者在任何时候将计算任务提交到任何 TeraGrid 资源上要收费的项目。我们在系统级使用了一种类似的机制来验证用户具有访问特定资源的权限，并且当前项目具有足够的 SU 来执行这个任务。如果一个项目用光了自己的 SU，那么在通过 TeraGrid 或 NSF 对等分配委员会重新进行分配之前，用户就无法在这个项目之下再运行任务了。

总之，AMIE 工具为所有的 TeraGrid 站点提供了自动化的帐号管理，并为所有 TeraGrid 资源的使用情况提供了记帐功能，这对于如此庞大规模和复杂性的项目来说是非常关键的一种能力。

安全性基础设施

网格系统管理器所执行的最耗时的手工任务是对 GSI 帐号的管理。在基于 Globus 的网格中，每个用户都必须拥有 CA（Certificate Authority）所发行的一个证书。这个证书有一个使用文本字符串标识的 DN（Distinguished Name），它对于这个用户和证书来说是全局惟一的。

在网格中的每台机器上，必须要维护一个名为 grid-mapfile 的文件。这个文件包含了 DN 与本地用户帐号名之间的映射关系。如果没有其他工具，系统管理员必须手工对这个文件进行维护。显然，在包含数千个用户的大型分布式环境中，这是不可行的，因此我们必须要开发一种替代机制。

除了帐号映射之外，每个网格站点都还必须维护一个可信 CA 的集合。网格用户必须从一个可信 CA 获得证书才能访问 TeraGrid 资源。由于为了能够将授权扩充到大型的昂贵资源上，项目要信任 CA 来验证远程用户的身份，因此存在一个过程来让项目成员定义某个 CA 是否可信是非常关键的。

为了实现这种验证功能，TeraGrid 内部有一个安全小组负责审查网格 CA 的策略，并确定它们是否适合项目通过照片标识或其他手段对用户标识进行严格验证的要求。当我们确定要信任某个给定的 CA 时，每个站点还必须要维护一个已删除 证书的列表 —— 这些证书可能存在危险，或者已经丢失了，因此不能再使用了。管理员必须周期性地下载每个 CA 的 CRL（Certificate Revocation List），Globus Toolkit 并没有为实现这个功能提供什么自动化机制。

为了满足帐号映射和 CA 管理的这些需求，TeraGrid 项目与 NMI（NSF Middleware Initiative）项目合作开发了 gx-map 工具包。这个工具包是一组开源的 Perl 脚本，提供了网格站点所需要的一些常见功能，以及 TeraGrid 站点所需要的一些特殊功能。这些函数包括一个用户可以用来将自己的网格证书（DN）映射到每台机器上的本地帐号的程序，这样用户就可以负责采用自己喜欢的方式在 TeraGrid 中对自己的证书进行维护了。gx-map 工具包还提供了一些机制来管理一组 CA 文件，包括 CRL 的自动更新。使用 gx-map 工具，系统工程师可以集中精力来帮助用户解决问题，并增强 TeraGrid 基础设施，而不是将自己的时间花在手工管理大量用户证书列表和下载 CRL 上。

---

结束语

本文对 TeraGrid 简要进行了介绍，TeraGrid 目前是美国公共高端计算资源集。本文介绍了这个项目的动机，并简要介绍了维护这样一个大型的地理分布的网格所需要面临的挑战。要解决这些挑战，我们需要采用很多策略和工具，本文概要介绍了 TeraGrid 项目用来克服这些挑战所采用的最重要的一些方法。

随着高性能计算和网格技术的不断成熟，TeraGrid 也会继续成长和变化，但是本文中介绍的这些策略和工具为构建其他基础设施和添加站点提供了一个坚实的基础。通过应用类似策略或使用类似的工具，我们就可以开始研究 TeraGrid 或其他网格，甚至自己的集成网格资源集。

“从 TeraGrid 中学习到的经验” 系列中以后的文章将着重介绍 TeraGrid 中为在大量网格资源之间自动配置计算任务而提供的特殊功能和工具。这些文章还将介绍目前使用的或正在开发的一些数据管理策略，它们用来进一步增强 TeraGrid 中用户和数据的可移动性。