GlusterFS测试
1 官方性能测试文档：
2 测试工具
2.1 fio
FIO是测试IOPS的非常好的工具，是一个I/O标准测试和硬件压力验证工具，它支持13种不同类型的I/O引擎（sync, mmap, libaio, posixaio, SG v3, splice, null, network, syslet,guasi, solarisaio等），I/O priorities (for newer Linux kernels), rate I/O, forked orthreaded jobs等等。fio可以支持块设备和文件系统测试，广泛用于标准测试、QA、验证测试等。
2.1.1 安装
apt-get install fio2.1.2 命令说明
Read Bandwidth test 读带宽测试：
fio --filename=/dev/sdb --direct=1 --rw=read --bs=1m --size=5G --numjobs=4 --runtime=10 --group_reporting --name=test-read
Write Bandwidth test 写带宽测试：
fio -filename=/dev/sdb1 -direct=1 -rw=write -bs=1m -size=5g -numjobs=4 -runtime=20 -group_reporting -name=test-write
Read IOPS test 随机读测试：
fio -filename=/dev/sdb1 -direct=1 -rw=randread -bs=4k -size=5G -numjobs=64 -runtime=20 -group_reporting -name=test-rand-read
Write IOPS test 随机写测试：
fio -filename=/dev/sdb1 -direct=1 -rw=randwrite -bs=4k -size=5G -numjobs=64 -runtime=20 -group_reporting -name=test-rand-write 说明：
filename=/dev/sdb1 测试文件名称，通常选择需要测试的盘的data目录。
direct=1 测试过程绕过机器自带的buffer。使测试结果更真实。
rw=randwrite 测试随机写的I/O
rw=randrw 测试随机写和读的I/O
bs=16k 单次io的块文件大小为16k
bsrange=512-2048 同上，提定数据块的大小范围
size=5g 本次的测试文件大小为5g，以每次4k的io进行测试。
numjobs=30 本次的测试线程为30.
runtime=1000 测试时间为1000秒，如果不写则一直将5g文件分4k每次写完为止。
ioengine=psync io引擎使用pync方式
rwmixwrite=30 在混合读写的模式下，写占30%
group_reporting 关于显示结果的，汇总每个进程的信息。
此外
lockmem=1g 只使用1g内存进行测试。
zero_buffers 用0初始化系统buffer。
nrfiles=8 每个进程生成文件的数量。
2.1.3 实例
root@compute:~# fio -filename=/mnt/dd_prof_10 -direct=1 -rw=randread -size 5G -numjobs=8 -runtime=120 -group_reporting -name=randread_4_psync
randread_4_psync: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
...
randread_4_psync: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.1.3
Starting 8 processes
randread_4_psync: Laying out IO file(s) (1 file(s) / 5120MB)
Jobs: 2 (f=2): [rr______] [14.4% done] [868KB/0KB/0KB /s] [217/0/0 iops] [eta 11m:59s]
randread_4_psync: (groupid=0, jobs=8): err= 0: pid=14178: Wed Mar 29 17:25:19 2017
read : io=108992KB, bw=929778B/s, iops=226, runt=120037msec
clat (msec): min=7, max=309, avg=35.23, stdev=21.11
lat (msec): min=7, max=309, avg=35.23, stdev=21.11
clat percentiles (msec):
| 1.00th=[ 13], 5.00th=[ 16], 10.00th=[ 18], 20.00th=[ 21],
| 30.00th=[ 23], 40.00th=[ 26], 50.00th=[ 30], 60.00th=[ 34],
| 70.00th=[ 39], 80.00th=[ 47], 90.00th=[ 61], 95.00th=[ 77],
| 99.00th=[ 114], 99.50th=[ 129], 99.90th=[ 169], 99.95th=[ 223],
| 99.99th=[ 302]
bw (KB /s): min= 38, max= 174, per=12.50%, avg=113.34, stdev=17.69
lat (msec) : 10=0.11%, 20=18.98%, 50=64.09%, 100=15.03%, 250=1.76%
lat (msec) : 500=0.03%
cpu : usr=0.04%, sys=0.13%, ctx=54522, majf=0, minf=65
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=27248/w=0/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
READ: io=108992KB, aggrb=907KB/s, minb=907KB/s, maxb=907KB/s, mint=120037msec, maxt=120037msec2.2 iozone
Iozone是一个文件系统的benchmark工具，可以测试不同的操作系统中文件系统的读写性能。
可以测试 Read, write, re-read, re-write, read backwards, read strided, fread等等不同的模式下的硬盘的性能。
2.2.1 安装
apt-get install iozone32.2.2 说明
测试参数：
-i 代表测试项目
Used to specify which tests to run. (0=write/rewrite, 1=read/re-read, 2=random-read/write 3=Read-backwards, 4=Re-write-record, 5=stride-read, 6=fwrite/re-fwrite, 7=fread/Re-fread, 8=random mix, 9=pwrite/Re-pwrite, 10=pread/Re-pread, 11=pwritev/Re-pwritev, 12=preadv/Re-preadv).
One will always need to specify 0 so that any of the following tests will have a file to measure.
-i # -i # -i # is also supported so that one may select more than one test.
0=write/rewrite 1=read/re-read 2=random-read/write
测试格式为-i #，比如测试写：-i 0,测试读和写：-i 0 -i 1。
-R 产生execl格式的输出日志
-b 将产生二进制的execl的日志文件名。
-s 测试的文件大小 -r 文件块大小
-a 在希望的文件系统上测试，不过只有-a的话会进行全面测试，要花费很长时间，最好用-i指定测试范围。
默认情况下record size从4K—16M，file size从64K—512M。
-g 指定最大测试文件大小
-n 指定最小测试文件大小
-t 启动线程的个数
当线程都创建好以后每个线程分别同时创建一个文件去读写
举例说明 iozone –t 2 –s 3m – r 50k –I 0 –I 1 F test1 test2 （强调必须的大写的F）
这个指令是说 创建两个线程 这两个线程同时写文件，线程1写test1,线程2写test2，文件大小为3m 以 50k的块大小去写
在这里可以插一句块大小与iops的关系：吞吐量=块大小*iops
当有其中一个文件写成个之后，这个测试就结束-F 指定临时测试文件组
-C 显示每个节点的吞吐量。
-c 测试包括文件的关闭时间
-e 测试包括flush时间
-w 测试结束后保留测试时产生的测试文件
参考：iozone的使用与介绍 http://blog.sina.com.cn/s/blog_3cba7ec10100ea62.html
iozone能测试direct io，并且能清除cpu cache的影响，分别通过指定-p, -I实现。通过如下测试：
iozone -i 0 -i 1 –Rb –p -I /root/test-iozone.xls -s 16m –q 4k读写的平均速率只在20-30MB/S。
2.2.3 iozone测试项
1.Write: 测试向一个新文件写入的性能。当一个新文件被写入时，不仅仅是那些文件中的数据需要被存储，还包括那些用于定位数据存储在存储介质的具体位置的额外信息。这些额外信息被称作“元数据”。它包括目录信息，所分配的空间和一些与该文件有关但又并非该文件所含数据的其他数据。拜这些额外信息所赐，Write的性能通常会比Re-write的性能低。2.Re-write:测试向一个已存在的文件写入的性能。当一个已存在的文件被写入时，所需工作量较少，因为此时元数据已经存在。Re-write的性能通常比Write的性能高。
3.Read: 测试读一个已存在的文件的性能。
4.Re-Read: 测试读一个最近读过的文件的性能。Re-Read性能会高些，因为操作系统通常会缓存最近读过的文件数据。这个缓存可以被用于读以提高性能。
5.Random Read: 测试读一个文件中的随机偏移量的性能。许多因素可能影响这种情况下的系统性能，例如：操作系统缓存的大小，磁盘数量，寻道延迟和其他。
6.Random Write: 测试写一个文件中的随机偏移量的性能。同样，许多因素可能影响这种情况下的系统性能，例如：操作系统缓存的大小，磁盘数量，寻道延迟和其他。
7.Random Mix: 测试读写一个文件中的随机偏移量的性能。同样，许多因素可能影响这种情况下的系统性能，例如：操作系统缓存的大小，磁盘数量，寻道延迟和其他。这个测试只有在吞吐量测试模式下才能进行。每个线程/进程运行读或写测试。这种分布式读/写测试是基于round robin 模式的。最好使用多于一个线程/进程执行此测试。
8.Backwards Read:测试使用倒序读一个文件的性能。这种读文件方法可能看起来很可笑，事实上，有些应用确实这么干。MSC Nastran是一个使用倒序读文件的应用程序的一个例子。它所读的文件都十分大（大小从G级别到T级别）。尽管许多操作系统使用一些特殊实现来优化顺序读文件的速度，很少有操作系统注意到并增强倒序读文件的性能。
9.Record Rewrite: 测试写与覆盖写一个文件中的特定块的性能。这个块可能会发生一些很有趣的事。如果这个块足够小（比CPU数据缓存小），测出来的性能将会非常高。如果比CPU数据缓存大而比TLB小，测出来的是另一个阶段的性能。如果比此二者都大，但比操作系统缓存小，得到的性能又是一个阶段。若大到超过操作系统缓存，又是另一番结果。
10.Strided Read:测试跳跃读一个文件的性能。举例如下：在0偏移量处读4Kbytes，然后间隔200Kbytes,读4Kbytes，再间隔200Kbytes，如此反复。此时的模式是读4Kbytes，间隔200Kbytes并重复这个模式。这又是一个典型的应用行为，文件中使用了数据结构并且访问这个数据结构的特定区域的应用程序常常这样做。
许多操作系统并没注意到这种行为或者针对这种类型的访问做一些优化。同样，这种访问行为也可能导致一些有趣的性能异常。一个例子是在一个数据片化的文件系统里，应用程序的跳跃导致某一个特定的磁盘成为性能瓶颈。
11.Fwrite: 测试调用库函数fwrite()来写文件的性能。这是一个执行缓存与阻塞写操作的库例程。缓存在用户空间之内。如果一个应用程序想要写很小的传输块，fwrite()函数中的缓存与阻塞I/O功能能通过减少实际操作系统调用并在操作系统调用时增加传输块的大小来增强应用程序的性能。
这个测试是写一个新文件，所以元数据的写入也是要的。
12.Frewrite:测试调用库函数fwrite()来写文件的性能。这是一个执行缓存与阻塞写操作的库例程。缓存在用户空间之内。如果一个应用程序想要写很小的传输块，fwrite()函数中的缓存与阻塞I/O功能能通过减少实际操作系统调用并在操作系统调用时增加传输块的大小来增强应用程序的性能。
这个测试是写入一个已存在的文件，由于无元数据操作，测试的性能会高些。
13.Fread:测试调用库函数fread()来读文件的性能。这是一个执行缓存与阻塞读操作的库例程。缓存在用户空间之内。如果一个应用程序想要读很小的传输块，fwrite()函数中的缓存与阻塞I/O功能能通过减少实际操作系统调用并在操作系统调用时增加传输块的大小来增强应用程序的性能。
14.Freread:这个测试与上面的fread 类似，除了在这个测试中被读文件是最近才刚被读过。这将导致更高的性能，因为操作系统缓存了文件数据。
3 测试指标吞吐量与IOPS
参考资料：
论存储IOPS和Throughput吞吐量之间的关系 http://www.csdn.net/article/2015-01-14/2823552
浅析I/O处理过程与存储性能的关系 https://community.emc.com/docs/DOC-28653
4 使用iozone对glusterfs的性能测试
首先新建一个glusterfs卷，然后关掉io-cache, read-ahead, write-behind这些用于提高性能的xlator。
关闭方法：
gluster volume set XXX off将卷挂载到/mnt，执行iozone开始测试。
root@compute:~# iozone -a -n 128m -g 2g -i 0 -i 1 -i 2 -r 4K -r 16K -r 64K -f /mnt/iozone
Iozone: Performance Test of File I/O
Version $Revision: 3.420 $
Compiled for 64 bit mode.
Build: linux-AMD64
Run began: Wed Mar 29 15:31:13 2017
Auto Mode
Using minimum file size of 131072 kilobytes.
Using maximum file size of 2097152 kilobytes.
Record Size 4 KB
Record Size 16 KB
Record Size 64 KB
Command line used: iozone -a -n 128m -g 2g -i 0 -i 1 -i 2 -r 4K -r 16K -r 64K -f /mnt/iozone
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
131072 4 11560 11560 398175 6827669 6014715 10985
131072 16 11568 11569 344740 7542390 7799635 11444
131072 64 11565 11566 328127 7764385 8699795 11549
262144 4 11520 11517 446189 7138026 4838743 10943
262144 16 11520 10777 390574 7926704 8080615 11400
262144 64 11519 11518 430082 8133817 9057544 11501
524288 4 11494 11494 487850 7421765 5786403 10922
524288 16 11497 11496 481602 8238485 5791890 11378
524288 64 11496 11496 428869 8466091 9246049 11478
1048576 4 11447 11485 488633 6190779 5636838 10912
1048576 16 11484 11484 532139 8433942 8230327 11367
1048576 64 11484 11484 522952 8688892 9378701 11468
2097152 4 11478 11348 510073 7583866 5577905 10906
2097152 16 11479 11377 494023 8534271 6861982 11362
2097152 64 11478 11455 497551 8848032 9445856 11461
iozone test complete.5 多客户端测试
iozone支持Gluster的多客户端测试，测试的大致思路是，在一台服务器上同时向Gluster的两台client端同时发送指令，进行写文件测试。
首先要配置好rsh，因为同时向两个client发送指令需要无密码登陆，iozone 的 +-m指令就是这么要求的。具体配置rsh我就不多说，其次就是Iozone –t 2 –s 32m –r 50k -+m client.txt
-+m filename
Used to specify a filename that will be used to specify the clients in a distributed measurement. The file contains one line for each client. The fields are
space delimited. Field 1 is the client name. Field 2 is the working directory, on the client, where Iozone will run. Field 3 is the path to the executable
Iozone on the client.这个client.txt文件的写法 ：
198.168.1.111 /mnt/dht3-client /bin/iozone
这三部分 别是 Gluster client所在的服务器 client路径 和 在client服务上 iozone的执行路径
1 使用命创建卷并启动。
Brick在block1和block2上。
root@block1:~# gluster volume create volume_mul_client replica 2 block1:/glusterfs/brick1 block2:/glusterfs/brick1 block1:/glusterfs/brick2 block2:/glusterfs/brick2 force
volume create: volume_mul_client: success: please start the volume to access data
root@block1:~#
root@block1:~# gluster volume info
Volume Name: volume_mul_client
Type: Distributed-Replicate
Volume ID: d397c037-6b4e-49cd-a10b-e0867b1d9b94
Status: Created
Snapshot Count: 0
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: block1:/glusterfs/brick1
Brick2: block2:/glusterfs/brick1
Brick3: block1:/glusterfs/brick2
Brick4: block2:/glusterfs/brick2
Options Reconfigured:
transport.address-family: inet
performance.readdir-ahead: on
nfs.disable: on
oot@block1:~# gluster volume start volume_mul_client
volume start: volume_mul_client: success
root@block1:~# gluster volume status
Status of volume: volume_mul_client
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick block1:/glusterfs/brick1 49158 0 Y 27942
Brick block2:/glusterfs/brick1 49157 0 Y 24844
Brick block1:/glusterfs/brick2 49159 0 Y 27961
Brick block2:/glusterfs/brick2 49158 0 Y 24863
Self-heal Daemon on localhost N/A N/A N N/A
Self-heal Daemon on compute N/A N/A N N/A
Self-heal Daemon on block2 N/A N/A N N/A
Task Status of Volume volume_mul_client
------------------------------------------------------------------------------
There are no active volume tasks2 挂载
root@block1:~# mount -t glusterfs 192.168.4.133:/volume_mul_client /mnt
root@block1:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 12K 3.9G 1% /dev
tmpfs 788M 800K 787M 1% /run
/dev/dm-0 909G 2.0G 861G 1% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 0 3.9G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/sda1 236M 75M 149M 34% /boot
/dev/sdb1 924G 35M 924G 1% /glusterfs
192.168.4.133:/volume_mul_client 1.9T 70M 1.9T 1% /mnt3 在block1和block2上安装rsh-server，在compute上安装rsh-client
参考：http://blog.csdn.net/zhaihaifei/article/details/684900394 使用iozone命令
在compute结点：
root@compute:~# iozone -a -n 128m -g 1g -i 0 -i 1 -i 2 -r 4K -r 16K -r 64K -f /mnt/iozone -+m client
Iozone: Performance Test of File I/O
Version $Revision: 3.420 $
Compiled for 64 bit mode.
Build: linux-AMD64
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
Vangel Bojaxhi, Ben England, Vikentsi Lapa.
Run began: Thu Mar 30 17:29:57 2017
Auto Mode
Using minimum file size of 131072 kilobytes.
Using maximum file size of 1048576 kilobytes.
Record Size 4 KB
Record Size 16 KB
Record Size 64 KB
Network distribution mode enabled.
Command line used: iozone -a -n 128m -g 1g -i 0 -i 1 -i 2 -r 4K -r 16K -r 64K -f /mnt/iozone -+m client
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random
KB reclen write rewrite read reread read write
131072 4 1274846 2303512 4700784 5254696 4488945 2767448
131072 16 1697784 2550280 5177641 5684239 5571389 3091106
131072 64 1574799 2688715 5324882 5314946 5647684 3243228
262144 4 1607201 2672974 5000853 5719063 4884725 3405443
262144 16 1780191 2745972 5503397 6126136 6264959 3735682
262144 64 1784067 2888292 5659044 6609596 7136636 4273486
524288 4 1841771 2977471 5486765 5459169 5056297 3734913
524288 16 2029606 3201835 6075945 7514744 7794007 3217082
524288 64 2229019 3311862 6211722 7549910 8452164 5216025
1048576 4 2134101 3596790 6127437 8038705 4643723 3696543
1048576 16 2372961 3957516 6791607 6821650 8067015 4830301
1048576 64 2445196 4013717 6990693 7010841 9009938 5446781参考：
1 glusterfs文件系统性能测试：http://blog.csdn.net/u014022631/article/details/32911669
2 http://blog.csdn.net/skdkjzz/article/details/41620589
3 GlusterFS与Ceph性能测试报告：http://www.openstack.cn/?p=2215
6 可靠性和可用性区别简介
可用性（Availability）是关于系统可供使用时间的描述，以丢失的时间为驱动（Be Driven By Lost Time）。可靠性（Reliability）是关于系统无失效时间间隔的描述，以发生的失效个数为驱动（Be Driven By Number of Failure）。两者都用百分数的形式来表示。
在一般情况下，可用性不等于可靠性，只有在没有宕机和失效发生的理想状态下，两者才是一样的。
1可用性
可用性最简单的表示形式是：A = Uptime / ( Uptime + Downtime )
如果我们要讨论一年的可用性，公式的分母就必须至少是8760小时。固有可用性从设计的角度来看待可用性：
Ai = MTBF / ( MTBF + MTTR )MTBF，mean time between failureMTTR，mean time to repair 或者
Ai = MTTF / ( MTTF + MTTR )MTTF，mean time to failMTTR，mean time to replace
从上述公式可以看出。如果平均失效间隔时间（MTBF，mean time between failure）或平均
失效前时间（MTTF，mean time to fail）远大于平均修复时间（MTTR，mean time to repair）或者平均恢复时间（MTTR，mean time to replace），那么可用性将很高。同样的，如果平均修复时间或平均恢复时间很小，那么可用性将很高。如果可靠性下降（比如MTTF变小），那么就需要提高可维护性（比如减小MTTR）才能达到同样的可用性。当然对于一定的可用性，可靠性增长了，可维护性也就不是那么重要了。所以我们可以在可靠性和可维护性之间做出平衡，来达到同样的可用性，但是这两个约束条件必须同步改进。 如果系统操作中没有人为疏忽的发生，Ai 是我们可以观察到的最大的可用性了。
在实际环境中，我们采用使用可用性公式。使用可用性公式考虑了人为影响的因素。 A0 = MTBM/ ( MTBM + MDT )
平均维护间隔时间（MTBM，mean time between maintenance）包括所有纠正的和预防行为
的时间（相比 MTBF 只关心失效发生时的维护更切合实际应用）。平均宕机时间（MDT，meandown time）包括所有跟宕机有关的纠正维护（CM，corrective maintenance）时间，MDT中包括了：
（1）修复失效过程中如路途、材料等方面造成的延迟时间（相比 MTTR 只关注失效修复时间更切合实际应用）
（2）为了防止宕机等失效而做的预防性维护操作（PM，preventive maintenance）时间因为在实际操作中总会有一些人为的延迟和疏忽。因此基于以上两点，A0 在数值上比 Ai 要小，但更接近系统实际的可用性。
2可靠性
可靠性最简单的表达式可以用指数分布来表示。它表述了随机失效。
R = e^[-(λ*t)] = e^[-(t/Θ)]
其中：
t = 运行时间Mission Time （1天，1 周，1月，1年等，可根据要求确定）λ = 失效率 Failure Rate
Θ = 1/λ = Mean Time To Failure 或 Mean Time Between Failures
注意，可靠性必须以任务时间作为一个参数去计算结果，当你在听取某产品的可靠性宣传
时优要关注，如果时间很短，则不合理。当你置疑失效模式，更要关注指数分布的表达式，因为：
（1）利用指数分布估算可靠性并不需要太多的信息作为输入（2）它可以充分代表由多种失效模式和机制组成的复杂系统（3）你几乎可以不必跟他人解释其复杂性。
当MTTF 或 MTBF 或 MTBM与运行时间（Mission Timw）相比比较长时，你可用可靠性
（Reliability）去度量（如不发生失效的可能性）；当MTTF 或 MTBF 或 MTBM跟运行时间相比比较短时，你可用不可靠性（Unreliability）去度量（如发生失效的可能性）。
参考：http://wenku.baidu.com/view/de6090bbfd0a79563c1e72a6.html
提高可靠性需要强调减少系统中断（故障）的次数，提高可用性需要强调减少从灾难中恢复的时间。
A系统每年因故障中断十次，每次恢复平均要20分钟，B系统每年因故障中断2次，每次需5小时恢复。则A系统可用性比B系统高，但可靠性比B系统差。
可靠性的量化指标是周期内系统平均无故障运行时间，可用性的量化指标是周期内系统无故障运行的总时间。一般提高可靠性的同时，也同时提高了可用性。
要提高可靠性，可使用变更管理，UPS，RAID，Cluster，链路冗余等管理和技术手段减少系统Down机的可能性。要提高可用性，除提高可靠性外，还可以使用合理备份，业务连续性计划等方式来减少从灾难中恢复的时间。
如何理解“可靠性”和“可用性”？：http://blog.csdn.net/cszhouwei/article/details/38459095
7 存储系统的可靠性
7.1 研究存储系统的可靠性
一 为什么要研究存储系统的可靠性
提升可靠性的主要途径大体上三类：1. 提高存储介质的品质2. 提高传输线路的品质3. 提高冗余度
研究存储系统的可靠性的目的之一就是想办法节约成本。尤其是市面上，大多数人采用的方案是基本一致的。如果，你能提供比别人便宜但是性能指标更好的服务，那就赢得了市场的先机。
对于一个存储集群来说，可靠性通过提高冗余度的方式来提升。带来冗余的方式除了副本，其实还有一个途径就是erasure code.
二 我们可以选择的冗余方案
给什么样的一个系统做冗余
首先，它得是个大型的存储系统，太小的系统太不稳定，突发的情况很多。
其次，我们得定义一下这个存储系统是用来干嘛的。我们可以把存储系统理解为计算机的外部存储，功能是存，取，删和移动资源。对象存储（以及类对象存储的文件存储系统）的可靠性问题。
最后，整个系统的总体成本得比较低，这样昂贵的和少见的硬件规格就被淘汰了。可以淘汰全闪存的设计。另外企业级磁盘也被淘汰了。企业级磁盘省在质保周期比较长，仅此而已(实际上，在扇区错误上企业级磁盘有一定优势）。就用最便宜的民用级的SATA盘作为存储介质好了。
这个性能可能不够啊?答案要从两个方面找，一个是提高网络传输水平，另一个是提高缓存质量（简单来说就是副本集群上面有个SSD热门资源的集群，再在SSD之上还有内存缓存，再出口外部还有一圈CDN做缓存。）。
冗余的两个途径，要么做副本，要么做erasure code。其中，三副本是最常见的实现方式，可用性和可靠性都不错，就是成本高。
为了节约成本，很多人使用了erasure code。EC(erasure code)用的多的有这么几种实现：Reed Solomon codes(RS)，Tornado Codes（LDPC）,另外还有fountain codes，Xcode，weaver等等。其中RAID5，应该是大家对熟悉的。但是，RAID5在不考虑扇区故障的情况下，只能容许一组raid中一块盘的去世，这个可靠性似乎不够用(准确的说是相当不够用，1副本的策略带来的效果和没有副本几乎是一样的）。
GlusterFS从设计之初就将可靠性纳入核心设计，采用了多种技术来实现这一设计目标。
首先，它假设故障是正常事件，包括硬件、磁盘、网络故障以及管理员误操作造成的数据损坏等。GlusterFS设计支持自动复制和自动修复功能来保证数据可靠性，不需要管理员的干预。
其次，GlusterFS利用了底层EXT3/ZFS等磁盘文件系统的日志功能来提供一定的数据可靠性，而没有自己重新发明轮子。
再次，GlusterFS是无元数据服务器设计，不需要元数据的同步或者一致性维护，很大程度上降低了系统复杂性，不仅提高了性能，还大大提高了系统可靠性。
7.2 如何衡量存储系统的可靠性
衡量存储系统可靠性的指标通常可用性（availability）和持久性（durability）：可用性（availability）：在任何给定的时刻，系统都可以正确的操作，可根据用户的行为来执行它的功能，用（故障时间/总时间）来衡量
数据持久度（durability）：表明数据保持不丢失/破坏的能力，用（1-数据丢失的概率）来衡量。
除此之外，运营存储系统的厂商通常还用RPO和RTO来展示发生故障时，对用户产生的影响。
RPO（Recovery Point Objectives）：恢复点目标，指当灾难发生后，容灾系统能将数据恢复到灾难发生前的哪一个时间点的数据。它是系统在灾难发生后将损失多少数据的指标。RPO越短，则丢失的数据越少。1个0分钟的RPO表明没有数据可以丢失，因为数据及时的备份、复制或记录下来，从而阻止任何数据丢失。
RTO（Recovery Time Objectives）：恢复时间目标，是恢复数据经历的最大时长。
8 稳定性测试
稳定性是指一个系统或设备能够稳定运行的程度，包括系统的冗余及抗干扰能力等。
可靠性是指一个系统或者设备能够安全可靠运行的程度，是指能不失效并完成系统规定任务的能力。
性能是软件的一种非功能特性，关注的是软件在完成特定功能是展示出来的及时性。及时性从不同的视角代表不同的指标：
1、用户：响应时间
2、系统管理员：资源利用率，可扩展性，系统稳定性，系统容量
3、开发人员：系统架构，数据库设计，设计和代码实现
可见，系统稳定性对系统管理员的意义重大，稳定性的好坏也可以直接影响到最终用户所关心的“响应时间”，所以说稳定性测试时性能测试中非常重要的一环。
稳定性测试（亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为7x24小时），检测系统是否能够稳定运行。
8.1 如何实施
· 识别并确认软件主要业务（是否需要稳定性测试）将稳定性测试的重心放在软件最有Value的地方，比如说一个抢票系统，它最有value的地方是当有一定数量的用户同时进行买票操作是系统的相应时间，资源利用率等是否能够正常且稳定，而不是用户如何添加新的联系人，修改个人信息等
· 罗列主要用户场景及相应负载量
用户场景可以根据软件主要业务进行设定
对主要场景负载量需要有一个清晰的定义（或者通过负载测试验证了用户场景的负载量，这将作为一个标准的负载在稳定性测试中使用）
· 制定稳定性指标模型（Modeling）
根据用户场景建模，创建合适合理的稳定性指标模型（之后会有一个例子）
· 测试环境准备（对软硬件环境的配置：配置的来源可以是客户环境模拟、需求文档规定的配置或者配置测试得出的最佳配置）
· 识别稳定性的主要性能指标（KPI）
用来描述稳定性测试关注的系统指标，比如响应时间、CPU、内存使用率等等，需要根据具体业务进行定义
· 测试的执行和数据收集
按照相应稳定性指标模型（Modeling)分析测试结果
将测试结果应用在稳定性测试模型中，观察是否满足稳定性要求
· 持续改进（如有必要）