PVS写缓存容量设计和部署位置的考虑

提示:这篇文章是本人在2011年11月5日有感而写的一篇电子邮件,因为其中的内容会在即将发表的一篇新博文被引用,故重新贴于此处。由于是近三年前的内容,技术也在不断进步,其中的部分内容已经不再适合于现在,仅作了解技术发展之用。

Citrix Blog经常会有一些Blog写的很有深度,适合于高手;也有一些Blog善于归纳,适合经验总结。今天看到一篇博客就属于后者,讲解PVS写缓存的容量大小设计和部署位置的考虑,供大家参考。

PVS WriteCache Sizing & Considerations

作者更在写文章之后做了一个问卷调查,实际调查PVS的用户都是如何配置写缓存的:

PVSWrite Cache Sizing & Considerations – Follow Up

我们摘要一些第一篇博客的精要:

一:部署位置

  1. 写缓存的部署地点可以有
  • Cache on ProvisioningServer
  • Cache on Target Device RAM
  • Cache on Target Device HardDrive
  1. 把写缓存设置在target side

    好处

    1. it keeps the write “close”to the target;
    2. minimizes the load on theProvisioning Servers
    3. this disk can also be usedfor data, which needs to be persistent

缺点

    1. it requires more resourceson the target side
  1. 作者的倾向:

    Personally I prefer using a target side hard disk for storingthe write cache for virtual desktops and XenApps.

二:本地磁盘

  1. 本地磁盘和共享存储部署写缓存的优缺点分析:

Option 1 – write cache disk on sharedstorage

Pro:

  • High level of performance(typically)
  • Easy to scale
  • Central monitoring andmanagement
  • Virtual targets can bemoved between hypervisor hosts for load balancing and/ or management reasons

    Con:

  • Complexity
  • Cost
  • Available disk space onhypervisor hosts is wasted

    Option 2 – write cache disk on localdisk

    Pro:

  • Cheap (compared to sharedstorage)
  • Low complexity

    Con:

  • Can be a performancebottleneck / hard to scale
  • Virtual targets are “tied”to a hypervisor host
  • Hypervisor hosts must havelocal drives

    并没有这样一个尚方宝剑来告诉你哪一个是最好的,用户的实际选择是各自不同的。

  1. 作者的观点

Personally I prefer to use local disks for provisioned XenAppservers whenever possible from an performance and management point of view.

刀片上的硬盘是不合适的,因为刀片一般就只有两块硬盘,无法满足虚拟桌面的并发需求。

三:磁盘大小

  1. 估算写缓存的大小是不可能的,因为这很大程度上取决于用户的行为和应用程序的工作模式。

    1. 例如用户拷贝大量文件到写缓存中;
    2. 应用程序缓存大量文件,例如数据库文件;
  2. 理论上写缓存不能大于vDisk的大小,当然,99.99999%的情况下这种情况不会发生;
  3. 如何减小写缓存的大小,提高读写效率
    1. 文件夹重定向:Keep the user profile small by redirecting profile folders suchas Desktop, My Documents, Application Data and so on.
    2. 使用App-V共享缓存或者是最新的CitrixApplication Streaming,后者现在具有VHD Mount feature (similarto App-V Shared Cache),不会再本地构建streaming cache。
  4. 重启设备后在本地硬盘上永久保存的文件
    1. Windows Pagefile..
    2. Windows Event Log.
    3. Citrix related logs.
    4. Anti-Virus pattern.
    5. App-V / Application Streaming Cache in case a shared cacheconcept cannot be used.
    6. EdgeSight DB.

      四、本地磁盘

      当把写缓存和其他items重定向到target的本地永久磁盘后我们需要考虑 两件事情:

  5. 永久性
    1. 必须记住把文件写在永久磁盘上违背了PVS中央管理的初衷,如何管理或者是删除这些文件是我们需要考虑的问题;
    2. 磁盘驱动器的大小。如果本地盘的容量不够支撑写缓存,如果不够的话写缓存就会写到PVS服务器上
  6. 举例说明

假设有一个XenApp服务器有50个并发用户,每个用户有20M的用户Profile,每个用户也都创建了50M的工作环境(例如临时文件),计算结果:

1.0GB user profiles (50 x 20MB)

2.5GB user workspace (50 x 50MB)

1.0GB system workspace (assumed, different for everyenvironment)

= 4.5GB write cache file

4.5GB write cache file

4.0GB Pagefile (check out KB889654 / KB2021748)

0.1GB Windows Event Logs

0.1GB Citrix Logs

0.3GB EdgeSight

1.0GB other

4.0GB Dedicated Dump File (see UPDATE section below)

2.0GB buffer (some room to grow)

= 16 GB local disk size required per XenApp target

五、调查结果

1.0GB other

4.0GB Dedicated Dump File (see UPDATE section below)

2.0GB buffer (some room to grow)

= 16 GB local disk size required per XenApp target

五、调查结果

时间: 2024-09-29 03:20:14

PVS写缓存容量设计和部署位置的考虑的相关文章

PVS让存储颤抖,系列博文之一:PVS的写缓存新技术

