截取的這個表格，只包含OS和虛擬化技術的認證，應該還不包括S2D存儲功能。

與前面三篇評測相同，我們是在Windows Server 2016 DataCenter系統上搭建的微軟S2D（Storage Spaces Direct）存儲和Hyper-V集群。至本文截稿之日，WS 2016虛擬機+Oracle 12c R2（12.2）已經出現在甲骨文的支持列表中，早些時候還只有WS 2012的信息。因此我們也先后嘗試過在2種虛擬機OS版本上安裝RAC，總體上都還比較順利。

準備工作：Oracle 12c R2 RAC搭建

雖然上圖中寫了VHD Set不支持Windows 10之前的（虛擬機）操作系統，但我們測試中分配給Windows Server 2012 R2的ASM磁盤是正常使用的。

需要注意的是，在S2D的CSV（集群共享卷）上創建Oracle ASM使用的磁盤鏡像時，應該選擇VHD Set而不是VHDX，因為這些磁盤需要同時掛載多個虛擬機到共享訪問。

為不同節點上2個RAC虛擬機分配的Oracle ASM數據磁盤，分別來自Owner在多個節點上的CSV。在網絡不是瓶頸的情況下（測試環境為100Gb RDMA以太網），這樣做有利于性能。

上面是單個數據庫虛擬機的配置信息。由于我們使用的Dell PowerEdge R630服務器上是2顆10核（20線程）CPU和128GB內存，這次就為虛擬機分配了40個虛擬處理器和64GB內存。關于磁盤（SSD）的配置情況我還會陸續交待。

注：物理Server后面的數字代表管理網口IP

為了幫助大家更好地理解，我們畫了上面的示意圖，其中簡略了微軟S2D的一些層次結構。

（1）每個CSV上的VHD Set磁盤文件，其數據塊打散分布在4臺服務器上的28個SSD。

（2）虛擬機訪問數據時會經過CSV當前的Onwer節點，如果它們正好在同一節點，會享受到超融合的本地讀優化。在最常用的2節點RAC方案中，為了使S2D的CSV存儲開銷平均分布到4個節點，我們配置了“完全互連”的磁盤組，也就是2個VM對應3-4個CSV。

（3）在Oracle RAC安裝、SwingBench與可用性（破壞）測試部分，我們使用了來自3個節點CSV的ASM磁盤；后面的Orion測試則用上了全部4個節點Onwer的CSV。

如上圖，由于S2D本身已經是3副本保護，所以在創建ASM磁盤組時選擇“外部冗余”就可以了。

SwingBench壓力工具的I/O和CPU負載

由于本文主要目的在于可用性驗證，裝好Oracle RAC集群后我們幾乎沒有做任何調優，在SwingBench中選擇了一個簡單的事物開始壓測。雙節點的TPS（每秒交易數）有時能達到16000，TPM（每分鐘交易數）超過93萬。

記得我們之前在《Optane P4800X評測(2)：Oracle 170萬TPM意味著什么？?》一文中調優后測出有實用意義的TPS為單機13000，不過那套Dell PowerEdge R830服務器是4路10核Xeon E5-4610 v4 1.8GHz CPU。另外跑的事物類型也不相同，沒必要直接對比。

除了TPS/TPM我們還要關注S2D集群上的存儲負載。在上述測試中兩個Oracle虛擬機的IOPS請求加在一起也沒有超過2萬，此時的壓測顯然是CPU成為了瓶頸。

2臺R630服務器上的CPU都跑滿了，并且Xeon E5-2640 v4還Turboboost到2.57GHz的頻率。根據我們以前對S2D的了解，每節點的CPU至少能支撐40萬以上4KB讀IOPS，所以當前的壓力絕大部分來自于RAC數據庫。

倒不是說Oracle就不能把壓力加到存儲上。我們換了一個壓力模型，2個節點總IOPS達到了23萬（如下圖）。不過此時TPS看上去并不養眼，應該是因為復雜長事物中的I/O操作較多吧。

Oracle OLTP應用的典型I/O大小就是8KB。對于超融合用戶來說，可以評估下這個IOPS是否能滿足自己應用的需求。

