VMware SDS 之四： VSAN的技術細節 （含VSAN 6.0、6.1版的新內容）

【編者按】

寫文章不容易，尤爲是技術細節，須要查證不少資料。本篇文章花了很長時間才撰寫完成。若是您以爲好，請幫忙轉發、點贊。您的鼓勵是微信公衆號"樂生活與愛IT"可以持續不斷分享乾貨的動力。

另外，歡迎你們投稿，請聯繫個人微信或者QQ號：9269216 。

---Begin--

本篇文章會詳細介紹虛擬機存儲策略，IO如何流動等技術細節。在介紹存儲策略前，咱們先來探討一下支持存儲策略必備的技術VASA。

目前佔據存儲市場主流的磁盤陣列，大多數都是在以vSphere爲表明的服務器虛擬化出現以前就存在的。因爲服務器虛擬化聚合了前端多個業務虛機的IO，使得陣列在性能、部署、管理上，面臨着巨大的挑戰。從2011年在vSphere 4.1開始引入的VAAI，到2013年在vSphere 5.0引入的VASA 1.0，再到2015年在vSphere 6.0引入的Virtual Volumes（簡稱vVOL）等技術，VMware就一直在發展相關技術，着力幫助用戶化解這一存儲難題。

1.       VMware VASA

VASA，全稱是VMware vSphere API for Storage Awareness，意指存儲感知的vSphere API（編程接口）。它是供vSphere使用的API。

若是你之前用磁盤陣列爲vSphere的虛機劃分過存儲空間，你會記得，咱們須要告訴存儲管理員，或者從存儲管理員那瞭解LUN的特性，例如磁盤類型，是否分層，RAID級別，是否精簡置備，是否設置了去重或壓縮，等等。

而後由vSphere管理員識別LUN ID，作VMFS格式化，建立datastore，最後才能提供存儲空間給虛機。整個過程，需多方配合，流程也很複雜。

若是虛機數量多，業務種類多，存儲管理員或vSphere管理員還得維持一張大的表格，去記錄每個datastore所在的LUN的特性，方便將來的管理或變動。VASA的出現，就是爲了解決用戶的這個痛點。

存儲供應商能夠使用VASA爲vSphere提供有關特定磁盤陣列的信息，包括磁盤陣列功能特性（例如快照、重複數據刪除、複製狀態、RAID級別、以及是精簡置備仍是厚置備）和狀態（容量、運行情況、故障排除等）等信息。

以便在存儲和虛擬基礎架構之間實現緊密集成。這些信息可經過VMwarev Center Server傳遞給用戶。在VMware的軟件體系中，vVOL、VSAN和vSphere APIs for IO Filtering （簡稱VAIO）都用到了VASA，將其用做vSphere存儲的單個統一控制層。

     VASA Vendor Provider，簡稱VASA Provider（後面以此簡稱爲主）或者Storage Provider，中文意思是存儲提供程序，也稱爲VASA提供程序。是在vSphere環境中充當存儲感知服務的軟件。該提供程序可協調一端的vCenter Server和ESXi主機與另外一端的存儲系統之間的帶外通訊。

      VASA Provider可提供來自磁盤陣列（爲vVOL）或VSAN的信息，以便存儲功能能夠顯示在 vCenter Server 和vSphere Web Client 中。反過來，VASA Provider會將虛擬機對存儲的要求推送給存儲，管理員能夠採用存儲策略的形式定義這些要求。

   以確保在存儲層中分配的存儲資源符合策略中設定好的要求。一般，存儲供應商負責提供可與vSphere集成的VASA Provider，VASA Provider都必須通過VMware的認證並進行正確部署。若是後端存儲是VSAN，VASA Provider會再VSAN羣集建立時，就已經自動註冊好了。

VSAN 的VASA Provider

VASA的出現，是虛擬化平臺相關存儲技術的一次飛躍

