将并行I/O标准化(Hadoop与并行I/O)

转自:http://www.searchstorage.com.cn/showcontent_46125.htm

日期：2011-3-7 来源：Dostor作者：Henry Newman译者：Bill

早在20年前，Thinking Machines和Kendall Square Research等公司就曾在创新型研究项目中进行过并行应用。这些公司现在已然不存在了，并行架构早期时候创建的大部分公司也已然不存在了，不过并行应用现在应用在各个领域，不仅仅是用来预测天气或设计飞机/汽车。

谷歌等搜索引擎，Hadoop等开源平台，Oracle和DB2等数据库，以及许多其他系统都是并行应用。

并行应用可以以两种不同的方式执行I/O：它们可以写入到一个并行文件系统，比如GPFS、Lustre或Pan-FS，或者写入设置内的每个服务器节点上的本地文件系统。问题是：除了针对并行处理通信的Message Passing Interface（MPI：消息传递系统）和针对并行I/O的MPI-IO外，并行应用并没有统一的标准。我觉得在短期内这种情况不会改变，因为那些控制着标准实体的公司并不希望改变什么，这样它们可以继续向客户销售那些从长期来看成本更高的专有解决方案,并将客户锁定到某个厂商上。如果你希望更换厂商的话，你的成本会提高。

搜索引擎的开源替代，比如Hadoop，使用并行通信，但是它们对本地文件系统进行I/O。我觉得这对I/O来说不是一个好的长期计划。这也就是我为什么写这篇文章的原因。

为什么我们都希望并行I/O

自从80年代以来，当UNIX的标准开始取得一致的时候，我们在主要的系统调用上取得了标准（打开、读取、写入、关闭、Iseek）。这些系统调用用于实施libc，而且我们在库调用上也拥有了标准，比如fopen、fread、fwrite、fclose和fseek。

从90年代以来，我们在用户应用程序的I/O领域几乎没有任何变化，除了对一些异步的I/O系统调用增加了标准。这意味着从应用程序和操作系统到文件系统的接口实际上基本没变过。

我曾经非常期待拥有丰富接口的对象存储可以给应用程序接口带来一些变化。但是市场没有提供基于对象存储设备（OSD）标准的产品，这打碎了我的希望——不是因为这不是一个好的技术想法，也不是因为存储厂商不能从中获得利润，而是因为这需要一定的投资同时世界经济处于低迷状况。

因此，自从应用程序I/O接口标准化以来，这个领域已经20多年没什么变化了。

文件系统的狭窄接口限制了并行文件系统的能力，使其难以提高应用程序I/O的性能。当然，许多厂商在文件系统上增加了接口功能以便让那些特定的文件系统实施实现应用程序优化。不过，每个厂商用不同的方式来实施应用程序接口。这可以理解，因为目前并行I/O或并行文件系统还没有统一的标准。标准化的建议虽然几年前有提过，但是OpenGroup没有重视。并行系统厂商仍然必须遵循文件系统的标准要求和相关命令（ls、df、find……）。这种情况严重影响了标准测试和I/O性能。

为什么会出现这样的局面呢？例如，为什么Hadoop将它的搜索引擎实施为一个本地文件系统呢？其中一个理由很简单：出于性能上的考虑，设计者必须进行本地I/O。鉴于所有管理要求必须符合POSIX（可移植操作系统接口）标准，并行文件系统和并行I/O会慢于本地I/O。甚至于如果每个应用程序从每个线程或任务打开一个单独的文件，并行文件系统也慢于本地文件系统。这通常被称为"N到N"（N个任务到N个文件）。如果是"N到1"（N个任务到一个文件）的话，事情可能更糟糕——这种情况下你有成百上千个或甚至数百万个任务要打开文件。

Hadoop执行本地I/O的另一个主要原因是考虑到存储通信网络的成本。在各个节点上配置本地驱动器是非常有成本经济性的，而且鉴于并行I/O和并行文件系统的性能问题，只有本地I/O才值得做。

因此，无论这个应用程序是一个数据库，搜索引擎，高性能计算（HPC）还是上面这三个的结合，并行I/O都有使用。在HPC的世界，应用程序通过MPI进行通信。人们意识到HPC需要并行I/O，因此控制着MPI标准的标准实体增加了一个专门针对并行I/O的叫做MPI-IO的标准。

MPI-IO的一些功能可以允许小型写入或读取合并成更大的写入或读取，并允许高速通信网络处理这种写入/读取合并。如果你是使用MPI编程模式的话，这一切都运行良好。但是，如果你没有MPI的话，就不行了。这意味着这种方式并不实用，因为MPI只用在HPC应用程序环境而不是用在数据库或搜索引擎上。

一个小小的建议

我觉得我们在并行应用上面临着先有鸡还是先有蛋的尴尬局面。HPC应用程序使用本地I/O，因为并行I/O到并行文件系统实在是太慢了。同样重要的是，我们在这些并行应用所能使用的I/O接口上没有一个标准，也使得并行文件系统厂商无法利用标准来进行各个层次上的优化。

我们需要重新通盘思考I/O。不幸的是，ANSI T10 OSD标准虽然在开始的时候为I/O提供了一个更新的框架，但是现在我认为这个标准基本上已经不能成为行业标准了。它的发布时机是错误的，同时，在我看来，存储行业也错误地忽视了I/O重新思考的重要性。即使ANSI T10 OSD成为一个行业标准，我们仍然还没有一个人讨论各个语言下的并行I/O框架。C++、C、Java、数据库和其他语言仍然使用标准的POSIX标准，没有机会进行并行I/O。

诚然，大多数搜索引擎之所以进行本地文件系统通信不仅仅是因为没有并行I/O标准，而且还以为并行文件系统的硬件成本比较高，不过在这些搜索引擎中，许多是利用节点上的多副本来解决节点故障问题。这种架构有刀片系统、本地网络、复制网络和电源/冷却成本。我不确定用户是否都明白这种架构的成本以及它们和并行文件系统成本的区别。不过这也不重要，因为现在还没有标准。

因此，我希望我们这个行业（标准实体、硬件厂商、数据库专家、计算机语言开发专家等）开发一个针对多种语言的并行I/O标准，并让这种标准支持MPI-IO所有的功能和特性。

这个新的并行I/O标准需要对POSIX进行一定的更改以便让应用程序写入能够将有关I/O的信息传递给文件系统从而提高性能。这个新的系统将要求调试器允许用户调试他们的并行I/O错误。这意味着控制着POSIX标准的OpenGroup将必须和各个ANSI委员会（有可能还要包括针对网络文件系统标准的IETF）做出一些重大修改。

所有人都必须协同合作以便我们可以最终获得一个拥有丰富接口的完美整合的I/O堆栈。这个I/O堆栈必须得到标准化，而且必须可以满足各种应用环境的要求--从数据库到搜索引擎到HPC--因为所有这些应用都（可能）要求并行I/O。

我最近曾和某个人谈起我的这个想法，结果他觉得我是在妄想。梦想是好的，不过就像我曾说过的，如果存储不能变得更加便于使用并随需扩展以满足带宽要求，那么存储的重要性可能会降低。可悲的是，我的想法能够实现的概率就和中强力球彩票的概率一样小，而且我还不买彩票。