CN1545047A - 一种存储虚拟化系统的元数据层次管理方法及其系统 - Google Patents
一种存储虚拟化系统的元数据层次管理方法及其系统 Download PDFInfo
- Publication number
- CN1545047A CN1545047A CNA200310111436XA CN200310111436A CN1545047A CN 1545047 A CN1545047 A CN 1545047A CN A200310111436X A CNA200310111436X A CN A200310111436XA CN 200310111436 A CN200310111436 A CN 200310111436A CN 1545047 A CN1545047 A CN 1545047A
- Authority
- CN
- China
- Prior art keywords
- list
- server
- matching
- metadata
- list server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种存储虚拟化系统的元数据层次管理方法及其系统。该方法对元数据逻辑树进行层次管理,引入匹配表以减轻根目录服务器的压力,不仅可以快速准确的定向到用户所请求访问的目录,而且使系统达到更好的扩展性。匹配表常驻内存,因为它只记录每个目录服务器的根入口地址,所以所占空间极小,而且管理方便。由于匹配表所拥有的条目并不多,搜索匹配表对用户请求目录进行匹配的效率也很高。其系统包括设置有匹配表及匹配表管理模块的元数据服务器和目录服务器;匹配表至少包括目录服务器名称和目录服务器上所保存的元数据子逻辑树的根目录。本发明具有效率高、扩展性好和易于管理等特点。
Description
技术领域
本发明属于计算机存储领域,具体涉及一种存储虚拟化系统的元数据层次管理方法及其系统。
背景技术
在现代高性能计算中,科学计算和军事应用对存储的要求越来越高,包括大容量、分布式、高性能和高可靠性。广域网的虚拟化存储管理方式将地理上分布的各种高性能存储系统集成为一体,形成庞大的分布存储空间,充分实现资源共享,提高资源利用率,有效解决存储数据的爆炸性增长和存储管理能力相对不足之间的矛盾。
在一个广域存储系统中,这些海量的存储资源必须被有效的管理,从而引入元数据的概念。元数据是描述数据的数据,它为系统提供对象物理位置与其逻辑名字之间的映射,一个逻辑文件可以对应多个物理文件副本。此外,元数据还包括文件目录信息,文件信息,存储设备信息及相关的系统信息等等。
在许多系统中比如SRB或者GridFTP,都采用层次目录结构管理元数据。当元数据变得庞大时,系统会同时启用多个元数据服务器,这样会导致以下问题的产生:一方面,逻辑树必须分布在这些元数据服务器上,而另一方面,自录服务器之间必须协同操作,因为要返回的元数据可能分布在不同的元数据服务器上,这样就对元数据的根目录服务器造成了压力。第三,如果根目录服务器出现故障,整个目录服务系统也就不能再正常运转了,很难做到系统的高可用。最后,这种结构使得元数据服务器的扩展也变得很困难。
发明内容
本发明的目的在于提供一种能克服上述缺陷的存储虚拟化系统的元数据层次管理方法。该方法具有更高的效率、更好的扩展性,并且更易于管理。本发明还提供了实现该方法的系统。
本发明提供的一种存储虚拟化系统的元数据层次管理方法,其步骤为:
(1)把整个存储虚拟化系统划分为多个逻辑域,每个逻辑域内的元数据分布在多个目录服务器上;
(2)在各逻辑域中设置一个元数据服务器,用于管理该域中的目录服务器;
(3)在各元数据服务器中设置一个匹配表,该匹配表至少包括二个字段:目录服务器名称和目录服务器上所保存的元数据子逻辑树的根目录,用于直接将用户请求定向到其所在的目录服务器;
(4)当用户提出请求时,从用户请求中提取要访问目录的路径;
(5)在该域的匹配表中对路径进行长匹配,判断在匹配表中是否存在符合的目录服务器;
(6)如果存在符合的目录服务器,直接访问匹配的目录服务器,并返回结果;否则显示出错信息。
实现上述方法的系统,被划分为多个逻辑域,每个逻辑域内的元数据分布在多个目录服务器上,其特征在于:每个逻辑域指定一台服务器作为元数据服务器,指定多台服务器作为保存元数据信息的目录服务器;元数据服务器内设置有匹配表及匹配表管理模块,匹配表至少包括目录服务器名称和目录服务器上所保存的元数据子逻辑树的根目录,匹配表管理模块用于匹配表中的记录进行维护、匹配表文件的解析以及根据用户请求的路径匹配到合适的目录服务器或显示出错信息。
本发明的元数据层次管理系统具有以下优点及效果。
(1)更高的效率:匹配表是常驻内存的,它保存的条目数受域内目录服务器数目所限,所以遍历匹配表对用户请求目录进行匹配的速度也很快。遍历后可以直接访问请求目录所在的目录服务器,而不用再途经根目录目录服务器,这将大大减轻根目录所在的目录服务器的负载,提高元数据的搜索的速度继而提高整个系统的效率。
(2)更好的扩展性:分层的树型管理模式使维护和管理易于扩展;当系统负载上升需要增加目录服务器时,只需要在匹配表中增加几个条目,标示出系统中新增加的目录服务器及其对应的根目录即可。因为有了匹配表的调度,目录服务器可以达到相互独立,不需要感知域内其他目录服务器的存在。这样,系统效率不会随目录服务器数目的增多而下降,达到系统效率的可扩展性。
(3)易于管理:匹配表的结构很简单,只记录了每个目录服务器的名字及存放在其上的元数据的根目录。所以其添加删除修改都很方便。
当发明采用JAVA作为开发工具时,可以实现平台无关性;当存储虚拟化系统增加元数据副本时,由于副本分布情况能够完全在匹配表中显示出来,可以通过匹配表选择一个合适的目录服务器,从而有效的利用副本,提高系统效率。
附图说明
图1为域内元数据逻辑树示例图;
图2为本发明的元数据访问流程;
图3为现有元数据逻辑树的访问方式;
图4为本发明元数据逻辑树的访问方式;
图5为元数据管理的结构图。
具体实施方式
在我们的存储虚拟化系统GSP(Global Storage Provider)中,通过划分逻辑域对整个系统进行层次管理。在每个域内,元数据分布在多个目录服务器上面,并按照类似Linux文件系统的组织方式形成一棵“本域元数据逻辑树”,图1是一个域元数据逻辑树示例。图中,1.1,1.2,1.3,1.4表示域内的目录服务器;A0表示域内元数据逻辑树的根目录;A1,A2…,表示域内元数据逻辑树的子目录。
每个用户都隶属于一个域,用户的根目录绑定到域内一个子目录上,用户登陆时,系统自动定向到用户的根目录去。
建立基于目录树结构的元数据目录服务器(Directory Server)来存储元数据及其副本。但是在广域网的范围内,随着系统中资源的增长,文件和目录的信息会变得越来越庞大,很显然,目录服务器组织得不好,就会成为系统的瓶颈。所以如何快速准确的定向到用户的根目录就是一个十分突出的问题,这将影响到元数据的搜索速度进而影响整个系统的效率。在我们的系统中,引入匹配表来解决上述问题。
在每个域中设置一个元数据服务器管理域中的多个目录服务器,匹配表保存在元数据服务器上。匹配表是一个常驻内存的数据结构,记录了每个目录服务器的名字及存放在其上的元数据的根目录;如果一个目录服务器上面保存了某个目录的副本,也把这个目录放到匹配表中去。在匹配表中,还可以设置索引字段,作为某个条目在匹配表中的唯一标识。
当系统收到用户的请求时,首先在元数据服务器上遍历匹配表,根据用户所请求访问的路径对匹配表包含的所有路径做一个最长匹配,找到用户要访问的目录所在的目录服务器,直接访问这个目录服务器,而不用通过域内元数据根目录所在的目录服务器依次查找;如果元数据存在副本,还可以从匹配表中选择一个合适的目录服务器给用户访问。元数据访问流程如图2所示。
图1列举了一个逻辑树的例子。这个逻辑树代表一个域内的文件目录结构,分布在四个目录服务器上。其中,逻辑树的根/A0存放在目录服务器1.1上,目录/A0/B1存放在目录服务器1.2上,目录/A0/A1/A2/C11和目录/A0/A1/A2/C12放在目录服务器1.3上,目录/A0/B1/B2/B3/B4/D1放在目录服务器1.4上。表2显示了与图1逻辑树对应的匹配表。
假设用户想访问/A0/B1/B2/B3/B4/D1/D2,如果按照现存的元数据访问方式,首先会从域内逻辑树的根目录所在的目录服务器1.1开始查找,历经目录服务器1.3,到达目录服务器1.4,然后再把结果返回给用户,如图3所示。图中,R表示用户请求访问的文件/目录的路径;1.1,1.2,1.3,1.4表示本域中的目录服务器;A0表示域内元数据逻辑树的根目录;B1,D1…,表示域内元数据逻辑树中的目录;虚线箭头和r1,r2…表示用户访问步骤。但是如果采取本发明所用的匹配表方式,系统收到用户的请求后,将首先查找匹配表,根据用户请求的路径做一个最长匹配,这样就可以得到元数据在目录服务器1.4上面。系统将直接访问目录服务器1.4,而不需要再通过根目录入口1.1,如图4所示。图中,1表示域内的所有的目录服务器,2表示域内元数据服务器GNS,3表示匹配表,虚线箭头和r1,r2表示用户访问步骤。
为了达到有效搜索的目的,所有目录服务器都必须自己保存域内元数据树的逻辑结构。例如,目录服务器1.4仍然会保存域内元数据树的根,但它只是一个路径,并不保存根的内容,这样当一个搜索请求到达1.4的时候就不需要对请求做任何变换。这个根条目由于内容为空,只需要占用极少的存储空间,并且维护起来也很方便。
匹配表的内容存放在一个文件中,当整个系统启动的时候,把文件中保存的匹配表读入内存。匹配表的结构和功能决定了一般情况下都是在内存中对匹配表进行读操作,这就不会涉及到对匹配表文件的读写。只有在新增目录服务器或者现有目录服务器的根目录发生变化的情况下才对匹配表进行修改,进而对文件进行修改,并不需要频繁读写匹配表的文件,大大节省了访问匹配表的时间。
在元数据服务器中添加一个匹配表管理模块,对匹配表中的记录进行维护,具体操作包括记录的添加、删除、更新操作,匹配表文件的解析以及根据用户请求的路径匹配到合适的目录服务器等等,具体解释如下。
匹配表记录的添加:当域内新增一个目录服务器的时候,向匹配表中添加一条记录;如果某个目录服务器中的一个子目录过大,需要迁移到另外一个目录服务器去,也要通知匹配表,增加一条相关记录,以记录这个子目录和其迁移到的目录服务器。
匹配表记录的删除:当某个目录服务器不再服务于某个域时,从匹配表上删除相应的记录;
匹配表记录的修改:当某个目录服务器上保存的目录树根目录发生变化时,修改相应的记录;
匹配表文件的解析:当系统启动的时候,把匹配表文件中的内容读到字符串数组中,常驻内存;
匹配用户请求的路径:在匹配表中查找用户请求访问的路径所在的目录服务器。
使用集群系统中的5个节点构建一个元数据层次管理系统,其基本配置如表1所示。
CPU | 内存 | 硬盘 | 网卡 | 操作系统 | 网络 |
双PIII 866 | 256M | 30G | 3C905B | Linux 6.2 | 100M交换机 |
表1各节点的硬件及网络配置
其中,一台作为元数据服务器,另外4个作为目录服务器。元数据服务器负责匹配表的维护,包括生成添加删除更新等一系列的操作。目录服务器负责保存元数据信息。
具体实施如下:其中一个节点充当元数据服务器,装载保存匹配表的文件和匹配表管理模块;其余四个节点充当1.1,1.2,1.3,1.4,装载LDAP数据库,保存域内的元数据。
依照图5,4.1表示一个逻辑域Domain,其后的阴影部分4.2和4.3代表和4.1结构相同的多个逻辑域;5表示匹配表管理模块,虚线箭头表示元数据服务器和目录服务器之间的互访。
整个系统的配置说明如下:
(1)匹配表包括两个字段,其示例如表2。
根目录路径 | 目录服务器 |
/A0 | 1.1 |
/A0/B1 | 1.2 |
/A0/A1/A2/C11 | 1.3 |
/A0/A1/A2/C12 | 1.3 |
/A0/B1/B2/B3/B4/D1 | 1.4 |
表2匹配表示例
各字段解释如下:
路径:目录服务器保存的元数据子逻辑树的根目录路径;
目录服务器名称:此目录服务器的名字,域内各目录服务器名称唯一。
(2)域内元数据保存在四个目录服务器上,具体分布示例如表3。
目录服务器名称 | 目录服务器保存的元数据信息 |
1.1 | /A0下的元数据,但不包括目录/A0/B1,/A0/A1/A2/C11,/A0/A1/A2/C12和/A0/B1/B2/B3/B4/D1下的内容 |
1.2 | /A0/B1下的元数据,但不包括目录/A0/B1/B2/B3/B4/D1下的内容 |
1.3 | 目录/A0/A1/A2/C11和/A0/A1/A2/C12下的元数据 |
1.4 | 目录/A0/B1/B2/B3/B4/D1下的元数据 |
表3匹配表示例
(3)匹配表运行示例
系统启动时解析保存匹配表的文件,读至以下三个字符串数组,常驻内存:
Sindex[i]:保存匹配表中第i个记录的索引值,匹配表中的索引值递增。它并非必需,但是可以简化和方便程序的编写;
Spath[i]:保存第i个条目中字段“路径”的内容;
sDS[i]:保存第i个条目中字段“目录服务器名称”的内容。
Sindex[i],spath[i],sDS[i]是相互对应的一套。从数组[1]开始记录文件。sindex[0]的值为表中存在的条目数;spath[0]为空;sDS[0]为空。
收到用户请求访问的文件或目录路径path后,首先遍历数组spath,如果spath[i]的值为path,返回sDS[i];如果spath中不存在path,则返回path的父目录所在的目录服务器们,或者父父目录直至整个域的根目录。
Claims (4)
1、一种存储虚拟化系统的元数据层次管理方法,其步骤为:
(1)把整个存储虚拟化系统划分为多个逻辑域,每个逻辑域内的元数据分布在多个目录服务器上;
(2)在各逻辑域中设置一个元数据服务器,用于管理该域中的目录服务器;
(3)在各元数据服务器中设置一个匹配表,该匹配表至少包括二个字段:目录服务器名称和目录服务器上所保存的元数据子逻辑树的根目录,用于直接将用户请求定向到其所在的目录服务器;
(4)当用户提出请求时,从用户请求中提取要访问目录的路径;
(5)在该域的匹配表中对路径进行长匹配,判断在匹配表中是否存在符合的目录服务器;
(6)如果存在符合的目录服务器,直接访问匹配的目录服务器,并返回结果;否则显示出错信息。
2、根据权利要求1所述的方法,其特征在于:所述匹配表中还设置有目录副本。
3、根据权利要求1所述的方法,其特征在于:所述匹配表中还设置有索引字段。
4、实现上述权利要求1所述方法的系统,该系统被划分为多个逻辑域,每个逻辑域内的元数据分布在多个目录服务器上,其特征在于:每个逻辑域指定一台服务器作为元数据服务器(2),指定多台服务器作为保存元数据信息的目录服务器;元数据服务器(2)内设置有匹配表(3)及匹配表管理模块(5),匹配表(3)至少包括目录服务器名称和目录服务器上所保存的元数据子逻辑树的根目录,匹配表管理模块(5)用于匹配表(3)中的记录进行维护、匹配表文件的解析以及根据用户请求的路径匹配到合适的目录服务器或显示出错信息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200310111436 CN1255748C (zh) | 2003-11-24 | 2003-11-24 | 一种存储虚拟化系统的元数据层次管理方法及其系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200310111436 CN1255748C (zh) | 2003-11-24 | 2003-11-24 | 一种存储虚拟化系统的元数据层次管理方法及其系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1545047A true CN1545047A (zh) | 2004-11-10 |
CN1255748C CN1255748C (zh) | 2006-05-10 |
Family
ID=34336101
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200310111436 Expired - Fee Related CN1255748C (zh) | 2003-11-24 | 2003-11-24 | 一种存储虚拟化系统的元数据层次管理方法及其系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1255748C (zh) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100423000C (zh) * | 2005-03-03 | 2008-10-01 | 乐金电子(中国)研究开发中心有限公司 | 一种多媒体服务的元数据分析处理方法及移动通信终端 |
CN100595761C (zh) * | 2007-12-29 | 2010-03-24 | 中国科学院计算技术研究所 | 一种拆分名字空间的元数据管理方法 |
CN101385338B (zh) * | 2006-09-19 | 2011-03-02 | 索尼株式会社 | 记录装置和方法以及再现装置和方法 |
CN102024016A (zh) * | 2010-11-04 | 2011-04-20 | 天津曙光计算机产业有限公司 | 一种分布式文件系统快速数据恢复的方法 |
CN101697168B (zh) * | 2009-10-22 | 2011-10-19 | 中国科学技术大学 | 一种分布式文件系统动态元数据管理方法及系统 |
CN101241510B (zh) * | 2005-01-14 | 2012-05-02 | 株式会社日立制作所 | 传感器数据的检索方法 |
CN102982151A (zh) * | 2012-11-27 | 2013-03-20 | 南开大学 | 多个物理文件合并为一个逻辑文件的方法 |
US8423581B2 (en) | 2009-10-07 | 2013-04-16 | International Business Machines Corporation | Proxy support for special subtree entries in a directory information tree using attribute rules |
CN103229173A (zh) * | 2012-12-26 | 2013-07-31 | 华为技术有限公司 | 元数据管理方法及系统 |
CN103870588A (zh) * | 2014-03-27 | 2014-06-18 | 杭州朗和科技有限公司 | 一种在数据库中使用的方法及装置 |
CN106980697A (zh) * | 2017-04-07 | 2017-07-25 | 广东浪潮大数据研究有限公司 | 一种目录分布查询方法及装置 |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101826054B (zh) * | 2009-03-04 | 2011-12-07 | 安凯(广州)微电子技术有限公司 | 一种微内存系统的内存管理方法 |
US10866963B2 (en) | 2017-12-28 | 2020-12-15 | Dropbox, Inc. | File system authentication |
-
2003
- 2003-11-24 CN CN 200310111436 patent/CN1255748C/zh not_active Expired - Fee Related
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101241510B (zh) * | 2005-01-14 | 2012-05-02 | 株式会社日立制作所 | 传感器数据的检索方法 |
CN100423000C (zh) * | 2005-03-03 | 2008-10-01 | 乐金电子(中国)研究开发中心有限公司 | 一种多媒体服务的元数据分析处理方法及移动通信终端 |
CN101385338B (zh) * | 2006-09-19 | 2011-03-02 | 索尼株式会社 | 记录装置和方法以及再现装置和方法 |
CN100595761C (zh) * | 2007-12-29 | 2010-03-24 | 中国科学院计算技术研究所 | 一种拆分名字空间的元数据管理方法 |
US8423581B2 (en) | 2009-10-07 | 2013-04-16 | International Business Machines Corporation | Proxy support for special subtree entries in a directory information tree using attribute rules |
CN101697168B (zh) * | 2009-10-22 | 2011-10-19 | 中国科学技术大学 | 一种分布式文件系统动态元数据管理方法及系统 |
CN102024016B (zh) * | 2010-11-04 | 2013-03-13 | 曙光信息产业股份有限公司 | 一种分布式文件系统快速数据恢复的方法 |
CN102024016A (zh) * | 2010-11-04 | 2011-04-20 | 天津曙光计算机产业有限公司 | 一种分布式文件系统快速数据恢复的方法 |
CN102982151A (zh) * | 2012-11-27 | 2013-03-20 | 南开大学 | 多个物理文件合并为一个逻辑文件的方法 |
CN102982151B (zh) * | 2012-11-27 | 2015-04-01 | 南开大学 | 多个物理文件合并为一个逻辑文件的方法 |
CN103229173A (zh) * | 2012-12-26 | 2013-07-31 | 华为技术有限公司 | 元数据管理方法及系统 |
WO2014101000A1 (zh) * | 2012-12-26 | 2014-07-03 | 华为技术有限公司 | 元数据管理方法及系统 |
CN103229173B (zh) * | 2012-12-26 | 2016-08-03 | 华为技术有限公司 | 元数据管理方法及系统 |
CN103870588A (zh) * | 2014-03-27 | 2014-06-18 | 杭州朗和科技有限公司 | 一种在数据库中使用的方法及装置 |
CN103870588B (zh) * | 2014-03-27 | 2016-08-31 | 杭州朗和科技有限公司 | 一种在数据库中使用的方法及装置 |
CN106980697A (zh) * | 2017-04-07 | 2017-07-25 | 广东浪潮大数据研究有限公司 | 一种目录分布查询方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN1255748C (zh) | 2006-05-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104850572A (zh) | HBase非主键索引构建与查询方法及其系统 | |
CN103067461B (zh) | 一种文件的元数据管理系统以及元数据管理方法 | |
CN101556557B (zh) | 一种基于对象存储设备的对象文件组织方法 | |
CN1255748C (zh) | 一种存储虚拟化系统的元数据层次管理方法及其系统 | |
CN109299113B (zh) | 具有存储感知的混合索引的范围查询方法 | |
US9367569B1 (en) | Recovery of directory information | |
US20040254907A1 (en) | Versatile indirection in an extent based file system | |
CN106682110B (zh) | 一种基于哈希格网索引的影像文件存储和管理系统及方法 | |
CN105677826A (zh) | 一种针对海量非结构化数据的资源管理方法 | |
CN108021717B (zh) | 一种轻量级嵌入式文件系统的实现方法 | |
US20080155171A1 (en) | File system, and method for storing and searching for file by the same | |
CN111427847B (zh) | 面向用户自定义元数据的索引与查询方法和系统 | |
WO2013188168A1 (en) | Elimination of duplicate objects in storage clusters | |
CN101079036A (zh) | 一种海量文件的存储方法及系统 | |
CN101051309A (zh) | 在数字图书馆中所采用的检索系统和检索方法 | |
CN102163232A (zh) | 一种支持iec61850对象查询的sql接口实现方法 | |
CN1845093A (zh) | 一种属性可扩展的对象文件系统 | |
CN1547137A (zh) | 基于数据库的海量文件管理系统与方法 | |
CN1614591A (zh) | 一种组织和访问分布式文件系统目录的方法 | |
CN107273443B (zh) | 一种基于大数据模型元数据的混合索引方法 | |
Zhang et al. | FlameDB: A key-value store with grouped level structure and heterogeneous Bloom filter | |
CN100342374C (zh) | 一种数据存储方法及装置 | |
CN1791873A (zh) | 还原数据库系统中的对象和从属对象 | |
CN105468599A (zh) | 一种存储虚拟化系统的元数据层次管理方法 | |
CN111274259A (zh) | 一种分布式存储系统中存储节点的数据更新方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C19 | Lapse of patent right due to non-payment of the annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |