PVS的內存和存儲規劃設計

提示：這篇文章是本人在2012年12月11日有感而寫的一篇電子郵件，由於其中的內容會在即將發表的一篇新博文被引用，故從新貼於此處。因爲是近三年前的內容，技術也在不斷進步，其中的部份內容已經再也不適合於如今，僅做了解技術發展之用。

差很少是去年的時候，我寫過關於一篇關於《PVS寫緩存容量設計和部署位置的考慮》，談到如何計算PVS服務所須要的內存。最近遇到一個項目，用戶的應用是基於B/S方式，並且都是運行在IE6環境上，也不能遷移到更高的IT版本上，怎麼辦呢？從表面上看我只能使用Windows2003Server + XenApp5.0的環境去部署，那麼個人Windows2003Server是否是隻能分配4G內存呢？若是分配4G內存，豈不是主機上就要部署太多Windows2003Server虛擬機，會不會影響每臺物理服務器所能承載的用戶數量？

在9月17日發給你的《PVS寫緩存容量設計和部署位置的考慮》文章中，咱們曾經談到過這個問題，今天把這個問題和PVS的存儲/內存設計考慮一塊兒來探討一下。另外，談到PVS方式，通常來講不只僅是涉及到PVS服務器端的內存和存儲規劃，還有Target Device端的內存該分配的問題，因此咱們一塊兒來討論。

1、Windows 內存分配機制和架構

咱們第一步必須先了解清楚Windows的內存分配機制，沒有這些底層知識，咱們設計時將無從下手。

第一件事情咱們應當瞭解的是OS處理的虛擬內存和安裝在系統中的物理RAM的不一樣。一個32位的Windows操做系統不管插在主板上的物理內存有多大，能直接處理的就只有4G大小虛擬內存。企業版和數據中心版的WindowsServer 2003 32位雖然能夠處理高達32G和64G內存，可是因爲32位處理器的限制，實際能處理的地址空間即便在使用了Physical Address Extension (PAE)的狀況下也只能處理到36位。PAE可讓CPU和操做系統利用4G以外的RAM空間。可是，從Kernel和進程方面來講，32位的Windows的core kernel仍然是在32位或者是4G虛擬內存空間內存工做。

下面的圖標就說明了32位的Windows Server2003是如何將4G的可尋址虛擬內存空間劃分爲兩個不一樣的區域：Kernel 空間和用戶空間：

如上圖所示，WindowsKernel的內存就只給了2G大小，同時又被劃分爲四個區域：

• System Cache（系統緩存）：該部分區域就是文件被map in和map out的區域，若是文件已經從硬盤讀入了內存，下次就能夠很是快的打開它了。最大可分配空間是960MB；下圖是當一個WinWord.exe程序被讀入時的狀態圖：

  即便是用戶關閉了這個應用程序，只要該部分的存儲空間還有足夠富餘，該內存空間仍然爲該程序保留，這樣，下次啓動該文件就很是迅速了。

  雖然該部分的空間只能是960MB大小，但不意味着只有960MB的文件能換存在該區域，實際上其餘文件緩存數據仍是能放在RAM的Standby區域，或者是Modified頁面文件中。以下圖所示：

   

• SystemPage Table Entries（PTE）：最該可分配空間是1.3GB；

• PagedPool：該部分最大可分配空間是650MB；

• Non PagedPool：該部分最大可分配空間是256MB；

關於上述每部分的內存用處再也不一一詳述，你能夠google搜索到。總之，全部的Kernel虛擬內存分配的總數不能超過2GB大小的地址空間。所以，好比System PTE空間小了，可是Paged Pool又有不少閒置內存，那麼PagedPool也不能將他的內存分給System PTE，還好這個限制在Windows2008就被取消了。

對於64位的操做系統來講，雖然內存架構仍是類似，可是再也不有這麼小的限制了，下面的圖標就是Windows Server 200864位的Kernel內存限制參數：

