肯定有很多讀者期待SAP HANA在Virtual SAN上的性能表現(xiàn)，為此我們進行了專門的測試。需要注意的是，目前SAP尚未授權(quán)將HANA運行在任何超融合架構(gòu)之中（包括Virtual SAN）。VMware目前正在努力溝通，希望SAP HANA可以增加對Virtual SAN的支持。通過閱讀本文，讀者可以對SAP HANA在全閃存架構(gòu)Virtual SAN上的性能有大體了解。

　　注釋：本次性能測試分為上下兩個部分，本文為上半部分，主要描述SAP HANA在不同工作負載，不同存儲策略配置下的性能影響。下半部分主要描述SAP HANA在各種故障場景下的彈性性能。

　　通過實際性能測試，結(jié)果表明在啟用Virtual SAN 6.2新特性的前提下，Virtual SAN可以勝任SAP HANA的工作負載。Virtual SAN在作為產(chǎn)品數(shù)據(jù)庫的同時還可以向SAP HANA提供快速的備份和恢復(fù)平臺。

　　Virtual SAN引以為傲的基于存儲策略的管理（Storage Policy Based Management，SPBM）可以在Virtual SAN數(shù)據(jù)存儲上對VMDK進行存儲策略管理。這意味著運行在其上的SAP HANA數(shù)據(jù)庫虛擬機可以針對不同的應(yīng)用需求使用不同的存儲策略。

　　圖一 Virtual SAN的SPBM可以針對應(yīng)用需求在空間使用率、性能及可用性上找到平衡點

　　測試中我們采用4臺雙路ESXi主機，每臺主機配有兩顆Intel Xeon CPU E5-2670 @ 2.3GHz v3處理器，256GB內(nèi)存，2塊400GB的Intel SSD作為緩存層以及8塊400GB的Intel SSD作為容量層（即每臺主機擁有兩個磁盤組），網(wǎng)絡(luò)配置基于萬兆網(wǎng)絡(luò)。

　　SAP HANA數(shù)據(jù)庫虛擬機的操作系統(tǒng)為SUSE Linux Enterprise 11 sp3 64位，數(shù)據(jù)庫服務(wù)器版本為1.00.112.02，虛擬機硬件配置如下：

　　SAP HANA HWCCT （Hardware Configuration Check Tool） 文件系統(tǒng)測試參數(shù)如下：

　　async_write_submit_active = on

　　async_write_submit_blocks = all

　　param async_read_submit = on

　　max_parallel_io_requests = 256

　　VMware在Virtual SAN 6.2中引入了校驗和，去重/壓縮以及糾刪碼（RAID 5/6）等新特性。為了全面驗證這些新特性對SAP HANA的支持，并且評估啟用新特性后對性能結(jié)果的影響，我們對Virtual SAN在以下5種不同類型的存儲策略下的性能進行了測試。需要注意的是，在全閃存架構(gòu)中，數(shù)據(jù)直接從容量層的SSD讀取，因此不需要閃存讀取緩存預(yù)留，系統(tǒng)默認(rèn)均為0%。

　　如表中所示，為了盡可能讓集群中的所有磁盤協(xié)同處理讀寫工作負載以提升性能，我們將存儲策略的條帶寬度設(shè)置為8。測試1a為典型的VMDK精簡部署配置，測試1b中的VMDK使用厚置備延遲置零。而測試1c~1e分別啟用了Virtual SAN 6.2中的新功能。

　　在以上所有測試案例中，我們使用SAP HANA HWCCT進行文件系統(tǒng)測試，并以數(shù)據(jù)盤的1MB隨機I/O和日志盤的4K順序I/O作為關(guān)鍵性能指標(biāo)。此外，為了展現(xiàn)Virtual SAN不同存儲策略配置的性能差異，我們將測試1a的結(jié)果作為性能基準(zhǔn)，并以對比基準(zhǔn)的百分比輔助進行對比。

　　從圖二對比可知，不啟用任何新特性的厚置備配置獲得了最佳的寫入吞吐性能。這是由于厚置備磁盤在部署時就已預(yù)留存儲空間，這可以避免對象在工作過程中的負載不均衡，使工作負載均勻分布在所有磁盤組上。

　　圖二 不同測試場景下的數(shù)據(jù)盤1MB隨機I/O寫入吞吐量

　　此外，測試1a與1d的寫入吞吐量幾乎相同，這是由于兩者除了啟用去重/壓縮特性這一差別外，其他存儲策略完全相同。HWCCT文件系統(tǒng)測試的數(shù)據(jù)尺寸非常小，因此所有的工作負載都保留在緩存層。而去重/壓縮操作只有在數(shù)據(jù)從緩存層下落到存儲層時才會執(zhí)行。因此，在HWCCT文件系統(tǒng)測試中，啟用去重/壓縮特性對測試結(jié)果幾乎沒有影響。