以往，業務虛機（及其用到的VMDK）與後端存儲宛若隔開的兩個世界，存儲不知道上面運行的是什麼虛機，情況如何？虛機不知道運行在什麼樣的存儲資源上，更沒法根據業務變化要求調整存儲資源。只能依靠vSphere管理員和存儲管理員介入和溝通。如今，經過VASA，就實現了虛機和存儲的雙向感知。

VASA 1.0的時候，信息流是單向的，存儲只是將磁盤類型、RAID設置、容量、健康狀態、配置等信息提供給vCenter，而且進行展示。vSphere管理員仍是必須本身選擇合適的存儲來存放虛機。通俗一點說，就是虛擬服務器vSphere只能讀取後端存儲的元數據信息。下面兩圖分別是EMC VNX和DELL Compellent的VASA特性在vCenter上的呈現。

EMC VNX在VASA1.0時，在vCenter界面上的呈現

DELL Compellent在VASA 1.0時，在vCenter界面上的呈現

到了VASA 2.0，則實現了雙向通訊，vCenter能夠將虛擬機對存儲的要求向下推送到後端存儲。管理員建立虛擬機時，能夠根據與底層磁盤相關的容量、性能和功能方面的詳細信息輕鬆選擇最合適的存儲資源。通俗一點說，就是虛擬服務器vSphere對後端存儲的元數據信息可讀可寫。

VASA爲VMware SPBM（基於存儲策略的管理）實現策略驅動存儲資源的部署和管理奠基了堅實的基礎。

2.       虛擬機存儲策略

截止版本6.1，VSAN的虛擬機存儲策略有5種功能，或者說5種規則（Rule）。從各家磁盤陣列廠商對Virtual Volumes的支持，咱們能夠看到VMware SPBM所涵蓋的規則要比VSAN的5個規則豐富得多，隨着VSAN在數據服務（Data Services，也即存儲功能）的不斷髮展，將來會支持更多的規則。例如，在2015年9月VMword大會看到VSAN6.2預覽版的去重、糾刪碼、QoS（IOPS Limit），相信未來也會逐漸放到存儲策略裏。

在VSAN裏，每一個定義好的策略其實就是5種規則的組合，也即規則集（Rule-Set）。下圖咱們能夠看到這5種規則，後面會按照圖中下拉列表的從上至下的順序詳細介紹各個規則的含義。

VSAN的虛擬機存儲策略的5種規則

1）每一個對象的磁盤帶數（SW）

Number of disk stripes per object ：每一個對象的磁盤帶數（Stripe Width，簡寫爲SW）是指，虛擬機對象的每一個副本所橫跨的持久化層的盤的數量，也即每一個副本的條帶寬度。值若是大於 1，則可能產生較好的性能，但也會致使使用較多的系統資源。下圖是條帶寬度爲2的示意圖。

虛擬機存儲策略之條帶寬度

在混合配置中，條帶分散在磁盤中。在全閃存配置中，可能會在構成持久化層的SSD中進行條帶化。

須要強調的是，VSAN目前主要是靠緩存層的SSD，來確保性能。全部的寫操做都會先寫入緩存層的SSD，所以增大條帶寬度，不必定就帶來性能的提高。只有混合配置下的兩種狀況，能確保增長條帶寬度能夠增長性能：一是寫操做時，若是存在大量的數據從SSD緩存層Destage（刷）到HDD；二是讀操做時，若是存在大量的數據在SSD緩存層中沒有命中。由於，多塊HDD的併發能在這兩種狀況下提高性能。

默認值爲 1。最大值爲 12。VMware不建議更改默認的條帶寬度。

2）閃存讀取緩存預留

Flash read cache reservation (%) ：閃存讀取緩存預留是指做爲虛擬機對象的讀取緩存預留的閃存容量，數值爲該虛擬機磁盤(VMDK) 邏輯大小的百分比，這個百分比的數值最多能夠精確到小數點後4位，例如2 TB的VMDK，若是預留百分比爲0.1%，則緩存預留的閃存容量是2.048 GB。預留的閃存容量沒法供其餘對象使用。未預留的閃存在全部對象之間公平共享。此選項應僅用於解決特定性能問題。