結論：在Windows Server 2003版本的操做系統上，不建議經過配置PAE參數以得到超過4G內存訪問的能力，也就是說，在WindowsServer 2003版本的操做系統上建議只分配4G大小的內存！

2、Provisioning Services的內存該如何分配

咱們瞭解了Windows是如何處理內存分配和文件緩存後，接下來看看Citrix PVS是如何被這些規則所影響的。下面的圖顯示了一個Windows XP的TargetDevice從一個共享的PVSvDisk的啓動過程，咱們暫時假設啓動過程須要讀取200MB大小的數據。

從上圖中能夠看到，PVS服務器只須要從物理磁盤讀一次vDisk便可，而後他就把vDisk的內容緩存到System Cache的內存中，而且向全部其餘的Target Device提供數據服務。只要足夠的內存空間，咱們就不須要考慮硬盤上的IOPS要求，由於I/O所有訪問在內存區域。

那麼，若是我製做了一個25G大小的Windows 7的vDisk，是否是我就要分配25GB大小的內存給這個vDisk呢？答案是不須要這麼多。實際上，一個Windows的運行是不須要將全部文件所有讀取到內存中去，他只須要去讀一些最經常使用的文件便可。一個典型的Windows XP會話大概須要從硬盤讀取1GB-3GB的文件，1GB-3GB是這麼來計算的：

• WindowsXP從啓動到登錄窗口，開啓系統服務，大概須要200MB；

• 用戶登陸而且加載他的Profile，而後啓動他的桌面環境，大概須要50MB；

• 用戶運行Office軟件，以及其餘應用程序以支撐他一天的工做，大概須要600MB；

• 用戶註銷操做系統甚相當閉操做系統，須要150MB；

基於以上的考慮，vDisk中大約有1GB大小的數據須要讀取到內存中，因爲是多個用戶共享一個vDisk磁盤文件，因此有不少文件是共享的。即便是考慮到用戶打開的文件是不一樣的，預計分配給PVS服務大小的System Cache RAM 2GB空間就能保證全部內容均從RAM裏面讀取，而不用從物理磁盤上讀取數據。

在System Cache中除了須要額外的RAM來支持vDisk的緩存外，System Cache還須要一些RAM來緩存Windows操做系統和服務所須要的核心繫統文件，還有一些服務的軟件，例如Provisioning Services服務。通常來講設計512MB來緩存這些文件是合適的。下面的公式就是說明如何計算須要多少System Cache RAM來支撐PVS服務：

System Cache RAM = 512MB + vDisk的個數×平均每一個vDisk須要讀取的平均數據

此外，vDisk所須要的System Cache RAM還須要加上CommittedBytes under load，因此最後的公式應該是：

Total RAM = Committed Bytes under load + System Cache RAM

舉個例子：

• 一個運行的PVS服務器Under Load顯示了2GB大小的Committed Memory

• 4個不一樣的Windows XP vDisk爲不一樣的Target Device提供服務；

• 平均每一個vDisk須要讀取2GB大小的數據；

• SystemCache RAM = 512 MB + (4 * 2 GB) = 8.5 GB

• Total RAM= 2 GB + 8.5 GB = 10.5 GB

也就是說在上述的場景中，該PVS服務器至少應當配置10.5GB大小的RAM才能能保證全部數據均從內存中讀取。

OK，到這裏應該看得出來安裝PVS最好的選擇不是32位的Windows Server操做系統，而是64位的Windows操做系統了。

3、Provisioning Services的IOPS該如何計算

不管是那種部署方式，IOPS的計算都是核心因素所在，對於PVS來講，不只僅是PVS服務器，還有TargetDevice也須要考慮。在咱們下面的上一封郵件已經對Write Cache放在什麼地方進行過論述，此處再也不詳述，總之建議放在共享存儲上，而不是PVS服務器本地。如此一來，若是在第二章你對PVS的內存配置正確的話，在PVS服務器上你幾乎能夠不用考慮這個因素了，由於基本上不會用到PVS服務器本地的資源。

 

