针对业务系统的架构瓶颈,通过群集文件系统来提升数据交互效率
系统业务处理裕量由原来的50%下降到25%甚至更低
（3）利用应用“解耦”提升系统可靠性
业务应用模块并不关心业务数据在哪里
一套完整计费帐务流程所涉及的17个模块不用绑定在一台主机上
（4）利用磁盘共享提高存储资源利用率，提高应用调度运维效率
通过构建全局存储视图将需要管理的存储空间数量有效降低了70％，将预留的冗余存储空间容量有效降低了50％
废止原有的socket和ftp等通过网络的数据交互模式,提高流水处理效率
通过细分业务、号段的方式实现业务调度粒度的精细化管理
应用系统运行及配置环境集中管理，实现一点配置，全网生效
（5）极佳的鲁棒性和系统弹性
每个业务模块的故障切换速度提升10～20倍，达到<1分钟的快速切换能力，提升了系统整体生存能力
未来新的业务处理节点、数据存储空间添加、业务模块调度调整可以在线进行，系统架构未发生变化，为系统平台的能力提升提供了安全、高效的手段
提供分级存储接入及数据存储规划能力，帮助对业务数据进行生命周期管理，实现分级存储，随需调度，降低系统采购成本并体现节能减排效益
5、系统鲁棒性及性能测试结果
为了对新的架构有一个全面准确的认识，我们对该平台进行了为期2个月的全面系统的性能及鲁棒性测试，从测试结果看，该平台基本达到了设计预期，详细情况如下：
5.1平台性能测试结果汇总
5.1.1系统平台读IOPS性能
对比各个层面的性能数据，我们可以发现：
在读IOPS压力场景下，各个层面基本都随着节点数量的增加而体现出线性的性能提升
多路径软件的开销相对裸设备层面而言并不大
单机环境下逻辑卷的开销相对多路径层面而言并不大，在多主机并行工作时，还有1~3%提高，这种应用的典型场景是Orac eRAC架构
文件系统在处理IOPS操作时，开销比较巨大，但这个在预期之内，我们发现通过增加节点的数量，可以有效提升系统整体的IOPS，鉴于目前四节点场景下，系统线性度非常好，我们有理由相信群集文件系统的节点规模和整体IOPS性能还有进一步提升的余地
5.1.2系统平台写IOPS性能
对比各个层面的性能数据，我们可以发现：
在写IOPS压力场景下，两个节点的压力基本可以达到硬件的性能瓶颈
多路径软件的开销相对裸设备层面而言并不大，但随着节点数量和并行度的提高,这一开销比例逐步减小. 另外多个节点对性能提升的比例并不大, 因此我们有理由相信，对于写操作的IOPS，如果应用直接采用裸设备的方式（比如数据库），那么增加节点对于存储性能的提升不大
文件系统在处理IOPS操作时，开销比较巨大，但这个在预期之内，我们发现通过增加节点的数量，可以有效提升系统整体的IOPS，由于文件系统的IOPS处理能力相对硬件极限还有非常大的空间，因此对于文件系统应用场景，通过增加运算节点的数量还突破单机的性能极限变得非常有意义，如果在增加节点时，系统还可以维持目前的线性度，整体系统的节点扩展极限大致为6个节点并行（此时达到硬件处理性能瓶颈）
5.1.3系统平台读吞吐量性能
对比各个层面的性能数据，我们发现在读吞吐量压力场景下：
从磁盘到文件系统，各个层面性能差别不大，说明各层面在处理大IO吞吐时，开销均不大
系统瓶颈当单机时，在系统HBA吞吐极限（1.5GB/S）
系统瓶颈当并行时，在磁盘阵列的吞吐极限（2.7GB/S）
两节点并行即可达到硬件瓶颈，进一步增加节点数量好处不大
5.1.4系统平台写吞吐量性能
对比各个层面的性能数据，我们发现在写吞吐量压力场景下：
从磁盘到文件系统，各个层面性能差别不大，说明各层面在处理大IO吞吐时，开销均不大
系统瓶颈当单机时，已经达到硬件极限（1.45GB/S）
系统瓶颈当并行时，性能基本没有变化
逻辑卷在并行处理时，性能反而有所下降
文件系统并行处理的效果要好于逻辑卷，这说明文件系统的buffercache在这里起了一定的作用，在处理IO争用时，有一定的buffer可以有效降低冲突发生的几率，从而提高性能
5.2平台鲁棒性测试结果汇总
5.2.1SAN链路子系统测试结果汇总
当模拟故障发生时，各场景对系统整体最大吞吐量的影响如下图所示：
当模拟故障发生时，个场景从震荡到恢复稳定工作所需时间如下图所示：
5.2.2操作系统I/O子系统测试结果汇总
当模拟故障发生时，各场景对整体稳定性的影响和自身业务应用切换时间如下图：
