突破I/O瓶颈 五种解决方案各有利弊

这样看来，“存储设备瓶颈”和“存储通道瓶颈”似乎都不是难以解决的问题，那么“网络交换瓶颈”的情况又如何呢?

照搬前面的计算方法，如果要为前端32个计算节点提供15～20MB/s的带宽，I/O节点需要提供至少500～650MB/s的网络带宽。这就是说，既便完全不考虑以太网交换的额外损耗，也需要安装6～7片千兆以太网卡。而一般的PC或PC服务器最多只有两个PCI控制器，要想保证这6～7片千兆以太网卡都以最高效率工作，完全是不可能的。更何况一般以太网的效率，只有理论带宽的50%左右。就是说实际上要想达到500～650MB/s的实际带宽，需要13～15片千兆以太网卡，十几个64位PCI插槽!这大概是目前最高端的PC服务器所能提供的PCI插槽数目的二倍。

照此看来，单一I/O节点架构无疑是整个集群系统性能死结。那么考虑多I/O节点的架构会如何呢?笔者的观点是：多I/O节点架构困难重重，但势在必行。

解决I/O瓶颈的途径----多I/O节点架构

引入多I/O节点架构，涉及到很多存储技术。笔者下面的分析中，主要考虑了FC-SAN，iSCSI-SAN，基于SAN的文件共享以及PVFS(并行虚拟文件系统)等技术手段。

方案一、简单SAN架构下的多I/O节点模式

实现多I/O节点，最容易想到的第一步就是引入SAN架构。那么，我们就先来分析一下简单的SAN架构能否满足Linux并行集群的需求。

由于基本的SAN架构不能提供文件级共享，两个I/O节点还是完全独立的工作。前端的所有计算节点如果同时读取同一个文件的话，还必须经由一个I/O节点完成。由此可见，在单一任务情况下，多I/O节点的结构形同虚设，根本无法负载均衡的为前端计算节点提供服务响应。为了解决这一问题。可以考虑在多I/O节点间需要引入文件级共享的工作机制。