从 TeraGrid 中学习到的经验，第 1 部分: 管理大型地理分布的网格
TeraGrid 项目的主要目标是让研究人员可以尽可能简单且透明地在 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 软件也必须使用这些工具。尽管最初为 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 中用户和数据的可移动性。
