桌面虚拟化项目的前期规划和测算

桌面虚拟化容量测算：当我们考虑构建一个桌面虚拟化方案前，一个很关键的步骤是做桌面虚拟化容量测算。准确科学的容量估算方法，是整个桌面虚拟化项目后期的架构规划、以及设备选型的关键依据。今天这篇文章就将重点介绍桌面虚拟化容量测算的方法。首先、做桌面虚拟化容量测算，按照国际通行标准，我们要针对桌面虚拟化的目标用户群体进行分类，以下是国际通用的三种用户类型分类：

	常用应用数量	关键应用打开时间	并行打开的应用	媒体应用	典型场景
任务型	7	3-8秒	1个	很少	呼叫中心、生产线、医生和护士、数据录入
办公型	12	2-8秒	2-6个	15%	秘书、业务支持
知识型	20	2-8秒	3-8个	20%	财务、市场、工程师

从中我们可以看到，任务型一般是我们经常碰到的柜面、呼叫中心、前台等应用场景，使用的应用比较简单，以数据输入和输出为主。而办公型是以office等办公应用为主体的用户群体，相对任务的负载量比任务型高，并且视频使用体验有限。而知识型则是比较复杂的复杂的用户群体，除了基本的办公类应用以外，还经常会使用一些专用的、负载比较大的专有类应用。桌面虚拟化容量测算实际上就是要模拟当我们把大量个人PC操作系统中的运算、存储、传输需求统一到一个桌面虚拟化架构后，如何进行科学的统计原来分散在个人PC中的运算、存储、传输需求，并做到精确定量。这当然不是简单的按照原来个人PC的配置，简单的乘以人数就可以做到的，而是要参照一下评估方法。计算前的关键假设：I .用户使用win7系统II.用户使用专用虚拟机模式III.存储使用RAID 10模式之所以进行上述假设，是因为如果换用其它操作系统、换用共享虚拟机模式、或者换用存储模式我的文章要2的3次方种或者更多版本。篇幅所限给大家推荐一种最常用的假设，建议初学者就不要过多考虑了。首先，我们针对集中后的运算总量进行估算（cpu GHz需求量）：从下表可以看出，按照不同的用户的类型，CPU的平均使用频率从0.2GHz（任务型）、0.5Ghz（办公型）、到0.8Ghz（知识型）不同。以上三个参数是在惠普实验室大量试验后做的数据统计。我们可以发现，我们平时采购和应用个人PC时、为了应付一些峰值应用，如使用复杂的软件、播放搞清流媒体、以及进行一些大型游戏。我们的采购标准默认会设定为峰值主频需求，这也就是今天大家甚至会使用双核、甚至多核心CPU个人PC的原因。但是桌面虚拟化方案不同，因为是大量的用户集中在一起使用动态分配的池化系统资源，所以我们不必担心某个用户在某一个时间点使用某些峰值应用，因为在一个大的池化CPU群中，这样的一点峰值消耗平摊到一个群中就可以忽略不计了，所以我们只需要统计清楚用户平均负载就好。

项目	用户数	需求/用户	总计	虚拟化损耗	总计
CPU (单位 GHz)	50	0.5	25	4	29
备注	N/A	使用WIN7系统 1.任务型 0.2GHZ 2.办公型 0.5GHZ 3.知识型 0.8GHZ		虚拟桌面中，运行VM Tools，远程连接协议等需要额外消耗15%CPU资源

从表格的模拟运算中我们可以看出，当我们界定好用户类型后，依照惠普试验室提供的参考用户类型CPU消耗数字，我们就可以乘出总体的CPU消耗。并且考虑虚拟化本身的损耗后，我们就可以推导出整体CPU的消耗量。接下来、相信大家可以猜到，我们要对整体内存需求量进行测算了：同样按照用户类型不同，平均消耗的内存也是不同的。按照你的用户类型，匹配相应的内存需求。乘以你的用户数量，就可以得出整体内存的消耗数量了。另外，和CPU需求一样。也要同时考虑虚拟化本身的损耗，增加这个部分后就可以得出总体的内存需求量了。

项目	用户数	需求/用户	总计	虚拟化损耗	总计
内存(单位G)	50	2	100	6	106
备注	N/A	使用WIN7系统： 1.任务型1.5G 2.办公型2.0G 3.知识型2.5G		为虚拟框架缓冲区和各种虚拟化数据结构预留的空间，以每用户120M计算