4、PVS中vDisk的存儲建議

如上節所述，vDisk建議放在共享存儲上，那麼問題就來了，又出現了兩個選擇：Block Level Storage和Network Storage，哪一種比較好呢？

Block Level Storage包括了SATA、SCSI、iSCSI以及光纖存儲；而NetworkStorage主要包括網絡重定向方式來讓PVS訪問到共享存儲，例如CIFS、NFS以及Netware。

正確的作法是將PVS的vDisk放到Block Level Storage設備上。若是你選擇了網絡方式例如CIFS來讓PVS訪問到vDisk，那麼PVS服務將沒法將vDisk的內容緩存到System Cache中。這就會致使雙倍的網絡流量，甚至引發嚴重的網絡負擔，進而下降整個系統的擴展性。

例如，若是一個TargetDevice啓動後從vDisk讀取了200MB大小的數據，那麼就會有200MB的網絡傳輸數據從服務器傳到Target Device。若是vDisk是從非Block Level的網絡附加存儲傳到服務器的，那麼服務器就會首先從網絡存儲中讀取200MB的內容，而後再傳輸200MB到Target Device，因此總共會形成400MB的網絡流量。因爲ProvisioningServices不能緩存網絡存儲的vDisk內容，服務器會在每次TargetDevice鏈接它的時候都會向網絡存儲去下載這200MB的數據，這就形成全部網絡操做都會雙倍數據處理。

在Windows 2008的SMB2.0對此已經有所改動，不過就Provisioning Services目前的版原本說都不會從CIFS Share中緩存vDisk的數據。

 

5、Target Device須要多少內存

Target Device須要分配多少內存的重要性和ProvisioningServices Server須要多少內存都是一樣重要的，並且Target Device也適用於咱們第一部分所講的Windows內存分配機制的原理。

當Target Device開始發出讀數據的請求，此時讀的IOPS數據開始從PVS服務器經過網絡下載到TargetDevice本地內存中。只要Target Device有足夠的空閒RAM來緩存這些數據，那麼文件就不會從網絡中傳輸過來一次之後再次傳輸，一直到Target Device重啓，或者是RAM緊缺。

下面的公式是一個計算的基線來幫助你計算一個Target Device須要多少內存。由於用戶打開多少文件和應用程序沒辦法一一重現，咱們只能用估算的方法：

Target Device Ram = 最大的Committed Bytes+ System Cache RAM

例如如下場景：

• Windows7+ Office應用；

• 典型用戶的最大Committed Bytes顯示是1.0GB

• 1.0GB + 512GB= 1.5GB

在上一個例子中，假設512MB對System Cache來講是足夠的，那麼Target Device就應該分配很多於1.5GB的RAM來保證應用程序的運行以及有足夠的RAM來緩存硬盤數據到SystemCache中。

 

6、總結

對於Provisioning Services來講：

• 使用64位的Windows操做系統；

• 按照第二章節的計算方法分配足夠的內存，通常來講分配8G – 32G RAM；

• 使用Block Level的存儲存放vDisk，不要使用CIFS

   

對於Target Device來講

按照第五章的計算公式分配足夠的RAM，一個典型的Windows桌面操做系統大概須要Committed Bytes + 256-512MB的System Cache。

 

備註：CommittedBytes In Use 是 Memory: Committed Bytes 與Memory: Commit Limit之間的比值。(Committedmemory指若是須要寫入磁盤時已在分頁文件中保留空間的處於使用中的物理內存。Commit Limit是由分頁文件的大小而決定的。若是擴大了分頁文件，該比例就會減少)。這個計數器只顯示當前百分比；而不是一個平均值。

Committed Bytes 是指已被提交的（不是保留的）虛擬內存字節數。此數並不必定表明頁面文件的使用量，由於它包含了物理內存中從未被換出過的私有提交頁面。固然，若是一個進程徹底是非駐留的，則它表明所使用的頁面文件數量。