分散式儲存 IO 路徑如何影響效能？以 VMware 和 SmartX 為例

不同的超融合軟體，其讀寫機制有一定的差異性，I/O 路徑也不盡相同，這使得他們在 I/O 讀寫效率以及資源佔用上都有不同的表現。有興趣著手構建超融合基礎架構的使用者，可能會希望瞭解更多關於 I/O 路徑的細節，從而在實施之前，進行更充足的準備和更合理的規劃（例如針對不同 I/O 路徑選擇更合適的網路頻寬）。

為了幫助讀者更好地理解超融合架構 I/O 路徑對叢集效能的影響，本文將對比 VMware 和 SmartX 超融合 I/O 路徑，分析不同場景下 I/O 讀寫的方式、發生機率及其對儲存效能和叢集的相關影響。

重點摘要

·

基於 SDS 的超融合架構中，I/O 既可能發生在主機內部的本地磁碟上，也有可能發生在外部的網路主機上。相同軟硬體配置下，本地 I/O 操作時延更短。

·

在寫入場景下，vSAN 至少有 1 個副本需要經過網路寫入。在讀取場景下，讀 I/O 路徑在正常狀態下不會出現 100% 本地讀取情況；在故障狀態下僅有 25% 機率出現 100% 本地讀取，其餘情況均為 100% 遠端讀取，且易因故障恢復導致效能瓶頸。

·

在寫入場景下，ZBS* 在正常狀態下不會發生 100% 遠端寫入的情況，並針對虛擬機器遷移後的 I/O 路徑進行了最佳化，最大限度避免 100% 遠端寫入的情況。在讀取場景下，正常狀態時可確保 100% 本地讀；資料恢復時優先進行本地恢復，並透過彈性副本恢復策略平衡恢復速度與業務 I/O。

· 在正常和資料恢復狀態下，ZBS 的本地 I/O 訪問機率比 vSAN 更高，理論上時延會更低；而在需要頻繁遷移的場景下，vSAN 本地 I/O 訪問機率更高。

·

即使超融合的整體 I/O 效能有富餘，更多的遠端 I/O 也可能引起網路資源爭搶等問題。

*ZBS 是 SmartX 超融合軟體 SMTX OS 中與 vSAN 對應的分散式塊儲存元件。

一、傳統虛擬化架構與超融合架構的 I/O 路徑對比

業務系統經過運算後生成了資料，並透過系統的

·

將資料傳輸到儲存介質上（一般是磁碟）進行持久化儲存。通常情況下，I/O 的持久化儲存過程會經歷不同的硬體裝置和軟體邏輯，而經過每一個硬體/軟體都會佔用一定的系統資源並增加處理時間（產生時延），因此 I/O 路徑的設計優劣跟業務系統的整體執行效率是息息相關的。

I/O 路徑

在傳統三層式基礎架構中，I/O 從虛擬機器端發起，需要經過 hypervisor（虛擬化軟體），然後透過主機的 FC HBA 卡，傳送至 SAN 交換機，然後到 SAN 儲存控制器，並最終將資料儲存到物理磁碟當中。

圖 1

I/O 路徑中涉及的硬體裝置和軟體邏輯包括：

1.傳統虛擬化架構下的 I/O 路徑

：伺服器主機 / SAN 儲存網路交換機 / SAN 儲存裝置……

硬體裝置

：虛擬機器作業系統 / 虛擬磁碟 / 虛擬化軟體 ……

軟體邏輯

超融合架構將計算、網路和儲存進行了融合，I/O 從虛擬機發起，同樣需要經過 hypervisor，然後傳送到軟體定義儲存（SDS），最終在本地或透過乙太網絡將資料儲存到物理磁碟當中。

圖 2

I/O 路徑中涉及的硬體裝置和軟體邏輯包括：

2.超融合架構下的 I/O 路徑

：伺服器主機 / 乙太網交換機……

硬體裝置

：虛擬機器作業系統 / 虛擬磁碟 / 虛擬化軟體 / 軟體定義儲存……

