X公司的会议室里，几位工程师和销售正吵得欢。下周就要投标了，可是他们到现在还没找到令人满意的解决方案。招标的项目是勘探数据处理系统，典型的面向石油和勘探行业的Linux并行集群环境，规模在32个节点到128个节点之间。这本来是很成熟的应用，没什么可以过多纠缠的，但考虑到几十个TB的存储系统，问题就不那么容易解决了。
长久以来，身处这个领域的部分IT主管以为在并行集群环境下引入存储系统会大大降低并行计算能力，而不愿把存储系统连接到集群环境中。可是不连进来，又不利于数据保护和资源充分共享。因此，高效处理并行计算与存储的关系一直是个未解的难题。
X公司专爱啃硬骨头，“勘探数据处理系统”项目他们是铁定了心地要做。
矛头指向I/O性能
用户当前最关心的就是集群系统中的I/O性能，资深客户经理老梁这样认为。
他与物探行业打了近十年的交道，对用户的应用可谓了如指掌。在很多情况下，集群运算能力已经很强，但是系统却要花大量的时间等待数据读写。而且往往是计算节点越多，读写过程耗费的时间就越长。图1所示的系统现在已经有将近一半时间是在等待I/O了。一个总共需要10小时的任务，真正花在处理上的时间只有不足6个小时。其他时间里大量的计算资源都闲着。
图1 多计算节点与读写长时耗关系
1．浅析问题
“这个系统里有多少计算节点？多少I/O节点？”小吴是位认真的新手，遇事总要问个仔细。
没等老梁回答，就有人接过话茬，“32个计算节点，1个I/O节点，你没看标书啊！”说话的是小蔡。
跟着老梁混了这几年，现在对这个行业也算有了些了解。“Linux并行集群现在都是这个结构的，就算上到64或者128个节点，一般也只配置一个I/O节点。”说完，他还拿出了一个图示递给小吴。
“对，用户的系统现在基本就是这个结构。”老梁指着图示（见图2）补充说。
用户现在已经在I/O节点上安装了两片千兆网卡，还做了双网卡负载均衡，以太网交换也早就换成千兆无阻塞的了，但是还是太慢。
图2 并行系统结构
因此，现在要确切的定位，到底哪里是I/O性能的瓶颈。按照这个系统的性能要求算一算，看到底现有的产品和技术能满足到什么程度。
2．直击要害
大家静了下来，都低头翻看着手头的标书。
按照每个计算节点15～20MB/s的要求计算，32个计算节点总共需要的带宽应该在500～650MB/s左右，好像中端磁盘阵列满足这个要求是没问题的。
但如果用户将来扩展到64个甚至更多计算节点呢？
目前中端磁盘阵列的带宽可以达到GB/s级别，而且还可以多个磁盘阵列借助虚拟存储技术实现负载均衡，支持到上百个计算节点应该不成问题。
而且，现在中端磁盘阵列都是光纤接口的，每个光纤端口可以支持到200MB/s的带宽，4个光纤端口绑定，就可以支持到800MB/s了，支持这32个节点绝对绰绰有余。
想到这儿，小蔡的眼睛忽然一亮。“噢，对了！既然有多个光纤卡绑定的办法，那I/O节点上也可以用更多的千兆网卡绑定啊。”
说完，他有些得意地在纸上算开了。“32个计算节点总共需要500～650MB/s的带宽，就需要至少7个千兆网卡……”
“最高级的PC服务器也只有6个全速的PCI插槽，你那第7个网卡插哪儿？”老梁打断了他。
“而且你没算千兆网卡的效率问题、PCI总线的效率问题、多网卡绑定的效率问题，这些都算上的话，14个网卡也未必真能支持到500～650MB/s的带宽。”
“而且还要给连接磁盘阵列的光纤卡留几个PCI插槽吧。”
“@#$%&……”
大家七嘴八舌地批评着，幸亏会议室里没有西红柿和鸡蛋，要不……
小蔡一脸郁闷，蔫了。
其实，问题就出在这个结构上。单一I/O节点就是系统的死结，应该引入多I/O节点。最好向用户推荐时下最流行的SAN架构吧。
“芝麻开花节节高”
1．用SAN补救多I/O
如果简单地通过SAN把两个I/O节点连接到一个磁盘阵列上，那等于还是两个独立的I/O节点在工作（如图3）。
图3 SAN架构多I/O节点模式
对一个计算任务来说，由于所有计算节点都需要访问同一个数据文件，读写负载其实还是压到了一个I/O节点上。两个I/O节点根本不能负载均衡地承担同一个任务。
这样的多I/O节点形同虚设，性能跟单I/O节点是一模一样的。
2．从多I/O走向文件共享
“明白了，但是现在有软件可以实现SAN架构文件共享啊。”小吴抓过了图示，改动了几下。
“喏，在两个I/O节点上安装文件级共享的软件，这样两个I/O节点就能看到相同的数据了，计算节点无论通过A还是B都能看到相同的数据。这样不就行了？”
“其实，这样还是有问题的。”老梁一边说，一边在图上又添了几笔（见图4）。“你看，所有计算节点被手工地分成两个部分。一部分只访问A节点，另外一部分只访问B节点，这个管理工作是很复杂的。”
图4 多I/O节点间文件级共享
“搞什么飞机？这点工作量也叫复杂？！”小吴又不解了。
这下小蔡又逮到了开口的机会，“真的是相当复杂！”他煞有介事地说。“因为很多情况下，一个集群可能会同时运行好几个任务，而且每个任务的计算资源要求也不一样，所以几乎是每增加一个任务，就要为这个任务设置一遍NFS绑定关系；每调整一次计算资源分配，也要设置一遍。到最后，往往是管理员自己也搞不清楚这些绑定关系了。”
“反正很复杂就是了。”老梁似乎讨论得有点累了，说话有些无精打采。
3．蜕化与进步
“我还有办法，可以干脆去掉I/O节点嘛！”小吴果然年轻，活力一点没减弱。他转身摸出一张白纸，画了起来。一会儿，又一个画满箭头和线条的图示（见图5）出现了。
图5 I/O节点蜕化为MDC，
计算节点接入SAN
小吴把图示推到桌子中央，介绍说，把刚才的那个方案稍微改动一下，不是在I/O节点上安装文件共享软件，而是在计算节点上安装。然后把计算节点直接连到SAN上，I/O节点只充当MDC，真正的数据流并不通过它，而是直接从磁盘阵列到计算节点。
“等等，什么叫MDC？”大家显然对这个概念都很陌生，连忙打断小吴的话。
MDC就是Meta Data Controller，它的角色就像个调度员，计算节点需要访问数据之前先问它数据在哪儿，但是访问数据的时候并不通过它，而是自己直接去拿。
IBM有个叫做GPFS的技术，号称是Linux并行集群专用存储系统，就是这么做的。
“那就是说，我们已经搞定喽？”小蔡出了口气，站起来伸着懒腰。
“好像还是有问题。”杨经理说话了。要不是这一声，大家还以为他早就睡着了呢。
“还有什么问题？”这回连老梁也弄不懂了。
“你们看看总共需要多少光纤卡？多少光纤交换端口？”
“32个计算节点当然是需要32片光纤卡啊。”
“不考虑冗余，至少要这么多。光这一块的成本就在50万左右了。还有交换呢？”
“32个计算节点，加上1个I/O节点，再加上4个磁盘阵列的端口，总共需要37个端口，看来得用一个48或者64端口的光纤交换机。”
“那又需要大概50万左右。”
“天啊！还没算磁盘阵列，就已经100万啦！人家现在10TB的存储系统一共才100万的预算。”
“还有呢，你还没算文件共享软件的钱吧？据我所知，每个节点的软件费用也要7～8万，这样算下来，32个节点上的软件费用还需要20多万。”
用户之所以用Linux并行集群，就是因为它性能价格比高，这样一搞，成本都跟大型机的价格差不多了，人家就没有用Linux集群的必要了。
4．iSCSI智取FC
用iSCSI替换光纤通道，好像可以降低些成本。
光纤卡换成iSCSI卡或者普通千兆网卡，20万就可以搞定32个节点了。光纤交换机换成无阻塞的千兆网络交换机，估计也就在10万左右。
这样的话，刚才的100万就减到30万了，不过共享软件的钱省不下，还是20多万。
“用户的预算一共只有100万。我们还没算最主要的磁盘阵列呢，就花了一半的预算了。还是不行！成本太高，太高。”老梁不满地说。
“哎！没办法，Linux用户总是投资这么有限，难怪他们用Linux，开放源码当然不花钱了，可是世界上没有免费开放的磁盘阵列给他们用啊。”小蔡开始不耐烦地发牢骚了。
“要说免费开放的东西嘛～还真有！”小吴转着眼珠，使劲回忆着。“有个叫PVFS的技术，就是免费开放的。”
5．PVFS笑到了最后
PVFS中文意思是并行虚拟文件系统。最开始是美国一个大学里的几个学生，为改善Linux并行集群做的课题，后来就发展成一个开放技术了，网上有源码，可以直接下载的。
应用PVFS的系统结构（见图6）跟前面那些不一样，它实现的是多I/O节点的负载均衡。不需要文件级共享软件，也不需要在计算节点里插光纤卡。
图6 多I/O节点间以PVFS实现负载均衡
PVFS的原理是把多个I/O节点虚拟成一个节点，这样前端的计算节点只需要简单地绑定一个NFS卷，就把负载分到所有的I/O节点上了。以PVFS构建的系统也不再需要SAN系统内文件共享，因为每个原始数据文件在I/O节点一级就被分割为一组小数据块，分散存储。
PVFS本身有两个重要版本。其中PVFS1存在严重的单点故障问题，一旦管理服务器宕机，则整个系统都无法正常工作。PVFS2中针对这个隐患做了比较大的修正，不再单独设立管理服务器，而是各个运行IOD进程的节点都可以接管该功能，以此来改善系统的单点故障问题。
“这些技术细节我就不想听了，这个技术有成功案例吗？”听了老梁冗长地介绍，小吴插话了。
“国外好像有，但……不是很多。”
“这种又便宜又好的东西，怎么会没人用呢？”
“这个技术现在只支持Linux平台，对其他平台还不能支持。”
“这恐怕不是问题吧，很多用户环境都是很纯粹的Linux环境啊。”
“恐怕是技术的成熟度和服务保证的顾忌吧。”杨经理开腔了。“这个技术不是由商业公司最终产品化的商品，而是基于GPL开放授权的一种开放技术。虽然免费获取该技术使整体系统成本进一步降低，但没有商业公司作为发布方，它的后续升级维护还有跟其他软件产品的兼容性等一系列服务，恐怕都难以得到保证。”
“萝卜白菜各取所爱”
“这就难办了，讨论了一下午，还是没个确定的方案。”老梁丧气的表情已经很明显了。
“别急，其实这一下午的讨论还是有收获的。”杨经理俨然是在做总结发言了。“用户的应用需求发展得这么快，现有产品和技术总是无法100%的满足需求，这也是正常的，否则IT技术就没有发展的动力了。”
“而且我们正是出于对用户负责，才在这里做分析的，对吗？我看前面讨论过的几个方案都各有优势，问题也同样明显。你们几个会后做个总结，把几个方案对比一下。”
如果用户可以接受管理维护的复杂性，那么方案二似乎最经济实惠。
如果用户愿意接受基于GPL无原厂商服务支持的自由产品，并在短期内不考虑对非Linux集群系统的整合问题，则可以采用PVFS技术，即采用方案五。
方案三虽然是所有方案中性能最好的，但是高昂的成本显然不是每一个用户都愿意接受的。
会后不久，一份方案对比表（见表1）交到了杨经理的办公桌上。
链接
超算即超级计算，也称高性能计算HPC（High Performance Computing），是计算密集型技术的总称。其中最常见的技术主要有三大类：
● 大型SMP，例如那些动辄数百颗CPU的IBM、Cray、SGI的大型机均属此类；
● 基于IA架构的Linux并行集群，因其低廉的价格和天然的开放性，近来已经逐渐成为超算的主流技术；
● 网格计算，可算做超算未来的希望。
Linux并行集群主要由负责执行计算任务的“计算节点”和负责统一管理数据的“I/O节点”组成，两种节点间一般通过标准NFS协议交换数据。当一个计算任务被加载到集群系统时，各个“计算节点”首先从“I/O节点”获取数据，然后进行计算，计算完成之后再将计算结果写入“I/O节点”。在这个过程中，计算的开始阶段和结束阶段“I/O节点”的负载非常大，而在计算处理过程中，却几乎没有任何负载。
表1 5种方案综合指标对比
方案一 方案二 方案三 方案四 方案五