全閃存配置不支持此規則，所以在定義虛擬機存儲策略時，您不該更改其默認值。VSAN僅支持將此屬性用於混合配置。

 無需設置預留便可獲取緩存。默認狀況下，VSAN將按需爲存儲對象動態分配讀取緩存。這是最靈活、最優化的資源利用。所以，一般無需更改此參數的默認值 0。

若是在解決性能問題時要增長該值，請當心謹慎。若是在多個虛擬機之間過分分配緩存預留空間，則需當心是否可能致使SSD空間因超額預留而出現浪費，且在給定時間沒法用於須要必定空間的工做負載。這可能會影響一些性能。

默認值爲 0%。最大值爲 100%。

3）容許的故障數（FTT）

Number of failures to tolerate ：容許的故障數（之後簡稱爲FTT）定義了虛擬機對象容許的主機和設備故障的數量。若是FTT爲 n，則建立的虛擬機對象副本數爲 n+1，見證對象的個數爲n，這樣所需的用於存儲的主機數爲副本數+見證數 = n+1 + n = 2n+1。

前面屢次提到的副本數爲2，表示的就是最多容許一臺主機出故障，也即FTT值爲1，此時主機數最少爲3。截止VSAN 6.1版，FTT的最大值爲 3，也即最多4份副本。

爲虛擬機分配存儲資源時，若是未選擇存儲策略，則VSAN將使用默認的虛擬機存儲策略，默認策略規定了FTT爲1。下圖就是FTT=1的示意圖。

虛擬機存儲策略之容許的故障數

若是已配置故障域，則須要 2n+1 個故障域，且這些故障域中具備可提供容量的主機。不屬於任何故障域的主機會被視爲其本身的單個主機故障域。

若是不但願VSAN保護虛擬機對象的單個鏡像副本，則能夠將FTT指定爲 0。可是，主機在進入維護模式時，可能會出現異常延遲。發生延遲的緣由是VSAN必須將該對象從主機中逐出才能成功完成維護操做。將FTT設置爲 0 意味着您的數據不受保護，而且當VSAN羣集遇到設備故障時，您可能會丟失數據。

VSAN的FTT默認值爲 1。最大值爲 3。

4）強制置備

Force provisioning ：若是強制置備設置爲是（yes），則即便現有存儲資源不知足存儲策略，也會置備該對象。這樣，在虛擬機Summary頁和相關的虛擬機存儲策略視圖中，這臺虛擬機會顯示成不合規（Not Compliant），以下圖所示。

虛擬機存儲策略之強制置備，呈現出來的不合規（Not Compliant）

強制置備容許VSAN在虛擬機初始部署期間違反 FTT、條帶寬度和閃存讀取緩存預留的策略要求。VSAN將嘗試找到符合全部要求的位置。若是找不到，它將嘗試找一個更加簡單的位置，即將要求下降到FTT=0、條帶寬度=1、閃存讀取緩存預留=0。這意味着VSAN將嘗試建立僅具備一份副本的對象。不過，對象依然遵照對象空間預留（下面會詳細介紹）的策略要求。

VSAN 在爲對象查找位置時，不會僅僅下降沒法知足的要求。例如，若是對象要求FTT=2，但該要求得不到知足，那麼VSAN不會嘗試 FTT=1，而是直接嘗試 FTT=0。一樣，若是要求是FTT=1、條帶寬度=10，但VSAN沒有足夠的持久化盤容納條帶寬度=10，那麼它將退回到 FTT=0、條帶寬度=1，即使策略FTT=1、條帶寬度=1 也許能成功。

使用強制置備虛擬機的管理員須要注意，一旦附加資源在羣集中變得可用，如添加新主機或新磁盤，或者處於故障或維護模式的主機恢復正常，VSAN可能會當即佔用這些資源，以嘗試知足虛擬機的策略設置，也即朝着合規的方向努力。

