Storwize V7000：SSD与RAID-5
摸底测验：SSD确非万金油
在检验Easy Tier的成效之前，我们首先对Storwize V7000环境中SSD和硬盘驱动器的性能进行了一个摸底测试，既可以作为之后参考的标尺，也能帮助大家认识何种类型的应用能够从自动分层存储中获益。
测试使用的IBM刀片配置2个英特尔至强X5355四核处理器，4GB内存，Windows Server 2003 SP2，稍显过时，但足以配合12个驱动器的的Storwize V7000
在测试软件上，我们选择了两种较为常用的评估工具：IOmeter 2006.07.27和Orion 10.2。Orion是Oracle I/O Numbers的简写，模拟Oracle数据库的I/O操作，可以评估存储系统运行数据库应用的性能，作为IOmeter的补充。
8个硬盘驱动器构成的存储池（SASR5-7D1P），和2个SSD构成的存储池（SSD），两个默认的图标很形象，但也可以更换。因为都是单存储层，所以两个存储池的Easy Tier功能处于不活动状态
我们首先建立两个单层的存储池，分别包含一个由硬盘驱动器组成的MDisk，和一个由SSD组成的MDisk。前者是8个300GB 10K RPM硬盘驱动器构成的RAID 5（“优化性能”模式的最大值，外加1个热备盘），可用存储空间约1.9TB；后者是2个300GB SSD构成的RAID 10，相当于SSD Easy Tier，只是没有热备盘，可用存储空间约280GB。两个存储池的可用空间之比约为6:1，我们各划出一个200GB的卷，运行IOmeter和Orion测试。
小数据块随机读，2个SSD的IOPS，约20倍于8个10K RPM HDD
IOmeter随机读：2个SSD的RAID 1（IBM称为RAID 10，应该是指其在读操作时从两个驱动器中获取数据，从而得到两倍于单驱动器的性能），性能大约是8个10K RPM硬盘驱动器的20倍（最低也有17倍）。换算过来，单个SSD的性能是10K RPM硬盘驱动器的80倍。
在数据块较小时，2个SSD的顺序读性能与8个10K RPM HDD基本相当，128KB以上后者逐渐胜出，并在2MB时有一个大幅度的跃升；因为RAID 5的缘故，8个10K RPM HDD的顺序写性能较低，同样在2MB时大幅跃升，估计是Storwize V7000的RAID代码的特性
IOmeter顺序读：大多数情况下，这2个SSD的顺序读性能与8个10K RPM HDD相当，较大数据块时，后者能达到前者的2倍左右。换算过来，单个SSD的顺序读性能是10K RPM HDD的2至4倍，与随机读相比，优势很不明显。考虑到带宽密集型应用往往也需要很大的容量，以及SSD高昂的价格，硬盘驱动器是更为合适的选择。
由于Storwize V7000控制器的写策略和项目时间等因素，我们没有考察SSD的写性能，但能感觉到比读性能有不小的降低。SSD在写性能上的衰减也是很多人关心的话题，不过本文的主题不是与硬盘驱动器比较，所以不再展开。无论如何，SSD在IOPS性能上的优势已是公认的事实，不然也就没有必要讨论自动分层存储了。
SSD与硬盘驱动器的Orion性能对比
Orion：在代表数据库性能的Orion测试中，2个SSD在IOPS性能上的优势没有IOmeter里那么夸张，“只有”8个10K RPM硬盘驱动器的10倍出头，换算成单挑的理想状况，大约是46倍。带宽性能（MBps）的优势倒是比IOmeter时大，达到2.5倍；延迟则只有十分之一，证明SSD的响应时间很短，反应非常迅速。
小结：SSD的性能优势主要体现在需要很高IOPS的小数据块随机访问，符合条件的典型应用如数据库，甚至Orion的输出MBps亦有明显提升。不过数据库日常操作的MBps更多还是来自随机访问和突发传输，总体数据量不会很大。那些需要大数据量传输的高清视频等应用，一则重复使用某些数据的几率不高（难有热点），二则数据量非常大，不符合自动分层存储的精神。正如本文开篇所言，那些以频繁访问较少量数据为特征的应用，才是自动分层存储技术大展身手的理想场合。
待机而发：Easy缘于全自动
如果用Easy Tier实现分层存储真的很简单，关键在哪里？是高度的自动化，几乎不需要用户干预，如果不是某些应用的性能突然提升，很难感知到它的存在。
Easy Tier不仅是不需要用户干预，事实上用户也很少有机会干预。因为Easy Tier基本没有用户可控的选项，而是在每个存储池（Storage Pool）内部，自动地运作。当存储池内只有一个存储层（可以是一或多个MDisk，包括来自外部存储阵列的逻辑卷）时，不管是SSD层，还是HDD层（Easy Tier只支持这两个存储层），Easy Tier都处于不活动状态——没有活动的理由。
只有一种情况，用户需要面对与Easy Tier有关的选项，即告诉Easy Tier加入存储池的来自外部存储阵列的MDisk属于哪个层，因为Storwize V7000通过存储虚拟化功能只能看到逻辑卷，无法知道其底层的硬件构成——如果是个外部的固态盘阵列呢？
当另一个存储层加入进来，Easy Tier便转为活动状态，为在层间迁移数据搜集信息并加以分析。如果新加入的MDisk由SSD组成，Easy Tier会在监测一段时间后，把热点数据从已有HDD组成的MDisk（们）上迁移过去；反之，则逐渐把SSD组成的MDisk上较少访问的数据，向HDD组成的MDisk迁移。
向只有硬盘驱动器的存储池中加入SSD组成的MDisk（红色方框中），在扩展存储池容量的同时，也开启了Easy Tier的功能
Easy Tier转入活动状态多久之后，就可以在层间迁移数据了呢？按照IBM的说法，这段时间太短了不行，过于频繁的迁移反而影响性能；太长了又不能对“热点”的变化作出及时的响应，所以设定为24小时。这个时间用户不能更改，但不意味着不可调节——IBM工程师们能够利用内部版本的固件，只经过1小时的数据采集分析便开始迁移，以免向用户演示功能的时候等待太长时间。
加入SSD（mdisk1）变为两个存储层之后，存储池的Easy Tier转为活动状态。存储池的名称和图标可以手动修改，不过信息栏中没有列出构成mdisk的驱动器类型，显得不够直观
不过，我们在测试中发现了一个有趣的事情：在建立了含有1.9TB HDD层（8个300GB 10K RPM做RAID 5）和约300GB SSD层（2个300GB做RAID 1）的存储池，随即对上面的特定区域不间断访问（制造热点）之后，不到23小时，这些区域所对应的数据块（Extent）就开始从HDD层向SSD层迁移了！
在有两个存储层的情况下，新创建的卷会先由较低的HDD层分配存储空间，其后由Easy Tier视访问频度决定把哪些数据块迁移到较高的SSD层上
具体些说，这个2.2TB的（HDD和SSD）混合存储池建成之后，我们在上面创建了两个卷，100GB的运行IOmeter，检验子卷级自动分层存储；110GB的运行Orion，观察整卷迁移的状况，作为辅助。
用IOmeter在100GB的卷上创建一个50GB的文件，检验Easy Tier的子卷级自动分层存储功能
原本IOmeter与Orion一样，通常是在一个卷的范围内进行访问操作，这样的话整个卷都可能会是热点区域，不适合用来测试子卷级自动分层存储功能。不过，在已经建立文件系统的卷上，IOmeter会先创建一个名为iobw.tst的文件，然后在这个文件里面模拟卷访问操作。如此一来，热点区域就被限制在这个文件的范围内，Easy Tier应该只迁移所对应的数据块，而卷上其他区域的数据块不受影响，从而证明其子卷级自动分层存储能力。
存储池中的Extent（扩展数据块）们正在从HDD层（mdisk0）向SSD层（mdisk1）迁移
两个卷上的测试同时进行，持续约18小时的随机访问，然后停止第二个卷上的Orion测试，此时两个卷还都在HDD层的mdisk0上。因为要等到24小时，我们在第一个卷上零星运行IOmeter，但是存储池建成还不到23小时，IOmeter的测试成绩突然大幅度提升！立即查看卷的详细信息，发现已经有一些Extent迁移到SSD层的mdisk1上了。
iobw.tst文件所对应的Extent迁移完成，可见卷只有一部分迁移到了SSD层，其余非热点区域仍保存在HDD层，成功验证“子卷级自动分层存储”
正如之前根据子卷级自动分层存储的定义所推断的，100GB的卷只有保存iobw.tst文件内容的数据块被迁移到SSD层上。数据块（即Extent）的粒度为256MB，所以这个“子卷”的总容量会比iobw.tst文件略大，约为51GB。
“子卷”迁移完成，HDD层（mdisk0）上保留的与迁移到SSD层（mdisk1）上的Extent（扩展数据块）数统计
小结：由于数据块的颗粒度限制，子卷级自动分层存储所迁移的数据多少会超出实际需要，但总比迁移整个卷要好得多。以我们这个例子来说，多迁移的数据不会超过256MB（默认的Extent尺寸），而若是卷级自动分层存储，多迁移的数据将超过48GB，相差近200倍。而在实际应用中，子卷级多迁移的数据可以更多或更少（譬如粒度更大或更小，Storwize V7000的Extent尺寸就有一个变动范围），卷级多迁移的数据与实际需要之间的比例则很有可能更大（本例约为1:1）。
iobw.tst文件所对应的Extent迁移完成，可见卷只有一部分迁移到了SSD层，其余非热点区域仍保存在HDD层，成功验证“子卷级自动分层存储”
正如之前根据子卷级自动分层存储的定义所推断的，100GB的卷只有保存iobw.tst文件内容的数据块被迁移到SSD层上。数据块（即Extent）的粒度为256MB，所以这个“子卷”的总容量会比iobw.tst文件略大，约为51GB。
小结：由于数据块的颗粒度限制，子卷级自动分层存储所迁移的数据多少会超出实际需要，但总比迁移整个卷要好得多。以我们这个例子来说，多迁移的数据不会超过256MB，而若是卷级自动分层存储，多迁移的数据将超过48GB，相差近200倍。而在实际应用中，子卷级多迁移的数据可以更多或更少（譬如粒度更大或更小），卷级多迁移的数据与实际需要之间的比例则很有可能更大（本例约为1:1）
简化管理：子卷与整卷随意分层
第一个卷（100GB）上因IOmeter测试而成为热点区域的约50GB“子卷”迁移完之后，Easy Tier继续从HDD层迁移相邻的卷。由于运行Orion的缘故，这个110GB的卷上热点遍布，整体都被迁移到SSD层。
运行Orion的110GB卷开始从HDD层向SSD层迁移
随着时间的推移，从HDD层（mdisk0）迁移到SSD层（mdisk1）的扩展数据块（Extent）越来越多
这个110GB的卷在迁移时并没有应用在运行，大约每分钟能迁移4GB左右的数据（16个256MB的Extent）。之前约50GB的“子卷”迁移时大概也是这个速度，虽然上面还在运行IOmeter，但似乎还不足以构成影响。
整个卷的110GB都已迁移到SSD层
迁移完毕，构成卷的扩展数据块（Extent）全部转移到了SSD层（mdisk1）
在层间迁移前后，我们也进行了IOmeter和Orion的对比测试。
IOmeter随机读：与之前在200GB的卷上进行的“摸底测试”相比，这一次是在50GB左右的iobw.tst文件上运行IOmeter。从硬盘驱动器的角度来讲，这50GB的空间缩小了访问的范围，也更靠近盘片的外圈，相当于“短击”（short-stroke）的效果，因此在Easy Tier动手迁移之前（仍在HDD层），随机读IOPS比原先200GB硬盘驱动器MDisk上时高出约10%。好在Easy Tier把这50GB迁移到SSD层之后，IOPS也比原来有同等幅度的提升……所以迁移后（SSD）与迁移前（HDD）的性能之比仍然在20倍左右，验证了子卷级自动分层存储的效果。
50GB的“子卷”迁移到SSD层之后，性能提升幅度与第5页SSD与HDD对照测试的比值基本相符
IOmeter顺序读：以顺序读写为主的应用不是自动分层存储技术优化的对象，我们依然进行了相应的测试，主要还是作为迁移成功的辅助判别依据。同样是在iobw.tst文件（而非真正的卷）上测试的缘故，迁移前后的性能都比原来在HDD和SSD上的对应测试略高，但是同样条件下的相对比值基本保持不变。
Easy Tier迁移之后（SSD层）与Easy Tier迁移之前（HDD层）的相对值，和第5页的同一测试表现一致
Orion：由于前几段提到的“短击”因素，Easy Tier迁移前（HDD层）的IOPS比200GB HDD MDisk时高出约10%（相应地，延迟有较明显缩短），不过迁移后（SSD层）也有小幅提升，所以两者之比（SSD vs. HDD）仍维持在11倍左右；MBps方面，迁移后亦比200GB SSD MDisk时高出约10%，迁移前则有所下降，所以两者之比拉大到3倍。显然，卷级自动分层存储的效果同样得到了验证。
卷从HDD层迁移到SSD层之后，Orion性能提升同样显著
总结：卷的概念大于子卷，能在子卷级实现自动分层存储，当然也可以对整卷进行自动分层操作。在具有多个存储层的存储池，新建的卷会先从分配给较低的存储层（如HDD层）分配存储空间，如果访问频度达到了“热点”的标准，自动分层存储软件会将相应的数据块迁移到较高的存储层（如SSD层）上来，以改善IOPS性能和响应时间（降低延迟）。反之亦然，在访问频度降下来（变“冷”）以后，自动分层存储软件也会将相应的数据块迁移到较低的存储层上，节约宝贵的SSD资源。
在设计合理的子卷级自动分层存储软件的帮助下，管理员只需要给应用分配所需的存储空间，而不用考虑它们对存储介质的性能要求，大幅度减少人工规划和手动调整的工作量，从而达到简化管理的目标——如同那自动挡的豪华跑车，驾驶员把握好方向即可，升档还是降档无须操心，要享受急速狂飙的乐趣时，狠狠踩下油门就好了……
在检验Easy Tier的成效之前，我们首先对Storwize V7000环境中SSD和硬盘驱动器的性能进行了一个摸底测试，既可以作为之后参考的标尺，也能帮助大家认识何种类型的应用能够从自动分层存储中获益。
测试使用的IBM刀片配置2个英特尔至强X5355四核处理器，4GB内存，Windows Server 2003 SP2，稍显过时，但足以配合12个驱动器的的Storwize V7000
在测试软件上，我们选择了两种较为常用的评估工具：IOmeter 2006.07.27和Orion 10.2。Orion是Oracle I/O Numbers的简写，模拟Oracle数据库的I/O操作，可以评估存储系统运行数据库应用的性能，作为IOmeter的补充。
8个硬盘驱动器构成的存储池（SASR5-7D1P），和2个SSD构成的存储池（SSD），两个默认的图标很形象，但也可以更换。因为都是单存储层，所以两个存储池的Easy Tier功能处于不活动状态
我们首先建立两个单层的存储池，分别包含一个由硬盘驱动器组成的MDisk，和一个由SSD组成的MDisk。前者是8个300GB 10K RPM硬盘驱动器构成的RAID 5（“优化性能”模式的最大值，外加1个热备盘），可用存储空间约1.9TB；后者是2个300GB SSD构成的RAID 10，相当于SSD Easy Tier，只是没有热备盘，可用存储空间约280GB。两个存储池的可用空间之比约为6:1，我们各划出一个200GB的卷，运行IOmeter和Orion测试。
小数据块随机读，2个SSD的IOPS，约20倍于8个10K RPM HDD
IOmeter随机读：2个SSD的RAID 1（IBM称为RAID 10，应该是指其在读操作时从两个驱动器中获取数据，从而得到两倍于单驱动器的性能），性能大约是8个10K RPM硬盘驱动器的20倍（最低也有17倍）。换算过来，单个SSD的性能是10K RPM硬盘驱动器的80倍。
在数据块较小时，2个SSD的顺序读性能与8个10K RPM HDD基本相当，128KB以上后者逐渐胜出，并在2MB时有一个大幅度的跃升；因为RAID 5的缘故，8个10K RPM HDD的顺序写性能较低，同样在2MB时大幅跃升，估计是Storwize V7000的RAID代码的特性
IOmeter顺序读：大多数情况下，这2个SSD的顺序读性能与8个10K RPM HDD相当，较大数据块时，后者能达到前者的2倍左右。换算过来，单个SSD的顺序读性能是10K RPM HDD的2至4倍，与随机读相比，优势很不明显。考虑到带宽密集型应用往往也需要很大的容量，以及SSD高昂的价格，硬盘驱动器是更为合适的选择。
由于Storwize V7000控制器的写策略和项目时间等因素，我们没有考察SSD的写性能，但能感觉到比读性能有不小的降低。SSD在写性能上的衰减也是很多人关心的话题，不过本文的主题不是与硬盘驱动器比较，所以不再展开。无论如何，SSD在IOPS性能上的优势已是公认的事实，不然也就没有必要讨论自动分层存储了。
SSD与硬盘驱动器的Orion性能对比
Orion：在代表数据库性能的Orion测试中，2个SSD在IOPS性能上的优势没有IOmeter里那么夸张，“只有”8个10K RPM硬盘驱动器的10倍出头，换算成单挑的理想状况，大约是46倍。带宽性能（MBps）的优势倒是比IOmeter时大，达到2.5倍；延迟则只有十分之一，证明SSD的响应时间很短，反应非常迅速。
小结：SSD的性能优势主要体现在需要很高IOPS的小数据块随机访问，符合条件的典型应用如数据库，甚至Orion的输出MBps亦有明显提升。不过数据库日常操作的MBps更多还是来自随机访问和突发传输，总体数据量不会很大。那些需要大数据量传输的高清视频等应用，一则重复使用某些数据的几率不高（难有热点），二则数据量非常大，不符合自动分层存储的精神。正如本文开篇所言，那些以频繁访问较少量数据为特征的应用，才是自动分层存储技术大展身手的理想场合。
待机而发：Easy缘于全自动
如果用Easy Tier实现分层存储真的很简单，关键在哪里？是高度的自动化，几乎不需要用户干预，如果不是某些应用的性能突然提升，很难感知到它的存在。
Easy Tier不仅是不需要用户干预，事实上用户也很少有机会干预。因为Easy Tier基本没有用户可控的选项，而是在每个存储池（Storage Pool）内部，自动地运作。当存储池内只有一个存储层（可以是一或多个MDisk，包括来自外部存储阵列的逻辑卷）时，不管是SSD层，还是HDD层（Easy Tier只支持这两个存储层），Easy Tier都处于不活动状态——没有活动的理由。
只有一种情况，用户需要面对与Easy Tier有关的选项，即告诉Easy Tier加入存储池的来自外部存储阵列的MDisk属于哪个层，因为Storwize V7000通过存储虚拟化功能只能看到逻辑卷，无法知道其底层的硬件构成——如果是个外部的固态盘阵列呢？
当另一个存储层加入进来，Easy Tier便转为活动状态，为在层间迁移数据搜集信息并加以分析。如果新加入的MDisk由SSD组成，Easy Tier会在监测一段时间后，把热点数据从已有HDD组成的MDisk（们）上迁移过去；反之，则逐渐把SSD组成的MDisk上较少访问的数据，向HDD组成的MDisk迁移。
向只有硬盘驱动器的存储池中加入SSD组成的MDisk（红色方框中），在扩展存储池容量的同时，也开启了Easy Tier的功能
Easy Tier转入活动状态多久之后，就可以在层间迁移数据了呢？按照IBM的说法，这段时间太短了不行，过于频繁的迁移反而影响性能；太长了又不能对“热点”的变化作出及时的响应，所以设定为24小时。这个时间用户不能更改，但不意味着不可调节——IBM工程师们能够利用内部版本的固件，只经过1小时的数据采集分析便开始迁移，以免向用户演示功能的时候等待太长时间。
加入SSD（mdisk1）变为两个存储层之后，存储池的Easy Tier转为活动状态。存储池的名称和图标可以手动修改，不过信息栏中没有列出构成mdisk的驱动器类型，显得不够直观
不过，我们在测试中发现了一个有趣的事情：在建立了含有1.9TB HDD层（8个300GB 10K RPM做RAID 5）和约300GB SSD层（2个300GB做RAID 1）的存储池，随即对上面的特定区域不间断访问（制造热点）之后，不到23小时，这些区域所对应的数据块（Extent）就开始从HDD层向SSD层迁移了！
在有两个存储层的情况下，新创建的卷会先由较低的HDD层分配存储空间，其后由Easy Tier视访问频度决定把哪些数据块迁移到较高的SSD层上
具体些说，这个2.2TB的（HDD和SSD）混合存储池建成之后，我们在上面创建了两个卷，100GB的运行IOmeter，检验子卷级自动分层存储；110GB的运行Orion，观察整卷迁移的状况，作为辅助。
用IOmeter在100GB的卷上创建一个50GB的文件，检验Easy Tier的子卷级自动分层存储功能
原本IOmeter与Orion一样，通常是在一个卷的范围内进行访问操作，这样的话整个卷都可能会是热点区域，不适合用来测试子卷级自动分层存储功能。不过，在已经建立文件系统的卷上，IOmeter会先创建一个名为iobw.tst的文件，然后在这个文件里面模拟卷访问操作。如此一来，热点区域就被限制在这个文件的范围内，Easy Tier应该只迁移所对应的数据块，而卷上其他区域的数据块不受影响，从而证明其子卷级自动分层存储能力。
存储池中的Extent（扩展数据块）们正在从HDD层（mdisk0）向SSD层（mdisk1）迁移
两个卷上的测试同时进行，持续约18小时的随机访问，然后停止第二个卷上的Orion测试，此时两个卷还都在HDD层的mdisk0上。因为要等到24小时，我们在第一个卷上零星运行IOmeter，但是存储池建成还不到23小时，IOmeter的测试成绩突然大幅度提升！立即查看卷的详细信息，发现已经有一些Extent迁移到SSD层的mdisk1上了。
iobw.tst文件所对应的Extent迁移完成，可见卷只有一部分迁移到了SSD层，其余非热点区域仍保存在HDD层，成功验证“子卷级自动分层存储”
正如之前根据子卷级自动分层存储的定义所推断的，100GB的卷只有保存iobw.tst文件内容的数据块被迁移到SSD层上。数据块（即Extent）的粒度为256MB，所以这个“子卷”的总容量会比iobw.tst文件略大，约为51GB。
“子卷”迁移完成，HDD层（mdisk0）上保留的与迁移到SSD层（mdisk1）上的Extent（扩展数据块）数统计
小结：由于数据块的颗粒度限制，子卷级自动分层存储所迁移的数据多少会超出实际需要，但总比迁移整个卷要好得多。以我们这个例子来说，多迁移的数据不会超过256MB（默认的Extent尺寸），而若是卷级自动分层存储，多迁移的数据将超过48GB，相差近200倍。而在实际应用中，子卷级多迁移的数据可以更多或更少（譬如粒度更大或更小，Storwize V7000的Extent尺寸就有一个变动范围），卷级多迁移的数据与实际需要之间的比例则很有可能更大（本例约为1:1）。
iobw.tst文件所对应的Extent迁移完成，可见卷只有一部分迁移到了SSD层，其余非热点区域仍保存在HDD层，成功验证“子卷级自动分层存储”
正如之前根据子卷级自动分层存储的定义所推断的，100GB的卷只有保存iobw.tst文件内容的数据块被迁移到SSD层上。数据块（即Extent）的粒度为256MB，所以这个“子卷”的总容量会比iobw.tst文件略大，约为51GB。
小结：由于数据块的颗粒度限制，子卷级自动分层存储所迁移的数据多少会超出实际需要，但总比迁移整个卷要好得多。以我们这个例子来说，多迁移的数据不会超过256MB，而若是卷级自动分层存储，多迁移的数据将超过48GB，相差近200倍。而在实际应用中，子卷级多迁移的数据可以更多或更少（譬如粒度更大或更小），卷级多迁移的数据与实际需要之间的比例则很有可能更大（本例约为1:1）
简化管理：子卷与整卷随意分层
第一个卷（100GB）上因IOmeter测试而成为热点区域的约50GB“子卷”迁移完之后，Easy Tier继续从HDD层迁移相邻的卷。由于运行Orion的缘故，这个110GB的卷上热点遍布，整体都被迁移到SSD层。
运行Orion的110GB卷开始从HDD层向SSD层迁移
随着时间的推移，从HDD层（mdisk0）迁移到SSD层（mdisk1）的扩展数据块（Extent）越来越多
这个110GB的卷在迁移时并没有应用在运行，大约每分钟能迁移4GB左右的数据（16个256MB的Extent）。之前约50GB的“子卷”迁移时大概也是这个速度，虽然上面还在运行IOmeter，但似乎还不足以构成影响。
整个卷的110GB都已迁移到SSD层
迁移完毕，构成卷的扩展数据块（Extent）全部转移到了SSD层（mdisk1）
在层间迁移前后，我们也进行了IOmeter和Orion的对比测试。
IOmeter随机读：与之前在200GB的卷上进行的“摸底测试”相比，这一次是在50GB左右的iobw.tst文件上运行IOmeter。从硬盘驱动器的角度来讲，这50GB的空间缩小了访问的范围，也更靠近盘片的外圈，相当于“短击”（short-stroke）的效果，因此在Easy Tier动手迁移之前（仍在HDD层），随机读IOPS比原先200GB硬盘驱动器MDisk上时高出约10%。好在Easy Tier把这50GB迁移到SSD层之后，IOPS也比原来有同等幅度的提升……所以迁移后（SSD）与迁移前（HDD）的性能之比仍然在20倍左右，验证了子卷级自动分层存储的效果。
50GB的“子卷”迁移到SSD层之后，性能提升幅度与第5页SSD与HDD对照测试的比值基本相符
IOmeter顺序读：以顺序读写为主的应用不是自动分层存储技术优化的对象，我们依然进行了相应的测试，主要还是作为迁移成功的辅助判别依据。同样是在iobw.tst文件（而非真正的卷）上测试的缘故，迁移前后的性能都比原来在HDD和SSD上的对应测试略高，但是同样条件下的相对比值基本保持不变。
Easy Tier迁移之后（SSD层）与Easy Tier迁移之前（HDD层）的相对值，和第5页的同一测试表现一致
Orion：由于前几段提到的“短击”因素，Easy Tier迁移前（HDD层）的IOPS比200GB HDD MDisk时高出约10%（相应地，延迟有较明显缩短），不过迁移后（SSD层）也有小幅提升，所以两者之比（SSD vs. HDD）仍维持在11倍左右；MBps方面，迁移后亦比200GB SSD MDisk时高出约10%，迁移前则有所下降，所以两者之比拉大到3倍。显然，卷级自动分层存储的效果同样得到了验证。
卷从HDD层迁移到SSD层之后，Orion性能提升同样显著
总结：卷的概念大于子卷，能在子卷级实现自动分层存储，当然也可以对整卷进行自动分层操作。在具有多个存储层的存储池，新建的卷会先从分配给较低的存储层（如HDD层）分配存储空间，如果访问频度达到了“热点”的标准，自动分层存储软件会将相应的数据块迁移到较高的存储层（如SSD层）上来，以改善IOPS性能和响应时间（降低延迟）。反之亦然，在访问频度降下来（变“冷”）以后，自动分层存储软件也会将相应的数据块迁移到较低的存储层上，节约宝贵的SSD资源。
在设计合理的子卷级自动分层存储软件的帮助下，管理员只需要给应用分配所需的存储空间，而不用考虑它们对存储介质的性能要求，大幅度减少人工规划和手动调整的工作量，从而达到简化管理的目标——如同那自动挡的豪华跑车，驾驶员把握好方向即可，升档还是降档无须操心，要享受急速狂飙的乐趣时，狠狠踩下油门就好了……
2同行回答
确实现在好多存储中都引入了SSD硬盘，能够提高数据的读写。收起
浏览2764
很好，多谢楼主分享，我正需要这方面的资料。收起
浏览2073