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