关于数据网格体系结构的论文学习笔记--转发别人的

lihp780328

关于数据网格体系结构的论文学习笔记
南京航空航天大学 计算机系 张海建
                             
  目  录
1.        数据网格：一个用于大型科学数据集的分布式管理与分析的体系结构（JNCApaper）        2
1.1 介绍        ………………………………………………………………………………………2
1.2 数据网格设计        2
1.3 核心数据网格服务        3
1.4 高层数据网格组件        4
2.用于分布式data-intensive科学的协议与服务（ACAT3）        7
2.1 协议、APIs、服务        7
2.2 数据传输协议：GridFTP        7
2.3拷贝管理        8
3.在高性能data-intensive计算中的安全有效的数据传输和拷贝管理（msc01）        9
3.1 Data-intensive Computing Requirements        9
3.2 Globus体系结构和数据管理        9
3.3 GridFTP：一个安全、有效数据传输机制        9
3.4 拷贝管理        11






















1.        数据网格：一个用于大型科学数据集的分布式管理与分析的体系结构（JNCApaper）
1.1 介绍
现在的科学计算需要大量的数据，在一些领域，比如全球气候变化，高性能物理等，它们所关注的数据已经成tb的增长，并且很快将达到pb级。这一领域的研究人员需要访问分析这些数据（经常使用一些复杂的并且昂贵的计算技术），但这些研究人员通常是在地理上是分布的，同样，他们的研究所以依赖的计算与存储资源也是分布的。
这种组合导致了现有的数据管理基础设施无法满足的复杂的，stringent性能要求。这种科学计算会产生大量查询，这些查询就会要求访问（或是超级计算级的计算）tb级的数据。有效而可靠的执行这些查询可能需要小心的管理tb级的缓存，在广域网上的gigabit数据传输，对数据传输和计算能力的合理调度，准确的性能估计用于指导数据拷贝的选择，和其他一些高级技术。这些技术使我们能极大限度的使用存储、网络、计算资源。
现在需要一种体系结构来帮助我们鉴别需求，通用于不同的系统的组件，并且把多种不同的技术整合在一起应用在pt级的data－intensive应用领域。
我们现在提出了一种体系结构，称作“数据网格”，我们的目标是定义需求（一个数据网格必须满足的）、（网格的实现所需要的）组件与APIs。

1.2 数据网格设计
有四个准则驱动了我们的数据网格体系机构的设计。
Mechanism neutrality：
Policy neutrality：
Compatibility with Grid infrastructure
Uniformity of information infrastructure
根据这四个准则，我们定义了一个层次的体系结构，如下图：

1.3 核心数据网格服务
我们特别关注两个基础服务：数据访问和元数据访问。
数据访问服务提供了机制，用于访问、管理和初始化存储在存储系统中的第三方传输。
元数据访问服务提供了机制，用于访问、管理关于数据在存储系统中存储的信息。

1.3.1 存储系统与网格存储API
在一个网格环境中，数据可能被存储在不同的位置和有着不同特性的存储设备上。我们认为，应用不应该需要知道这些底层的机制就可以访问特定位置的数据。取而代之的是，我们应该提供给应用程序一致的数据视图，并且通过一致的方式访问数据。这种需求可以通过存储系统抽象和我们的网格存储API来满足，所有这些定义了我们的数据访问服务。

1.3.1.1        数据抽象：存储系统
我们介绍一个基本的数据网格组件：存储系统。我们定义存储系统是这样一个实体，可以被一个函数集合操作（创建、销毁、读、写），它（存储系统）可以操作称为文件实例（即命名的字节序列）的属性。
注意，我们定义的存储系统是一个逻辑设备：一个存储系统可以由许多存储技术实现。
我们定义的“文件实例”也是逻辑上的。一个存储系统持有数据，这些数据可能存储在文件系统、数据库或其他的系统中；我们不关心数据是如何存储的，我们只知道我们要处理的基本单元是一个命名的无间断的一串字节。文件实例并不意味着数据是存储在传统的文件系统中，比如：一个数据网格的实现可能采用象SRB这样的系统访问存储在数据库管理系统中的数据。
        存储系统将要与文件实例结合在一起，每个文件实例包含一些属性包括名字，大小，访问限制等。文件实例的名字只对相应的存储系统有意义。

1.3.1.2        网格存储API
数据网格用户看到的一个存储系统的行为是由数据网格存储API定义的，数据网格存储API定义了对存储系统和文件实例的一系列操作。这里的API的功能还在完善，不过肯定应该包括对命名的文件实例的远程请求读/写，察看文件实例的属性（比如大小）。此外，为了支持拷贝管理服务的优化实现，我们要求一个第三方的传输操作，用来在不同的存储系统之间传输文件实例的内容。
虽然上面列出的功能都看起来很简单，但是当实现起来的时候，要考虑到方方面面的因素，就会复杂很多。比如：为了对远程访问进行安全限制，存储系统访问的功能必须与每个节点的安全环境结合起来；高层功能的健壮性要求在存储系统和网络接口中实现预留功能；应用程序可以根据访问模式、网络性能等，来提示存储系统使用优化的行为来提供服务。类似的，存储系统应该能够监控自身的性能。

