PVS讓存儲顫抖，系列博文之六：深刻探討PVS的寫緩存新技術

在前面一系列的博客當中咱們都介紹過PVS 7.1版本能夠把每虛擬機所須要的IOPS降低到0.1個IOPS。你可能會不相信，或者試圖證實這是不可行的，沒問題，咱們歡迎科學研究精神，歡迎來信探討。咱們也對此技術作了一些更細緻的測試研究。

服務器硬盤IOPS監控

爲了更完整的展示PVS的這個新的Write Cache技術「Ram Cache with Disk Overflow」，咱們特地在實驗室中注意蒐集了一些其餘的數據，例如包含了登陸過程的100個用戶的完整的工做持續時間的測試細節（不包含啓動過程，由於啓動過程大部分都是讀操做，並且都是緩存在PVS的服務器內存中），以下圖所示：

    對於這臺物理主機來講，咱們把1個虛擬桌面會話的IOPS需求數據按照時間順序聚集成一個完整的數值圖。如上圖所示，整個工做時間段當中最高峯的就是登陸過程，最高的IOPS也不過是12個IOPS！

若是咱們不把用戶分散來計算，直接來看看這臺服務器的本地硬盤的完整IOPS圖形呢？

如上圖所示，在運行100個VDI虛擬桌面後這臺服務器的IOPS大部分時間都在40個IOPs如下，而峯值是155個IOPS。若是我沒記錯的話，一個15,000轉的硬盤大概的IOPS都能達到180個IOPS。也就是說一塊15,000轉的SAS硬盤便可知足100個VM的需求。

咱們的測試環境平臺以下：

• 測試拼圖LoginVSI 4.0 medium workload

• Hypervisor: Hyper-V 2012R2 and vSphere 5.5

• 虛擬機: Windows 7, 2 vCPU and 2.5 GB of RAM(512 MB RAM Cache)

   

數據讀寫比例

經過PVS發佈的虛擬機咱們都知道通常的虛擬機在存儲上的讀寫比例在10:90，即便是如今這個數據在大部分的場景也是正確的，不過在咱們實驗室針對「Ram Cache with Disk Overflow」的研究測試當中，咱們卻拿到了不一樣的結果。

• 在中等負荷的XenApp環境（實驗是部署在Hyper-V的WindowsServer 2012 R2版本之上）中，平均的IOPS是不高於1，在咱們以前的博客已經討論過；

• 讀寫比例：當使用新的寫緩存方式時（仍是部署在Hyper-V的Windows Server 2012 R2版本之上），讀寫比例變成了40：60

  • 此數字是從服務器上直接讀取的，非虛擬機層

爲何會發生這樣的變化？

這還要從「RAM Cache with Disk Overflow」的原理提及了。咱們都知道「RAM Cache with Disk Overflow」的原理是從虛擬機的內存中劃出一小塊區域來處理本應該是在寫緩存上的磁盤讀寫操做。當這塊區域被寫滿了的時候，纔開始寫入到寫緩存的硬盤中。也就是說只要你分配足夠大小的內存，你就能顯著的減少IOPS的大小，特別是寫的IOPS操做。咱們來看看PVS磁盤和內存緩存的不一樣吧。以下圖所示：

咱們之因此顯著的減小了寫的活動是由於咱們都寫入到了內存中，而後從內存寫滿後再寫入到硬盤中的時候的數據塊也是2M大小的，這個數字也可以減小IOPS的開銷。更重要的是，這個2M的數據塊是以順序方式寫入的，而以前寫緩存的技術都是以4K或者是8K大小的數據塊以隨機讀寫方式寫入到磁盤中，這會大大增長IOPS的開銷。

最後，若是你看看物理服務器上的磁盤的空閒時間，你就能清晰地看到當使用了「RAM Cache with Disk Overflow」以後磁盤有了更高的空閒比例，由於咱們實際上往磁盤上寫的數據量大爲減小。

