一篇 vSAN 入門，送給大家

一直想抽空寫寫 vSAN 這個產品，在 15 年的時候筆者第一次聽說 vSAN 這個產品，當時 VMware 還以 VDI 最佳拍檔的方式去推廣 vSAN，短短兩年的時間， vSAN 經過多個版本的更新迭代，無論從功能還是穩定性上均有很大提升，最廣泛的應用也由 VDI 變為了承載核心業務。

這篇文章總結一下筆者對 vSAN 的一些學習和使用經驗，簡單介紹下 vSAN，希望可以用最少的文字介紹清楚 vSAN 的架構、優勢以及需要注意的地方。

以下內容僅代表個人觀點，如果錯誤歡迎指正。

01

—

虛擬化的存儲

在 NSX 系列文章NSX從入門到精通(2)：NSX介紹-網路工程師篇中，簡單介紹了虛擬化及 vSphere，本文以這個背景開始介紹存儲。

對於企業來說重要的是數據，而承載數據的設備就是存儲設備（Storage）。

與個人電腦類似，企業級存儲設備一般由多塊硬碟與RAID卡組成。通過 RAID 卡可以將多個磁碟組成邏輯的陣列，使得數據分散保存在多個磁碟中，實現高效的讀寫，實現冗餘，避免單個磁碟故障引起的數據丟失。

通常會使用 RAID 1 和 RAID 5 兩種配置模式，兩種模式使用的演算法不一樣，最終讀寫效率、資源利用率也不同，但最終目標都是一致的：可以避免一塊磁碟的故障。

RAID 卡及磁碟組成的陣列是純硬體層面的，對於操作系統來說，最終的使用方式是將其格式化為 XX 文件系統去使用，拿 Windows 系統來說，會格式化成 NTFS 去使用。

在虛擬化出現之後，這樣的硬體架構依然可以被使用。

vSphere 有個很重要的功能是進行了虛擬機的封裝，一個虛擬機以文件的形式存在，可以任意拷貝到其他其他。為了更精確定義這一個虛擬機需要的資源，會有很多個文件來表示這個虛擬機，例如 .vmx 後綴的虛擬機配置文件、.vmdk 後綴的數據文件等等。

單台伺服器做了虛擬化，跑很多的業務，這樣沒什麼問題，但在企業環境下，還必須考慮伺服器硬體的故障。因此，vSphere 下有了集群的概念，一個集群視為一個資源池，搭配很多 vSphere 的高級特性後，業務可以運行在集群中任意主機上，不必擔心單一主機故障。

下圖演示的就是單台伺服器故障後 vSphere 的故障恢復機制HA，可以將故障主機上的虛擬機「遷移」到其他主機運行。

而在這個功能的背後，有一個前提，便是共享式集中存儲。這裡面的關鍵詞是共享，一個存儲可以被多個伺服器同時連接，同時讀取數據，任意一台伺服器故障後，數據不受影響，進而其他伺服器可以使用這些數據快速恢復業務。

一般存儲會有兩個機頭（相當於存儲的大腦）保證冗餘，每個機頭會有多個介面保證介面冗餘，每個介面都可以對外提供數據訪問服務，但這個數量是固定的，在伺服器很多的情況下，需要存儲交換機的介入，為保證冗餘，需要至少兩台。

02

—

大數據的到來

章節 1 的架構一直很穩定，直到各種新概念的出現。

幾年前和現在比，對個人而言最大的變化是「人手一機」，對於企業最大的變化是「數據劇增」。

短短几年內，用戶產生的數據在劇增，對數據的存儲、分析等需求也在劇增。

再回到章節 1 看看傳統的集中式存儲，一下子暴露出很多缺陷：

容量有上限

所有配件均為專用硬體，一旦設備停產，無法進行硬體升級

不能平滑地按照業務需求升級容量和性能

嚴重依賴於存儲廠商提供服務

上線周期長

配置較為複雜，與業務無強關聯性，容易出現誤操作

無法針對業務提供區分式服務

為了解決以上問題，需要做到三件事：即拋棄單點的設計，避免單點性能瓶頸(無集中式主控)；拋棄專有硬體，使用標準硬體搭建存儲系統；使用一種靈活的存儲管理程序提供存儲服務。

而實現的最終效果，便是軟體定義的基於伺服器集群搭建的分散式存儲。

雖然上面的話比較繞口，但我覺得一句話可以完整表達出它的三個特點：

軟體定義：存儲的管理程序必須是基於軟體實現的，唯有軟體才能做到開放、靈活、快速，適應企業對於存儲的種種需求。