使用 SAN 儲存的場景中，虛擬機器資料必須透過 SAN 網路儲存到伺服器外部的 SAN 儲存裝置上，也就是資料讀寫 100% 需要經過網路。而與此不同的是，超融合架構裡面虛擬機器的 I/O 是透過內建的 SDS 儲存軟體寫入磁碟的，

軟體邏輯

其中不難理解的一點：

而 SDS 屬於分散式架構，I/O 既可能發生在主機內部的本地磁碟上，也有可能發生在外部的網路主機之上。

畢竟 I/O 需要經過網路傳輸到遠端節點執行，勢必會增加 I/O 操作的時延。即使網路交換機的速度越來越快，依然無法完全避免時延的增加。

二、vSAN 與 ZBS I/O 路徑分析與對比

在同樣的軟、硬體條件下，本地 I/O 操作顯然要比遠端主機上的 I/O 操作的響應時間更短，

VMware 超融合中的儲存軟體 vSAN 本質上是物件儲存，它將虛擬機器磁碟檔案（。vmdk 檔案）以物件（object）的形式進行儲存，並提供了包括 FTT=1（RAID1 Mirror/RAID5），FTT=2（RAID1 Mirror/RAID6）等多種資料冗餘機制。下面以較為常用的 FTT=1（RAID1 Mirror）為例展開 I/O 路徑的討論（RAID5/6 只適用於全閃叢集，實際上混合儲存在超融合環境更為常見）。

在 FTT=1 的儲存策略下，虛擬磁碟（。vmdk）的副本數量是 2，兩個副本會分別放置在 2 臺不同的伺服器主機上。而 vSAN 中 object 預設大小是 255GB，條帶數為 1。舉個例子：當虛擬機器建立了一個 200GB 的虛擬磁碟，vSAN 會建立一組映象元件，它包含 2 個 object 元件（實際上還有 1 個見證元件，但不包含業務資料，暫不討論），分別放置在 2 臺不同的主機上。如果虛擬磁碟的容量大於 255GB，則以 255GB 為單位拆分為多個 object。

圖 3

1.vSAN 的 I/O 路徑

（1）寫 I/O 路徑

前面提到在 SDS 當中，本地讀寫相比遠端讀寫而言是一個更優的選擇，因為它的時延更低，網路開銷更少。vSAN 對於副本（object）的放置並沒有優先寫入本地的策略，而是隨機寫入兩個節點。下面將分析 vSAN 在不同情況下的寫 I/O 路徑。

以 4 節點的叢集為例，2 個副本的放置節點位置共有 6 種可能性，當中有 3 種情況（½ 的機率），虛擬機器寫入的兩個 object 均不在虛擬機器執行所在伺服器主機，需要 100% 遠端寫入（兩個副本都需要經過網路進行寫入），其餘 3 種情況都是有一個副本是本地寫入（另外一個副本經過網路進行寫入），顯然後者是更優的路徑選擇（2 個副本，必然導致至少有 1 個副本需要經過網路寫入）。

圖 4

a. 正常狀態下的 I/O 路徑

（2）讀 I/O 路徑

根據 VMware World［1］

的技術資料透露，vSAN 的 I/O 讀取會遵循 3 個原則：

副本間負載均衡讀。

非必然發生的本地讀（如果只剩下一個副本）。

確保同一資料塊從同一個副本中讀取。

vSAN 的平衡讀機制，意味著即使虛擬機器所在的主機本地有資料副本（圖 4 中虛擬機器本地擁有副本的機率為 ½），也將會有 50% 的讀取是透過網路進行的。另外，有 ½ 機率虛擬機器所在的節點沒有任何一個本地副本，需要 100% 遠端讀取。總而言之，

a. 正常狀態下的 I/O 路徑

圖 5

圖 6

vSAN 在正常狀態下是不會發生 100% 本地讀。

當叢集中發生硬碟故障時，由於副本降級（其中 1 個副本由於硬碟故障而損失），無法再執行平衡讀，所有讀 I/O 將發生在同一個副本內。

其中，故障場景下將有 ¼ 機率發生 100% 本地讀，這是相比正常狀態更優的 I/O 路徑。

圖 7

剩餘 ¾ 機率都是 100% 遠端讀。

圖 8

