現在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移動客戶端，您可以訂閱西瓜哥專欄，第一時間獲得知名專家和業界領袖的深度剖析與趨勢分析。