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和网络带宽要求以下：

 

至此，咱们本系列的所有文章连载完毕，欢迎你的阅读，有任何意见欢迎留言。