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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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