1.5.3 对象存储文件系统体系结构

对象存储系统的概念一经提出，受到学术界和工业界的广泛关注。众多研究机构和厂商纷纷开发出各具特色的原型系统，其中备受人们关注的有集群文件系统公司的Lustre系统，Panasas公司开发的Activescale Storage Cluster以及IBM公司的Storage Tank系统。这些对象存储系统在性能上较传统的SAN和NAS系统都有很大的提高，特别是在可扩展性方面特点尤为突出。

1.Lustre

Lustre是一个开放源码的、基于对象存储的高性能分布式文件系统，由集群文件系统(cluster file system, CFS)公司研发，已经开放的版本为1.4.6，在其官方网站(http://www.lustre.org)可以自由下载。目前，Lustre在美国能源部(DOE)、Lawrence Livermore国家实验室、Los Alamos国家实验室、Sandia国家实验室、Pacific Northwest国家实验室的高性能计算系统中已得到了初步的应用。Lustre运行在商业设备上，使用基于对象的磁盘(object-based disks, OBD)存储数据，元数据服务器(MDS)为整个文件系统提供元数据服务。Lustre由三个部分组成，即客户端、MDS和存储服务器(object storage target, OST)。三个部分通过高速的互联网连接。Lustre把文件当作由元数据服务器定位的对象，元数据服务器指导实际的文件I/O请求到存储服务器，存储服务器管理在基于对象的磁盘组上的物理存储。对于客户端而言，Lustre是一个透明的文件系统，无须知道具体数据所在的位置，可以透明地访问整个文件系统中的数据。客户端同OST进行文件数据的交互，包括文件数据的读写、对象属性的改变等；同MDS进行元数据的交互，包括目录管理、命名空间管理等。由于采用元数据和存储数据相分离的技术，可以充分分离计算和存储资源，使得客户端计算机可以专注于用户和应用程序的请求，存储服务器和元数据服务器专注于读、传输和写数据。存储服务器端的数据备份和存储配置以及存储服务器扩充等操作不会影响到客户端，存储服务器和元数据服务器均不会成为性能瓶颈。三个组成部分除了各自的独特功能以外，相互之间共享诸如锁、请求处理、消息传递等模块。Lustre是一个高度模块化的系统，三个组成部分可以在一个节点上工作，也可以在不同的节点上工作。

2005年3月中旬，惠普公司宣布正式向国内市场推出其第二款基于惠普“存储网格”体系结构的产品——HP StorageWorks Scalable File Share(HP SFS)。惠普公司推出的SFS是首款采用Lustre技术的商业化产品。Lustre技术已经于2004年在世界上最大的10个Linux集群之一的美国能源部西北太平洋国家实验室(PNNL)上投入使用。PNNL的HP Linux超级集群配备了1800多颗安腾2处理器，运算速度可达11 Teraflops(1 Teraflop相当于每秒1万亿次浮点运算)，并且可以在单一的53 TB基于Lustre的文件共享系统中提供3.2GB/s的带宽来运行生产负载。独立的Linux客户机可以向并行Lustre服务器以650MB/s的速度来写入数据。这套系统消除了I/O带宽瓶颈问题，从而为用户在成百甚至上千台独立的、分布式的文件系统之间拷贝文件节约了大量时间。

2.Activescale Storage Cluster

同集群文件系统公司一样，Panasas公司也开发出了自己的对象存储系统——Activescale Storage Cluster，应用于大规模的Linux集群环境。该系统由StorageBlade, DirectorBlade和Panasas文件系统组成。

StorageBlade就是对象存储体系结构中的OSD，数据保存在StorageBlade上。目前，系统中每个StorageBlade包含两个120GB或者150GB的SATA硬盘用于存放数据。StorageBlade使用的是1.2 GHz Intel Celeron CPU，配备512MB SDRAM作为内存。StorageBlade使用一个千兆位以太网作为传输接口。这就使得StorageBlade具有了相当的处理和数据传输能力。DirectorBlade就是对象存储体系结构中的MDS。DirectorBlade拥有很强的处理能力，使用Intel LV Xeon 2.4 GHz的CPU，并配备了4GB的DDR内存。为了保证DirectorBlade拥有足够的数据传输带宽，DirectorBlade配备了两个千兆位以太网接口。根据需要，DirectorBlade还可以再添加一个，组成双机热备份。Activescale Storage Cluster使用千兆位以太网作为网络连接，其中对外的连接由4个千兆位以太网进行捆绑，提供了高速的访问接口。Panasas文件系统运行在Activescale Storage Cluster上，为应用程序提供文件系统接口，将应用程序的文件请求发送给DirectorBlade和StorageBlade，并将StorageBlade返回的数据交给应用程序。Panasas文件系统在客户端将需要写到StorageBlade的数据进行RAID分带，将包括校验数据在内的所有分带分别写入各个StorageBlade，从而使数据的存储更可靠。DirectorBlade也为文件系统提供了元数据访问、文件和目录访问管理，以及客户端上数据的Cache一致性。Panasas文件系统在可扩展性上表现非常突出，当OSD的数量从30增加到300时，整个系统的集合访问带宽几乎呈直线增长。

3.IBM Storage Tank

IBM公司在原有的GPFS文件系统之上进行改进，开发出了Storage Tank存储系统。总体上来讲，Storage Tank仍然属于SAN文件系统，但它在很大程度上借鉴了对象存储的理念，使得Storage Tank在性能和可扩展性方面较传统的SAN系统有了很大的改进。

Storage Tank是一个异构可扩展的SAN文件系统。它可以提供异构环境下的文件共享访问，对数据进行集中管理，而且能提供企业级的可扩展性。Storage Tank采用积极的缓存策略，尽量在客户端缓存文件元数据和数据。即使打开的文件被关闭，都可以在下次使用时利用已经缓存的文件信息，整个文件系统由管理员按照目录结构划分成多个文件集(fileset)。每一个文件集都是一个相对独立的整体，可以进行独立的元数据处理和文件系统备份等。不同的文件集可以分配到不同的元数据服务器处理，形成元数据服务器机群，提供系统的扩展性、性能、可用性等。

在Storage Tank中，块虚拟层将整个SAN的存储进行统一的虚拟管理，为文件系统提供统一的存储空间。这样的分层结构有利于简化文件系统的设计和实现。同时，它们的客户端支持多种操作系统，是一个支持异构环境的分布式文件系统。Storage Tank采用了基于策略的文件数据位置选择方法，能有效地利用系统资源、提高性能、降低成本。与传统的SAN相比，Storage Tank在数据管理上改动较大。传统的SAN在管理数据块时是进行统一管理的，向上也是提供统一的块访问接口。而Storage Tank在此基础上进行改进。对于存储资源，它仍然使用统一的块管理，但在此之上增加了一个抽象层，对上提供普通的文件服务，文件到块的映射关系由此抽象层管理。这就使得数据管理具有更清晰的层次，更具模块化。系统的可扩展性较传统的SAN也有较大的提高。由于使用普通的文件访问接口，就很容易让不同环境下的用户使用，提高了系统的可用性。

4．对象存储系统体系结构

对象存储系统是一个分布式的网络文件系统。它主要由三个部分组成：设备端、元数据服务器端和客户端。这三个部分通过高速网络进行互联，目前大多数的对象存储文件系统都是采用高速的以太网作为互联网络。

对象存储文件系统的设备端部分就运行在各个OSD上。OSD是一个智能设备，除了拥有大量的存储资源外，它还拥有自己的CPU和内存。对象存储文件系统的设备端主要负责OSD内的对象及其属性的组织和在存储介质上的物理存放，并向外提供基于对象的访问接口。对象存储文件系统的设备端接收从网络上发来的各种请求，对其进行命令解析和安全验证。当安全验证通过后，将数据从存储介质上读出，以对象为基本传输单位发送给请求者。用户在向OSD发出数据请求时，以对象为基本单元，而对象在存储介质上的物理分布对用户来说是透明的。

对象存储文件系统的元数据服务器部分运行在元数据服务器上。元数据服务器可以是一台普通的服务器，也可以是集群服务器。对象文件系统元数据服务器部分主要负责维护用户请求的文件到OSD上的对象的映射关系、安全认证信息和Cache数据一致性等。与SAN不同的是，对象存储文件系统的元数据服务器部分所管理的是对象一级的元数据。而对象在磁盘上的组织等元数据交由存储该对象的OSD管理。这就大大减轻了对象存储系统元数据服务器的负载，减小了元数据服务器成为瓶颈的可能，增加了整个对象存储系统的可扩展性。

对象存储文件系统的客户端运行在各种用户的终端机或者大型的集群服务器上。它主要负责给用户提供一个友好的访问界面，能够高效、安全地利用OSD提供的存储资源。为了不影响用户的应用，客户端要求能支持各种平台环境，并能在用户不修改应用程序的情况下提供高效、安全的服务。因此，客户端一般提供两种使用方式，一种是以API或者系统调用的形式提供给用户直接使用；另一种就是直接在Linux环境下挂载出一个目录或者在Windows环境下创建一个逻辑盘符供用户使用。

5．对象存储的设备端

对象存储文件系统设备端运行在对象存储设备上。对象存储设备是一个智能存储设备，它拥有自己的CPU、内存、EPROM、网络接口、块设备接口和磁盘等存储介质。对象存储设备体系结构如图1.6所示。

如图1.6所示，对象存储文件系统设备端运行在对象存储设备上时，通过网络接口接收和发送数据。此时接收和发送的数据都是以对象作为基本传输单元的；而对象及其属性在磁盘等存储介质上如何存放，磁盘上的空间如何管理等都由运行在OSD上的对象存储文件系统客户端部分管理。OSD的一些配置信息和启动参数都存放在EPROM中。

当数据请求到达OSD后，网络接口将接收到的数据存放到内存中，交由CPU进行处理。CPU从数据中提取出请求命令、对象ID、对象内偏移、读写长度等相关信息。CPU得到这些信息后，根据对象存储文件系统客户端部分软件设计的一种机制找到对象所存放的磁盘及其具体的位置，并向磁盘发出读写请求，完成操作。最后通过网络端口向请求发出者返回相关信息。

从图1.6中我们可以看出，较传统的存储设备而言，OSD具有了相当的处理能力。因此，对象存储文件系统就将对象在存储介质上的具体存放的任务交由OSD负责。同时，OSD可以利用自己的处理能力合理安排对象及其属性在不同磁盘上的分布，在OSD所挂载的多个磁盘上做负载平衡。

另外，每个对象都有属性，OSD还可以自己定义对象的属性，而对象的属性反映了对象的特征。这样一来，OSD就可以利用对象的属性把对象进行分类管理，方便用户使用。另外，对象存储文件系统的设备端部分可以利用OSD的处理器和内存，借助对象的属性，对用户访问的对象进行预取和缓存，提高OSD的性能。另外，在响应读写请求时，OSD还以对象为基本单元负责数据的安全。因此，用户访问OSD只能以对象为基本单元，用户无法读取OSD中磁盘上指定位置的数据块。这就使得对象存储系统中有关数据的安全信息较SAN而言大为减少，相应的管理也更为合理。

6．对象存储文件系统元数据服务器

对象存储文件系统的元数据服务器部分运行在普通的服务器或者集群服务器上，它负责管理由用户访问时所使用的文件名到OSD上的对象ID的映射关系、对象存储文件系统中的Cache数据一致性、用户认证以及安全证书等。

对象存储文件系统的元数据服务器部分与客户端和OSD通过Socket进行通信。MDS负责维护文件到对象的对应关系，并实时掌握OSD的各种信息，如负载、可利用空间等。这通过这些信息对负载和对象在OSD间的分布进行实时的调度，实现OSD间的负载平衡。此外，元数据服务器还负责管理用户的访问权限。与传统的分布式文件系统不同的是，这里的元数据服务器对权限的管理以对象为基本单元，其粒度介于块和文件之间，相对于块一级和文件一级而言，在易管理性和可共享性上做了很好的折中。与此同时，元数据服务器还负责对用户的认证以及安全证书的发放。

对象存储文件系统的元数据服务器部分为每个用户维护着一张文件与对象之间的对应表。一个文件可以对应多个对象，多个文件也可以聚合起来，在一个文件中存放。这可以通过元数据表中的Flag值来表示：Flag为0时，表明一个文件对应了多个对象，索引号表明文件对应的各对象的排列顺序，偏移表示对象在文件中的起始的偏移地址；Flag为1时，表明多个文件聚合存放在一个对象中，索引号表明各文件在这个对象中的排列顺序，偏移表示各文件在这个对象中的起始偏移地址。OSD号是指各OSD设备的设备号，它是各OSD设备的唯一标识。对象号是全局唯一的，根据OSD命令集的规定，它是一个128位无符号数。要注意的是，这里的文件名对某个用户而言是全局唯一的，因为对象存储系统同时可以对多个用户提供服务，但每个用户所看到的文件视图应该是各自独立的。

7．对象存储文件系统客户端

对象存储文件系统的客户端部分运行在用户的终端PC机或者高性能集群服务器上。它提供一套标准的访问接口供用户调用，使得用户在访问对象存储系统时像访问本地文件系统一样。

用户对各种应用程序不进行任何修改就可以在对象存储系统上运行。用户的终端PC机或者高性能集群服务器所使用的操作系统平台是各不相同的。为了保证用户的应用程序能透明地访问对象存储系统，对象存储文件系统就必须能在Windows操作系统下创建出一个虚拟的盘符或者在Linux操作系统下挂载一个目录。当用户访问虚拟盘符或者这个目录时，实际上使用的就是对象存储系统中的存储资源。与此同时，对象存储文件系统还提供一套标准的API供用户调用。用户可以根据自己的要求直接调用API来使用对象存储系统，从而提高性能。

对象存储文件系统客户端接收到上层应用发下来的读写请求时，通过与元数据服务器交互，获知所访问的文件由哪些对象组成，在哪个OSD上。然后直接与OSD通信进行数据访问。在进行数据传输时，不需要元数据服务器干预。这种结构大大减小了元数据服务器的负载，用户在进行数据访问时的性能和效率也大为提高。也正因为此，对象存储系统具有很强的可扩展能力。

8.OSD命令集

OSD命令集(Information Technology-SCSI Object-Based Storage Device Commands)由美国T10工作组指定和修改。T10工作组是美国信息技术标准国际委员会(The International Committee for Information Technology Standards, INCITS)旗下的一个标准制定组织，主要负责指定SCSI存储接口方面的标准。INCITS隶属于美国国家标准研究所(American National Standards Institute, ANSI)。

T10工作组维护的OSD命令集于2004年7月30日又一次做了修改。该命令集已经于2004年11月15日由INCITS出版(ANSI/INCITS 400—2004)。目前T10工作组正在制订下一代OSD命令集(Information Technology-SCSI Object-Based Storage Device Commands-2, OSD-2)。OSD命令集定义了一组用于对象存储的命令集，从而替代传统的“块”一级的存储模式。OSD命令集是SCSI-3命令集的扩充。它的指定主要用来定义一种能提供高效的输入/输出接口、可自我管理、自我分配、可变长的数据存储容器——对象。

2005年9月全球网络存储工作协会(中国)(Storage Networking Industry Association, SNIAChina)和《计算机世界》共同主办的美国网络存储世界(Storage Networking World, SNW)大会中国分会上，希捷公司(Seagate)、美国Emulex公司和IBM共同进行了面向对象的存储设备联合技术演示。该次SNW上的演示是OSD第一次展示在驱动器上生成文件系统，同时也是第一个符合OSD命令集的原型设备。

OSD命令集的主要包含4部分内容：对象存储模型、对象存储命令一般格式、对象存储命令和对象存储命令的参数。

对象存储模型定义了一种全新的存储模式。传统的存储系统中文件系统分为两个层次：文件系统用户组件和文件系统存储管理组件。这两个部分都运行在主机系统中。而对象存储模式将这两个部分进行了拆分。文件系统存储管理组件被下移到对象存储设备(OSD)上，称为OSD存储管理组件。对象存储管理组件向上以对象存储接口提供服务。文件系统用户组件通过对象存储接口，调用OSD上的对象存储管理组件。这种存储模型的实质就是将用户与存储设备之间的接口由“块”变为对象。对象在磁盘上的分布与管理由OSD负责，减轻了主机的负担。对象存储模型中还定义了一种基于三方通信的安全模型。

OSD命令集是SCSI-3命令集的扩充，它的命令形式和SCSI命令十分相似。与SCSI命令不同的是，OSD命令中除了有对数据的操作外，每个命令都包含处理对象属性的部分。OSD命令集定义了20个对象操作命令，其中包括常见的读、写等操作，也定义了一些对象存储系统特有的操作命令，如LIST, LIST Collection等。对象存储命令的参数较为复杂，也是它的一大特色。主要是因为对象都具有属性，而每个OSD命令都有对对象属性进行处理的部分。正是因为对象拥有属性，而属性反映了对象的某些特征，这就使得OSD能较为合理地自我管理和分配对象在磁盘上的分布，OSD就能提供高效的基于对象的存储服务。对象存储命令的参数主要分为属性参数、诊断参数、日志参数、模型参数等。

9．对象存储文件系统的数据访问流程

对象存储文件系统的三个部分是一个不可分割的有机整体，它们通过高速互联网络互相通信，共同为用户提供服务。对象存储文件系统的数据访问流程(以写数据为例)如图1.7所示。

典型的对象存储文件系统的写数据的访问流程具体步骤如下：

①用户在使用对象存储文件系统时，以写文件为例，首先向对象存储文件系统客户端发出写请求，同时将所写文件的文件名、文件的数据及其长度传给对象文件系统客户端。对象文件系统客户端在接收到写请求后，首先与元数据服务器进行通信，获取写文件的安全认证等相关信息。

②元数据服务器接到用户的请求后，就会对用户进行安全检测，判断是否是合法用户、是否拥有写权限等。安全检测通过后，就会根据目前整个系统的负载和各OSD上存储资源的使用情况，合理分配一些OSD负责接收用户的数据，并将相关信息返回给客户端。其中包括用户可以将文件写到哪些OSD上，文件由哪些对象组成，其对象ID是多少以及安全证书等。

③与此同时，MDS将与被分配用来接收数据的OSD进行通信，让其做好准备接收数据，并将相关的安全认证信息告诉此OSD。

④对象文件系统客户端得到这些信息后，直接与OSD建立连接，向OSD发出写对象请求，并将安全证书发送给OSD。OSD接收到安全证书后对其进行安全检验，通过后开始接收数据。此时的数据都以对象为单位进行传输。数据传输完成后，创建对象的相关属性。

⑤数据传输完成后，向用户返回信息，通知数据已经接收完成。对象存储文件系统客户端得知数据传输完毕后，向上层应用程序返回信息。

⑥与此同时，通知元数据服务器数据传输完毕，让其记录文件到对象的索引信息。整个写请求操作完成。

整个数据传输的过程是一个三方通信的过程。用户在进行文件数据传输时，直接和OSD通信，元数据服务器没有直接干预，这就使得元数据服务器不再成为分布式文件系统的瓶颈。另外，元数据服务器对整个对象存储系统中各OSD的负载情况了如指掌，当用户有访问请求时，元数据服务器可以合理安排那些OSD相应请求，做到OSD间的负载平衡。而且元数据服务器管理的是对象的元数据，较SAN系统而言，其管理的数据量要小很多，从而摆脱了元数据服务器成为分布式文件系统的瓶颈。

用户的应用程序要能从OSD读写数据，就必须由对象文件系统客户端、元数据服务器端和OSD合作共同完成。三方通过高速网络进行连接，保持实时交互。文件由哪些对象组成、分布在哪些OSD上都是由元数据服务器根据整个对象存储系统的实时负载合理地进行分配。