SAP HANA在全閃存架構Virtual SAN上的性能測試（上）

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

　　注釋?zhuān)罕敬涡阅軠y試分為上下兩個(gè)部分，本文為上半部分，主要描述SAP HANA在不同工作負載，不同存儲策略配置下的性能影響。下半部分主要描述SAP HANA在各種故障場(chǎng)景下的彈性性能。

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

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

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

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

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

　　SAP HANA HWCCT （Hardware Configuration Check Tool） 文件系統測試參數如下：

　　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的支持，并且評估啟用新特性后對性能結果的影響，我們對Virtual SAN在以下5種不同類(lèi)型的存儲策略下的性能進(jìn)行了測試。需要注意的是，在全閃存架構中，數據直接從容量層的SSD讀取，因此不需要閃存讀取緩存預留，系統默認均為0%。

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

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

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

　　圖二 不同測試場(chǎng)景下的數據盤(pán)1MB隨機I/O寫(xiě)入吞吐量

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

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

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

　　圖三 不同測試場(chǎng)景下的數據盤(pán)1MB隨機I/O讀取吞吐量

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

　　圖四 不同測試場(chǎng)景下的日志盤(pán)4KB順序I/O寫(xiě)入延遲

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

　　圖五 不同測試場(chǎng)景下的日志盤(pán)4KB順序I/O寫(xiě)入吞吐量

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

　　圖六 通過(guò)Virtual SAN性能服務(wù)監控后臺性能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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