基於集群：集群代表搭建這樣的存儲系統，必須有多台伺服器的參與，這些伺服器需要有相似的配置，提供統一和標準的功能；

分散式：分散式可以將數據、IO訪問分散到多個節點，讓整個存儲系統隨著節點的增多容量和性能線性增加。

基於上面的概念圖，再來看看具體如何去實現。

1、誰提供容量？

如圖所示，每台伺服器都需要本地安裝硬碟來貢獻一部分容量。為了讓存儲性能更佳，需要配置 SSD 硬碟來做讀寫緩存，HDD 用來提供大容量的存儲。

2、如何將每台伺服器的提供的硬碟連接起來？

通過網路，為了保證性能，一般需要使用專用的萬兆乙太網。為了保證網路冗餘，也需要兩台交換機，雙線連接。

這裡有個重點是，萬兆交換機之間必須互聯！

3、向誰提供服務？

如果在虛擬化環境中，則最終使用存儲的是虛擬機，前面提到虛擬機以文件的形式保存，所以只需要讓虛擬化層可以把文件保存在上面即可。

4、如何提供存儲？

傳統存儲架構下，所有的服務都是要通過存儲的大腦--機頭來實現。

如果改成了分散式，每個節點都需要提供存儲資源，也需要訪問存儲，因此每個節點都會有相關的組件存在。

03

—

VMware vSAN

VMware 於 2013 年正式推出 vSAN，全名 VMware Virtual SAN，其架構很類似於章節 2 提到的分散式存儲架構，在某些設計上更加「完美」，也做到了企業級的安全+消費級的簡單。

下面就三個關鍵詞講解 vSAN ：

池化：

vSAN 做的第一步，是將集群內多個伺服器上的多個磁碟進行池化。

1、伺服器內部的連接

X86 伺服器的架構決定了每個伺服器必須有 RAID 卡才能使用硬碟，多塊硬碟使用 RAID 卡匯聚到一起再和主板連接。

在每個 vSAN 伺服器內，至少需要配置一塊 SSD + 一塊 HDD，HDD 用於存儲容量，SSD 只用於讀寫緩存。

在 RAID 卡選擇上，建議使用支持直通模式（Pass Through）的 RAID 卡。在這種模式下更換硬碟、新增硬碟會非常方便（而如果配置 RAID 來供 vSAN 使用，則很多時候需要重啟主機進入 BIOS 來配置）。

可能有人會問不配置 RAID，硬碟壞了數據丟失怎麼辦？不用擔心，vSAN 有自己的冗餘機制，下面會講到。

SSD 70%的容量用於讀緩存，30%的容量用於寫緩存。默認所有寫的數據會被先行放在 SSD 中以減少寫延遲，通過一些機制將這些數據逐漸寫入到 HDD 中（這個過程叫 Destage）。在從 vSAN 讀數據的時候，vSAN 有一套演算法來決定哪些數據為熱點數據，然後預先緩存到 SSD 加快讀取速度。

所以，通常也不建議使用 RAID 卡自帶的讀寫緩存，因為 vSAN 已經有很優化的讀寫緩存加速了。

在這裡需要格外注意的是 vSAN 要求 SSD、HDD、IO Controller必須在 vSAN 兼容列表內，否則會出現不穩定等情況。

2、伺服器之間的連接

一個伺服器內部，通過 RAID 卡將硬碟匯聚在了一起，伺服器之間，則需要網路保證數據能夠互通。

當然，僅依靠乙太網，是不能將多個硬碟連接起來，需要有個中介，這個中介就是嵌在 vSphere 中的 vSAN 進程。兩個網路節點之間通信，雙方必須有 IP 地址才可以，於是有了vSAN VMkernel，每台主機都需要一個 vSAN VMkernel 和獨立的網路，保證節點之間數據高速、穩定的傳輸。

有了以上元素，只需在 vSphere 集群中開啟 vSAN 功能，所有主機的磁碟會組成一個邏輯的存儲池。

故障域：

1、

前面提到了傳統存儲使用 RAID1 或者 RAID5 來防止單硬碟故障，在分散式存儲中，也需要避免單點故障。

vSphere 提供了 HA 功能，保證單台主機故障後業務可以在其他主機上運行，這裡故障的單位是「主機」，vSAN 也繼承了這一設定（也很合理，因為主機也需要硬體維護，在維護的時候，一台主機能提供的所有存儲資源都會下線）。

在這樣的設定下，為了保證數據不丟失，數據的存放位置就有講究了。

同一個虛擬機的同一份數據，必須保存在不同主機上。