1.3.2 元数据服务
元数据服务提供了一种方法来发布和访问元数据。
元数据可以分为很多种。有关于文件内容信息的元数据，关于数据所在环境信息的元数据，有助于应用程序处理数据的元数据――我们称这些为“应用元数据”。这些元数据可以看做定义了一种逻辑结构或语意，把这些逻辑结构或语意应用到那些未解释的字节串上就构成了一个文件实例或一个文件实例集合。另一种元数据是用来描述数据网格自身的构造层的：比如，关于存储系统的细节（容量，使用策略），关于一个存储系统中文件实例的信息。
元数据服务提供了一个统一的方式来命名、发布和访问这些不同的元数据。每一种元数据在它的访问频率、更新机制、与其他网格组件之间的逻辑关系等方面有它自己的特性。有的应用可能有它自己特有的元数据，不过我们认为我们应该使用一种统一的方式访问所有的元数据。
为所有的元数据指定一种通用的结构显然是很有难度的。有的应用通过以一种自描述的格式（NetCDF，HDF）存储数据，把元数据配置库建造在一列文件实例上。高能物理应用成功的使用了一种特别的索引结构。Digital Library正在为不同领域开发一套元数据。其他的组织继续从事用XML来表示应用元数据。
如果是在一个大的数据网格环境中，我们又需要考虑其他的一些要求，这又增加了复杂度。我们不仅要考虑如何通过一种方式整合不同的元数据存储与表示，还要考虑如何在一个分布式的环境中让他们有效的协同工作。它必须是可以升级的，支持由大量组织的大量信息源产生的大量实体（元数据）。这个服务必须是健壮的，组织必须有对他们的信息的本地控制能力。
通过对这些需求的分析，我们得出一个结论，元数据服务必须是一种具有层次结构的分布式系统。分布会导致高效检索的复杂性，不过可以通过让数据组织利用元数据服务的层次结构特性来解决。
这些分析使得我们计划元数据服务可以被当做一种分布式的目录服务来对待，就象由LDAP所提供的那样。这些系统支持一种层次的命名结构，和丰富的数据模型，并且就是设计用于分布式环境的。LDAP定义的机制包括：一种命名对象的方式，一个基于命名的属性集合的数据模型，一种基于属性的数据元素搜索/写 协议。我们相信它适用于数据网格。
与LDAP相关的目录层次结构提供了一种结构，用来组织、复制和分布目录信息。然而，目录服务不管数据如何存放以及在哪存放。LDAP协议可以放在一个广泛的信息与元数据服务前面，这就提供了一种机制，使得数据网格支持多种方式来为应用提供元数据服务，同时方式还是保持一致的。

1.3.3 其他基础服务
        安全服务：GSI
        资源预留与分配机制。（比如对于存储系统、网络资源等。）
        对于关键资源的性能度量与估计技术。
        其他一些基础设施服务。（端对端的存储传输等一些操作）

1.4 高层数据网格组件
理论上在数据网格体系结构的上层可以有无限多的组件，我们在此只讨论两个有代表性的组件：拷贝管理和拷贝选择。

1.4.1 拷贝和换存管理
拷贝管理器（replica manager）应该是一种数据网格服务，它的功能应该是由存储系统和元数据配置库定义的。拷贝管理器的功能是在特定的存储系统上创建（删除）文件实例的拷贝。创建拷贝可能是因为另一个存储系统上有更好的性能，删除可能是因为存储空间有另外的用途。
这里的讨论我们假设文件拷贝是只读的，暂时不考虑文件的更新与一致的问题，因为只读模式对于许多科学应用已经足够了，同时也是为了降低难度。将来我们会再进一步讨论这些问题。
为了方便，我们把所有文件的拷贝以及相关的元数据归为元数据配置库中的一个实体，因为它与文件实例一起表现为一个逻辑结构，所以我们称之为一个“逻辑文件”（logical file）。（附说明：一个逻辑文件在元数据配置库中有一个实体，在拷贝目录中有一个或多个文件实例）

逻辑文件存在于元数据配置库中，它描述了一个文件实例集合的属性，它在配置库中的位置为逻辑文件提供了一个全局唯一的名字。为了方便数据发现，相关的逻辑文件会被聚集在一起，称为拷贝目录（replica catalogs）。拷贝目录是存储在元数据配置库中众所周知的地方的。文件实例、逻辑文件、拷贝目录的关系见下图。