实现桌面虚拟化的障碍来自于哪里?你可以列举出很多因素,包括实施的复杂性,要替换掉前端PC,PC使用人员惰性对项目的抵触等等,但是更重要的是他的成本在首次购置时超出了一台PC的价格. 桌面虚拟化整体项目的成本不外乎是软件.硬件以及服务.其中软件包括虚拟化软件的License和微软相关软件的授权License,硬件一般包括服务器.存储和网络交换设备等.一般来说硬件成本占整个桌面虚拟化成本的超过60%,甚至更高.在硬件成本中存储的成本又是最高的,有统计数据表明硬件成本中超过一半是共享给了共享存储. P

PVS的写缓存新技术把虚拟桌面的IOPS需求下降99%

在过去的多年当中,硬件成本一直是VDI项目的噩梦.往往是为了达到满足Windows7/Windows Server操作系统所需要运行的最小的IOPS的需求,用户不得不去采购昂贵的存储设备,或者因为预算紧张只能忍痛割爱:即使是鼓起勇气采购桌面虚拟化也是选择小范围试点:同时很多时候,项目是和硬件一起打包招标的,这就导致虚拟化软件往往只在整体项目预算中占很小一个比例,经常是失去了话语权.而系统集成商出于各种原因往往会推荐很高档次的存储设备,而事实上即使是在PVS的新Write Cache技术出来之前,

PVS让存储颤抖,系列博文之三:PVS的写缓存新技术之Win7桌面实测篇

在Hyper-V 2012 R2平台上的PVS 7.1 RAM Cache 256M方式发布的Windows 7 VDI桌面 备注:以下测试和上面的MCS环境的测试是在同一个硬件平台上完成. 四核超线程CPU,32G内存,Hyper-V平台: 一块专用的7200转SATA 3硬盘(带64M缓存),用户存放Windows 7虚拟机的写缓存: Windows 7 X64虚拟机配置:2 vCPU,2.5G内存: PVS 7.1标准镜像,RAM Cache设置为256MB(PVS在单独的主机上): 用户

PVS让存储颤抖,系列博文之四:PVS的写缓存新技术之XenApp方式实测篇

XenApp运行环境 XenApp 6.5运行在Windows 2008 R2上 和运行VDI的测试类似,XenApp的测试方式如出一辙.LoginVSI还是设置为中等负荷,使用同样的用户帐号设置,也是同样的用户配置文件设置.不过用户配置文件我们使用的是优化了的配置文件管理.另外,XenApp虚拟机一般来说数量较少而内存较大,所以我们侧视了几种Cache in RAM with Hard Disk Overflow的大小,包括1GB.3GB以及12GB的内存,测试结果在下面. XenApp 6.

PVS让存储颤抖,系列博文之五:PVS的写缓存新技术之总结篇

总结和参数推荐 从上面大量的测试结果中我们可以看出来,新的PVS的写缓存技术对于存储读写显著减少可以大量消除你去购买昂贵的SAN 存储的必要性,无论你是用于XenApp还是池化桌面都是完全适用.PVS的这个特性产生的原因其中之一就是因为它改变了I/O写入磁盘的模式.一个XenApp或者是一个VDI传统上都是发送大部分的4K大小的随机写操作到磁盘中,对于硬盘来说这是最吃力的大小,这也是为什么VDI方式对SAN产生压力的主要原因.当配置了Cache in RAM with Hard Disk Ove

面试挂在了 LRU 缓存算法设计上

好吧,有人可能觉得我标题党了,但我想告诉你们的是,前阵子面试确实挂在了 RLU 缓存算法的设计上了.当时做题的时候,自己想的太多了,感觉设计一个 LRU(Least recently used) 缓存算法,不会这么简单啊,于是理解错了题意(我也是服了,还能理解成这样,,,,),自己一波操作写了好多代码,后来卡住了,再去仔细看题,发现自己应该是理解错了,就是这么简单,设计一个 LRU 缓存算法. 不过这时时间就很紧了,按道理如果你真的对这个算法很熟,十分钟就能写出来了,但是,自己虽然理解 LRU

【58沈剑架构系列】互联网架构,如何进行容量设计?

一,需求缘起 互联网公司,这样的场景是否似曾相识: 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题: (1)机器能抗住么? (2)如果扛不住,需要加多少台机器? 场景二:系统设计阶段,技术老大杀过来,又问了两个问题: (1)数据库需要分库么? (2)如果需要分库,需要分几个库? 技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一.常见的容量评估包括数据量.并发量.带宽.CPU/MEM/DISK等,今天分享的内容,就以[并发量]为例,看看如何回答好这两个问题.

如何进行容量设计

一,需求缘起 互联网公司,这样的场景是否似曾相识: 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题: (1)机器能抗住么? (2)如果扛不住,需要加多少台机器? 场景二:系统设计阶段,技术老大杀过来,又问了两个问题: (1)数据库需要分库么? (2)如果需要分库,需要分几个库? 技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一.常见的容量评估包括数据量.并发量.带宽.CPU/MEM/DISK等. 二,容量评估的步骤与方法 [步骤一:评估总访问量] 如何知道

MyBatis的二级缓存的设计原理

MyBatis的二级缓存是Application级别的缓存,它可以提高对数据库查询的效率,以提高应用的性能.本文将全面分析MyBatis的二级缓存的设计原理. 1.MyBatis的缓存机制整体设计以及二级缓存的工作模式 如上图所示,当开一个会话时,一个 SqlSession对象会使用一个 Executor对象来完成会话操作, MyBatis的二级缓存机制的关键就是对这个 Executor对象做文章.如果用户配置了" cacheEnabled=true",那么 MyBatis在为 Sql