本篇文章會詳細介紹虛擬機存儲策略，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里讀數據（無需復制到緩存層！）；

VMware SDS系列，未完待續……，歡迎持續關注和轉發 : )

本篇文章參考了《VSAN權威指南》、VMware官方網站和VSAN 6.0 Design and Sizing Guide等文章。在此一并致謝。

本文轉自學海無涯博客51CTO博客，原文鏈接http://blog.51cto.com/549687/1747492如需轉載請自行聯系原作者

520feng2007

總結

以上是生活随笔為你收集整理的VMware SDS 之四：VSAN的技术细节的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。