結合上面的架構和 vSAN 的網路架構，假如一台主機網路有問題怎麼辦？（此時主機並不能確定是自己的網路中斷還是其他主機中斷，只知道無法和其他節點通信。）

這時候需要有個仲裁機制保證同時只有一份數據是活動且是最新的，否則會造成衝突。

於是在上圖的架構中，為每份數據再創建一個仲裁文件，保存在第三台主機中。

這便是 vSAN 最簡單的架構，此架構允許一台主機故障，當然一台主機上的任意硬體壞掉也是允許的，只要故障發生在一台主機內。

下圖便是 vSAN 故障域的一個簡單示意。vSAN 中有個詞叫 FTT （Fault to Tolerance），意為最大允許同時故障多少台主機。FTT 決定的是虛擬機數據保護級別，也決定了一個集群所需的最小數量，一個集群中主機數量>=2N+1，N=FTT的值。

2、上面提到每台主機需要 RAID 卡將多個硬碟連接起來，也需要至少一個 SSD 和一個 HDD。SSD 只做讀寫緩存，從經濟的角度看，不可能每個 HDD 都配置一塊 SSD，需要多個 HDD 共享一塊 SSD的資源。

在 vSAN 中，有了磁碟組這一概念，磁碟組是個邏輯的組，用於讓多塊 HDD 共享一個 SSD。

所以 vSAN 磁碟組和 RAID 組完全不是一個概念，數據是按照故障域為單位自動存儲的，不能手動選擇保存在哪台主機，更不能選擇保存在哪個磁碟組。

vSAN 規定每個磁碟組最少需要一塊SSD+一塊HDD，最多一塊+7塊HDD。每台主機不能多於 5 個磁碟組。

讓多塊 HDD 共享一個 SSD 雖然節約成本，但也有一定風險，比如萬一 SSD 故障，整個磁碟組的數據均會處於無法訪問的情況，因此一般建議使用多個磁碟組分散數據，減少此種故障帶來的影響。

舉例：

集群1：每主機一個磁碟組，由1塊400G SSD + 4塊800G HDD 組成

集群2：每主機兩個磁碟組，每磁碟組由1塊200G SSD + 2塊 800G HDD 組成

一旦集群1的一個 SSD 故障，vSAN 存儲池會失去 3.2T 裸容量。

一旦集群2的一個 SSD 故障，vSAN 存儲池會失去 1.6T 裸容量。

區分服務：

只要存在不同類型的業務，必然存在區分服務。

對於傳統存儲而言，服務的區分是存儲卷級別的。一個存儲卷的底層使用 RAID 10，上層業務獲得的存儲資源便是 RAID 10的保護級別和性能；一個存儲卷的底層使用 RAID 5，上層業務獲得的存儲資源便是 RAID 5 的保護級別和性能。

1、

如前面在故障域中提到的，使用 vSAN 來保證數據在單節點故障時不丟失，至少需要三個節點。

如果要讓數據在雙節點故障時依然可以訪問（即 FTT=2），數據應該怎麼保存？

此時或許有人搶答，數據一分三，加一個仲裁，保存在四個節點上，如下圖所示：

然而很可惜，這樣的架構存在腦裂的風險，假如主機剛好兩兩隔離，那無法判斷哪兩個主機上的數據才是活動的，哪兩台主機的存儲資源需要被暫停。

因此可以通過加入一個見證節點來避免腦裂的發生（在實際情況中數據存儲並不一定完全按照下圖執行）。

實現下圖的冗餘級別，只需要修改虛擬機的存儲策略，將 FTT=1 改為 FTT=2 即可。

2、

vSAN 通過存儲策略來給不同的對象區分不同的服務。

例如：

給虛擬機 1 設置存儲策略 A（ FTT=1，不預留緩存，限制 IOPS 為100）

給虛擬機 2 設置存儲策略 B（FTT=2，預留 10% 的 SSD 緩存，不限制 IOPS）

Wait！上面提到一個詞，對象（Object），什麼是對象呢？

一個文件，例如 vmdk ，在 vSAN 中便是一個對象；

一個快照文件是一個對象；

虛擬機 swap 文件是一個對象；

虛擬機一般都會有一個文件夾存放與其相關的 vmx 文件、日誌文件等，這個文件夾(VM home)在 vSAN 下也是一個對象。

可以理解為，在 vSAN 的世界中，一個虛擬機由多個對象組成。

對象並不是最小單位，對象由多個組件（Component）組成。一個對象如何變成多個組件便是由存儲策略去決定的。

每個 Component 有大小限制，最大為 255G，因此大於 255G 的 Object 會被強制拆分成多個 Component。

至此，vSAN 主要的實現原理基本講完了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！