Citrix MCS桌面管理技術解讀

 

 

1、MCS概述

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並將其格式化以後掛載給虛擬機。這樣的情形下咱們上次寫入的緩存信息是不會獲得保留的。

 

2、MCS的不足

主要有兩點：

一、佔用空間過多

二、對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就不行了，這個時候桌面運行就顯得很緩慢。

 

3、MCS的性能提高

解決方案：

一、佔用空間大：精簡置備

二、讀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技術的一個進一步改進。能夠把基礎鏡像模板放到服務器的本地內存中緩存。這樣對虛擬桌面環境下的虛擬機啓動將會帶來飛躍，同時帶來性能的提高。

 

4、MCS我認爲還須要改進的地方

主要有兩個：

一、MCS模式下，在LUN生成的虛擬機文件不能遷移？使用MCS虛擬機故障切換是沒有問題的，即HA。但若是你想移動虛擬機磁盤/文件以及使用的Storage vMotion，好比使用存儲實時遷移或存儲的XenMotion，這就不支持了。這是由於虛擬機駐留在磁盤ID /數據存儲（存儲在中央站點數據庫信息）之間存在很強的依賴性，一旦這個關聯關係中斷你的虛擬機將不能正常啓動。

二、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好好弄弄仍是有戲的。

 

5、軟件定義存儲如何解決MCS的上述挑戰解讀

如何使用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的克隆和更新問題。