为EB级归档做好准备

传统的备份技术已经越来越难以应付数据和文件不断膨胀的局面了，这就推动了分级存储管理系统（hierarchical storage management systems，HSM）的发展。

但是这个过程并非一帆风顺。一些影响HSM和归档的问题也会影响备份，但是归档系统通常有更多的文件和数据要管理，所以问题复杂了。标准可能会有帮助，但是标准之路过于漫长曲折。

数据管理标准很长时间都没有发生过重大的变化了。数据路径被分成了不同的标准片段，分属于不同的机构管理，从针对文件系统接口的OpenGroup和POSIX、到诸如T11和T13这样的低级别组，T11和T13都是INCITS （InterNational Committee for Information Technology Standards）的组成部分，再到IETF （NFSv4和pNFS以及其中的很多其他的标准）都是如此。

我看到归档接口存在着很多问题，对于用户和管理员来说都是如此：

•  信息生命周期管理（ILM）的用户界面是非标准化的。
•  升级文件系统元数据的接口受到了原子行为（atomic behavior）的POSIX标准的限制（参看《I/O Standards: What Went Wrong》）。
•  find和ls –lR之类的命令是用于处理文件系统元数据的，它们可以完成不同的操作，例如文件延寿问题，以及统计每种文件类型的文件数量。

归档在大型机时代情况更好，在我们向PB级存储和EB级存储进军的过程中，这些差异将会变得越来越重要。

ILM接口

为打开/读/写制订标准是OpenGroup的事情，标准的制订过程漫长而坎坷。很多公司对此都有最终决定权，出于自身利益考虑，他们都反对修改标准。如果你是一家操作系统厂商或者文件系统厂商，有人希望增加一系列新标准，那么你就必须开发相应的代码，你完全有理由预料到这些修订会增加你的成本。那么操作系统厂商或者文件系统厂商会总是把用户或管理员的想法放在首位吗？显然，答案很可能是否定的，因为你的目标是提高公司的竞争能力，所以你的兴趣只在于如何维护公司的利益。

无论如何，我们确实需要一个标准的接口，它作为标准公开声明的一部分，应该可以将标准化的ILM管理信息传递给存储管理系统。这个接口应该包含以下的一些信息：

•  文件保持时间：你希望将这个文件保存多长时间？对一些文件来说，这个时长也许是1年，而对另一些文件来说，则可能是75年，甚至更长的时间。
•  所有权信息：目前我们被POSIX用户/组所有权控制束缚住了。如果一个文件需要保存上75年的话，创建这个文件的人不一定会一直都在。我们需要一个更好的方法来维护文件的所有权。
•  性能问题：对于任何存档系统，你对于什么时候可以访问文件都会有性能要求。我发现一些存档站点中，用户会在创建一个文件后的几周里反复使用该文件，然后他们也许几年内都不会再使用该文件了，甚至可能永远也不再使用该文件了，而另一些文件可以立刻进行长期存档。
•  版本管理：因为HSM文件系统通常没有版本管理功能，允许每个文件保存多个版本或者允许文件被替换是很不错的主意。目前，绝大部分的HSM文件系统的做法都是为不同的版本起不同的文件名，而不是让文件系统进行版本管理。

我确信我们可以提出很多策略，应该建设一个框架可以通过策略的结构，让每个人都同意，并且为厂商或者站点特有的功能提出一个方法。这一点不会在短期内实现，这需要得到大部分厂商的支持。

扩展的接口

让我们面对这样一个事实吧：硬件厂商是不会有兴趣创建标准的，这样做只会降低他们硬件的销量，这大约也是为什么标准如此难以变动的一个主要原因。

目前存储系统的使用效率如何？我们是否只利用了磁盘驱动器1%、5%、25%、50%或者80%的性能？从我看到的信息看来，这一比例通常接近5%。特别是对于那些需要大量IOPS的应用来说更是如此。造成这种局面的原因有很多，但是其中一个原因是从应用到存储设备，资源没有实现调和，这点我已经一遍又一遍地强调了。因为除了OpenGroup建议的修改之外，我们还需要进行其他一些修改。下面是一些建议：

•  理顺整个数据路径：T10 OSD是很好的一步，但是它没有包含磁带或者SATA磁盘驱动器，它们是存档系统不可或缺的元素。
•  支持文件系统元数据通用接口：OpenGroup 的DMAPI只支持存档。现在没有一个通用的接口可以访问现有的文件元数据，更不要说未来可能出现的元数据类型了。

我们需要这些改变，它们让我们可以迁移到新的系统或者更换供应商——这也许是硬件厂商不支持这些改变的原因之一吧。

通用命令

今天，我们有一些标准接口的命令，可以用于不同的文件系统，例如ls –l和find，但是如果你需要查看一些文件系统特殊的存档信息，你就需要使用这个文件系统的特殊命令。这些命令没有提供一种通用的数据格式，查看文件信息的方法也各不相同。如果我们还要对其他的文件信息做出修改的话，那么我们就应该改变命令集，以便在存档系统中查看文件。为什么即使我们已经有了这些数据库，我们仍然必须通过读取索引节点或者扩展属性访问文件数据呢？悲哀的是，我们必须这样做，即使我们已经开发出能够支持所有其他搜索操作类型的数据库，我们仍然只能一次一个索引节点或一次一个属性地读取文件系统元数据。

为未来做好准备

我和几家拥有PB级存储系统的站点一起工作。就在10年前，2TB的文件系统还闻所未闻，2GB的文件大小限制还是我们生活中无法更改的事实。以此类推EB级的存储系统也不会离我们太远了。目前的命令和标准限制了硬件的扩展，由于数据路径扩展的限制，客户需要采购大量的硬件设备。

和我一起工作的很多站点都在公开地谈论对支持文件系统元数据的SSD硬件的需求。今天的SSD通常指的是闪存，它和传统的SSD相比，在成本和所需要的能耗方面有很多不同，传统的SSD使用的是内存DIMM。SSD面临的一个问题是，很多文件系统无法有效地使用这种技术，即使这些系统可以有效地使用它，这种技术在企业里的可靠性也还没有得到证实。当然，它很适合你的USB驱动器，但是它能够适用于大型存档系统吗？如果它不行，又意味着什么？让我们回想一下大型机的年代。在20世纪70年代，IBM在MVS里解决了其中一些问题。IBM控制着操作系统，因此可以对市场需求做出比较快的响应。

闪存不是问题的答案，因为它只是处理“伤口”的权宜之计，数据路径需要一次大的“外科手术”，才能够提高效率和可管理性，满足未来的需求。