数据管理：重点概念

GT4中的数据管理部分综述

globus工具集提供了许多处理数据管理的组件。这里展示了高层次的综述，下面的组件链接中给出了独立组件的详细信息。

数据管理可用的模块分成两个基本的类别：数据移动和数据复制。

第一章：数据移动

在globus工具集中有两个数据移动相关的组件：globus GridFTP工具和globus 可靠文件传输（RFT）服务

1.GridFTP

GridFTP是GFD（网格建议论坛）定义的一个协议，并且是IEFT FTP工作组之前的一个草稿。GridFTP协议提供安全，健壮，快速和高效的数据传输。globus工具集提供了这个协议最常用的实现，尽管其他已经存在了（主要关联到私有的内部系统）。

globus工具集提供了：

一个叫做globus-gridftp-server的服务器实现，

一个叫做globus-url-copy的可脚本化的命令行客户端

一套用于定制客户端的开发函数库

虽然globus工具集不提供交互式客户端，GridFTP用户指南确实提供了至少是一个由其他项目开发的交互式客户端。

如果你想让数据对于他人可用，你需要在主机上安装一个可以访问那些数据的服务器并且确保有一个对于这个存储系统可用的合适的数据存储接口（DSI）持有这些数据。这典型地意味着一个标准的POSIX文件系统，但是DSIs对于存储资源代理（SRB）确实存在，高性能存储系统（HPSS），和Wisconsin大学Condor团队中的NeST--Madison。这有DSIs的完整目录.如果你需要的存储系统的接口没有列在这，或者使用这个系统的一个足够广泛的团体被确定，我们可以有能力获得联合资金来开发必要的接口。

如果你只是想存取别人使之可用的数据，你需要一个GridFTP客户端。globus工具集为这个目的提供了一个叫做globus-url-copy的客户端。这个客户端能通过一系列协议（http，https，ftp，gsiftp，和file）来存取数据。如上所述他不是一个交互式客户端，但是一个命令行接口，适合脚本化。如例所示，下面的命令：

globus-url-copy gsiftp://remote.host.edu/path/to/file file:///path/on/local/host

会从一个远端主机传输一个文件到本地可访问的在第二个URL中指定的路径

最终，如果你想添加通向存储在GridFTP服务器下文件的入口，或者你需要功能性地定制客户端，你可以用我们强大的客户端函数库来开发定制客户端功能。

2.可靠文件传输（RFT）服务

虽然globus-url-copy和GridFTP总体来说是一个非常强大的工具集，有一些特性不总是最理想的。首先，GridFTP协议不是一个网络服务协议（它没应用简单对象访问协议SOAP，网络服务描述语言WSDL等）。其次，GridFTP需要客户端在整个传输期间保持一个对服务器开启的套接字连接。对于长时间的传输这是不合适的，例如在笔记本上运行。虽然globus-url-copy应用GridFTP健壮的特性去恢复远端的故障（网络中断，服务器故障等），客户端或客户端主机的故障意味着恢复是不可能的，因为恢复需要的信息存储在客户端内存中。解决这些问题需要的就是一个基于网络服务协议的服务接口，这个服务接口在可靠存储中存留传输状态。我们提供了这样一个叫做可靠文件传输（RFT）的服务。

RFT是一个服从网格服务的网络服务资源框架（WSRF），他为数据移动提供类似作业调度的功能。你简单的提供一系列源和目的地的URLs（包括路径或文件目录）然后这个服务将你的作业描述写入数据库，再然后代表你移动数据。一旦服务接受了你的作业请求，与它的交互与其它作业调度非常类似。提供了查询传输状态的服务方法，或者你可以用标准的WSRF工具（也在globus工具集里有所提供）来订阅状态改变事件的通知。我们提供了这个服务实现和一个非常简单的客户端，这个服务实现安装在网络服务容器中（像所有的网络服务一样）。有可用的java类来进行定制开发，但是由于缺少时间和资源，仍需工作要做以让它简单。

第二章：数据复制

副本定位服务（RLS）是网格环境下数据管理服务的一个组件。RLS是一个在网格环境下提供追踪一个或多个复件，或副本，或文件的能力的工具。这个包含在globus工具集中的工具对于需要得到存在的文件在网格中的位置的用户或程序特别有用。

1.副本定位服务（RLS）

RLS是一个简单的追踪副本在物理存储系统中位置的登记处。当文件被创建的时候用户或服务在RLS中登记文件。以后，用户查询RLS服务器来找到这些副本。

RLS是一个分布式的登记处，这意味着它可能包含在不同站点上的多个服务器。通过分配RLS登记处，我们能增加系统整个的规模并且比单个集中的目录更可能存储更多的映射。我们也避免在网格数据管理系统中创建一个独立的故障点。如果需要，RLS也可以被部署成一个独立，集中地服务器。

