从 TeraGrid 中学习到的经验，第 2 部分: 管理大型网格上的大数据集

      宇宙论和分子生物学等领域的研究所产生的数据正在以前所未有的指数级速度增长，这可能会带来许多收益 —— 从提高我们对宇宙起源的理解，一直到疾病的预防和治疗。本系列的 第 1 部分 对 TeraGrid 简要进行了介绍 —— 那是一个面向科学的大型网格，提供了 PB 级的分布式高性能和归档存储，并展示了 TeraGrid 应对网格服务的开发与部署的一些关键策略。

      在第 2 部分中，我们将进一步讨论 TeraGrid 为新一代科学和工程研究所提供的服务。本文将探索驱策我们为网格开发健壮的数据基础设施的用户需求，以及这些用户需求背后隐藏的技术需求。还将介绍传输和管理数据所使用的一些 Common TeraGrid Software Stack（CTSS）客户机和服务器工具的部署和配置，并简要说明此小组进行的基准测试和有效性验证工作。

      您还将了解到 San Diego Supercomputer Center（SDSC）和 IBM 开展的开发工作，SDSC 与 IBM 协力通过 IBM General Parallel File System（GPFS）与标准网格技术的结合提供全球化文件系统访问。目标是为用户访问远程数据提供一个透明的高性能接口，使其不必再显式地在计算机之间传输数据，也不用考虑数据位置。

     阅读完本文后，您应能够理解管理网格数据的各种模型以及在网格标准和 Globus Toolkit 中支持这些模型的工具的实现。并简要了解 TeraGrid 项目是如何达成支持数据管理、利用标准工具以及开发构建于网格标准之上的功能性这一任务的。

网格中的用户和数据

      在过去 5 年中，典型应用程序输入输出的大小和复杂性方面的用户需求呈指数级增长，常见需求从数 TB 增长到数十 TB 乃至数百 TB。在生产环境中，该小组发现，不管文件系统有多大，数据集总是在不断增长，不断填满可用空间。在任何大型网格中 —— 包括 TeraGrid 在内，每个计算资源通常都有一个与之相关的存储资源，例如文件系统，只能通过该存储资源及其相关登录节点访问。

      这种存储的本地性与数据和文件系统规模不断增长的趋势使得网格环境中出现了特有的一些挑战。用户不仅希望能够存储数据，还希望能够在可用性最佳的网格资源上使用这些数据，因而必须能够将数据获取到机器中。在网格中，这可能意味着要将 TB 级的数据通过网络长距离传输。TeraGrid 有一个专用的网络，其速度已在很长一段时间内保持恒定，而数据需求却增长迅猛，因此从用户角度来看，网格必须更有效地利用这种恒定的网络带宽，继续高效工作。

数据的不同类型

      在管理员为网格上的数据管理和传输提供解决方案时，或在用户选择解决方案时，必须要考虑两个描述数据集的主要变量：粒度，文件的数目及其组织的复杂性。

      粒度 是指我们处理的文件或记录的规模。例如，一个在数百个处理器上运行的大型仿真程序可能会将整个仿真内容作为一个数百 GB 的文件进行读写，也可能会让各进程只读写代表其各自负责那部分仿真数据的文件。随之而来的就是文件的数目及其组织的复杂性。对于某些领域（例如天文学）的数据集，可能会有数十万个文件分布在复杂的目录层次结构中，这些目录可能包含很多层，表示从夜空中所捕获的数据的空间排列。

       对于任何给定的任务来说，应用程序利用数据的方法和所处理数据的类型也会影响到数据移动的最佳机制。应用程序通常需要对数据进行预处理、仿真或合成以及后处理，从而生成一些有用结果。最有效的计算或可视化资源对于每个任务来说都可能不同。有些应用程序可能只需要对大型数据集的几个文件进行处理，而另外一些应用程序则可能要求仿真使用的所有数据均可用，以便呈现完整的结果。