一个数据网格中可以有多个拷贝目录。拷贝目录其实就是对一类相关的逻辑文件的归类。拷贝目录也应该组织为一种层次的结构。
拷贝管理器既可以对整个拷贝目录进行访问控制，也可以对单个逻辑文件进行访问控制。通过结合存储系统和元数据配置库提供的功能，拷贝管理器还可以执行一系列基本操作，包括创建/删除文件拷贝、逻辑文件、拷贝目录。
请注意，拷贝管理器不管拷贝何时何地被创建，或是哪个拷贝被应用程序使用，也不管是不是所有的文件实例都进了拷贝目录。我们让这些策略独立于拷贝管理器。为什么，举个例子，用户不希望自己所有的文件都被注册进拷贝目录中，一个没有进拷贝目录的文件实例可以被看做是一个本地“缓存”（cache），只能供本地使用。

1.4.2 拷贝创建与拷贝选择
这是数据网格的另一个典型高层服务――拷贝选择。拷贝选择并不是构造在核心服务上的，而是依赖于拷贝管理组件提供的功能上的。拷贝选择的功能是：选择一个拷贝，能够为应用访问数据提供额外的服务，比如：更快的速度，较小的开销，安全等。选择的拷贝可能是本地的，也可能是远程的。对拷贝的选择也可能导致一个新的拷贝的创建，这个新的拷贝的性能会比已有的那些要好。
选择哪的拷贝是要基于访问时间来考虑的。网格信息服务可以提供关于网络性能的信息，甚至可以预留网络带宽；元数据配置库可以提供文件大小的信息。有了这些，选择器（selector）可以为现有的拷贝分级，以决定使用哪个拷贝会有更快的访问速度。此外，选择器还可以得到信息，考虑是否存在一个存储系统，在这个存储系统上创建拷贝会带来更好的性能。
一个更一般的选择服务可以考虑访问一个文件实例的子集。科学试验通常要产生大量的文件，这些文件包含变量，时间步骤，事件的数据。有些应用可能只要其中的一部分，在这种情况下，选择器可以从文件实例选取一部分数据提供给应用，这可以明显的减少移动的数据量。
这种类型的拷贝管理已经由其他的数据管理系统实现了。比如：STACS就能满足高能物理应用的要求，它能从一个文件实例中抽取数据。其他的机制通过从自描述的文件格式中取得应用元数据也可以实现这样的功能。
复制策略决定，数据文件的子集对于选择管理器来讲，是否要被视为一个新的逻辑文件，还是只需本地使用。

































2.        用于分布式data-intensive科学的协议与服务（ACAT3）
本文是基于Globus项目的。
2.1 协议、APIs、服务
协议：定义了在两个系统之间交换的数据的格式，包括消息的构成、字符集、消息的顺序。它与具体的语言无关。它的价值是提供了互操作性。它允许sun工作站上的java应用程序与Cray T3－E 超级计算机上的C程序协同工作。

API：指定了接口，通过这些接口，应用程序员就可以编写代码。它指定了功能、名字、数据类型、参数顺序和返回值。它不是实现，虽然存在同样API的实现。有一个共同的API的好处就是提高了效率。比如：对于不同的存储系统，我们有同样的API，程序员的编程工作就大大简化了。

服务：通常自动启动并一直在运行，为其他进程提供了基础功能。他们也被称为用户代理（user agents）或daemons（后台程序）。服务的好处是使得应用程序开发更快、程序更小（客户程序不需要包含服务代码）、更稳定。

2.2 数据传输协议：GridFTP
我们设计一个通用的数据传输和访问协议――GridFTP，提供网格环境中安全、高效的数据移动。这个协议是在标准的FTP协议上进行扩展的。
我们选择标准的FTP协议进行扩展是因为：（略）
目前绝大部分的FTP实现只支持FTP协议中的一部分功能，并支持扩展。一些平时很少用到的功能对网格应用是有用的，但标准FTP协议还是缺少网格应用程序需要的一些功能，我们选取标准FTP的子集，并在将来进行扩展，加入一些新的功能，我们相信最终的协议将适用于网格数据传输。
新加入的功能如下：
l        GSI和Kerberos支持；
l        数据传输的第三方控制：通过在现有的FTP标准的third-party transfer（第三方传输）基础上加入了GSSAPI安全进行实现。
l        并行数据传输；
l        Striped 数据传输：把数据在多个服务器上进行分割，可以提高平均带宽。
l        Partial（部分）文件传输：许多应用要求只要传输文件的一部分，而传统的FTP要求传输整个文件或是从某个偏移量之后的剩下的部分（对于那些支持断点续传FTP）。
l        支持可靠数据传输。

2.3拷贝管理
这一节我们要展现Globus拷贝管理的体系结构。
拷贝管理系统服务包括：
l        创建完整或部分的数据集的拷贝
l        把这些拷贝在拷贝目录（replica catalog）中进行注册
l        允许用户或应用程序在拷贝目录中对现有的拷贝进行查找，查找一个或多个文件。
l        基于存储和网络性能的估计，选择最好的拷贝进行访问。
Globus拷贝管理体系结构是一个分层的体系结构。最底层是拷贝目录（功能：用户把文件注册为logical collections（逻辑集合），提供文件（文件集合）的逻辑名字