在详细解释RLS之前，我们需要定义一些术语。

逻辑文件名是文件内容的一个唯一的标识符。

物理文件名是在存储系统中文件复件的位置。

RLS的工作就是保持逻辑文件名和一个或多个副本的物理文件名的这种联系，或者说映射。用户可以向RLS服务器提供逻辑文件名来查找所有登记的副本的物理文件名。用户也可以查询RLS服务器来找到和一个特定的物理文件地址相关联的逻辑文件名。

另外，RLS允许用户使登记在目录中的逻辑或物理文件名与属性或者描述信息发生联系（就像大小和检验和）。用户也可以基于这些属性进行查询。

2.应用RLS：一个例子

一个应用RLS作为数据管理框架一部分的系统的例子就是LIGO项目。LIGO的科学家们检测重力波存在的设备在两个站点。在一个科学实验运行期间每一个LIGO设备站点产出百万个数据文件。在其它八个站点上的科学家想拷贝这些大量的数据到他们的本地存储系统以便他们可以在这些数据上运行科学分析。因此，每一个LIGO数据文件可能在网格中最多被复制在了十个物理位置。LIGO将RLS服务器部署在每个站点上来记录本地映射并且搜集在其它LIGO站点上的映射信息。为了找到数据文件的复件科学家从叫做轻量数据副本（LDR）的LIGO数据管理系统请求文件。LDR查询RLS来查明是否有这个文件的本地副本，RLS告诉数据管理系统这个文件在网格中的存在地。然后LDR系统生成一个请求去复制这个文件到本地存储系统并且在RLS服务器中登记这个副本。

LIGO通常在它的生产数据管理环境中使用副本定位服务。这个系统记录了三百万个逻辑文件名与三千万个物理文件位置的映射。

第三章：高级数据服务

GT4.2.0也提供了高级数据管理服务将两个已经存在的数据管理组件结合了起来：RFT和RLS

1.数据复制服务

在GT4.2.0的技术预览中，我们设计实现了一个为网格文件提供基于牵引的复制能力DRS。DRS是一个建立在两个GT数据管理组件之上的高级数据管理服务：RFT和RLS。

DRS的功能是确保指定的文件集存在于一个存储站点。DRS开始通过查询RLS来发现需要的文件存在于网格中的位置。文件定位以后，DRS创建一个由RFT执行的传输请求。传输完成以后，DRS用RLS登记这个新的副本。

DRS是作为一个网络服务实现并遵守网络服务资源框架说明书。当收到一个DRS请求，它创建一个网络服务资源来保持每个正在复制的文件的状态。包括在文件上的哪个操作成功了或失败了。

第四章：数据管理：RLS中的重点概念

副本定位服务是一个在网格环境下提供追踪一个或多个文件的复件或副本能力的工具。这个包含在globus工具集中的工具，对于需要在网格中查找存在的文件的位置的用户或程序特别有用。

1.RLS概览

副本定位服务是网格环境下的一个数据管理组件。RLS是一个简单的追踪副本在物理存储系统中位置的登记处。当文件被创建的时候用户或服务在RLS中登记文件。以后，用户查询RLS服务器来找到这些副本。

RLS是一个分布式的登记处，这意味着它可能包含在不同站点上的多个服务器。通过分配RLS登记处，我们能增加系统整个的规模并且比单个集中的目录更可能存储更多的映射。我们也避免在网格数据管理系统中创建一个独立的故障点。如果需要，RLS也可以被部署成一个独立，集中地服务器。

另外，我们正在开发一个高级的WS-RF数据复制服务，这个服务用globus的RFT复制文件然后在RLS中登记新的副本。这个服务在GT4.2,0的发布版中作为一个技术预览模块是可获得的。

2.一些术语

在详细解释RLS之前，我们需要定义一些术语。

逻辑文件名是文件内容的一个唯一的标识符。

物理文件名是在存储系统中文件复件的位置。

RLS的工作就是保持逻辑文件名和一个或多个副本的物理文件名的这种联系，或者说映射。用户可以向RLS服务器提供逻辑文件名来查找所有登记的副本的物理文件名。用户也可以查询RLS服务器来找到和一个特定的物理文件地址相关联的逻辑文件名。

另外，RLS允许用户使登记在目录中的逻辑或物理文件名与属性或者描述信息发生联系（就像大小和检验和）。用户也可以基于这些属性进行查询。

3.应用RLS：一个例子

