建置虛擬桌面環境時，為避免使用者體驗不佳，虛擬桌面管理伺服器勢必要進行優化，以加速系統反應並降低工作負載，但市面上具備硬體快取機制的設備十分昂貴，所以直接利用VMware內建的View Storage Accelerator機制來提升整體的使用操作體驗，將是最好的解決辦法。
事實上，從VMware vSphere 5.0版本開始，便支援ESXi Host Caching機制（Content-Based Read Cache，CBRC），也就是VMware vSphere內建的讀取快取機制，到了VMware View 5.1版本，更將底層的ESXi Host Caching CBRC機制整合進來，稱之為「View儲存加速器（View Storage Accelerator）」。
整合了底層ESXi Host Caching CBRC機制的View儲存加速器，能為虛擬桌面環境帶來以下幾個優點：
- 內建CBRC讀取快取機制後，當虛擬桌面所要存取的資料在ESXi Host Disk內已經存在時（包含View Composer OS Disks及Full Clone Pool），便能發揮讀取快取的效果。
- CBRC讀取快取機制能夠有效降低原有儲存設備的Read I/O Requests工作負載，並且幫忙處理虛擬桌面「啟動風暴（Boot Storm）的情況，也就是當為數眾多的虛擬桌面一起開機（Power On）時所造成的大量Read Requests。
- 根據VMware官方統計結果顯示，啟用View儲存加速器機制後，在部署虛擬桌面時，可以降低80%的Peak IOPS，就整體來說，能夠降低65% Peak Throughput。
- 當虛擬桌面執行應用程式時，例如Outlook、Adobe Reader等等，系統一樣會透過CBRC讀取快取機制，將Read Request重新導向到Shared Cache Memory當中，以便讀取CBRC快取內容縮短回應時間。
- 支援由vCenter Server所管理的各種虛擬桌面資源池，包含手動桌面資源池、自動化完整複製虛擬桌面資源池、自動化連結複製桌面資源池等。
- CBRC讀取快取機制支援虛擬桌面作業系統磁碟，若虛擬桌面中的Persistent Disk有包含User Data時也有支援。
但在使用CBRC讀取快取機制之前，必須先了解下列相關的功能限制及注意事項，才能順利地啟用讀取快取機制：
- 啟用CBRC讀取快取機制時，ESXi Host上所運作的VM虛擬桌面主機，其運作狀態必須為「關機（Power off）」，或將所有VM虛擬桌面主機先遷移至別台ESXi Host主機，否則ESXi Host的CBRC讀取快取機制無法套用生效。
- 採用「連結複製（Linked Clone）」虛擬桌面機制時，Shared Disk中的VM虛擬桌面，其運作狀態也必須關機，否則CBRC讀取快取機制也無法套用生效。
- 因為CBRC讀取快取機制是將ESXi Host的「Physical Memory」空間劃分出一塊來使用（最大至2GB），所以嚴格來說會降低ESXi Host上VM虛擬主機的整併比率。
- 啟用CBRC讀取快取機制之後，每台虛擬桌面主機其儲存資源會增加Boot VMDK和Snapshot VMDK，所以虛擬桌面主機的磁碟占用空間會增加。
- 後續若變更某些CBRC參數值內容，必須要將
vSphere CBRC Module重新載入（Unloaded→
Reloaded），才能套用變更生效新的參數設定。
- CBRC讀取快取機制，不支援「未」被vCenterServer所管理的虛擬桌面資源池，同時也不支援Terminal Server虛擬桌面資源池。
TOP 2：CBRC讀取快取機制的運作架構為何？
CBRC讀取快取機制最大使用空間，不是只能設定ESXi Host的2GB，就可以有這麼大的讀取快取效能嗎？它是怎麼達成降低儲存設備工作負載，加速使用者要求回應時間？
CBRC讀取快取機制，是以「離線雜湊（Offline Hashing）」配合「線上快取（Online Caching）」這兩種機制來達成提供讀取快取的特色功能。
從圖3可以看到，VM虛擬主機的VMDK檔案連接到CBRC VSCSI Filter（簡稱CBRC Filter），此時的CBRC Filter，便是在VM虛擬主機與ESXi Host之間負責提供Hashing及Caching快取機制運作的溝通介面。
 |
| ▲圖3 CBRC快取機制運作架構概念圖。（圖片來源：VMware Technical Papers – View Storage Accelerator in VMware View 5.1） |
簡單來說，CBRC Filter透過RAM-Based Cache機制來管理ESXi Host當中的「磁碟快取資料區塊（Cached Disk Blocks）」，當VM虛擬桌面主機需要存取資料時，便會偵測VM虛擬桌面需要使用到快取中的哪些資料區塊，進而快速回復給VM虛擬桌面，如圖4所示。
 |
| ▲圖4 CBRC Filter運作示意圖。（圖片來源：VMware Technical Papers – View Storage Accelerator in VMware View 5.1） |
離線雜湊機制會在VMDK File當中產生「摘要檔案（Digest File）」（包含Digest Headers、Journaling、Digest Hashes等資訊），並且在每個Boot VMDK檔案內，也會透過Digest機制在每個Content Blocks內產生「雜湊數值（Hash Value）」，其中的Journaling是用來「復原（Recovery）」線上快取運作時的雜湊數值。
摘要檔案（Digest File）便是在VM虛擬主機內所看到的「-digest.vmdk」檔案，該檔案記錄著每個資料區塊（Block）當中的雜湊數值，同時也包含「中繼資料（Metadata）」內容。
若是以SHA1 Hash及4K Block Size當作基準，且「衝突偵測（Collision Detection）」設定為禁用（Disabled）時，摘要檔案大小將為Logical Disk Size的0.5%，若衝突偵測設定為啟用（Enabled），則檔案大小將為Logical Disk Size的1.2%。
簡單來說，一個具有20GB的Windows VM虛擬桌面主機，大約會有100MB大小的摘要檔案，但是當VM虛擬主機執行快照（Snapshot）時，摘要檔案將會額外分開產生，所以採用連結複製（Linked Clone）技術所建立出來的VM虛擬桌面主機，會有屬於個別（Respective）的Redo Log（Delta File），如圖5所示。
 |
| ▲圖5 摘要檔案（Digest File）運作示意圖。（圖片來源：VMware Technical Papers – View Storage Accelerator in VMware View 5.1） |
至於線上快取（Online Caching）機制，當VM虛擬桌面開機（Power on）時，摘要檔案將載入到ESXi Host的記憶體空間內（包含Block-Hash Mapping），所以當VM虛擬桌面需要進行「Read
I/O Request」時，ESXi Host便會檢查（Check）記憶體空間中是否有相對應的雜湊值（也就是可用的資料區塊）。