本文作者Henry Newman是Instrumental Inc.的首席技术官。他是一位行业咨询师,在高性能计算和存储领域拥有28年的工作经验。
DOSTOR存储在线3月4日国际报道：早在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个任务到一个文件）的话，事情可能更糟糕——这种情况下你有成百上千个或甚至数百万个任务要打开文件。
欲想了解更多，请阅读：专家博客：我们亟需将并行I/O标准化（下）
