存储在线专栏文章：很多网友建议我分享一下案例，但案例如果不是本人亲自参与，很难落笔。但各个厂商发表了不少最佳实践的白皮书，我想，这段时间和大家分享一下各个厂商的最佳实践比较靠谱，因为这里没有客户层面的内容，只是一些技术的研讨。
今天和大家分享一下EMC、HDS和IBM与ORACLE的最佳实践。
最佳实践之一：VMAX+ORACLE
先来看看VMAX和ORACLE的最佳实践。具体产品就是VMAX 10K和ORACLE 11g。我们来看看EMC的建议。
首先，我们来看一下EMC VMAX 10K的规格，10K是高端入门产品，支持4引擎8控（有网友问10KK是啥意思，其实就是10000啦，老外喜欢把1000叫做K）：
现在VMAX也支持用Unisphere来进行配置，因此EMC建议采用GUI的界面，不需要用命令行去做了：
在配置的时候，EMC建议采用Auto Provisioning Group来进行主机、端口以及存储资源的映射，这种方式比传统的方式大大减轻配置的工作量：
虽然是数据库应用，但EMC还是建议采用精简配置（VP)来做。就算你不用thin这个功能，但由于设备是thin device，VMAX可以充分使用thin pool里面使用的硬盘，实现宽条带化，也就是性能提升:
thin pool里面的设备叫data device，数据就是存放在上面：
当然，用thin device，你就可以使用FAST VP特性，优化数据库的性能：
比如设计一个存储池的策略，给每种介质分配一定比例的空间，系统就可以根据数据的热度在里面进行自动迁移了，用户基本不用管理，是比较方便的一种做法。
EMC的FAST策略里面的百分数的和可以超过100%，这样相当于把决定权交给系统，如果需要，系统可以把所有的数据迁移到某一层。资源比较富裕的时候，这就是一个懒人做法。
当然，要做迁移，需要分析性能数据，这块的工作其实是在管理控制台上做的，还有迁移的算法也是在管理控制台上，但迁移的动作是Enginuity来完成：
当然，如果要做CDP保护，EMC经常推它的recoverpoint产品，因为VMAX内置了recoverpoint的分离器。每一个I/O下来，VMAX都可以复制一份给recoverpoint系统使用。在招标的时候，如果你看到要求存储集成I/O分离器，基本都是EMC引导的标书，O(∩_∩)O哈！
EMC的thin deveice其实也支持全部空间预分配，如果用户担心数据库快速增长的时候需要分配新空间带来的性能问题，可以提前把空间分配给thin device。也就是我们不用传统的thin provisiong的功能，只是用thin device支持的FAST、宽条带化等特性，提高ORACLE的性能。
由于ORACLE的卷管理软件是ASM，ASM也有条带化功能，因此，数据的热点也是分散开来，但是还是有一些热点的，这个时候再配合FAST VP，把这些热点迁移到flash上，性能就可以得到优化。这个是ORACLE提供的heat map示意图，我们前面讲过ORACLE的ZFS存储可以利用这个heat map做自动迁移，EMC应该无法自动利用这个heat map，还必须用它自己的性能分析工具去分析：
小结一下，EMC VMAX建议采用Unisphere GUI来进行管理，建议尽量采用VP功能，尽快你可能不需要瘦分配特性。从这里我们可以看出，其实EMC+ORACLE没有太多的耦合，虽然EMC提供了一个管理插件可以嵌入到ORACLE管理软件里面，但由于ORACLE不开放接口，因此EMC也无法做深度的结合了。
其实EMC还有一个武器——VFCache（服务器闪存加速），VMAX+VFCache+ORACLE才是EMC主推的方案，因为这个方案其他高端都没有，因此，西瓜哥就不展开了，想学习的可以找EMC的白皮书看看。
最佳实践之二：VSP+ORACLE
接下来来看看HDS的情况，大体上和EMC差不多。
硬件主角是HDS VSP，软件是Oracle Database 11gR2，当然，卷管理还是ASM（Automatic Storage Management）。
HDS的thin管理软件叫Hitachi Dynamic Provisioning（HDP)，HDS建议在ORACLE用这个功能，主要的作用除了thin外，也是使用宽条带化来提高性能。使用DP的卷叫DP-VOL，可以按需扩展。
当然，HDS建议ORACLE删除比较多的数据的时候，采用ASM的一个ASRU工具把空余的空间写零，然后用HDP里面的Reclaim Zero Pages功能回收这些空间。在性能方面，由于一个卷可以跨多个磁盘，HDS建议用户先根据性能来规划到底需要多少磁盘，然后再考虑容量。
Hitachi Dynamic Tiering（HDT)是HDS的自动分层功能软件。HDS也建议用HDT来提高ORACLE的数据库性能。但HDS只建议ORACLE的DATA文件采用分层存储，而对于REDO和ARCH，由于都是顺序写，加入SSD也不会提升多少性能，因此不建议用分层存储。
HDS VSP测试表明，增加SSD磁盘，读性能提升明显。在读I/O占比为88%情况下，性能是原来的2.05倍，在读I/O为62%占比的情况下，性能是原来的1.8倍。
而且反应时间也有很大改善，88%读情况下只是原来的70%，而62%读的情况下，只有原来的57%（有点奇怪，性能提升多的，时延的改善不如性能提升少的？估计性能提升太多，负载重了吧）。
由于采用自动分层技术，读I/O越多，迁移到SSD的数据就越多。下图可以看到86%读的情况下SSD的使用容量比62%读的情况下几乎多了一倍。
HDS当然也建议采用SATA来存放不经常访问的数据。增加SATA后，HDT会自动进行数据的迁移：
而数据重分布后，性能没有任何影响。HDS实验室测得不常访问的数据迁移到SATA后，性能和原来一样（但实验室数据性能居然有1%提升，估计是和当时的I/O情况有关吧）：
也就是HDS认为同时采用SSD/SAS/SATA，能够降低TCO而又不影响业务。
在RAID的选择上，HDS建议SSD和SAS用RAID 5，而SATA用RAID 6：
当然，如果是很多小的随机I/O，HDS还是建议RAID 1+0，但虽然是随机I/O，但I/O比较大，如32K以上，HDS认为用RAID 5就可以了，性能差不多。
大家知道ORACLE ASM需要创建很多个disk group，那么和存储的DP-VOL是如何对应的呢？下图是一个例子：
如果加上ORACLE数据对象，整个数据布局如下：
这个图总结得不错，把和存储相关的对象都罗列出来了，他们的关系也都看得一清二楚，值得收藏。
ASM虽然也有数据保护功能，但所有的存储厂商都会建议用存储的保护功能，否则存储的价值就不大了，O(∩_∩)O哈！当然，外部做保护减轻服务器的压力。
还有，ASM也有空间再平衡功能，HDS建议用HDP的空间再平衡功能代替，这样效率更高。
最后，总结一下HDS在ORACLE ASM环境下的配置建议：
最佳实践之三：DS8000+ORACLE
前面我分享了EMC、HDS和ORACLE的最佳实践，接下来看看IBM的DS8000。这三家是高端存储里面的三雄，高端市场基本是这三个产品瓜分的。
但西瓜哥发现，IBM对ORACLE好像不是太上心，毕竟老大哥有自己的数据库DB2，当然要优先考虑自己家的东东啦。因此，我看到IBM发布的最佳实践也是很早以前的，很多都是2010年前写的，基本没有更新过。
再看一下最佳实践的内容，也没有太多原则的东西，更多的是配置步骤，我想这个具体的步骤就不和大家分享了吧。
因此，我们就分享IBM总结的DS8000针对ORACLE 10g的一个通用原则吧：
解读一下，就是
一个ASM disk group中用多个一样的LUN；
这些LUN容量和特性最好一致；
当扩容的时候，最好也用一样属性的LUN；
用ASM的外部冗余选项
把data和log文件放在同一个disk group里；
这些原则其实很多在新的版本里面应该都会发生变化。比如一个disk group其实不需要太多的LUN来做条带化了，因为现在DS8000有Easy tiering，存储做宽条带就可以了，主机不需要做。还有就是一般建议把data和log分开到不同的disk group更好一些，因为这样备份和恢复更方便一些。
因此，感觉参考IBM DS8000老的最佳实践基本没有太多价值。希望能够看到IBM推出新版本的东东。
希望大家积极反馈你的意见和建议，微信扫描如下二维码，关注微信公众号“高端存储知识”，与作者微信互动。通过掌上DOIT移动客户端，您可以订阅西瓜哥专栏，第一时间获得知名专家和业界领袖的深度剖析与趋势分析。
