內容來源：2018 年 7 月 17 日，VMware大中華區原廠高級技術講師史峻在“VMware直播分享 第二期”進行《vSAN架構解析與6.7功能介紹》演講分享。IT 大咖說經主辦方和演講者審閱授權轉發。
閱讀字數：6759 | 17分鐘閱讀
嘉賓演講視頻回放，請複製：http://t.cn/RdpdNBV，粘貼至瀏覽器地址欄即可觀看。
Overview of vSAN
About vSAN
vSAN的基礎架構實際上就是將服務器的本地存儲聚集起來打造成一個虛擬的共享存儲，這也是vSAN的名稱由來。所有的主機都位於vSAN集群中通過vSAN專用的網絡來進行存儲數據的傳輸。由於vSAN是基於對象的存儲技術，因此vSAN Datastore中存儲的都是虛擬機的對象。vSAN同時也是一個軟件定義存儲，在VMware環境中是通過策略來定義對象如何保存，可用性和性能目標都需要通過策略實現，而傳統存儲的性能和可靠性是在最底層磁盤等物理介質上來實現。
vSAN and object-based storage
前面提到過vSAN Datastore中存儲的都是虛擬機的對象，那麼什麼是對象呢？vSAN Datastore的一個對象其實是文件的元數據和數據的集合。在傳統存儲中保存的是虛擬機的文件夾，文件夾中存放著虛擬機相關的文件，比如磁盤文件、配置文件、日誌文件等。
在對象存儲中這些文件都變成了對象，vSAN存儲中虛擬機對象被分為了5類，第一類是虛擬機的Home Namespace對象，第二類是VMDK對象（也就是虛擬機的磁盤文件），第三類是Snapshot delta（快照差異對象），第四類是內存對象，第五類是虛擬機的Swap對象。後面這四個對象其實就是虛擬機文件夾中比較大的文件，其他的小文件包括虛擬機文件夾則是第一類對象。
我們知道vSphere環境中集群依賴於共享存儲上VMFS文件系統，集群的一部分功能在設計之初都是依賴於這個文件系統的。而VM Home Namespace可以被看作是一個小的VMFS文件系統的實現，這樣就可以使對象存儲仍可以兼容VMFS內置的一些功能。
對象存儲是基於策略來保存對象的，所以在進行數據I/O的時候不是直接將對象本身放在磁盤組的硬盤中，而是以組件（Compnent）的形式，根據存儲策略定義的可用性和性能進行存取。
從圖中可以看到vmware的vSAN緊密的和虛擬化環境結合在一起的，實際上是將虛擬機的文件通過策略存儲在vSAN的存儲上。整個vSAN datastore有默認的策略，也可以針對虛擬機指定不同的策略，甚至是將策略指定給單個VMDK。
Enterpeise Storage in a Native vSphere Architecture
Vmware vSAN是集成在虛擬化產品vSphere系統內部，所以不需要像其他產品一樣需要準備存儲的管理虛機來管理軟件定義的存儲。如果有這樣的虛機，不僅要準備額外的CPU和內存，存儲I/O的路徑也會被延長，存儲的I/O開銷也會被放大。
vSAN是和Hypervisor集成在一起，所以虛機進行IO的時候是先到Hypervisor然後直接到SSD。分佈式I/O流傳輸的時候，也是通過一臺Hypervisor訪問另一臺Hypervisor，然後再去訪問SSD。這樣就能將管理本身的開銷降到最低，沒有額外的CPU和內存開銷，也沒有I/O路徑的延長或者開銷的放大。
vSAN可以匹配大多數業務場景，比如對於虛擬桌面的支持，我們知道虛擬桌面有大量的存儲I/O訪問，vSAN由於是分佈式的存儲，所以在存儲訪問的時候可以訪問本地的SSD，也可以訪問其他主機上的SSD。具體訪問哪裡，會根據負載均衡的算法來調度，但很有可能一部分I/O會落到本地，不用所有的I/O都走網絡，這樣在I/O的延時和速度上有很大的優勢。
One Management Plane – A Common Framework
vSAN 6.7對管理界面進行了升級，主要是將web界面逐漸的遷移到HTML 5上，原先的flash界面因為技術原因需要一定的加載時間，HTML 5 消除了這一加載過程，同時支持大多數的瀏覽器，目前已經實現了70%-80%的功能。
vSAN Architecture
Modern Object Based Storage for vSphere
上圖中有一個700G的VMDK的硬盤需要進行存儲。VMDK進行I/O的時候實際上是以組件的形式去寫入到存儲上，默認情況下組件最大是255G。而我們現在有700G文件需要存儲，所以它會被均分成3個組件來寫入到存儲中。
又因為是RAID-1所以每個組件會有兩份拷貝保存到存儲上，另外還會有一臺主機來存放仲裁組件。可以發現如果要做vSAN的話，一般情況下最少需要3臺主機。
圖中的FTT等於1表示的是組件容忍出現的故障，比如容忍故障為1就需要準備兩個副本，如果FTT等於0就是沒有副本。
vSAN Object Compliance Status
vSAN的存儲中為組件設計了3種狀態，第一種狀態叫Absent；第二種狀態叫Degraded；最後是Stale。
組件如果有多個副本，副本之間在寫數據的時候這些數據都是最新的。RAID-1寫的時候，數據就會同時寫到多個主機上，如上圖的這兩臺主機的數據都是最新的，如果某臺主機損壞，就無法訪問其中的數據。這裡的無法訪問具體情況有這幾種，Absent狀態下是主機在沒有發出任何消息的情況下，主機的存儲就突然無法訪問。Degraded狀態下是主機明確發出消息，比如硬盤損壞導致無法訪問。既然有問題那麼就需要修復，關於修復這三種狀態對應的策略也不一樣。
這些狀態都可以在HTML 5的界面中看到，類似上圖能夠看到存儲策略、組件狀態、分佈的主機。一旦無法訪問active就會變成Absent、Degraded、Stale其中之一。
網絡
在6.6之前的版本中部署vSAN的時候網絡是多播環境，從6.6之後就開始支持單播。只有一個集群的情況下多播影響不大，多個集群的時候可能會要在不同的網絡中修改多播地址，因此單播的開銷相對多播要低一些。
現在的網絡有IPV6和IPV4，vSAN對於純IPV6和純IPV4以及他們的混合網絡都支持。另外對於vSAN的冗餘我們也提供了更快的故障倒換的機制，假設現在有兩個vSAN網絡（物理上完全隔開），相當於創建了多個vSAN的vmknics，每個vmknics實際上是位於完全獨立的網絡中，無論是軟件還是物理層面，並且交換機之間也沒有連接在一起，當一個網絡斷開之後可以快速的切換到另一個上。
vSAN's Distributed Object Manager at a Glance
CLOM，集群對象管理器，它以進程的形式，運行在用戶空間，根據存儲策略確定對象的位置分佈。
DOM，分佈式對象管理器，位於主機內核空間，它沒有對應的進程，分為DOM Client與DOM Owner，DOM Client位於主機上，每主機一個；DOM Owner則針對對象，每對象一個。所有的對象處於DOM層面，由DOM控制I/O，它保證所有的副本處於一致狀態。
DOM Client將I/O給到DOM Owner，DOM Owner將之給到對象組件所在主機的DOM Comp.Mgr（DOM組件管理器）上，然後DOM Comp.Mgr和主機本地的LSOM通信，由LSOM訪問物理的存儲適配器進行數據的I/O。
vSAN Architecture — LSOM
主機本地I/O實際上就是對硬盤數據進行存取。寫的時候數據流從上層組件發送到LSOM的時候，LSOM會先將數據寫到緩存盤中，然後同步到存儲節點上。讀的時候是先從內存緩存中讀，（若前面未命中）再從硬盤緩存中讀，（若前面未命中）最後讀容量盤。這裡需要注意一下，可以看到圖中右邊的綠色線條實在寫緩衝和讀緩存中間，實際上在硬盤緩存區域中會先探查寫緩衝然後再探查讀緩存最後再去探查容量盤。
當寫數據放到SSD的寫緩衝之後會向後臺進行同步（我們稱此動作為de-stage），在6.7版本中我們對這個同步的性能進行了增強。比如原來的窗口大小是64k，現在被增加到了256k，數據同步的窗口增大之後，de-stage吞吐性能有了顯著的提升，大概在30%-40%左右（注意這裡不是指vSAN的總體性能，指的是從緩存到容量盤的同步吞吐性能的提升，非正式評估數據）。
vSAN Data Placement and Management
Caching and Capacity Tiers
前面提到過數據寫的時候是先寫緩衝再寫同步至容量盤，讀的時候也是先讀緩存區域再讀容量盤。這裡如果是全閃存結構，SSD的所有容量都會被用來做寫緩衝，因為這種架構下寫有收益而讀沒有。從圖中可能有人已經發現了，緩存SSD中還是有著讀操作的，其實在數據沒有被同步到容量盤之前，仍然是可以在寫緩衝中讀取到命中數據。
混合部署架構中，緩存區域的分佈是，讀寫是三七開，容量盤是機械盤，緩存盤是SSD，數據寫入到寫緩衝即返回寫成功，可以從讀緩存中讀取命中的緩存數據。
Disk Groups
vSAN集群中硬盤被放置在磁盤組中。每個主機上最多5個磁盤組，最少1個磁盤組，1個磁盤組中有且只有一個SSD作為緩存盤，最多7個容量盤（可以是機械盤也可以是SSD）。
很多人喜歡問vSAN的容量，舉個例子來說，假如集群有8臺主機，每臺主機5個滿配磁盤組，容量盤單盤容量4TB，那麼該vSAN集群理論最大容量為，5（DG）* 7（容量盤）* 4TB * 8Host，約等於1.1PB。
對於緩存盤，需要注意的是，vSAN迄今為止，支持的緩存大小最大為600GB，如果緩存盤大小超過600GB，有效使用的緩存空間，仍為600GB，但更大的容量（超過600GB），仍具有其價值，會增加該緩存盤的耐受度和壽命。
The different types of storage traffic in vSAN
vSAN的流量被分為兩類。第一類為虛擬機的前端流量，指的是虛擬機和存儲之間的訪問流量。另一類為存儲的後端流量，比如主機之間（因為策略變更產生的）複製流量，組件轉移流量，重平衡流量，重構流量等。
在對流量進行分類之後，我們可以直接在管理界面中看到流量的細分類型，從圖中很輕易的看到他們的IOPS情況。
I/O Management of Resyncs
在存儲I/O密集甚至擁塞的時候，我們需要對某些流量進行保障和控制。一個是存儲的Resync流量，另一個是虛擬機對於存儲的訪問流量。
如上圖所示，一開始數據組件都是正常的，沒有故障，也就沒有產生後端Resync流量，某個時間點有某臺主機的磁盤組發生了故障，要對組件進行修復複製，就會產生Resync流量，並且根據數據量的多少，帶寬的使用也不定。圖中藍線表示的是前端流量，橙線是後端Resync流量，可以看到在2-4階段，他們帶寬分佈情況是相對的，後端流量起來之後，前端會相對下降。需要注意的是如果兩者流量都達到了100%，那麼前端最多下降到80%，後端最多提升到20%，只有在不存在競爭的情況下後端Resync才有可能會超過20%。
An Example of how Resync Traffic is Generated
這裡我們具體來看下Resync的操作過程。圖中的硬盤有2個副本以及1個仲裁組件，其中某個副本發生故障需要在另外一臺主機上重新生成該副本，這時就會產生Resync流量。
在Absent狀態下不會立刻產生Resync流量，而是會等待60分鐘。Degraded狀態下，會立刻產生Resync流量。
Better Balance of Data as Maximum Capacity Nears
後臺存儲流量中有一種叫做Rebalance。在上圖中有三個組件分別寫入到了三個SSD，這三個組件未必來自同一對象，有可能是不同對象的不同組件，所以在大小並不一定相等。這裡就出現了一個問題，比如前面兩個組件來自同一個對象，消耗了SSD的70%存儲，第三個組件則來自於一個更大的對象，消耗了SSD的85%存儲，可以看到他們在存儲空間的消耗上較不均勻。
Rebalance的作用就是讓空間的消耗更加均衡，將磁盤空間使用超過80%（觸發Rebalance的臨界值）的容量盤中的較大的組件（如C3）打散成更小的兩部分組件（如C3+C4）甚至更多的組件，分別放到不同的磁盤中。
這種Break up（我稱之為打散）機制，最多能夠將大組件打散成8份更小的組件。
Faster Resynchronizations in Transient Outages
現在有這樣一種情況，圖中第一臺主機損壞導致需要在第四臺上創建新的副本（C1、C2、C3），當新的C1副本剛創建完成時第一臺主機又恢復了。
vSAN從6.6開始有了一種新的機制，用來對此種情形進行選擇，是繼續生成新的副本，抑或使用現有的副本。在圖中的情況下，會放棄生成第四臺主機上的C1，轉而使用第一臺主機上的舊的副本，當然這些副本數據會同步至最新狀態。如果第四臺主機已經快複製完成了，就不會再去使用舊的副本。這就是智能Rebuild的操作過程。
Opportunistic Repairs to Regain Resilience
上圖結構有3個副本和2個仲裁組件，可以看到有兩臺主機已經損壞，但是隻有一臺空閒主機。此時我們會盡可能多的修復組件，最後的空閒主機會用來複制副本，其中一個仲裁組件所在的主機也會用來放置副本，原先的仲裁組件被移除。當損壞的主機重新上線之後，仲裁組件會被放入其中。
Resilient Repairs during Transient Outages
我們日常下載中經常會應用到斷點續傳的技術，vSAN中也有類似的處理機制。上圖的場景中由於第一臺主機損壞後又重新上線了，於是需要從第二臺主機上同步最新副本至第一臺主機，在同步了一部分之後網絡突然斷開了。在原先的版本中這種情形是需要重新同步的，而現在則可以在網絡恢復後，接著同步後續的部分。這就是Resumable Resync技術。
Degraded Device Handling（DDH）
vSAN有一個很好的特性叫做故障的主動探測。當硬盤出現故障或者被判斷為將來會出現故障的時候，該設備會被列為懷疑設備。如果設備有副本就會在副本所在的主機上將副本標為已消失，然後再找一個新的設備進行Resync。如果不存在副本則會主動的將組件給轉移到其它的主機上。
vSAN Caching and I/O Path Explained
Anatomy of a write
如上圖所示的，在寫數據的時候，Guest OS將寫操作發送到VMDK，VMDK會先將任務交給控制器，然後控制器轉到DOM Client，接著由DOM Client轉到DOM Owner。DOM Owner會根據存儲策略克隆寫操作，向多臺主機分發，數據被寫入到主機SSD緩存中（Log），然後返回寫成功，最後兩臺主機從緩存向容量盤同步數據。
Anatomy of a Read（All flash）
Guest OS執行了一個讀操作，DOM Owner根據負載均衡策略，可以從眾多個節點中選取一個主機上的副本進行讀取，同一個Block始終從同一個主機上的副本讀取，如果只有本地副本，則會直接讀取，略過負載均衡機制。
讀操作到達主機後，首先探查的是主機的內存緩存，內存緩存最多隻能用到0.4%或1GB。然後探查SSD的寫緩衝或者讀緩存，如果還是沒有的話就去容量盤中探查讀取，任何一步命中後，數據返送到Owner，然後返送到VM。
vSAN Caching Algorithm
在集群級別，儘量提高flash的利用率，獲取緩存收益。
做VM遷移的時候儘量只遷移虛擬機的內存數據，儘量避免存儲的遷移。
關注延時問題，讀數據的時候，如果是直接從本地的緩存（Flash）中讀取，延時是微秒級別的。而數據要是通過網絡讀取的話，延遲會達到毫秒級別（5-50）。由於vSAN的存儲是分佈式的，所以在遷移的時候如果附帶存儲，就需要進行跨網絡的讀取，此時它的延遲相對本地SSD I/O要大很多。
我們都知道延伸集群可以將vSAN擴展到兩個數據中心，類似於雙活存儲。這時數據在進行I/O的時候本地和遠程的主機都有可能被讀取，而遠程主機的讀取延時是比較高的，所有在這種延伸集群中我們可以讓vSAN 100%讀取本地，以避免高延時，保障性能。
以上為今天的全部分享內容，謝謝大家！
閱讀更多 IT大咖說 的文章