這是新的「RAM Cache with Disk Overflow」下的數據：

最後仍是把咱們的測試環境說明一下：

• LoginVSI     4.0 ，選擇中等負荷測試環境

• Hyper-V     2012R2

• XenApp     7.5 運行在 Windows Server 2012R2

• 6 vCPU,     16GB RAM, 2 GB RAM Cache

• 7 VMs / 物理服務器

虛擬桌面端wC的變化

在PVS的舊Write Cache方式下，看到的Write Cache磁盤文件名是.vdiskcache，以下圖所示：

在PVS的新Write Cache技術「Ram Cache with Disk Overflow」方式下，Target Device的本地硬盤上的WriteCache文件名是vdiskdif.vhdx，正是這個文件以2MB爲一個單位增加，在硬盤上順序讀寫。

用戶配置文件管理

咱們在以前的系列文章的第二期的Windows 7桌面採用新的WriteCache技術「Ram Cache with Disk Overflow」的測試環境中談到，一個設計良好的Windows7虛擬桌面環境，是須要優化用戶配置文件和文件夾重定向的策略配置的。比較好的用戶配置文件管理每用戶的User Profile應該控制在15MB之內，甚至10MB之內，這樣對VDI環境的總體運行效率有很大的幫助。

那到底應該如何設計用戶配置文件管理呢？我把以前寫過的幾篇關於如何設計User Profile的文章剛剛也放到了51CTO個人博客上。一共是三期，分別是：

Citrix Profile Management 和 VDI系列講座之一：如何正確管理Profile

Citrix Profile Management 和 VDI系列講座之二：Profile漫遊須要怎麼配置存儲和網絡

Citrix Profile Management 和 VDI系列講座之三：大規模環境下的擴展架構設計

這三期關於User Profile設計和管理的文章從最基本的用戶配置文件和文件夾重定向的設計入手，再到網絡須要和存儲須要的分析，直至最後的大型環境設計，都做了具體的說明，能夠做爲一個實際實施項目的指南。

細節你們能夠點擊上面的連接地址訪問，或者直接從主頁進入，咱們在本篇博文中不作過多論述，僅做一個基本的總結：

• 必定要作用戶配置文件管理和文件夾重定向；

• 用戶配置文件管理的網絡路徑建議和重定向的文件夾網絡路徑不是一致，即分開路徑管理；

• 文件夾重定向必定要作某些無用文件夾的目錄排除操做，以減小漫遊的User Profile文件夾大小；

  • 須要同步的文件夾舉例以下：

• • 不須要同步的文件夾舉例以下：

• 即便是配置的某些須要重定向的文件夾，也要作文件類型篩選，例如只重定向*.dat, *.ini；類型的文件，而不是整個文件夾所有作重定向；

  • 舉例以下：

• Citrix Profile Management中建議配置Profile的流化（Profile Streaming），以及主動回寫（ActiveWrite Back）這兩個策略；

• 一個示例的ProfileManagement 和 Folder Redirection的基線GPO策略下載地址以下：

  • 基線策略的下載地址：Win7UPM & FolderRedir

• 用於存儲用戶配置文件的文件服務器若是使用的是Windows Server操做系統，建議配置以下：

  • 文件服務器至少是32G內存（最好是64G）

  • 文件服務器至少是2個core/vCPU（建議配置4個或更高配置）；

  • 按照上面CIFS調優的建議完成全部關於SMB的調優建議；

  • 若是是本地存儲（雖然最好是別這樣。。。），至少也要配置15k轉的SAS硬盤，以及RAID卡。

• 在已經規劃良好的UserProfile和文件夾重定向策略管理下，每一個用戶的User Profile 和 Folder Redirection所須要的IOPS和網絡帶寬要求以下：

 

至此，咱們本系列的所有文章連載完畢，歡迎你的閱讀，有任何意見歡迎留言。