超算即超级计算，也称高性能计算HPC（High Performance Computing），是计算密集型技术的总称。其中最常见的技术主要有三大类：
大型SMP，例如那些动辄数百颗CPU的IBM、Cray、SGI的大型机均属此类；
基于IA架构的Linux并行集群，因其低廉的价格和天然的开放性，近来已经逐渐成为超算的主流技术；
网格计算，可算做超算未来的希望
XX公司的会议室里，几位工程师和销售正吵得欢。下周就要投标了，可是他们到现在似乎还没找到满意的解决方案。招标的项目是个勘探数据处理系统，典型的Linux并行集群环境，规模在32个节点到128个节点之间。这本来是很成熟的应用，没什么可以过多纠缠的，但是当考虑到几十个TB的存储系统时，问题好像就不那么简单了。
“用户当前最关心的，就是集群系统中的I/O性能。”发言的是资深客户经理老梁，他与物探行业打了近十年的交道，对用户的应用可谓了如指掌。“在很多情况下，集群运算能力已经很强，但是系统却要花大量的时间等待数据读写。而且往往是计算节点越多，读写过程耗费的时间就越长。你们看看这个图示，这个系统现在已经有将近一半时间是在等待I/O了。一个总共需要10小时的任务，真正花在处理上的时间只有不足6个小时。其他时间里大量的计算资源都闲着，你们看到没有？"
“这个系统里有多少计算节点？多少I/O节点？”小吴是位认真的新手，遇事总要问个仔细。
没等老梁回答，就有人接过话茬，“32个计算节点，1个I/O节点，你没看标书啊！”说话的是小蔡。跟着老梁混了这几年，现在对这个行业也算有了些了解。“Linux并行集群现在都是这个结构的，就算上到64或者128个节点，一般也只配置一个I/O节点。”说完，他还拿出了一个图示递给小吴。
“对，用户的系统现在基本就是这个结构。”老梁指着图示补充说，“用户现在已经在I/O节点上安装了两片千兆网卡，还做了双网卡负载均衡，以太网交换也早就换成千兆无阻塞的了，但是还是太慢。”
“所以我们现在要确切的定位，到底哪里是I/O性能的瓶颈。”坐在一旁半天没出声的杨经理发话了。“就按照这个系统的性能要求算一算，看到底现有的产品和技术能满足到什么程度。”
大家静了下来，都低头翻看着手头的标书。
小吴一边在纸上比划，一边自言自语的说着，“按照每个计算节点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架构吧。”
方案一：简单SAN架构多I/O节点模式
“这个想法以前我们就提出来过，不过好像问题不那么简单耶。”小蔡谨慎的抬起头，递出一张方案结构图。“你们看，如果简单的通过SAN把两个I/O节点连接到一个磁盘阵列上，那等于还是两个独立的I/O节点在工作。”
“那又怎么样？”小吴一时还没弄明白。
“对一个计算任务来说，由于所有计算节点都需要访问同一个数据文件，读写负载其实还是压到了一个I/O节点上。两个I/O节点根本不能负载均衡的承担同一个任务。”老梁解释说。“这样的多I/O节点形同虚设，性能跟单I/O节点是一模一样的。”
方案二、多I/O节点间文件级共享
“明白了，但是现在有软件可以实现SAN架构文件共享的啊。”小吴抓过了图示，改动了几下，“喏，在两个I/O节点上安装文件级共享的软件，这样两个I/O节点就能看到相同的数据了，计算节点无论通过A还是B都能看到相同的数据。这样不就行了？”
“其实，这样还是有问题的。”老梁一边说，一边在图上又添了几笔。“你看，所有计算节点被手工的分成两个部分。一部分只访问A节点，另外一部分只访问B节点，这个管理工作是很复杂的。”
“搞什么飞机？这点工作量也叫复杂？！”小吴又不解了。
这下小蔡又逮到了开口的机会，“真的是相当复杂！”他煞有介事的说。“因为很多情况下，一个集群可能会同时运行好几个任务，而且每个任务的计算资源要求也不一样，所以几乎是每增加一个任务，就要为这个任务设置一遍NFS绑定关系；每调整一次计算资源分配，也要设置一遍。到最后，往往是管理员自己也搞不清楚这些绑定关系了。”
“反正很复杂就是了。”老梁似乎讨论得有点累了，说话有些无精打采。
方案三、I/O节点蜕化为MDC，计算节点接入SAN
“我还有办法，可以干脆去掉I/O节点嘛！”小吴果然年轻，活力一点没减弱。他转身摸出一张白纸，画了起来。一会儿，又一个画满箭头和线条的图示出现了。
小吴把图示推到桌子中央，介绍说，“把刚才的那个方案稍微改动一下，不是在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集群啊？”
方案四、以iSCSI技术取代光纤通道
“用iSCSI替换光纤通道，好像可以降低些成本。”
“能降到多少？”
“光纤卡换成iSCSI卡或者普通千兆网卡，20万就可以搞定32个节点了。光纤交换机换成无阻塞的千兆网络交换机，估计也就在10万左右。”
“这样的话，刚才的100万就减到30万了，不过共享软件的钱省不下，还是20多万。加起来是……”
“还要50万啊？别忘了，用户的预算一共只有100万。我们还没算最主要的磁盘阵列呢，就花了一半的预算了。还是不行！成本太高，太高。”
“哎！没办法，Linux用户总是投资这么有限，难怪他们用Linux，开放源码当然不花钱了，可是世界上没有免费开放的磁盘阵列给他们用啊。”小蔡开始不耐烦的发牢骚了。
“要说免费开放的东西嘛～还真有！”小吴转着眼珠，使劲回忆着。“有个叫PVFS的技术，就是免费开放的。”
方案五、多I/O节点间以PVFS实现负载均衡
“你那儿名词真多！什么是PVFS？跟我们这个方案有关系吗？”
“PVFS中文叫并行虚拟文件系统，就是专门干这事的。最开始好像就是美国一个大学里的几个学生，为改善Linux并行集群做的课题，后来就发展成一个开放技术了，网上有源码，可以直接下载的。”
“那其他相关的硬件成本呢？”
“应用PVFS的系统结构跟前面那些不一样，它实现的是多I/O节点的负载均衡。不需要文件级共享软件，也不需要在计算节点里插光纤卡。”
“你们看，PVFS的原理是，把多个I/O节点虚拟成一个节点，这样前端的计算节点只需要简单的绑定一个NFS卷，就把负载分到所有的I/O节点上了。以PVFS构建的系统也不再需要SAN系统内文件共享，因为每个原始数据文件在I/O节点一级就被分割为一组小数据块，分散存储。”
“这个方案看起来倒不错。”
“PVFS本身有两个重要版本。其中PVFS1存在严重的单点故障问题，一旦管理服务器宕机，则整个系统都无法正常工作。PVFS2中针对这个隐患做了比较大的修正，不再单独设立管理服务器，而是各个运行IOD进程的节点都可以接管该功能，以此来改善系统的单点故障问题。”
“这些技术细节我就不想听了，这个技术有成功案例吗？”
“国外好像有，但是……好像不是很多。”
“这种又便宜又好的东西，怎么会没人用呢？”
“这个技术现在只支持Linux平台，对其他平台还不能支持。”
“这恐怕不是问题吧，很多用户环境都是很纯粹的Linux环境啊。”
“恐怕是技术的成熟度和服务保证的顾忌吧。”杨经理开腔了。“这个技术不是由商业公司最终产品化的商品，而是基于GPL开放授权的一种开放技术。虽然免费获取该技术使整体系统成本进一步降低，但没有商业公司作为发布方，它的后续升级维护还有跟其他软件产品的兼容性等一系列服务，恐怕都难以得到保证。”
“这就难办了，讨论了一下午，还是没个确定的方案。”老梁丧气的表情已经很明显了。
“别急，其实这一下午的讨论还是有收获的。”杨经理俨然是在做总结发言了。“用户的应用需求发展得这么快，现有产品和技术总是无法100%的满足需求，这也是正常的，否则IT技术就没有发展的动力了。而且我们正是出于对用户负责，才在这里做分析的，对吗？我看前面讨论过的几个方案都各有优势，问题也同样明显。你们几个会后做个总结，把几个方案对比一下。我的意见是，如果用户可以接受管理维护的复杂性，那么方案二似乎最经济实惠。如果用户愿意接受基于GPL无原厂商服务支持的自由产品，并在短期内不考虑对非Linux集群系统的整合问题，则可以采用PVFS技术，即采用方案五。方案三虽然是所有方案中性能最好的，但是高昂的成本显然不是每一个用户都愿意接受的。”
会后不久，一份方案对比表交到了杨经理的办公桌上。
