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

 

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