Citrix在桌面虛拟化領域一直是業内上司者，其中對于虛拟桌面的批量置備和管理的技術，擁有PVS和MCS兩種成熟的技術。這兩種技術的好處就是可以基于一個模闆批量的對大量的虛拟桌面進行統一維護和更新管理。在本文中我們簡要聊聊MCS置備模式。
MCS模式在Citrix是XenDesktop 5.0的版本的時候推出的功能，總體來說還是比較年輕的，不想PVS久經風霜。那個時候正是Citrix的XenDesktop 4.x的IMA架構邁向XenDesktop 5.x的FMA架構的時候，可以說MCS是FMA架構的基礎和核心。FMA起初僅僅是應用于VDI架構的，你看XenApp在6.5還在使用IMA就知道那個時候Citrix的産品方向就是這樣設計的。
其實從本質上來說，不管是MCS還是PVS，都是一種純粹的存儲技術，MCS就是基于存儲所謂的“連結克隆”技術而建立。MCS通過“連結克隆”建立虛拟機，建立的每個VM都配置設定了兩個或三個盤：
Master Image（主映像）：這是基于模闆虛拟機的快照而建立的虛拟磁盤，這個磁盤本身建立出來之後是隻讀的屬性，包含了模闆虛拟機系統盤裡面的内容。
Differencing Disk（差異磁盤）：差異磁盤連接配接到建立出來的虛拟機，裡面存儲了虛拟機的所有變化（作為寫緩存）。
Identity Disk（身份盤）：大約為16 MB 空間大小的一個磁盤。該磁盤包含了一些基本的資訊，如機器名、SID、域計算機帳戶密碼等等資訊，這些資訊在啟動作業系統的時候被注入到虛拟機裡面，以保證虛拟機可以被正确識别。
Personal vDisk（個人虛拟磁盤）（可選）：該磁盤存儲我們想要永久儲存的資料（超出本文的範圍）。
具體如下圖所示：
比如我們通過MCS模式建立了一組虛拟桌面，那麼這組虛拟桌面在Studio中表現為一個計算機目錄，在該計算機目錄中，對應與伺服器虛拟化底層的一個存儲LUN，該LUN記憶體在一個Master Image。同時存在多個Differencing Disk和Identity Disk一起構成該計算機目錄資源池。所有在該計算機目錄中的虛拟機都同時讀取Master Image上面的作業系統。然後再由寫入時才會将各自的寫IO緩存到各種虛拟機挂載的Differencing Disk中進行緩存。
而我們知道Citrix的MCS模式下存在着池靜态和池動态之分，池靜态就是在虛拟機重新開機之後，不對LUN内的虛拟機挂載的Differencing Disk進行删除，這樣就可儲存我們寫入的緩存資訊在我們虛拟機重新啟動之後還存在。而池動态模式模式下，每次重新開機虛拟機都保證将虛拟機挂載的Differencing Disk删除掉，在虛拟機重新啟動的時候，複制MasterImage磁盤的空間重新生成Differencing Disk并将其格式化之後挂載給虛拟機。這樣的情形下我們上次寫入的緩存資訊是不會得到保留的。
主要有兩點：
1、占用空間過多
2、對Master Image磁盤讀IO壓力大
上面大緻說了MCS的一些基本概念，接下來，我們書接上文繼續說說在MCS建立好計算機目錄之後，将虛拟桌面配置設定給了使用者進行使用。使用一段時間之後管理者需要對虛拟桌面京維護更新，他隻需要在模闆虛拟機上面将需要更新的部分安裝配置完畢，然後基于這個安裝更新對模闆虛拟機制作一個快照，即可基于這個快照進行更新。
MCS在這裡就出現了其缺陷，我們的每一次更新，在伺服器虛拟化底層的LUN中，都會将更新的快照重新生成一個新的Master Image，如下圖中，比如我們更新的新的Master Image叫B，原始第一個叫A。在更新的過程中，在保持A及其生成挂載到虛拟機的磁盤不變外，還需要重複第一次建立計算機目錄的過程，生成B的Master Image并生成相應的虛拟機的Differencing Disk。所不同的是Identity Disk不在生成。那麼在這個時候，其對應我們的存儲空間的占用的雙倍的。我們必須保證有足夠多的空間用于我們進行這樣的更新操作。
但B的Differencing Disk建立完畢後，會自懂将A的Differencing Disk删除，然後将B的Differencing Disk挂載給對應的虛拟機。知道所有的虛拟機都完成這個操作，即更新完成。這個時候A的Master Image還不會自動删除，需要大概六個小時之後才會自動進行删除。A在不自動進行删除的情況下，即在這六個小時之内，我們是可以進行復原操作的。
上述說明MCS在更新的時候占用空間過大，那麼Citrix是如何來解決這個占用空間過大的問題的呢？這個問題客官您等會看第三小節。我繼續說MCS的不足。
上面我說了，MCS的建立的一個LUN裡面，如果對應一個計算機目錄，那麼這個計算機目錄内的是以虛拟機都會同時去讀取相同的Master Image，那麼毫無疑問的是，在會對Master Image所知的磁盤造成很大的讀IO壓力。測試結果表明在MCS模式下，虛拟機對于磁盤的讀寫IO比為75%：25%。如果是HDD的磁盤，那麼在大量并發下讀IO就不行了，這個時候桌面運作就顯得很緩慢。
解決方案：
1、占用空間大：精簡置備
2、讀IO高：SSD加速、緩存到記憶體
針對于MCS占用空間的不足，解決方法是什麼：使用存儲精簡置備技術，按需使用存儲空間，對上層應用欺騙以達到按需使用的目的，減少存儲空間的占用。
那麼存儲精簡置備技術是咋實作的呢？
看上面的圖，不管是什麼牌子的存儲，其底層無非就是兩種新形式：塊和檔案，當然這裡不包括對象存儲。事實上對象存儲也不适合這樣的業務場景。有了上述基礎之後，我們再來說，塊存儲在底層是直接将資料存儲到磁盤上，并且以磁盤的塊為機關，是直接裸盤存儲。而檔案呢，則稍微有所差別，檔案是将磁盤上的塊機關的這一片空間送出給檔案系統維護管理，是以的虛拟機儲存的資料都是叫給檔案系統，有檔案系統将這些資料儲存到磁盤上，至于怎麼儲存，虛拟機不管。有了這樣一個中間人之後就好辦了，我隻需要在檔案系統上标記說這一段空間給你了，而實質上這一點空間我隻給了你需要使用的那部分，剩餘的部分檔案系統可能就另外挪作他用了。但虛拟機需要使用的時候，向檔案系統發起存儲請求時檔案系統在給他再一塊空間給虛拟機使用，是不是感覺和社會上的某種風氣類似，其實都是源于社會上來實踐，才能想出這樣的設計。當然毫無疑問，社會上的這種風氣被人吐槽，這種設計也好不到哪裡去是吧。為什麼這麼說呢？比如說你使用精簡置備模式，那天應用一抽風，一小時之内給你把盤塞滿你來得及加盤不？沒事，我有備用盤。那就更無語了，備一堆盤不如開始就加上去呢?此外，不僅對運維來說壓力大，在性能上也是有影響的。由于是使用按需配置設定，如果有多個邏輯資源同時并行寫入，這個時候這些邏輯資源在實體視圖上就是交織配置設定的，就變得空間上不連續了，不連續的檔案靈碎的放置在機械盤上，對機械盤的尋道是緻命的影響，性能不下降才怪。
書歸正傳，那麼回答了上述問題，存儲的精簡置備是怎麼實作的？儲存設備的精簡各自有各自的做法，底層存在一定差異，但大緻上思路類似。能實作LUN精簡置備的存儲基本上是智能的，下層幾乎都有一個fs結構來統治塊的配置設定和歸屬。例如netapp是采用LUN on file，即每一個LUN都對應一個檔案，和實際的塊松綁。初建時檔案很小，随着寫入持續增大至預定義的大小上限。
基于這個，再次引申出一個問題？為啥XenServer上不支援塊存儲的精簡置備，隻有NFS才支援呢？XenServer上因為本身沒有自己的檔案系統，虛拟機之間寫塊儲存設備，是直接寫入到磁盤的。是以不像VMWare這樣，本身有VMFS這樣的檔案系統可以在虛拟化層實作精簡置備。那麼虛拟化層不能實作這個技術，那麼隻有靠存儲來提供了。是以在XenServer上使用精簡置備需要使用NFS了。當然XenServer就是一塊存儲，可不可以實作精簡置備，當然也沒有問題，這就靠提供塊存儲的儲存設備在底層實作，然後将接口API和XenServe內建即可實作。當然不僅僅是FS這一層了，還有Locking問題，是以也不好做滴。
MCS的第二個不足是讀IO較高，因為所有的虛拟機都會同時的去讀Master Image。解決辦法是采用SSD來進行加速。MCS需要存儲（讀）IOPS較多。相對而言，相比于PVS，MCS大約需要的IOPS是PVS的1.6倍。
對于這方面的優化，Citrix的XenServer推出了Intellicache的功能，IntelliCache支援MCS的Pooled和Dedicated這兩種模式；Pooled模式支援本地的讀和寫的Caching，但是不支援XenMotion，能最大存儲的IO和空間節省。但是如果是Dedicated模式，就隻支援本地的讀，是以可以做XenMotion了，也能節省存儲的讀IO。IdentityDisk就一直都是放在存儲上，因為本身體積小，就不用參與其中了。好了，将緩存放從共享存儲移到主機的本地磁盤，是節省了一定的存儲鍊路開銷，但是本地存儲的IOPS不夠支撐虛拟機的磁盤在本地存儲上讀寫怎麼辦？這個時候主機上的本地磁盤就得加SSD了。
IntelliCache對Cache是寫到硬碟中，那麼我們可不可以将其采用PVS的類似技術一樣，寫到記憶體中呢？答案肯定是可以的，在XenServer6.5版本中，就開發了這樣一個技術，叫記憶體的讀緩存技術，XenServerv6.5的記憶體讀緩存技術是對IntelliCache技術的一個進一步改進。可以把基礎鏡像模闆放到伺服器的本地記憶體中緩存。這樣對虛拟桌面環境下的虛拟機啟動将會帶來飛躍，同時帶來性能的提升。
主要有兩個：
1、MCS模式下，在LUN生成的虛拟機檔案不能遷移？使用MCS虛拟機故障切換是沒有問題的，即HA。但如果你想移動虛拟機磁盤/檔案以及使用的Storage vMotion，比如使用存儲實時遷移或存儲的XenMotion，這就不支援了。這是因為虛拟機駐留在磁盤ID /資料存儲（存儲在中央站點資料庫資訊）之間存在很強的依賴性，一旦這個關聯關系中斷你的虛拟機将不能正常啟動。
2、XenServer記憶體讀緩存然并卵，還需要類似于PVS的Cache in RAM with overflow to disk的機制？伺服器主機的記憶體總是緊俏資源，至少現在來說是的。我們有那麼多的記憶體拿去做緩存使用嗎？而且在XenServer大規模部署環境下，每個LUN得一個Master Image，每一個Master Image緩存到記憶體需要多大的空間，那麼多的Master Image我有那麼多了記憶體來放嗎？是以還是做點向階段來說比較物美價廉的功能吧？是以MCS還需要類似PVS的Cache inRAM with overflow to disk的機制。那你要問了，這個機制實作起來容易嗎？當然這是Citrix的問題，但是從技術角度來說，實作是沒有問題的，難易程度我就不便成說，畢竟不是搞開發的。
那基于上面的倆個想法，我認為第一點問題，Citrix本身需要從産品層面去解決。為什麼有這樣的改進呢，我認為這樣的改進可以方面我多DR？做存儲的HA？對吧！在Citrix沒有改進産品之前，當然不知道會不會有改進了。那麼我們的臨時解決方案是什麼呢？我們考慮實施一些SDS解決方案來達到DR或者存儲HA的效果，像Nutanix，Atlantis，VSAN，VPLEX等解決方案，使您可以在 MCS下也能移動虛拟機，包括虛拟機的磁盤，無論是自動還是手動，同時保持虛拟機磁盤ID依賴使用并結合像影子克隆，資料局部性，資料同步等功能。許多SDS解決方案不僅可以幫助MCS利用存儲的自動精簡配置，而且還可以提高讀取緩存。在超過400個桌面的機關模闆讀取中，我們看到讀緩存率通常為85-90%。而這可以在沒有使用任何固态硬碟的SDS資料存儲上實作！SDS存儲可以提供比intellicache甚至新的XenServer 6.5讀取記憶體中的企業和桌面+版本緩存更好的結果。
是以我認為，要解決這個問題，軟體定義的存儲是關鍵。Citrix的軟體定義存儲什麼出來啊?結合XenServer好好弄弄還是有戲的。
如何使用Nutanix計算平台解決CitrixMCS的3個最大的挑戰，綜合我上述所言，其挑戰主要如下：
讀IO
資料存儲
連結克隆技術和資料局部性
1）讀IO
首先讓我們來看看Nutanix Distributed Storage Fabric（NDSF）I/O路徑：
Oplog角色：持久性寫緩存
描述：Oplog 類似于檔案系統的日志（journal），用來處理突發的寫操作，并聚合這些寫操作順序地寫到 ExtentStore 中。為了保證資料高可用性的要求，在寫操作完成（Ack）之前，資料寫入Oplog 的同時被同步複制到另一個 CVM 的Oplog 中。所有CVM的Oplog 都參與複制操作，并依據CVM負載情況自動選擇。 Oplog 儲存在CVM的SSD層以提供極高的IO寫性能，特别是随機IO寫操作。
Extent Store角色：持久性資料存儲
描述：Extent Store 是DSF 中持久性大容量存儲元件，它橫跨 SSD和HDD，并且能擴充到其他節點的儲存設備上。有兩種資料流進入Extent Store， 一種是從 Oplog 中被合并的資料順序寫入到 Extent Store，另外一中是繞過 Oplog 的順序寫操作直接寫入 Extent Store 中。Nutanix 的 ILM（informationlifecycle management）基于IO 類型（IOPattern）動态決定資料儲存的熱分層位置，并且在不同熱分層之間移動資料。
Unified Cache角色：動态讀緩存
描述:Unified Cache 是可消重的讀緩存，它橫跨CVM 的記憶體和SSD。當讀取的資料不在緩存中（或基于一個特定的指紋），資料會放到Unified Cache的Single-touch池，該池完全保留在記憶體中，并且使用 LRU(最近最少使用算法)直到資料被彈出。如果後續有對該資料的讀取操作，資料會被“移動”（其實沒有實際的資料移動，移動的隻是資料的中繼資料（metadata）到 Multi-touch池（Multi-toiuch 池跨記憶體和SSD）中的記憶體段。這時開始，資料塊具備 2 個 LRU，一個是其位于記憶體段的LRU，如果LRU耗盡，則資料被移動到Multi-touch池的 SSD段，并被賦予一個新的LRU。如果資料再次被讀取，則資料被移動到Multi-touch池的頂端。
緩存的粒度和邏輯：
資料是以 4K 粒度讀進緩存的，所有緩存是實時完成的，沒有延遲，也沒有采用批處理方式把資料讀進緩存中。
總之，處理讀取IO的NutanixDSF是容易的，提供最優的IO路徑處理讀寫請求。
2）單一的資料存儲
傳統的Citrix MCS實作計算節點（刀片、機架裝置等）。使用SSD也能達到虛拟桌面的IO所需要的速度。但是這種體系結構有兩個主要的缺點：
管理開銷
緩慢的更新過程
具有多個資料存儲庫，将導緻管理開銷，在更新/部署的時候部署的數量，錯誤的次數等也會相應的增加。同時複雜的也是有的。
其次，每次更新需要複制我們的資料存儲，可能會導緻一個非常緩慢的更新過程。有一個軟體定義的存儲解決方案或HCI，像Nutanix。會給我們帶來所有的共享存儲和本地存儲的性能和不曾有的不管理便捷性。同時由于其底層采用的多副本機制，MCS釋出出來的虛拟機磁盤檔案是支援進行存儲遷移的。
3）連結克隆技術
正如上面前面提到的，MCS是基于連結克隆技術，其中MCS的過程如下：
建立主映像
建立快照
建立計算機目錄，選擇快照等
此後，該快照的完整副本Master Image将被用來為每一個虛拟機建立差異磁盤和身份磁盤。
那麼從IO角度看，假如我們通過MCS建立8個目錄，每個目錄包含100台虛拟機。所有虛拟機的讀取都是基于做快照的完整副本，800台虛拟機通過單一VMDK/ VHD進行讀取檔案，然後所有的寫操作留在本地的差異磁盤。Nutanix有一個技術是專門針對Citrix MCS的連結克隆，稱之為影子克隆技術。它利用資料局部性解決有MCS的Master Image的克隆和更新問題。