【IT168 技术】根据IDC和Garnter的很多报告和统计数据，我们可以得知在当今的存储器市场中，销售量增长最快、技术发展最快、市场前景最好的存储器产品当属于中端模块化存储器市场，因此本章将继续从其他角度讲解基于集群技术模块化存储器的设计思路发展。(注：现阶段中端模块化存储器发展的另外一个方向是从集群模式发展到scale out架构，这个话题不在此节讨论主题中，笔者将在后面章节中提到。)
上一节我们花了不少时间从体系结构的角度讲解了基于集群技术的模块化存储器的发展思路，我们可以发现提高存储器的整体性能很大程度上和如何提高一台服务器的整体性能的思路是很类似的，然而自古华山不止一条路，条条道路通罗马，除了简单提升控制器芯片的性能外，聪明的设计师们会独辟蹊径，从其他的方面提升存储器的性能，方法之一就是把存储器底层lun打散到多个磁盘的存储虚拟化技术。这种技术的最大特点就是使得该存储阵列的控制器能够象马克思著作里面描述的资本家一样最大程度地攫取存储器中每一块磁盘的最大性能(每次从主机端得到一个IO请求，都调动存储器内尽可能多的磁盘快速运转来响应)。
上图是一张我们经常能够看到的磁盘的参数图(包括常见的Seagate公司和HGST公司的常见磁盘型号，73GB、146GB、300GB 转速为15K/10K RPM的磁盘)，可以看到影响单个磁盘性能的主要参数包括Seek time(磁头定位寻道时间)和average latency time(和磁盘转速有关)。掌握了这两个关键指标，基本上我们可以确认存储器中单个磁盘在cache不命中的情况下的最大IOPS和顺序吞吐量等性能指标。
如一块146GB 转速15000RMP的磁盘的平均写性能为164个IO：
Avg 146K write IOPS = 1000ms / (4.1 + 2.01) = 164
而一块400GB 转速10000RPM的磁盘的平均读性能为127个IO：
Avg 300J read IOPS = 1000ms / (4.9 + 2.99) = 127
由于缓存命中率这个指标是无法事先设定的(一般开放系统中存储器系统的缓存命中率低于20%)，因此保守情况下我们是通过该存储器磁盘的性能来估算该配置下存储器的整体性能指标。但是这个所谓的保守指标往往也是很不准确的，为什么会这样呢?
下面通过一个系统管理员和DBA的亲身经历来说明一下。很多时候，当IT业务系统出现性能问题，我们都会安排性能调优，这个性能调优当然包括很多方面(应用、数据库、主机、存储和网络)，而且很多时候整个系统通过调优后都能够更加高效地运行。请注意，调优的本质是：系统整体资源是能够支撑该业务系统的，只是因为资源分配不合理才导致性能问题。所以调优的工作就是把IT资源更加合理分配的过程。
那么在存储器方面的调优主要包括什么呢?我们把存储器细细分解一下，看看可以从哪些地方打注意：
1. 控制器方面：模块化存储器的控制器的资源一般是固定死的很难改变;因此一旦你买好了一个模块化阵列，想通过修改什么公开的参数去提升控制器性能一般没戏(除非是同一个系列控制器不同等级的控制器升级，比如从HP EVA 6400控制器升级到HP EVA 8400，把EMC CX300控制器头升级到CX700，而磁盘笼子里面的数据不变，但实际操作中由于商务原因很少有人这么做);
2. 缓存命中率方面：前文说过，开放式系统的缓存命中率不高，一般只有20%左右，而缓存命中率到底能到多少本身就是个难以人为调优的问题(如果该IO类型是离散型随机IO，比如说用户到电信公司每个月查自己的话费，用户往往一个月就查询一次当月的记录，这在存储层面表现为从磁盘中找到一个数据并且load到缓存中，返回给主机查询结果。用户在查询到并且缴款以后短期内通常也不会再去查询当月话费，因此对于这种应用，不管你存储器的是32GB、16GB还是8GB，从控制器的缓存命中率角度来讲通通表现为缓存不命中)。因此想提升缓存命中率在存储器这端是别指望了，除非在应用端或者主机端做优化;
3. 磁盘性能方面：前文我们已经分析过，单个磁盘性能基本上是固定的，除非是再掏银子买更多的磁盘，否则没戏。由于更多的磁盘确实能够带来更多的IOPS。因此通过买新的磁盘，或者重新分配已经购买了的磁盘到热点数据组中确实是常用的存储器性能调优方法。所谓人多力量大嘛。
现在我们找到了关键点，即消除磁盘热点。磁盘热点本质上是什么呢：我们通过下图举例说明：传统的磁盘阵列是通过RAID技术来保护数据的，比如下图中，把每6块磁盘做成一个RAID 5的RAID磁盘组(RAID GROUP)，如果一个存储器购买初期配置了18块磁盘，并18块磁盘组合成为3个RAID磁盘组(从上往下以此为是RAID Group 0、RAID Group 1和Raid Group 2)，系统管理员在每个RAID组上再进一步划分lun映射给主机，每个lun从主机的角度看就是一个个磁盘。用户把磁盘阵列配置好后，把数据库装在该存储阵列上。比如数据库有三个表空间分别映射到三个磁盘组上。
假设说三个表空间的数据访问频率都是一样的，那么这种传统的磁盘组保护方式就能够很好地工作。但实际情况下往往很难做到三个表空间的访问频率做到平均，如果出现一个表空间访问频率超级高(想象一下正好那个表空间中存储了XX车模的XX劲爆新闻数据)，导致支撑该表空间的磁盘组(RAID group)里面的6块磁盘即使满负荷运行(每块盘都提供了最高的IOPS)也无法满足前端应用的需求，而支撑其他表空间的RAID group里面的磁盘想帮忙也只能干瞪眼......
上图比较生动地表现了我们所说热点问题，说白了就是由于传统的存储器采用的是把RAID group磁盘组建立在预先固定分配好的几块磁盘上，而应用访问数据空间是随机的，这样有可能会导致磁盘资源整体分配不均衡(注意：不是说该存储器的整体磁盘资源不够，而是针对热点lun的底层磁盘资源分配不均衡)。在这种情况下，最好的方法就是做磁盘分配的再调优，也就是说希望能够通过添加更多的磁盘消除该热点数据。说来容易，做起来难，这不仅仅是简单添加磁盘就能做到的，一般通过下面几种思路来实现：
1. 第一种方法是从存储底层做文章，对于文件系统层面、数据库层面是透明的。这个思路的最大好处是应用层、操作系统层的配置文件不用做任何改动，然而最大的挑战确是往热点表空间上的RAID group中添加更多磁盘并且重新去条带化的过程耗时耗力，一般经历这么一折腾，磁盘上的数据都会消失，因此事先必须把数据先备份出来，等底层重构好后再把数据恢复回来，显然这种思路的停机时间较长;
2. 第二种思路是从文件系统做文章，通过LV 层面的条带化实现。传统的商用UNIX环境中，如果是HPUX或者AIX都配备有内置的LVM，Solaris则需要配置Storage Foundation可以做到LV层的在线扩展，通过LV的一些精细地操作，可以间接实现此类功能。如果按照这种思路调优，也强烈建议事先先做数据备份，同样停机时间较长;
3. 第三种是从数据库层面做文章，前提是数据库本身支持表空间的在线扩展。通过表空间在线添加更多的数据文件(LV)，这样新写入的数据将写到新的lun里面。这些操作工作对于DBA有较高的要求，而且还面临一个问题是已有的热点文件还是很难再平衡Re-balance;
4. 最新的一种方法是某些数据库自己内置的卷管理功能，能够实现再打散。不过这需要安装数据库的最新版本，而且这个功能本身还很新，在关键应用环境中很少使用。
通过对于上述四种方法的分析和综合比较，我们可以发现每种方法都有自己的缺点，往往对IT系统管理人员要求很高，甚至还需要安装一些付费的商用软件或者特定的数据库，否则磁盘层面热点问题很难彻底解决。比如很多windows或简化版的linux环境是没有LVM级别的卷管理软件的;或者说DBA和系统管理尽管理论上知道怎么再平衡数据，但是实际环境总是因为害怕出错或者停机时间较长，不敢真正下决心解决这个问题;当然更可怕的事情是，也许花了大力气按照现在的业务系统特点做了数据热点迁移，可是天算不如人算，迁移成功后发现原来的热点数据变得不“热”了，而非热点数据又变“热”了，又要重新安排存储底层的再优化，这简直就是恶梦......