默認值爲否（no），這對於大多數生產環境都是可接受的。當不知足策略要求時，VSAN能夠成功建立用戶定義的存儲策略，但沒法置備虛擬機，以下圖的警告信息表示，須要3臺主機提供存儲，而目前在集羣裏只發現兩臺。

虛擬機存儲策略之強制置備，存儲容量不夠沒法建立虛擬機

5）對象空間預留

     Object space reservation (%)：對象空間預留是指，部署虛擬機時應預留或厚置備的虛擬機磁盤(VMDK) 對象的邏輯大小百分比。默認值0意味着部署在VSAN上的全部對象都是精簡置備的，一開始不佔任何空間，只有當數據寫入後，纔會按存儲策略動態佔據vsanDatastore的空間。

默認值爲 0%。最大值爲 100%。當對象空間預留設置爲100%時，虛擬機存儲對空間的要求會被設爲厚置備延遲置零（LZT，Lazy Zeroed Thick）格式。

3.       存儲策略的使用

1）系統默認的存儲策略

下圖咱們能夠看到VSAN的5個規則在默認狀況下表示的含義，分別是：

FTT=1，也即副本數爲2，這樣寫滿100GB的VMDK，實際要消耗200GB的存儲空間；

條帶寬度爲1，也即每一個副本只橫跨一塊持久化盤；

強制配置爲否；

對象空間預留爲0%（也即精簡配置）；

閃存讀取緩存預留爲0.0000%（也即不預留）。

VSAN虛擬機存儲策略的默認值

2）   分配虛機時選擇存儲策略

VMware的基於存儲策略的管理，使得管理員能夠更多地關注業務應用，圍繞着業務應用/虛機爲中心，而不是圍繞着存儲爲中心，從上至下的自動化地分配存儲資源。存儲管理員能夠從以往重複繁瑣枯燥的卷管理、LUN映射、VMFS格式化、建Datastore的工做中解脫出來，專一在更高級的工做中，也即根據不一樣的工做負載對存儲性能、可用性、容量的要求，建立存儲策略。存儲策略建立好後，可以適用於同類工做負載的不一樣虛機。

以下圖，建立的存儲策略有，Print Server，Tier 2 Apps，VDI-Desktops。當vSphere管理員須要建立虛機，或者給已有虛機建立新的VMDK時，就能夠根據存儲管理員事先建立好的存儲策略，或者系統默認的存儲策略，進行選擇了。這樣，就極大地減小了各個管理員交互的時間和工做量，使得存儲資源的部署很是便捷。下圖是建立虛機時，選擇存儲策略。

.分配虛機時選擇VSAN的存儲策略

3）   變動存儲策略很是簡單

咱們知道，用戶的業務應用種類不少，有些業務應用可能在某一個特定時間段須要經過變動存儲資源，去應對高峯時刻或關鍵時刻所需的高性能、高可用性。傳統存儲須要好幾個步驟，甚至須要停頓業務，才能變動存儲策略。而VSAN很是簡單，只需建立新存儲策略，並施加到(Apply)虛機，便可。

變動存儲策略：傳統存儲與VSAN的比較

4.       VSAN的故障域（Fault Domain）

在VSAN 6.0裏，新增了一個特性是Rack Awareness（機架感知），它能夠爲機架、主機、網絡和磁盤提供故障恢復能力。不管磁盤、主機、網絡發生硬件故障，甚至整個機架出故障，也不會形成停機或數據丟失。其實機架感知就是藉助VSAN的故障域，與vSphere HA 和維護模式互操做來實現這一功能的。下圖意指每一個機櫃設置成一個故障域，VMDK的兩份副本必定會自動化分放在不一樣的機櫃裏，這樣即便機架A出現故障（如斷電），也不會停機或數據丟失。

VSAN支持機架感知（Rack Awareness）

VSAN故障域功能將使VSAN副本分散到各個不一樣故障域中的主機上。

