近两年来，超融合和软件定义存储（简称SDS）方案如雨后春笋般涌现，方案多了难免会有鱼目混珠。遗憾的是目前。测试的标准，一些流行的测试方法，尤其是性能测试方法存在漏洞，虚高的产品性能，增加了用户选择好产品的难度。
本文旨在揭露测试作假的原理和方法，并针对性提出如何发现和防止作假的方法。在开始正文之前，需要说明以下几点：
首先，本文“测试过程中作假”的定义为：通过一些临时的手段（这些手段无法应用于生产环境，比如使用特定的系统配置、使用特定的测试顺序或甚至修改程序），以获得比系统在正常生产环境下高很多的性能测试数据。
其次，本文只讨论与性能相关的测试方法，不涉及功能测试等（本文作者还写了一篇相关文章“超融合产品，如何辨别真伪”探讨如何直观的判断SDS的优劣）。而且，本文的作假方法适用于使用SATA或SAS磁盘作为存储介质的SDS系统。对于使用全闪存的SDS系统不完全适用。
再次，由于超融合系统的性能在很大程度上依赖于它的储存系统（通常也为SDS），所以本文章的所涉及的内容也可以应用于超融合系统。
最后，SDS可以有多种存储形态（参见“AWS存储前系统架构师陈靓：我看国内软件定义存储”），本文章总是以ServerSAN产品为例，其他的存储形态，如对象存储等也部分适用文章里提及的原则和方法。
测试作假的总原则和应对的方法
ServerSAN 产品的性能通常从IOPS和响应延迟两个方面来考量。为了得到虚高的性能数据，各种测试作假的手段基本上是围绕着如何能减少或者避免对储存介质进行读写操作。另外，网络传输会增加读写延迟，通过一些手段缩短IO路径，尽可能避免网络传输，这种作假方式可以使得测出来的读写延迟很小。
所以作假的手段的总原则是：
1)尽可能不对服务器的磁盘进行读写，而尽可能对缓存（通常为内存，也包括高性能的PCIE卡和SSD盘）进行读写。
2)尽可能缩短IO路径，尽可能避免网络传输。这种作假方式可以使得测出来的读写延迟很小。
针对作假的总原则，发现和应对方法的总原则是：
1)可以用iostat命令去观察存储服务器上的磁盘读写操作的IOPS。如果iostat反映出来的读写IOPS和测出来的性能数据相差很大，甚至存储介质没有任何的读写操作，则测试出来的性能数据不正确。
2)可以通过“长时间、大量数据读写”的方式来应对只对缓存数据读写和恶意缩短IO路径的作假。
3)对读写的数据进行一致性检查。
6种常见的作假手段和应对办法
作假测试方法1：用小的卷做性能测试，比如卷的大小小至1GB。
原理：ServerSAN系统一般都有缓存，分为一级和二级。一级缓存通常是内存，大小从1GB到几十个GB不等；二级是PCIE卡或者是SSD盘，大小从200GB到1TB不等。当使用小卷进行性能测试时，卷的数据都被缓存在内存或PCIE卡上，这样测出来的读写性能数据是内存的读写速度，而不是系统在生产环境下的真正体现的性能数据。
发现方法: 总原则1，即用iostat观察。
防止作假手段：用大卷（大小比缓存大）做测试。
作假的测试方法2：先测读性能，再测写性能。
原理：很多ServerSAN系统能记录下来卷的哪些部分被写过了，哪些没被写过。对没有写过的部分进行读时，系统可以直接返回0，而不需要去服务器的存储介质上去读这些数据。如果对一个空卷进行读测试时，测出来的读性能虚高。甚至会出现随机读将网络带宽跑满。在实际应用中，可以观察到现象是随着写入卷的数据越来越多，卷的读请求的性能逐步降低。
发现方法: 总原则1，即用iostat观察。
防止作假手段：先用顺序写把整个卷写一遍，然后再开始读性能测试。
作假的测试方法3：先做顺序性能测试，再做随机性能测试。
原理：这种作假方式在用小卷做性能测试尤为管用，能测出很高的随机读写性能。原因是通过顺序读写测试，可以将卷的大部分数据缓存在内存里，在紧接下来的随机测试，数据读写皆发生在内存里，导致测出来的随机性能数据虚高。
发现方法: 总原则1，即用iostat观察。
防止作假手段：用大卷（大小比缓存大）做测试，而且总是先测随机，再测顺序读写性能。
作假的测试方法4：打开客户端驱动程序的Write-back缓存。
原理：当Write-back的缓存生效时，即使应用程序的数据被要求刷到存储服务器后端，数据放在缓存里面，而没有通过网络传到后端服务器上，便返回写成功。我们不建议在生成环境下使用客户端Write-back的缓存，因为这种缓存方式很容易导致应用程序的数据丢失。但是把客户端Write-back的缓存打开，同时结合用小卷做测试，即将客户端缓存的空间增加到比卷的大小还大时，几乎所有的IO请求都在客户端上处理，能测出来“最好的性能数据”
发现方法: 总原则1，即用iostat观察。
防止作假手段：用大卷做长时间（比如1个小时的读写）测试。
作假的测试方法5：测试读性能时，直接返回假数据，而不读磁盘或从磁盘里只读一部分的数据。
原理：系统只处理小部分读请求。 这种作假方式能够测试出很好的读性能。
发现方法: 验证写入数据的一致性。
防止作假手段：测试用例需要既测性能，还需要验证读写一致性。参见测试用例1和2。
作假的测试方法6：测试写性能时，直接扔掉数据，不写或写一部分数据到磁盘。
原理：系统只处理小部分写请求。这种作假方式能够测试出很好的写性能。
发现方法: 验证读出来的数据的一致性。
防止作假手段：测试用例需要既测性能，还需要验证读写一致性。参见测试用例1和2。
不容易作假的测试方法
目前，测试性能的流行工具有FIO等。但单纯用FIO测出来的系统性能，无法反映ServerSAN在实际环境下的性能。这是因为实际应用的数据同时包括一定的随机数据和一定的顺序数据，还有在一定时间范围内的热点数据；而FIO只能产生纯随机或纯顺序数据集。
以下将提出一些测试用例，既可以防止测试作假，又可以测试出ServerSAN系统更贴近实际应用的性能数据。
测试用例1：读写大文件测试系统的顺序读写性能
（1）创建一个1TB的卷，并将卷挂载到测试机上。在这个卷上创建ext4文件系统。
（2）在测试机的某个SSD盘上（必须是SSD盘，否则会影响测试结果）准备好100个5G的文件，并为每个文件生成MD5的校验文件。
（3）将在SSD盘中的100个文件拷贝到卷里，记录完成所有文件拷贝的时间，这个时间可以认为是卷的顺序写的时间。
（4）将100个文件从卷里拷贝出来到SSD盘上的不同的目录下，记录完成所有文件拷贝的时间，这个时间可以认为是卷的顺序读的时间
（5）计算从卷里拷贝出来的100个文件的各自的MD5校验码，验证和相应的源文件的校验码一致。
测试用例2：用Oracle RAC数据库测试系统的随机读写性能
（1）安装用于性能测试的oracle 虚拟机2台（6vCPU，32GB内存，系统卷20GB，可以挂载虚拟机所在物理机的本地硬盘）， 为Oracle创建3个卷。每个卷的大小分别为300G、400G和500G。将Oracle RAC安装在这三个卷上。
（2）创建一个数据库。
（3）将SwingBench安装在另外一台虚拟机上，配置它指向RAC中的其中一个数据库实例，调整并发数量为250个，运行30分钟后，观察平均的TPM值。
测试用例3：用FIO测试系统的读写性能和相应延迟
用FIO测试时必须遵循以下几个原则：测大卷、测长时间；先测随机、再测顺序；先测写、再测读。
（1）创建两个卷，一个大卷（假设设备名为/dev/bigv），大小1TB，用于FIO性能测试。一个小卷，大小10G，安装一个ext4文件系统。
（2）用 dd if=/dev/zero of=/dev/bigv count=1048576 bs=1048576把大卷的每个字节置零。
（3）在以下进行FIO性能测试的同时，每隔10秒钟向文件系统拷贝一个小文件，并且调用sync命令将文件从文件系统的缓存刷到小卷上。每次FIO性能测试结束后，umount掉文件系统，重新mount文件系统，查看是否文件存在并且内容正确。
（4）测试分为随机读写和顺序读写。每个测试时间为2个小时，用单线程，direct模式，用libaio和iodepth 128方式发送IO。举例而言，用于随机写测试的命令为：
fio -name randwrite -filename /dev/Pyd0 -ioengine libaio -direct=1 -group_reporting -bssplit=8K -iodepth=128 -ramp_time=10 -runtime=7200 -rw=randwrite –time_based
标准化软件定义存储的测试还有很长的路要走，本文希望能起到抛砖引玉的作用，期待出现越来越多的文章来探讨这个话题。
作者简介：陈靓，1999年北京航空航天大学硕士毕业，2002年考入美国俄亥俄州立大学学习计算机科学，2006年获得该校博士学位。此后入职美国Amazon，于AWS Storage Team（云计算核心存储团队）工作，长达7年之久，曾经担任系统架构师和研发团队带头人，负责设计和实现了著名的AWS Glacier系统结构；2011年加入AWS S3团队，负责对AWS S3 的Volume子系统新版本的研发。2013年，接受南京市政府321计划的感召，选择归国创业，创办了南京鹏云网络科技有限公司，致力于私有云存储产品的研发。2015年入选中组部“国家千人计划”专家人才。