数据传输模型

        这种数据的异构性需要导致 TeraGrid 小组至少要为访问网格上的远程数据提供两个模型，它们都是为了更简便、更有效地利用可用网络带宽。尽管这两种模型无法涵盖管理网格数据的所有可能选择，但该小组相信它们已经合理地涵盖了大部分情况，而不会导致用户选择数据移动和访问机制的复杂性过高。

        第一种访问远程数据的模型 —— 也是传统的模型 —— 是通过标准或专用的客户机和协议访问，例如 GridFTP，它为文件传输提供了一种基于 FTP（File Transfer Protocol）的机制；或 SRB（Storage Resource Broker），它将来自多个存储位置的数据和元数据聚集到一个接口中，并提供存储和检索来自 SRB 服务器上的文件的机制。这适用于只需传输少量大型文件的情况，也适用于仅需从一个大型集合中获取一个或几个文件的情况。但有时需要访问大型的复杂数据层次结构，并且应用程序需要访问某个集合中的所有文件（或其中的绝大部分），此时这并非最有效的方案。在此类情况下，传输大量文件的负载会导致网络利用率极低，远程资源上的任务需要很长时间来准备和启动。

        SDSC 与 IBM 在 TeraGrid 项目中探索的一种新模型 —— 也是 DEISA（Distributed European Infrastructure for Supercomputing Applications）European Grid 所采用的模型 —— 通过与多个远程网格位置间的网络提供了本地高性能的并行文件系统的共享。此模型将 IBM GPFS 与网格标准技术结合在一起，允许整个计算机网格访问一个文件系统，如同访问本地存储设备一样，它以一种对用户透明的方式来处理身份验证与授权。

        尽管网络延迟可能会使这个模型对于特定 I/O 密集型的程序而言效率不高，但在使用网络和网格存储资源方面效率很高，这是因为用户仅需要一个文件系统上的一份文件副本即可，只有用户或应用程序直接访问的数据会通过网络进行传输，因此不必在任务开始前传输大量远程站点的数据。

数据基础设施实现
        在介绍 TeraGrid 的数据基础设施工具时，了解一下 CTSS 中的某些开发成果非常有用，它们主要构建于现有网格标准之上，并需要每个 TeraGrid 资源都进行安装和支持。这种功能为支持数据在 TeraGrid 中的移动定义了一个基准，并且也提供了第一个模型为远程数据访问所提供的功能。理解 GPFS-WAN 的成果也非常有用，它提供了一种机制，使用标准的 UNIX® 工具和 I/O 操作来访问网格上的远程数据。目前，希望提供这种能力的 TeraGrid 站点可在开发时选择是否支持此机制。

GridFTP

        GridFTP 不是一个完整的独立标准。而是广泛应用的 FTP 协议的一组标准扩展，旨在支持高性能传输和网格安全模型。GridFTP 标准是较为成熟的标准之一，多年前就已有投入实际使用的实现。但只有基于标准的 Globus Toolkit 的最新发行版才提供了对 GridFTP 完整扩展集的支持。随着软件的不断成熟，整个 TeraGrid 中的软件部署也越来越成熟。

       GridFTP 服务的最重要开发领域已集中到并行性和易用性。在过去的 GridFTP 实现中，发送和接收主机之间可使用并行 TCP 流来更好地利用网络。然而，这种功能限制了网格中任意两台计算机间的可用带宽 —— 通常是一条 1 GB 的以太网链路，约为 100 MB/秒。以这种速度，传输 1 TB 的数据可能需要 3 个小时，无疑，传输大型数据集可能需要用上几天甚至几周的时间。

       最新的实现添加了对一种称为分段（striping） 的特性的支持，应用这项特性，各端的文件传输分割到多个主机，从而分布负载，为文件传输提供更好的带宽。目前在 TeraGrid ，每个站点都配有 4 到 10 台专用 GridFTP 服务器来处理大型的并行传输请求。

        在GridFTP 协议的完整实现中，您可设立大批参数，包括并行级别和分段级别，以及用来通过 TeraGrid 网络进行高性能数据传输的各种缓冲区和 I/O 参数。但是为任何给定的计算机组合选择最有效的参数集都是一个非常耗时的过程，使用标准 Globus 命令行 GridFTP 客户机执行一项特定任务可能会成为一个相当不透明的过程。因此，小组觉得 TeraGrid 必须提供一种简单易用的工具来执行大部分选择最佳参数，并为用户构建执行文件传输任务的命令。

        小组开发了一种名为 tgcp 的工具，它允许各站点定义 GridFTP 服务器和在主机间传输数据所用的最佳参数。随后，用户就可以使用语法类似于

cp

这样的简单命令传输文件，tgcp 会将这些命令转换成最有效的 GridFTP 命令，并代表用户执行操作。通过去耦用户访问客户机所用的 GridFTP 客户机和工具，小组使升级 GridFTP 客户机和服务器的灵活性提高了一个级别，并且优化了传输参数，从而改善了所提供服务的水平，而用户甚至不会注意到这一切。

GPFS-WAN 文件系统

        GridFTP 中的一个非常活跃的开发领域是 WAN 或网格文件系统的供应。目前使用的系统基于 IBM GPFS，TeraGrid 内部将其称为