計劃內維護–虛擬機遷移測試

在Oracle RAC集群正常運行的情況下，我們首先對其中一個虛擬機手動“Live Migration”到另一個節點。

Windows超融合集群上的Oracle RAC虛擬機節點，在18-19秒完成遷移。如果不是CPU滿載，或者分配的內存容量較小還會更快。

我們看到TPS最低點在8000左右，此時恰好是1個Oracle數據庫節點的性能。

如上圖，在虛擬機遷移的瞬間TPS有個下降后很快恢復；而TPM數值統計的是過去一分鐘，因而沒有明顯的波動。

破壞性測試1：CSV存儲節點Reset

模擬破壞性測試，我們是通過Dell服務器iDRAC帶外遠程管理界面來操作的。

接下來就要做Windows+S2D集群的節點冷重啟（Power Cycle）測試了。這里面還要分為兩種情況：

（1）被重啟/關機的服務器上沒有Oracle RAC虛擬機，只提供S2D的存儲資源，也就是其中一個CSV的Onwer。

（2）模擬故障的服務器上同時還運行RAC虛擬機。

先來看第一種情況。

由于分布式存儲的冗余配置，無論多副本還是糾刪碼保護都應該能通過這個測試。

如上圖，當組成ASM磁盤組的一個VHD Set對應CSV Onwer節點離線時，Oracle IO會hang住10多秒然后恢復，就像傳統存儲陣列的多路徑故障切換Timeout那樣，數據庫連接會話不中斷。S2D集群應該也有一個默認的超時設置，因為如果我們手動切換/切回（Fail over/Fail back）CSV Onwer基本上是即刻完成的。

原來Onwer在46節點的Cluster Virtual Disk，在故障后自動切換到了48節點。

等46節點重啟恢復之后，我們想把CSV Onwer切回來也只是點兩下鼠標的事，在這個實驗中只涉及到少量數據的Rebuild，還沒有觸發Rebalance重平衡。

破壞性測試2：RAC+存儲節點Reset

這部分的操作，會觸發一個12c RAC虛擬機節點在Hyper-V故障轉移集群中的另一臺服務器上自動啟動（HA接管）。我們記錄了一下時間，Window Server 2012 R2虛擬機OS啟動只用時31秒，至故障發生后3分23秒Oracle ASM實例啟動完成，5分25秒整個數據庫恢復正常。

就此我咨詢了一下數據庫專家朋友，Oracle啟動時間受版本影響比較大，我們測試的是12c（12.2），如果換成10g或者11g應該會快很多。

Orion單虛機10GB/s+帶寬：別忘了100GbE RDMA

下面使用Oracle Orion I/O壓力工具來測試下OLAP（數據倉庫/分析型負載）存儲性能。

由于帶寬測試使用1MB大數據塊，從S2D存儲底層到虛擬機上層都不會有多大CPU的開銷，這一點與IOPS測試不同。

最后我們又簡單測試了一下帶寬，發現只要1個虛擬機就能基本達到11GB/s順序讀的峰值。每個VHD Set磁盤建立在不同節點Onwer的CSV上，相當于用Orion模擬了ASM條帶化的效果。

具體來說，就是11,007 MB/s中有大約3/4來自跨節點訪問，而本次測試環境的網絡比較牛（見下圖），這些都不是問題。

在實際生產環境，推薦使用性價比較高的25Gb網絡，同時網卡支持RDMA，雙端口NIC Teaming能提供50Gb帶寬，可滿足高負載業務需求。

由于是2個100G網口Active-Active連接，虛擬機中的網卡速度顯示為200.0 Gbps。

在順序寫測試中，我們同樣遇到了SSD性能隨時間下滑的正常情況。也就是說S2D集群配置的盤“還不夠快”，否則在第一篇測試中也不會順序寫只達到2626MB/s。如果只是看峰值寫入帶寬，超過3700MB/s的情況我也見到過。

至此，本次微軟S2D系列測試告一段落，感謝朋友們的大力支持！

特別鳴謝

上海維賽特網絡系統有限公司副總工程師 高翔（Sean）

上海戴爾客戶解決方案中心Tony Wang

本文作者：高翔(Sean)、唐僧