【IT168 技术】归档系统是常用系统，然后我就学习及深入的研究归档系统，在这里和大家一起探讨归档系统的使用方法，希望对大家有用。存储世界12月03日报道：随着数据和文件继续爆炸式的增长，使用传统备份技术变得越来越困难，从而刺激了分层存储管理系统(HSM)的发展。但是这个过程也伴随着一些突出问题。

　　一些影响着分层存储管理系统和归档的问题也影响着备份，但是归档系统一般要管理远远更多的文件和数据，因此这个问题更严重。制订标准也许有帮助，但是标准的制订过程往往非常困难。

　　数据管理标准在很长时间里没有大的变动。我们的数据之路被各种不同的标准实体给弄得支离破碎，从文件系统界面的OpenGroup(开放组)和POSIX(可移植操作系统界面)，到低一级的组织，如从属于INCITS(国际信息技术标准委员会)的T11和T13，以及IETF(国际互联工程任务组)(NFSv4和pNFS，以及两者之间的许多其他标准)。用户和系统管理人都面临着一些归档界面问题：信息生命周期管理(ILM)的用户界面没有被标准化;

　　升级文件系统元数据的界面受到POSIX标准关于原子行为的限制find和ls -IR这样的命令可以用于处理文件系统元数据，从而完成不同的操作，如文件延寿问题，以及统计每种文件类型的文件数量。过去，在大型机时代，归档要好的多，而且当我们迈向PB级和EB级归档的时候，这些差异则更加重要。

　　信息生命周期管理界面

　　对于像打开/读取/写入这样的事情来说，其标准制订(现由OpenGroup维护)的过程是漫长而艰难的。许多公司希望有自己的话语权，而且因为担心潜在的成本而不愿意修改标准。如果你是一个操作系统商或文件系统商，而另一个人希望加入的标准可能使你需要另外开发代码来支持，那么你可能将这些变动看成是高成本的。操作系统商或文件系统商会一直站在用户和系统管理者这边吗?答案很可能是不。当然，因为他们是要让自己的公司处于有利的位置，因此他们只会寻找那些最符合他们公司利益的事情。

　　无论如何，作为标准开放声明的一部分，我们真正需要的是一个标准界面，以便让标准化的信息生命周期管理的管理信息能够传递到存储管理系统中。这个界面需要包括如下信息：文件保留时间：你希望多长时间保留这个文件?对一些文件，可能是一年，而其他，可能是75年或更长。

　　所有权信息：目前我们受到于POSIX 用户/组 所有权的控制。如果一个文件要保留75年，那么建立这个文件的人不太可能存活这么长的时间。我们需要一个更好的方法来维护文件的所有权。

　　性能提示：对于任何归档系统，你都有在某个时候访问某个文件的性能需求。我看到在许多归档站点中，用户在建立了一个文件后，在几个星期内会使用这个文件，然后可能在今后几年中或永远都不会再使用这个文件，而其他文件可以马上进入长期归档。

　　版本管理：由于分层存储管理系统的文件系统通常没有版本控制，因此最好是每个文件保持一个文件的多个版本，或允许该文件被替换。目前，对于大部分分层存储管理文件系统，这是通过将不同版本的文件命名为另一个名字来实现的，而没有让文件系统来管理版本。

　　我相信我们可以想出很多政策，但是需要有一个框架来让所有人都同意并通过一个政策结构，并且为对厂商和站点专门的功能提出一个方法。这不会很快实现，而且需要来自广大厂商的同意。

　　扩展界面

　　看看：对于硬件厂商来说，建立一个能够降低他们所出售的硬件数的标准不符合他们的利益，因此许多标准的变动非常缓慢。现有存储系统的利用效率如何?我们是否利用了磁盘驱动器的1%，5%，25%，50%或80%的性能?就我所看到的情况而言，通常是接近5%。

　　对于那些需要很高的IOPS(每秒输入输出)的应用程序而言，尤其如此。这种情况有许多原因，但是其中一项原因，如同我过去一再指出的那样，就是那些从应用程序到存储设备之间的资源没有得到很好的协调。除了OpenGroup已经提出的那些改变之外，还需要有一些改变来支持更好的可伸缩性。这里有一些建议：

　　协调整个数据路：T10的OSD(基于对象存储)就体现了这种努力，但是它还不能包括磁带或SATA磁盘驱动器，而这两者对于归档系统来说是必须的。 对文件系统元数据的通用界面的支持：OpenGroup的DMAPI只支持归档。现在还没有一个通用界面来访问今天现有的文件系统元数据，更不用说未来可能存在的元数据了。我们需要这些改变，让我们能够进行像迁移到新系统和厂商这样的事情--这也可能是硬件厂商可能不支持这种改变的一个理由。

　　通用命令

　　今天我们有标准界面的文件系统命令，如ls -l和find，但如果你像要看文件系统专门的归档信息，你需要用一些专门的命令来看文件系统。这些命令不提供通用的数据格式，查看文件信息的方式也不同。如果我们想要对其他的文件信息做出修改，那么我们就需要改变命令集，以便在归档系统中查看文件。为什么我们有了这些数据库，我们还是需要通过读取文件标志符(inodes)和扩展属性来访问文件数据呢?这的确很悲哀，我们必须得通过这种方式来访问文件，即使我们已经发展出能够支持所有其他搜索操作类型的数据库，我们还是得一次读取一个文件标志符和属性来读取文件元数据。

　　为未来做准备

　　我同一些有PB级存储系统的单位合作。仅仅10年前，还没有人听说过2TB的文件系统，文件大小的限制就2GB，甚至无法改变。而现在，EB级的存储系统也不远了。目前的命令和标准正在限制硬件的扩展，因此，由于数据路径扩展性的限制，我们需要购买大量的硬件。

　　和我合作的许多站点公开讨论对支持文件系统元数据的SSD(固态硬盘)硬件的需求。今天，相对于传统的使用内存双列直插内存模块(DIMM)SSD，现在SSD经常意味着闪存，在成本和能耗方面有许多不同。SSD的一个问题是许多文件系统本身的设计不能有效使用这种技术，而且，即使它们可以，就我所知，还没有这种技术的公司的可靠性还没有得到证实。

　　当然，对于你的USB驱动器它能运作得很好，但是它能用于大型归档系统么?如果不能，这意味着什么?回到主机。在1970年代，IBM在MVS(多重虚存系统)解决了其中一些问题。IBM控制着这个操作系统，因此能很好的快速回应市场需求。闪存不是问题的答案，因为它只是在伤口上贴了一个创可贴而已(治标不治本);数据之路需要大的手术，才能提高效率、可操作性，并满足未来需求。