本篇文章會詳細介紹虛擬機器儲存策略，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) 通過跨越不同副本實現負載均衡

相關推薦