一个应用RLS作为数据管理框架一部分的系统的例子就是LIGO项目。LIGO的科学家们检测重力波存在的设备在两个站点。在一个科学实验运行期间每一个LIGO设备站点产出百万个数据文件。在其它八个站点上的科学家想拷贝这些大量的数据到他们的本地存储系统以便他们可以在这些数据上运行科学分析。因此，每一个LIGO数据文件可能在网格中最多被复制在了十个物理位置。LIGO将RLS服务器部署在每个站点上来记录本地映射并且搜集在其它LIGO站点上的映射信息。为了找到数据文件的复件科学家从叫做轻量数据副本（LDR）的LIGO数据管理系统请求文件。LDR查询RLS来查明是否有这个文件的本地副本，RLS告诉数据管理系统这个文件在网格中的存在地。然后LDR系统生成一个请求去复制这个文件到本地存储系统并且在RLS服务器中登记这个副本。

LIGO通常在它的生产数据管理环境中使用副本定位服务。这个系统记录了三百万个逻辑文件名与三千万个物理文件位置的映射。

4.RLS的组件

RLS的设计由两种类型的服务器组成：本地副本目录（LRC）和副本位置索引（RLI）。

本地副本目录（LRC）存储着数据项的逻辑文件名和这些数据项副本的物理位置之间的映射。客户端查询LRC来发现与一个逻辑文件名相联系的副本。最简单的RLS部署由一个单独的担当一个或多个存储系统登记处的LRC组成。典型的，当一个RLS部署在一个站点上，管理员populates它反映存储系统或本地文件的目录。如果一个新的数据文件由一个工作流管理者或数据出版服务生产出来。这些服务典型地把新创建的数据文件登记在RLS中并作为他们出版数据的一个过程。对于一个中等强大的后端有MySQL关系型数据库的工作站，我们将LRC部署在上面的性能研究表明目录可以承受大约每秒600次更新和2000次查询。

对于分布式的RLS部署，我们也提供了一个高级副本位置索引服务器（RLI）。每个RLI服务器搜集在存储在一个或多个LRC上的关于逻辑文件名的映射信息。一个RLI也应答关于这些映射的查询。当一个客户端想找出存在于多个位置的副本时，客户端会向RLI提交一个查询，而不是一个独立的LRC。作为回应，RLI会返回所有它了解的包含了查询中逻辑文件名的LRC的列表。客户端然后查询这些LRC来找到副本的物理位置。

分布式RLS部署利用软状态更新协议把信息从LRC发送到RLI。每一个LRC周期性地将它的逻辑文件映射信息发送到一系列的RLI上。RLI搜集这些映射信息并根据这些信息应答查询。RLI中的信息时间到并周期性地通过后来的更新而更新。利用这种软状态协议的优点就是当RLI故障后恢复操作，它的内容可以用这些更新来重建。

因为每一个LRC会保持数百万逻辑文件映射，LRC到RLI的更新可能变的很大。通过网络发送它们可能很慢，特别是在广域网上；当更新到达一个RLI时，它们可能在那消耗大量的存储空间。使这些更新更高效的一个选择就是压缩它们的内容。多种压缩策略都是可用的。我们为RLS选择实现的是布鲁姆过滤器压缩。每一个本地副本目录周期性地创建一个总结它内容的位图，这种总结是通过对注册在LRC中的每个逻辑本件名采用一系列哈希函数并在位图中设置相配的位来实现的。

5.RLS部署中的配置操作（不重要）

我们可以通过部署LRC和RLI服务器的数目和配置的LRC和RLI之间的更新来决定RLS的性能和可靠性。例如，我们可以通过配置系统以便每一个LRC都更新多个RLI索引来提高可靠性。

实际上，现在RLS系统的部署相对较小。例如，LIGO物理协作在十个站点上部署了RLS。为了部署这种规模RLS通常部署为全连接配置，每个站点上都部署一个LRC和一个RLI，并且所有的LRC向所有的RLI发送更新。这样的配置有一个优点就是每一个站点都有这个分布式系统中一个完整的副本图。

对于大型的部署，这种配置不太可能好衡量，因为有大量的更新需要在服务器之间传输和在RLI上存储。例如，在一个拥有数百个RLS站点的系统中，全连接部署需要每个站点发送和接收数以百计的更新。在这样大的部署中很可能系统会被分区以便每一个RLI只会收到LRC一个子集的更新。

理想化的，分布式RLS的管理应该自动自检，这样LRC和RLI互相发现并且他们之间的更新在服务器加入或离开系统的时候被自动的分配来平衡负载。虽然我们在研究自动会员管理的方法，包括RLS服务器的点对点自管理，当前RLS的实现利用了LRC和RLI一个简单的静态配置。管理者必须手动地改变服务器之间的更新方式。

6.RLS和副本一致性服务

未完待续…