　　雖然相比測試1a的基準(zhǔn)性能，啟用校驗和（1c）和糾刪碼（1e）的寫入吞吐量結(jié)果較差，但也能夠滿足關(guān)鍵性能指標(biāo)。造成性能變差是由于啟用校驗和與糾刪碼導(dǎo)致的寫入增加。

　　如圖三所示，從讀取性能的角度來說，在所有測試場景中，測試1b擁有最好的讀取性能。而其他測試場景的讀取性能相差不大，這是因為這些測試場景都是基于精簡置備的。另一方面，由校驗和與糾刪碼導(dǎo)致的I/O增加并不會影響讀取工作負載，因此測試1c與測試1e的讀取性能幾乎相同，甚至比基準(zhǔn)測試性能稍好。

　　圖三 不同測試場景下的數(shù)據(jù)盤1MB隨機I/O讀取吞吐量

　　從覆蓋寫入延遲的角度來說，數(shù)值越低越好，所有的Virtual SAN配置策略都可以在400微秒內(nèi)執(zhí)行4KB順序I/O。事實上，這些場景中的測試差異幾乎可以忽略不計，因為差異實在太小，差值最大也就60微秒。

　　圖四 不同測試場景下的日志盤4KB順序I/O寫入延遲

　　從覆蓋寫入吞吐量的角度來說，由于我們僅在數(shù)據(jù)盤上應(yīng)用糾刪碼功能，而日志盤均使用測試1a的默認(rèn)精簡置備策略（在本測試中，我們沒有對場景1e進行測試）。覆蓋寫入吞吐量在測試1a，1b以及1d之間的差別又一次十分之小，不超過7%。由于I/O寫入增加對小尺寸塊的I/O影響十分小，因此在場景1c的測試中，啟用校驗和功能后只比基準(zhǔn)性能低了10%。

　　圖五 不同測試場景下的日志盤4KB順序I/O寫入吞吐量

　　我們使用Virtual SAN性能服務(wù)監(jiān)控后臺性能，通過性能服務(wù)可以具體查看一段時間內(nèi)的具體數(shù)值。在測試期間，我們在Virtual SAN后臺捕獲到如下延遲數(shù)據(jù)，可以看到4KB順序I/O測試中寫入延遲持續(xù)保持在600微秒之下。

　　圖六 通過Virtual SAN性能服務(wù)監(jiān)控后臺性能

　　經(jīng)過實際測試，我們可以得出以下結(jié)論：Virtual SAN在啟用版本6.2新特性的情況下可以支持SAP HANA的實際工作負載。但是，如果用戶想在集群中啟用Virtual SAN的新特性并且橫向擴展SAP HANA數(shù)據(jù)庫（例如，部署三臺不同的SAP HANA數(shù)據(jù)庫在三臺不同的主機上），請確保虛擬機首先可以滿足HWCCT文件系統(tǒng)關(guān)鍵性能指標(biāo)。

　　企業(yè)級數(shù)據(jù)庫備份與恢復(fù)的重要性不言而喻。常規(guī)的備份會影響數(shù)據(jù)庫性能，因此通過優(yōu)化配置降低備份對性能的影響至關(guān)重要。雖然數(shù)據(jù)庫備份恢復(fù)事件發(fā)生的頻率并不高。但是一旦出現(xiàn)類似事件，恢復(fù)時間至關(guān)重要。有多種因素可以決定合適的RTO。由于測試范圍的原因，我們主要關(guān)注不同的配置下的性能差異。在對比不同配置差異時，我們主要關(guān)注以下幾個場景：

　　在測試中，我們啟用了Virtual SAN中的去重/壓縮功能。為了對比測試，我們添加了一臺NFS數(shù)據(jù)存儲，將其掛載在每臺ESXi主機上作為外部存儲。

　　為了進行數(shù)據(jù)庫備份恢復(fù)性能測試，我們在SAP HANA虛擬機中額外添加了690GB精簡置備的VMDK作為備份存儲，如前文所述，該VMDK掛載在新添加的PVSCSI控制器上。

