PVS的内存和存储规划设计

一、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大小的内存！

二、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操作系统了。

三、Provisioning Services的IOPS该如何计算

无论是那种部署方式，IOPS的计算都是核心因素所在，对于PVS来说，不仅仅是PVS服务器，还有TargetDevice也需要考虑。在我们下面的上一封邮件已经对Write Cache放在什么地方进行过论述，此处不再详述，总之建议放在共享存储上，而不是PVS服务器本地。如此一来，如果在第二章你对PVS的内存配置正确的话，在PVS服务器上你几乎可以不用考虑这个因素了，因为基本上不会用到PVS服务器本地的资源。

 

四、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的数据。

 

五、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中。

 

六、总结

对于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 是指已被提交的（不是保留的）虚拟内存字节数。此数并不一定代表页面文件的使用量，因为它包含了物理内存中从未被换出过的私有提交页面。当然，如果一个进程完全是非驻留的，则它代表所使用的页面文件数量。