當硬碟遭遇故障時，需透過讀取（唯一）可用副本進行資料恢復。由於 vSAN 中 object 的預設大小為 255GB，條帶為 1，這種設定使得虛擬機器資料副本很容易集中到單一、兩塊硬碟當中。

b. 故障狀態下的 I/O 路徑

因此，VMware 會建議在儲存策略中透過增加“條帶數”配置，以便儘量利用多塊硬碟的讀能力。

在資料恢復時觸發的讀取操作容易受限於單塊硬碟的效能瓶頸，難以利用多塊硬碟執行併發恢復。

SmartX 分散式塊儲存 ZBS 將虛擬磁碟切分為多個數據塊（extent），併為資料塊提供 2 副本或 3 副本的資料冗餘保護。其中 2 副本在資料冗餘保護級別與 vSAN 的 FTT=1（RAID1 Mirror）是相對應的，下面將以 2 副本策略分析 ZBS 的 I/O 路徑。

在 2 副本儲存策略下，虛擬磁碟由多個數據塊（extent 大小為 256MB）組成，而 extent 以一組映象（Mirror）的方式存在，預設條帶數為 4。ZBS 支援資料本地化功能，可精準控制副本的位置：虛擬機器執行所在主機放置一份虛擬磁碟的完整副本，另外一份副本則放置在遠端主機。

2.ZBS 的 I/O 路徑

（1）寫 I/O 路徑

同樣以 4 節點叢集為例，由於 ZBS 可以保證虛擬機器所在節點一定會有 1 個數據副本，寫 I/O 操作可以一直保證 50% 寫入發生在本地，50% 寫入發生在遠端，無論另外一個副本如何放置，都不會受到影響。因此，

a. 正常狀態下的 I/O 路徑

ZBS 在正常狀態下不會發生 100% 遠端寫入的情況。

資料本地化功能可確保虛擬機器的一份資料副本完整存放在本地主機，從而降低 I/O 訪問的時延。但大家可能會思考一個問題：如果虛擬機發生了線上遷移，離開了原有主機，那麼資料本地化是否失效了？通常來講，遷移後的虛擬機器可能遭遇到以下 2 種情況：

情況 1：遷移後，兩個副本都不在本地，100% 遠端寫入（觸發機率 66。6%）；

情況 2：遷移後，虛擬機器移動到對應的副本位置，50% 遠端寫入（觸發機率 33。3%）；

從分析中可以看到，當虛擬機器遷移後，發生 100% 遠端寫入的機率比較高。ZBS 針對這類場景提供了專門的 I/O 路徑最佳化：

b. 虛擬機器遷移後的 I/O 路徑

同時可以解決遷移後遠端讀的問題。

當虛擬機器遷移後，新寫入的資料將直接存放在本地新節點，並且會在 6 小時後，將虛擬機器原有節點上對應的資料副本移動到新節點，重新形成資料本地化，

（2）讀 I/O 路徑

虛擬機器執行所在的主機總是擁有一份完整的副本，

a. 正常狀態下的 I/O 路徑

可以一直確保 100% 本地讀。

場景 1：虛擬機器所在節點發生硬碟故障

I/O 訪問從本地快速切換到遠端節點維持正常業務的執行，同時觸發資料恢復，優先在本地的可用空間進行恢復，並重新形成資料本地化。

場景 2：虛擬機器遠端節點發生硬碟故障

I/O 讀取依然保持本地訪問，並同時觸發資料恢復。資料恢復的 I/O 流是從本地可用副本讀取，然後向遠端節點寫入恢復資料。

大家可能會意識到：在資料恢復過程中，唯一可用的副本需要同時響應業務的正常 I/O 讀寫和資料恢復讀訪問，是否會給儲存系統造成較大的壓力？

ZBS 針對故障恢復場景也有專門的最佳化方案：

ZBS 的資料塊劃分相比 vSAN 更小（vSAN object 大小為 255GB，ZBS extent 大小為 256MB），加上條帶化策略，使得虛擬機器的資料更容易分散在多個硬碟，

b. 資料恢復狀態下的 I/O 路徑

內建彈性副本恢復策略：