比较有经验的个人PC使用者可能会发现一个不同，就是和CPU相比，虚拟化方案的单体内存使用量是没有那么显著下降的。个人CPU我们采购了双核、甚至四核2.xG主频的CPU，整体上我们其实采购了8GHz-10GHz的运算能力，但是我们平时平均用到的只是其中5%-10%. 而内存我们一般今天标配得2G 或4G内存条，则往往能平均使用其中40%-75%。其实这就是我们今天使用个人PC的现状，大量的CPU闲置和相对少量的内存闲置… 而桌面虚拟化方案恰恰可以通过集中资源和池化供应做到在满足个性需求、峰值应用需求前提下，整体降低CPU的消耗量，部分减少内存的需求量。至少它是一种对地球资源的合理节约对吗。第三步，我们就要对整体桌面虚拟化的存储进行估算了 存储估算时关键要计算三个结果、第一容量、第二IOPS、第三并发启动带宽，接下来我们依次介绍。这三个数值缺一不可，详情下面分析。A.容量估算这里我们其实就并不那么科学了，因为容量的规划完全是取决于用户的需求的，我们提供的三种标准是国际上比较流行的容量规划标准作为参考。一个经验是一般任务型需求<办公型需求<知识型需求。但是比较重要的是，我们需要把个人操作系统的容量空间测算和个人数据的容量测算单独列开。这样当未来考虑存储设备时，我们就很清楚总体用户的操作系统空间需求和总体用户的个人数据空间需求，并且可以按照两者不同的需求匹配不同的硬盘组类型。一般来说系统盘集群因为交互时IO需求较高，可以考虑用更快的SSD盘（预算容许的前提下），而个人数据盘因为交互时的IO需求相对较低，可以考虑用一般的SAS硬盘甚至sata硬盘。

项目	用户数	需求/用户系统（G）	需求/用户数据（G）	磁盘容量需求(G)	备份空间需求(G)	总存储容量(G)
容量规划（GB）	50	20	40	3000	3,000	12,000
备注	N/A	使用WIN7系统 1.任务型 10G 2.办公型 20G 3.知识型 30G	1.任务型 20G 2.办公型 40G 3.知识型 60G	假设为每个用户使用专用虚拟机	常规的桌面备份，只留2-3个备份副本，约需与原始存储空间相同的空间。	RAID10会消耗两倍存储容量

需要注意的是，在上述表格中我们采用的桌面虚拟化模型是专有虚拟机模式，即每个用户一个完全独立并个性化的操作系统。坏处是这样整体消耗是比较高的（50个用户就需要1000G的总体系统空间），好处是每个人完全掌控自己的操作系统，使用体验最接近个人PC. 其实在桌面虚拟化方案中还有一种所谓的共享虚拟机模式，即一组用户使用的是一个完全相同操作的系统，只是登陆时会加载不同的个人配置文件。这种方式可以大大降低操作系统总体空间需求（如50个用户依然还是20G操作系统空间），坏处是每个人不能完全掌控自己的操作系统，相当于某种公共计算机。应用的安装和删除掌握在管理员手中，个性化配置掌握在个人用户自己手中。另外、在整体容量估计中，我们考虑到了对于每个用户的系统和用户数据做了一次全备份。这样的好处是可以在某些系统崩溃或文件丢失的情况下，用户依然可以最大化和恢复生产力。我们多少人有个人PC数据丢失后无法恢复的痛楚。所以这一般也是桌面虚拟化作为更高级方案的一个标配，我们在容量测算中自然要考虑。另外、在桌面虚拟化方案中，因为需要同时保证数据的可靠性和并发读写需求，最好的选择就是RAID10模式的盘阵构成，这样会自动消耗1倍的硬盘空间用于形成RAID…消耗很大但是只能支付。这样综合几点，回到上面的计算，50个用户总容量需求3T ，再备份一次3T。再考虑RAID10就需要(3+3)*2=12T 。容量计算完毕 B. IOPS估算：首先快速介绍一下IOPS，IOPS就是英文Input / output per second .就是每秒读写操作次数的简称。计算这个参数的意义在于当我们把几十甚至几百用户的硬盘容量集中到一个存储中的时候，也就把每个用户在个人PC上所有的硬盘IO操作集中到一个存储设备上，考虑并发的IO容量就非常关键了。上面总体存储容量的部分可以理解为一个人的肠胃，而IOPS就是它的牙口。胃口大牙口不好也会吃不下去对吧… (存储瓶颈风险)。所以任何一个桌面虚拟化的评估都一定要评估整体IOPS消耗。从下表可以看出，不同类型的用户同样有不同的平均IOPS需求，如办公型单用户的IOPS在10左右，就是一个办公型的用户每秒中会有10次硬盘的读写操作。那么简单的乘法后可以推出50个用户就需要500个IOPS… 抱歉、这个计算还没结束，因为毕竟个人的硬盘的读写方式和存储的读写方式还有本质的不同的，在存储上我们往往为了保证更高的数据安全性会采用成熟的RAID方案把单个盘编成盘阵。RAID10是最适合的桌面虚拟化RAID方式，它的读写方式是:1个读IOPS就是1个读IOPS, 而存储的cache会一般命中30%，就是1个读=0.7个读IOPS1个写IOPS在RAID10盘阵中会产生1个读+1个写IOPS =2个IOPS.

项目	用户数	需求/用户	合计	读IO	写IO	总IOPS消耗 RAID10
IOPS	50	10	500	350	150	545
备注	N/A	使用WIN7系统 1.任务型 6 2.办公型 10 3.知识型 15		用户磁盘读写中一般有70%的读	用户磁盘读写中一般有30%的写	配置为RAID10时，1个读操作产生1个IO操作,一个写操作实际会产生2个IO操作（1个读、1个写）.通常存储配有读Cache,命中率30%左右；容量升级可以依次类推

