ESXi等虚拟机的存储IO会因为阵列的Cache而性能迥异。
阵列Cache使用方式对系统性能的影响
提及磁盘阵列，大家可能都不会感到陌生。这项技术利用多块磁盘组合成一个逻辑磁盘，数据的读写也按照不同的分散排列方式，取自或存储于不同的磁盘中。该技术所带来的好处是它不仅可以利用多块硬盘为系统组建出一个更大的存储空间，更重要的是它可以提高磁盘数据的读写性能和容错能力。正是由于RAID具有这些特点，使它成了服务器配备存储系统时的首选。
在阵列卡的使用配置中，大家可能更多的会考虑使用哪种阵列方式，而忽略了对阵列卡其它一些设置项的关注，而正是这种疏忽常常会带来很大的性能差异，接下来我们就以cache写入方式为例，来揭示在进行阵列卡配置时不同的设置对于系统性能产生的影响。
此次进行对比分析时我们所使用的服务器平台为一台IBM System X3550 M3，该服务器配有两个至强5630处理器，6条4GB DDR3 1333内存。磁盘为4块2.5英寸，容量为146GB，带16MB缓存的万转硬盘，它所使用的阵列卡是一块IBM ServeRAID M5015，该阵列卡的设计规格与LSI MegaRAID SAS 9260-8i完全相同。
接下来我们就来介绍在对比分析时，磁盘阵列卡的设置过程 。在服务器系统启动时，首先进入到服务器BIOS界面下，并选择System Settings项。
系统BIOS界面
接下来选择Adapter UEFI Drivers项。
System Settings界面
选择LSI EFI SAS Driver磁盘阵列卡。
Adapters UEFI Drivers界面
进入到磁盘阵列卡的配置界面。
磁盘阵列卡配置界面
在下边的配置界面中可以看到，我们利用该阵列卡及4块硬盘组建了一个RAID 5阵列。
RAID选择和配置界面
在这里我们主要关注的是Default Write选项，该选项有Write Through、Always Write Back以及Write Back with BBU三种选择，其中Write Back with BBU是阵列卡配有Battery Backup模块元时的可选项，它的作用是用以在系统断电时保护Cache中的数据，避免断电造成中间数据的丢失。
另外就是Access选项，该项用于规定在读、写和读写时使用缓存。该阵列卡缺省设置为读，用户可根据实际应用需要来选择，不过通常为了平衡系统的读写性能，最常采用的是RW模式。
阵列Cache模式设置
Write Through和Write Back是阵列卡Cache的两种使用方式，也称为透写和回写。当选用write through方式时，系统的写磁盘操作并不利用阵列卡的Cache，而是直接与磁盘进行数据的交互。而write Back方式则利用阵列Cache作为系统与磁盘间的二传手，系统先将数据交给Cache，然后再由Cache将数据传给磁盘。
在采用这两种不同的Cache使用方式时，对于系统性能有何影响呢，接下来我们就以对比实验来揭开这一谜题。 测试分两种模式，一是在在安装阵列卡后，采用它的缺省设置，此时阵列卡Cache采用的是Write Through，而ACCESS并非是RW，而是READ。另一测试模式则ACCESS采用的是RW，阵列卡Cache采用的是Write Back。
读取IOps
读取吞吐量
写入IOps
写入吞吐量
从以上4张测试对比图我们可以看到一个有趣现象，那就是在两种不同的工作模式下，缺省设置与在RW且Write Back配置下相比，前者的读取性能要远高于后者，而写入性能则刚好相反，可谓泾渭分明。
导致这一现象的原因主要来自两个方面，一是Access选择的不同，缺省模式下采用的是read，这直接提升了该模式下系统的读取性能。然而在写入时，由于缺少了阵列卡Cache的支持，系统要写数据到磁盘时，会直接进行磁盘写入，而与系统的I/O能力相比，磁盘的读写速度要慢出很多，这直接致使系统写盘的下降。
Netbench测试结果对比
Netbench测试结果主要反映的是系统被用作文件服务器时，能够为用户访问提供的数据吞吐量。由于该项重点考查的是服务器的磁盘读取性能，因此该服务器在缺省模式下比另一模式下有2.5倍的性能优势也就不足为奇。
SQL2005测试结果对比
在SQL2005测试中，我们看到两种不同模式在性能结果上基本相当，这是该项测试主要考察的是在数据库的查询、添加、删除、修改等操作时服务器的处理能力，该项测试中更为偏重于对数据库的查询，而实际的写盘操作要远少于读盘操作，这就使得缺省模式下系统超强的读取性能弥补了它写盘较慢的不足。结果使得测试成绩相差不多。
通过以上几项测试大家不难发现，在阵列卡的设置中，不仅仅是RAID方式会影响到存储子系统的读写性能，阵列卡中一个小小的设置往往会带来应用性能的巨大差异。因此在阵列卡的使用中，对于如何设置大家还真应该重视。