GPFS-WAN。

        GPFS-WAN 在 TeraGrid 上是作为一个 200 TB 的文件系统实现的，可从分布在整个 TeraGrid 上的多种计算和可视化资源的所有节点处访问它。采用这种设置，用户可以在广泛分布的异构资源上执行准备工作、计算任务、后处理以及可视化处理，而不需要执行显式的数据传输操作。

        然而，在网格上提供并行文件系统必须要克服两个主要的挑战：其一是身份验证和用户身份映射；其二是在重负载的情况下提供高性能处理能力，此时可能会有数千台机器同时访问同一个文件系统。

        之所以需要用户身份映射，是因为 TeraGrid 包含多个单独的管理域，每个站点都负责维护自己的用户列表和用户 ID（UID）。例如，某个用户在一个站点上的身份可能是
jdoe，UID 为 455233；在另外一个站点上其身份可能是 johnd，UID 为 983491。由于 NFS（Network File System）和 GPFS 这样的文件系统通常用 UID 值来确定文件权限，因此某个用户在一个站点上写入的文件在另外一个站点上可能被认为不归该用户所有，因为 UID 不同。

       为了解决这个问题，IBM 为 GPFS 增加了一组功能，允许通过全局惟一名（GUN）在 UID 之间进行映射。服务器节点使用一个函数在用户的 UID 和 GUN 之间进行映射；客户机使用了另外一个函数在 GUN 和本地 UID 之间进行映射。采用这种方法，GPFS 将 UID 值从客户机重新映射到服务器端，从而总是使用相同的 UID 值在这个文件系统中存储文件。这些机制并没有指定哪种令牌用作 GUN，因此实现可自由选择对于自己有意义的模型。

        对于 TeraGrid，TeraGrid 小组严重依赖 Globus Toolkit 及其相关的安全层（即 GSI）来实现 TeraGrid 上的单点登录功能，自然也就采用这种机制实现 UID 映射。SDSC 和 IBM 合作实现了一组映射函数，实现本地 UID 到 Globus 识别名（DN）的映射以及 DN 到本地 UID 的映射。现在，TeraGrid 小组可在 TeraGrid 上的任意位置部署文件系统，用户可在任意站点上使用这个文件系统，不必担心不同站点上的身份不同的问题。

        由于可能会有大量用户和数千个节点同时访问文件系统，因此为整个用户群提供一致的高性能处理能力就成为一个非常严峻的挑战。对于 GPFS-WAN 来说，TeraGrid 小组通过为文件系统分配大量的磁盘空间（大小是其他任何高性能文件系统的两倍）入手，确保底层存储空间足以满足可用带宽的需求。

        IBM GPFS 的基本特征之一就是可分配给某文件系统的服务器节点数量具有高度灵活性，因而 TeraGrid 小组也可以分配 64 个服务器节点（每个节点都有一条千兆以太网连接）来维护这个文件系统。TeraGrid 网络主干的带宽只有 30 GB/秒（GBps），理论上来说需要数量超过两倍的服务器来满足网络需求，这样可以确保即使在可伸缩性不好的情况下，TeraGrid 也可以完全利用网络带宽资源。

        另外一个体现出灵活性的领域是纯粹用于数据传输和用于元数据访问（也就是说，列出某个目录的内容或创建一个新文件）的服务器数量的对比。大型数据操作不应干扰尝试访问文件系统的用户，这一点非常重要。因此，小组分配了 6 个服务器节点来执行元数据操作，还提供了超过需求的大量的容量来确保文件系统在高负载情况下的响应能力。

结束语
        尽管网格计算已问世多年，但网格模型的大规模实现仍然是一个相当新的课题。用户快速采纳网格工具的领域可能就是数据的访问和移动。管理员必须迅速行动，才能跟上日益增长的用户需求；在通过网格访问远程数据并有效地服务用户群方面，该小组积累了丰富的经验，也学习到了很多教训。

        小组对于显式数据传输工具（例如 GridFTP）方面的经验说明，尽管这些网格工具相对于其他选择来说性能更好，但依然要作出大量的努力，在为用户提供更好的性能同时使用户能够快速、高效地利用这种性能。这一工作会通过供应 tgcp 之类的工具及不断开发其他更为先进的数据管理接口、组件和标准得以延续。

        虽然广域的并行文件系统并非所有使用模式的最佳选择，但小组发现，用户往往倾向于以它作为显式的数据传输模型，尽管此时延时和访问模式使其将数据移动到本地存储资源的效率很低。从很大程度上来说，这是因为使用户具备访问远程资源并启动任务的能力所花费的时间比下面这种情况少：用户需要提前将正确的文件移动就位，并调整作业脚本指向新文件的位置。这种模型提供了一种独具特色、往往也极为重要的效率级别，可以高效地利用用户的时间，这是网格计算的终极目标，对 TeraGrid 而言更是如此。