C. 并发加载的带宽需求：很多的桌面虚拟化方案估算忽略了这个部分，在一种典型场景下一定需要考虑这个风险。我们在个人电脑上经常碰到的情况就是启动慢，我想你最常见的反应是痛斥自己的PC不给力，甚至对它动动粗。可是如果500个企业员工早上9点同时坐在办公作为等待超常的系统登陆时间，并痛斥公司的桌面虚拟化方案启动慢，那我想压力就不是一星半点了。这个对于任何一个桌面虚拟化方案设计者都不可以掉以轻心，一定要做到心里有数。知道如何科学评估这一潜在风险，并在设计中屏蔽掉可是非常关键的。要典型场景分析：在一个早上9点统一上班的企业，假设有500名用户同时登陆个人的虚拟机，每个虚拟机处在待机状态（注意不是关机状态）。排除情况1：如果没有统一定点上班习惯的场景可以直接省去这个部分的计算，因为不是并发登陆就不会产生集中的数据加载带宽峰值。排除情况2：如果用户使用习惯是每天不是登陆和注销、而是直接断开远程桌面连接，恭喜你也可以忽略这个部分的计算。更糟情况：如果每个虚拟机都处于关机状态，上班时同时启动虚拟机（很极端，一般不会这样用）请按照2倍下表的带宽需求。

项目	用户数	需求/用户（G）	需求/总用户（G）	带宽需求 GB/秒	带宽需求 Gb/秒
存储带宽规划（GB）	50	1	50	0.833333333	7
存储带宽主要分析所有虚拟机同时加载个人配置文件和个人桌面文件所产生的网络带宽需求	N/A	使用WIN7系统： 1.任务型0.5G 2.办公型1.0G 3.知识型2.0G	两个假设 1.按照加载个人配置文件、个人桌面文件加载进行计算 2.按照60秒平均加载速度计算

如上表，我们假设每个办公型用户基本上加载的个人配置文件和桌面文件数据量为1G. 那50个人就是50GB. 假设用户可以接受的系统登陆时间心理上限为60秒。这样存储-网络-服务器通路就需要在60秒内传输完50GB的数据到服务器内。这个三段式链路的带宽就需要0.83GB/秒 =7Gb/秒。注意啊，我们配置桌面虚拟化方案时单个服务器承载的用户数、单个存储承载的用户数、和网络交换机的端口数是一个设计中很需要注意的问题。无论是设计者还是使用者，都可以通过上面算出的带宽需求自己检查一下是否存在带宽瓶颈，并验证桌面虚拟化价格和设备选型是否合理. 举例：两个机架服务器DL380、每个承载50个用户 2个10Gb 并发登陆带宽需求为 7Gb/秒/服务器一个24口万兆交换机一个P4530存储、承载100个用户 4 个 1 GbE iSCSI 端口并发登陆带宽需求为14Gb/秒/存储看到问题了吗，机架服务器网络端口没有瓶颈、交换机没有瓶颈，而存储的端口只有需求带宽的1/3不到. 这样配置的下场就是，准备每个用户60秒*3=180秒以上的登陆时间吧… 总结：根据以上的分块分析，我们依次对总体CPU 、内存、存储容量、存储IOPS、并发登陆网络带宽5大容量参数进行了测算。这五大参数将是我们后期进行桌面虚拟化方案规划的需求总览，它将定量的指导我们进行合理的服务器规划和选型、存储规划和选型、和带宽规划和选型（服务器到交换机到存储端口规划）。

项目	用户数	需求/用户	总计	虚拟化损耗	总计	加权总计
CPU (单位 GHz)	50	0.5	25	4	29
内存(单位G)	50	2	100	6	106
IOPS	50	10	500	350	150	545
容量规划（GB）	50	20	40	3000	3,000	12,000
存储带宽规划（GB）	50	1	50	0.833333333	7

再次重申、用户类型定义是惠普依据国际标准定义的，里面的计算参数都是依据批量试验结果得来的，当然这不代表它是唯一标准，但是相信是一个适合大多数情况的基准数据，有相当的借鉴意义。后记：容量测算部分就全部介绍完了，后面还有一篇文章重点介绍桌面虚拟化的方案规划和设备选型。其中引用的数据基本出自本章。建议读者在阅读后续文章时两相认证，加强理解。

项目	用户数	需求/用户	总计	虚拟化损耗	总计	加权总计
CPU (单位 GHz)	300	0.5	150	23	173
内存(单位G)	300	2	600	36	636G
IOPS	300	10	3000	2100	900	3270
容量规划（GB）	300	20	40	18000	18000	72T
存储带宽规划（GB）	300	1	300	5	40Gbps

300*0.5=150 150*15%=22.5 150+23=173GHz300*2=600 300*0.12=36 600+36=636G300*10=3000 70%=2100 30%=900 2100*0.7=1470 1470+900+900=3270300*(20+40)=18000 18000+18000+18000+18000=72T300*1=300 300/60=5 5*8=40Gbps上述文章虽然说明的非常详细，但是我还是感觉数据被估计的偏小，应该适当增大。