故障域構造時必須至少定義三個故障域，每一個故障域可能包含一個或多個主機。故障域定義必須確承認能表明潛在故障域的物理硬件構造，如單個機櫃。若是可能，建議使用至少四個故障域。緣由與以前建議VSAN至少4個主機作爲集羣相似。另外，建議向每一個故障域分配相同數量的主機，使用具備統一配置的主機。若是啓用故障域，VSAN將根據故障域而不是單個主機應用虛擬機存儲策略。根據計劃分配給虛擬機的存儲策略中規定的「容許的故障數」屬性，計算羣集中的故障域數目：

Number of fault domains=2*Number of failures to tolerate(即FTT) +1

VSAN的故障域

5.       VSAN I/O流

在理解VSAN I/O的讀寫機制前，咱們須要明確一個前提，就是VSAN是分佈式對象存儲。當VMDK對象的第一筆橫跨各個條帶的數據按照存儲策略寫入盤後，實際上該VMDK對象在VSAN集羣會存放在哪些主機的哪些盤上，就已經固定下來了，也就是說，以後新增的數據，仍會遵循一樣的部署方式，按照條帶分段大小（1MB）以增量的方式去消費盤上的空間，體現出來的是對象容量在增加。直到對象增加超過255GB，此時VSAN會新建一個組件。這也是有時咱們發現某個副本實際的組件數會比條帶寬度大的緣由。

VSAN的條帶是按照1MB的增量進行擴大的

1）   剖析寫I/O

寫I/O在混合配置和全閃存配置下是同樣的。假設：

FTT=2（也即兩份副本）；

虛機vm運行在主機01上；

主機01是vm的VMDK對象的屬主；

該對象有兩份副本，分別在主機02和主機03上；

咱們來剖析一下寫I/O的步驟：

步驟1，虛機vm發起寫操做；

步驟2，VMDK對象的屬主（也即主機01）觸發寫操做到虛擬磁盤；

步驟3，主機01克隆寫操做，主機02和主機03各自獨立地執行；

步驟4，主機02和主機03各自在本身的緩存層（SSD）的log上執行寫操做；

步驟5，緩存寫完，主機02和主機03分別馬上發確認信息給屬主；

步驟6，屬主收到了兩個主機都完成I/O並確認的消息後；

步驟7，屬主將一批已經確認過的寫I/O合併，Destage到持久化層的盤；

剖析VSAN的寫I/O

2）   將緩存的寫I/O刷進持久化層

混合配置中的持久化層是HDD，HDD在順序寫狀況下表現良好。VSAN使用電梯算法（Elevator Algorithm）異步地未來自不一樣虛機的，緩存內的，按照每塊HDD物理地址相鄰的數據，批量地Destage（刷）進磁盤中，以此來提高性能。若是寫緩存還有充足的空間時，VSAN不會頻繁開啓Destage的操做，這樣就避免了對同一個數據的屢次改寫，屢屢刷進HDD裏。

全閃存配置中的持久化層是SSD，被頻繁寫的數據（也即熱數據）仍然停留在緩存層，而那些較少訪問的數據纔會被刷進持久化層（也即提供容量的SSD）。

3）   剖析讀I/O

首先須要注意的是，讀可能跨副本發生。

先來看混合配置下的讀I/O：

步驟1，虛機vm發起對VMDK對象的讀操做；

步驟2，VMDK屬主（主機01）根據以下原則選取從哪一個副本讀：

1) 經過跨越不一樣副本實現負載均衡

2) 不必定要從屬主所在主機的副本讀

3) 一個給定的塊，其上的數據會只從同一個副本讀；

步驟3，若是在讀緩存裏，直接讀；

步驟4，不然，從HDD讀到讀緩存，取代某些冷數據；

步驟5，將數據返回給屬主；

步驟6，完成讀操做，將數據返回給虛機vm；

剖析VSAN的讀I/O（混合配置下）

再來看全閃存配置下，它的讀I/O大部分與混合配置下同樣，只是在步驟3和步驟4有所不一樣：

步驟3，若是數據在寫緩存裏（注意是寫緩存，不是讀緩存！），直接讀；

步驟4，不然，直接從持久化層的SSD裏讀數據（無需複製到緩存層！）；