分类： 服务器与存储
2008-07-18 23:01:48
数据管理标准在很长时间里没有大的变动。我们的数据之路被各种不同的标准实体给弄得支离破碎，从文件系统界面的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只支持归档。现在还没有一个通用界面来访问今天现有的文件系统元数据，更不用说未来可能存在的元数据了。
我们需要这些改变，让我们能够进行像迁移到新系统和厂商这样的事情--这也可能是硬件厂商可能不支持这种改变的一个理由。