　　本測試場景評估了在執(zhí)行備份時，不同存儲配置對數(shù)據(jù)庫的性能影響。所有的測試場景都達到了HWCCT的關(guān)鍵性能指標(biāo)。在測試過程中，我們首先使用腳本創(chuàng)建了48個10列的表格，在每張表中插入了800萬行的數(shù)據(jù)。之后，我們使用hdbsql進行全數(shù)據(jù)備份，備份路徑為掛載的備份VMDK。這條命令同時被分發(fā)到每臺SAP HANA數(shù)據(jù)庫虛擬機上，一旦數(shù)據(jù)執(zhí)行就觸發(fā)。

　　在數(shù)據(jù)備份和數(shù)據(jù)執(zhí)行完成后，我們刪除了通過腳本生成的源數(shù)據(jù)表，以此來測試備份數(shù)據(jù)恢復(fù)。所有的數(shù)據(jù)執(zhí)行、備份和恢復(fù)任務(wù)在所有的SAP HANA虛擬機上同時執(zhí)行。

　　我們首先對比單臺虛擬機的場景2a與2b。由于糾刪碼導(dǎo)致的I/O寫入增加，備份數(shù)據(jù)到RAID 1的VMDK比備份到RAID 5的VMDK擁有更好的數(shù)據(jù)執(zhí)行性能和更少的性能沖擊。

　　圖七 單臺SAP HANA數(shù)據(jù)庫虛擬機在執(zhí)行備份與恢復(fù)時的性能

　　與此同時，由于數(shù)據(jù)備份是重寫入工作負載，備份到RAID 1的VMDK的速度是備份到RAID 5的VMDK的2.5倍。在測試2a中的備份速度大約為322MB/s，而我們從Virtual SAN后臺看到實際吞吐量達到了720MB/s。

　　圖八 通過Virtual SAN性能服務(wù)查看后臺實際吞吐量

　　由于數(shù)據(jù)恢復(fù)是重讀取工作負載，糾刪碼對其性能影響微乎其微，因此測試2a與2b在數(shù)據(jù)恢復(fù)速度上幾乎相同。兩次測試都可以在不到5分鐘的時間內(nèi)完成。

　　接下來，讓我們對比將VMDK安置在Virtual SAN與外置NFS數(shù)據(jù)存儲上的區(qū)別。測試對比結(jié)果為四臺虛擬機的平均值。通過查看測試2c與2d的平均數(shù)據(jù)執(zhí)行時間，我們可以看到將VMDK放置在外部存儲上對數(shù)據(jù)庫的性能影響更小。這是因為備份到Virtual SAN數(shù)據(jù)存儲相比備份到外置存儲上（只需要處理數(shù)據(jù)庫工作負載）增加了對Virtual SAN的寫入工作負載。但是，由于備份和恢復(fù)速度十分依賴外置存儲的性能，因此在場景2c（備份在RAID 1配置的Virtual SAN中）中的平均備份速度是場景2d（備份在NFS中）中的3倍。而場景2c的平均恢復(fù)時間只有場景2d的四分之一。

　　圖九 四臺SAP HANA數(shù)據(jù)庫虛擬機同時執(zhí)行備份與恢復(fù)時的性能

　　簡而言之，相比使用外置存儲，使用Virtual SAN可以消耗更少的備份與恢復(fù)時間。如果著重于在備份和恢復(fù)期間的數(shù)據(jù)庫性能，也許考慮使用外部存儲會是更好的選擇。但是，如果沒有合適的外部存儲用作備份和恢復(fù)，可以選擇將備份磁盤安置于Virtual SAN中，這樣可以極大地縮短備份和恢復(fù)的時間，這在設(shè)計數(shù)據(jù)庫備份和恢復(fù)架構(gòu)方案中是個很好的選擇。

　　實際測試結(jié)果表明，即使在啟用Virtual SAN 6.2新特性的前提下，Virtual SAN依舊可以勝任SAP HANA的工作負載。Virtual SAN在作為產(chǎn)品數(shù)據(jù)庫的同時還可以向SAP HANA提供快速的備份和恢復(fù)平臺。此外，關(guān)于SAP HANA在Virtual SAN上面對各種場景故障的彈性性能表現(xiàn)，我們將于下半部分詳細描述，敬請期待！

　　本文作者為VMware存儲與可用性事業(yè)部Virtual SAN解決方案團隊（Product Enablement，PE）的魏塵/丁楠。Virtual SAN解決方案團隊主要負責(zé)Virtual SAN與各種行業(yè)關(guān)鍵應(yīng)用平臺的融合。通過設(shè)計、構(gòu)建、驗證關(guān)鍵應(yīng)用在Virtual SAN超融合架構(gòu)下各種場景的性能表現(xiàn)，針對產(chǎn)品特性進行性能調(diào)優(yōu)，并以參考架構(gòu)——白皮書的方式向客戶提供使用Virtual SAN的最佳實踐。