利用多個硬碟的讀取能力以及多個硬碟的寫入能力，有效提升資料恢復速度，避免單個硬碟效能成為瓶頸。

當節點 I/O 繁忙，恢復速度下降至最低水平；節點負載下降，系統會逐步提升恢復速度，以求平穩、快速地恢復資料副本級別。（可閱讀：

透過彈性副本恢復策略平衡資料恢復速度與業務 I/O 效能

https：//www。smartx。com/blog/2022/05/resilient-copy-recovery-strategy/）

三、小結

根據上面的 I/O 路徑分析，我們彙總和對比 vSAN 與 ZBS 在不同狀態的 I/O 路徑情況，其中以 100% 本地訪問為最優，50% 遠端訪問為次之，100% 遠端訪問為再次之。

從對比表格上看到，無論在正常還是資料恢復的狀態下，ZBS 的本地 I/O 訪問的機率都要比 vSAN 更高，理論上時延會更低；而 vSAN 在絕大部分情況下都會有遠端 I/O 發生，換言之，對網路的佔用要更高一些。在虛擬機發生線上遷移的場景下，ZBS 的本地 I/O 的機率有所下降，而 vSAN 的 I/O 路徑顯得要更好一些，隨著 ZBS 重新完成資料本地化，這種情況會有所改善（至少需要幾個小時）。

基於以上的分析，

ZBS 支援自動感知當前業務壓力並根據壓力調整資料恢復速度。

而在實際生產環境下，頻繁的線上遷移並不常見。

ZBS 在不頻繁發生虛擬機器線上遷移（幾小時就發生一次遷移）的環境下具有明顯的優勢，反之，vSAN 會有一定優勢。

文章上面提到過，在超融合場景中，本地 I/O 發生機率越大，理論上儲存的效能也會更好。但同時也會有另外一種聲音：如果超融合的整體 I/O 效能是有富餘的，那麼是否就不需要考慮本地讀寫的優勢呢？答案依然是否定的，

1.I/O 路徑對於叢集的其他影響

在叢集正常狀態下，或許這些網路的開銷未必會造成很大的壓力，但針對部分特定場景，這部分影響還是無法忽略的，如：

因為更多的遠端 I/O，除了增加了時延，還額外佔用了網路資源。

當虛擬機發生遠端 I/O 的比例比較高的時候，虛擬機器部署密度增大，遠端 I/O 的流量也會劇增，有可能最終無法滿足虛擬機器的 SLA 要求。

虛擬機器高密度部署

當叢集容量使用率較高時，系統一般會觸發資料平衡（執行資料遷移），平衡過程中通常都會涉及主機之間的資料複製，這時候網路頻寬的壓力會較大。此時，資料平衡和虛擬機器的遠端 I/O 容易造成網路資源爭搶的情況，使得資料平衡完成的時間延長，甚至帶來不必要的風險。

資料平衡

資料恢復與資料平衡類似，需要依賴網路完成資料複製，但通常情況下，資料恢復需要更多的網路頻寬，對業務的影響更大。一旦出現資源爭搶的情況，將延長資料恢復時間，引入更大的風險。

最終，為了避免網路資源爭搶的問題，使用者可能需要付出額外的成本（如切換至 25G 網路），也許這並不是使用者所期望的。

資料恢復

超融合在選型和規劃上有許多值得關注的細節，充分了解和重視細節可以幫助使用者最大程度發揮超融合架構的優勢。後續我們將與讀者探討更多關於超融合基礎架構的技術話題。

參考資料：

1

VMworld 2016： STO7875 – A Day in the Life of a vSAN I/O。

https：//www。youtube。com/watch？v=oxi1_Eb7vxA

推薦閱讀：

VMware 與 SmartX 分散式儲存快取機制淺析與效能對比

https：//www。smartx。com/blog/2022/09/cache-vs-vmware/

VMware 與 SmartX 快照原理淺析與 I/O 效能對比

https：//www。smartx。com/blog/2022/08/snapshot-vs-vmware/

生產級 VMware 虛擬化方案替換路線與評估

https：//www。smartx。com/blog/2022/05/vmware-replacement/