NetApp 技术报告NetApp 和 VMware View 5,000 席位性能报告.docx

《NetApp 技术报告NetApp 和 VMware View 5,000 席位性能报告.docx》由会员分享，可在线阅读，更多相关《NetApp 技术报告NetApp 和 VMware View 5,000 席位性能报告.docx（56页珍藏版）》请在三一文库上搜索。

1、NetApp技术报告NetApp和VMwareView5,000席位性能报告NetApp公司ChadMorgensternsChrisGebhardt2011年8月ITR-3949摘要2010年，NetApp.VMWareaCisco、Fujitsu和WySesl联合发布了一个50,000席位VDl参考架构，向客户提供设计和架构方面的概述。该报告详细分析了一个5,000席位“桌面池”(POD)(50,000席位架构的构建块)的性能，其中通过模拟场景展示了一个桌面在两周内的情形。这样做是为了说明工作负载特征每天都可能发生改变，因此对架构的影响也会有所不同。调整VDI存储大小不仅是为了稳定状态，还

2、是为了应对各种各样的工作负载。目录1 内容提要52 环境113测试、方法和工具112.1 场景-112.2 创建测试132.3 启动测试132.4 登录后执行工作负裁测试144最终用户体验165详细测试结果175.1 创建进程185.2 初始登录195.3 星期二早晨登录265.4 重新启动325.5 星期一早展登录365.6 稳定状态425.7 观察结果和经验总结436附录446.1 SSD和SATA-446.2 应用程序工作负裁467参考528致谢52表格目录表1）创建场景。6表2）初始登录场景。6表3）“星期二早晨”或典型登录场景。6表4）启动场景。7表5）“星期一早晨”或配置文件加载登

3、录场景。7表6）稳定状态场景7表7）AcmeCorporation日历。13表8）初始登录的用户体验（以秒为单位）。20表9）初始登录用户体验（“好”、一股和“差”登录时间的百分比）。20表10）初始登录期间DataONTAP8.0.1与8.1的对比结果。21表11）初始登录时的I/O并发数、速率以及读取和写入操作大小。25表12）星期二早晨登录的用户体验（以秒为单位）。26表13）星期二早晨登录用户体验（“好”、”一般”和“差”登录时间的百分比）。27表14）星期二早晨登录期间DataONTAP8.0.1与8.1的对比结果。27表15）星期二早晨登录时的I/O并发数、速率以及读取和写入操作大

4、小。31表16）重新启动期间DataONTAP8.0.1与8.1的对比结果。33表17）星期一早晨登录的用户体验（以秒为单位）。37表18）星期一早晨登录的用户体验（”好工”一般”和“差”登录时间的百分比）。37表19）星期一早晨登录期间DataONTAP8.0.1与8.1的对比结果。37表20）星期一早晨登录时的I/O并发数、速率以及读取和写入操作大小。41插图目录图1）每秒读取和写入操作数。8图2）读取和写入吞吐量。8图3）启动时的读取操作细分。9图4）初始登录时的读取操作细分。9图5）稳定状态时的读取操作细分。10图6）“半POD”架构。11图7）RAWC屏幕，显示登录后执行工作负载场景

5、15图8）Stratusphere（图片由LiquidwareLabs提供）o16图9）显示机器体验指标的VDIUX配置文件屏幕。17图10）显示I/O体验指标的VDIUX配置文件屏幕。17图W）克隆虚拟桌面各阶段花费时间细分。19图12）初始登录时的读取和写入吞吐量。21图13）初始登录时的每秒读取和写入操作数。22图14）初始登录中的读取/写入协议延迟。22图15）初始登录时的读取和写入延迟。23图16）初始登录时的CPU利用率。23图17）初始登录时的读取操作细分。24图18）初始登录时的读取和写入操作大小。25图19）星期二早晨登录的读取和写入吞吐量。28图20）星期二早晨登录时的每

6、秒读取和写入操作数。28图21）星期二早晨登录的读取和写入协议延迟。29图22）星期二早晨登录的读取和写入延迟。29图23）星期二早晨登录的CPU利用率。30图24）星期二早晨登录的读取操作细分。30图25）星期二早晨登录的读取和写入操作大小。32图26）启动时的读取和写入吞吐量。33图27）启动时的每秒读取和写入操作数。34图28）启动时的读取和写入协议延迟。34图29）启动期间的CPU利用率。35图30）启动时的读取操作细分。35图31）星期一早晨登录的读取和写入吞吐量。38图32）星期一早晨登录的每秒读取和写入操作数。38图33）星期一早晨登录的读取和写入延迟（以秒为单位）。39图34）

7、星期一早晨登录的来宾操作系统读取和写入延迟。39图35）星期一早晨登录的CPU利用率。40图36）星期一早晨登录的读取操作细分。40图37）星期一早晨登录的读取和写入操作大小。42图38）滴水工作负载（每秒操作数）43图39）滴水工作负载（每秒MB）44图40）显示“滴水效应”工作负载的屏幕。44图41）启动时间对比（按驱动器类型）。45图42）使用SATA驱动器的用户的初始登录体验。45图43）使用SATA驱动器的用户在星期一早晨的体验。46图44）首次打开和关闭MicrosoftWord时的读取操作数。47图45）首次打开和关闭MicrosoftWord时的写入操作数。47图46）后续打开

8、和关闭MicrosoftWord时的读取操作数。48图47）后续打开和关闭MicrosoftWord时的写入操作数。48图48）首次打开WindowsMediaPlayer并播放影片时的读取操作数。49图49）首次打开WindowsMediaPlayer并播放影片时的写入操作数。49图50）后续打开WindowsMediaPlayer并播放影片时的读取操作数。50图51）后续打开WindowsMediaPlayer并播放影片时的写入操作数。50图52）保存Excel工作簿时的读取操作数。51图53）保存Excel工作簿时的写入操作数。511内容提要2010年8月，NetA即联合若干合作伙伴共同

9、发布了一份白皮书，其中介绍了如何部署使用NetApp存储、CiscoUnifiedComputingSystem-(CiscoUCS-)sCiscoNexus.VMware软件和Fujitsu服务器的50,000席位虚拟桌面基础架构(VDI)环境。这份初始白皮书仅关注每个合作伙伴为支持此部署而提供的高级别的架构设计和技术详情。根据在虚拟化基础架构中部署5,000席位的硬件和软件需求，最初需要使用NetAppFAS3170存储控制器，以及界定好的模块化存储单元和服务器(称为“桌面池”POD)0初始白皮书将POD定义如下： 60个ESX4.1主机(CiSCOUCS或FujitsuPRIMERGY)

10、 1个FAS3170A高可用性(HA)集群 96个15KRPM光纤通道驱动器 2个512GB闪存卡 2个VMWarevCenter-Server 3个运行PC-over-IP(PCoIP)连接协议的VMwareView-ConnectionServer 5,000个MicrosoftWindows7虚拟桌面虚拟机(VM)发布初始白皮书后不久，NetApp便更新了其中端存储产品，用FAS3270存储系统取代初始白皮书中使用的FAS3170存储系统，提高了容量和性能。因此，在本技术报告所述的测试中，我们使用FAS3270存储系统而不是初始白皮书中所用的FAS3170(因为FAS3270显著提升了解

11、决方案的性能和可扩展性)。除此之外，后续的早期测试也表明：要想能够有效支持5,000个VDI桌面，需要我们再添加30台服务器，以保证测试期间有充足的内存资源。因此，我们现在将POD定义如下： 90个ESX4.1服务器：配备2个具有超线程功能的四核心NehalemCPU的FujitsuPRIMERGYRX200-S548GB主内存 1个FAS3270AHA集群 96个15KRPM光纤通道驱动器 2个512GB闪存模块 2个VMWarevCenterServer 3个运行PC-over-IP(PCoIP)连接协议的VMwareViewConnectionServer 5,000个Microsoft

12、Windows7虚拟桌面VM根据这一新定义，每个NetAppFAS3270控制器支持45个ESX服务器和2,500个Windows7永久虚拟桌面。由于创建一个完整的POD需要满足众多硬件要求，因此我们决定对这些后续测试作出限制：使用相当于二分之一个POD所要求的上述硬件，或者使用由两个FAS3270存储控制器中的一个提供服务的2,500个虚拟桌面。由于每个FAS3270存储控制器实际上独立服务于2,500个虚拟桌面，因此针对2,500个虚拟桌面衡量得到的性能直接加倍，就能得到支持5,000个虚拟桌面的完整POD的性能。在这些测试中，我们使用VMwareView4.5和VMwarevSphere

13、4.1部署由2,500个虚拟桌面组成的场景。除此之外，我们还使用VMwareReferenceArchitectureWorkloadCode(RAWC)工具生成VDl环境中的典型工作负载。我们针对最新的公开发布(GA)版本(DataoNTAPW.0.1)和DataONTAP8.1进行测试C之所以选择使用DataONTAP8.1,是因为它能进一步提升NetApp虚拟存储分层(VST)功能的性能，同时减少所需的磁盘轴数量.借助VST1客户不仅可以从NetApp存储效率中受益，而且还可以显著提高I/O性能。DataONTAP操作系统本身内置有VST1并且通过利用NetApp主存储重复数据删除和文件

14、/卷FIexCIone等块共享技术应用VST1可以减少所需的缓存量并消除重复磁盘读取。对于任意重复块，仅将一个实例读入缓存，因而所需的缓存少于传统存储解决方案。由于使用节省空间的NetApp克隆技术，VMwareView的实施最初可节省高达99%的空间，这意味着更高的缓存重复数据删除率和高缓存命中率。在处理并发系统启动（即启动风暴”）和登录成百上千个虚拟桌面系统（可能导致传统旧式存储系统超负荷工作）方面，VST特别有效。与以前版本的DataONTAP相比，8.1版本可以更加高效地共享主内存中经过重复数据删除的块。这样，存储控制器的主内存就可以处理更大型的工作集，从而加快访问速度并减少占用CPU

15、o通过测试，我们确认了用户在正常办公期间访问其桌面时，VDI工作负载远远超出了稳定状态下的工作负载。了解该阶段的特征非常重要，但是在某些情况下重新启动、登录、创建配置文件和操作大量虚拟桌面也会给支持整个VDI环境的存储带来沉重压力。如果没能理解和计划这些工作负载，会对最终用户体验和项目成功产生严重的负面影响。在本报告接下来的内容中，我们将从AcmeCorporation这个虚构公司的视角查看一些不同的VDI常见场景。Acme已经借助NetApp存储部署了2,500席位VDI环境，Acme希望了解在一个典型工作周内可能遇到的不同类型的工作负载（极具代表性的用户大量登录、启动和停止应用程序，以及借

16、助为其提供的应用程序执行日常任务）。另外，曰常维护有时会要求关闭所有虚拟桌面，然后又需要同时打开并启动大量VMo在表1到表6中，这些场景及结果都根据用户体验进行了衡量，并且从一个较高的水平进行了定义。在整个报告中，用户体验均由LiquidwareLabsStratusphereUX使用加权算法确定是不是“好启动场景和创建场景的用户体验用启动和创建所用的时间来衡量。请注意，测试中选择的是VMware建议的应用程序混合，这些应用程序产生的工作负载为：每秒12次输入/输出操作（IOPS）/桌面（即预期的“有经验用户”的工作负载）。表1）创建场景“|测试|成功的主要衡量标准|用户体验2,500个用户在

17、半个小时之内首次登录并且开始工作。该登录触发创建2,500份配彳阿端始登录场景“由LiqUidWareLabSUX衡量的用户DataONTAP8.0.1:62%的用户获得体验“好”用户体验，38%的用户获得“一般”用户体验。DataONTAP8.1:97%的用户获得好”用户体验，3%的用户获得“一般”用户体验。测试|成功的主要衡量标准|用户体验2,500个用户登录以前访问过，并且之后未重新启动的VMo登录后，用户开始工作。由LiquidwareLabsUX衡量的用户体验 DataONTAP8.0.1100%的用户获得好用户体验。 DataONTAP8.1:100%的用户获得“好”用户体验。测试

18、成功的主要衡量标准|创建时间了包健苇胸郢冕濡哮哽开始创建到准备好第一次启动所花从克隆进程开始到准备好启动2,500个费的时间。费的时间VM共花费3个小时测试成功的主要衡量标准|用户体验2,500个用户登录之前访问过，之后又重新启动的VMo登录后，用户开始工作。无论是配置文件还是应用程序DLL都必须从磁盘加载.由LiquidwareLabsUX衡量的用户体验得“好”用户体蛤。DataONTAP8.0.1:100%的用户获DataONTAP8.1:100%的用户获得“好”用户体验。测试|成功的主要衡量标准|用户体验2,500个用户已经完成登录并且打开和关闭所有应用程序至少一次，但是他们继续自己当

19、天的工作。由LiquidwareLabsUX衡量的用户体验 DataONTAP8.0.1:100%的用户获得“好”用户体验。 DataONTAP8.1:100%的用户获得“好”用户体验，测试|成功的主要衡量标准|启动时间VMwarevCenter控制2,500启动所用的总时间DataONTAP8.0.1:36分钟个虚拟雅靴蜜酬吩浮。席位性能报告Dataqntap81.21分钟是配置文件还是应用程序DLL都不必从磁盘加载C测试|成功的主要衡量标准|用户体验2,500个用户在半个小时之内首次登录并且开始工作。该登录触发创建2,500份配置文件。员5）“星期一早晨”或配置文件加由Liquidware

20、LabsUX衡量的用户DataONTAP8.0.1:62%的用户获得体验“好”用户体验，38%的用户获得“一般用户体验。DataONTAP8.1:97%的用户获得“好”用户体验，3%的用户获得载登录场景。“一般用户体验。测试成功的主要衡量标准|用户体验2,500个用户登录以前访问过，并且之后未重新启动的VM0登录后，用户开始工作。由LiqUidWareLabsUX衡量的用户体验DataONTAP8.0.1:100%的用户获得用户体蛤。DataONTAP8.1:100%的用户获得“好”用户体验。测试|成功的主要衡量标准|创建时间专N）Q复翻并衡量花从开始创建到准备好第一次启动所花从克隆进程开始到

21、准备好启动2,500个荷产心费的时间VM共花费3个小时测试|成功的主要衡量标准|用户体验表4）启动场景“由LiquidwareLabsUX衡量的用户DataONTAP8.0.1:100%的用户获体验2,500个用户登录之前访问 过，之后又重新启动的VMo 登录后，用户开始工作。无 论是配置文件还是应用程序得“好”用户体验。 Data ONTAP 8.1 : 100% 的用户获得“好”用户体验。景以及初始登成功的主事衡强标准公琛作镂次均输 附喇单团序至少一次，但是他们继续瞿霰禹工每个场景的特征操作，IOPS计国广体验:的工作负载的读取和写景以及棉足状至电什献技国里性鳗下茬负载要多于稳定状态场景。

22、均会对最终用户及其整体体验产生景复 fR1 部件标T；+七I卜维D 米的耳得好用户体验。龈常糟域臧焉茂斌，送前的主要衡量揉淮 VIliU口y 土 H匕习匕二31 刃狂禾15分钟才能使用桌面。:频限解这些丽询颜嬲艰例时基础架构和最绛哪哈骗绅、1瓢将黏响项目的成功。I鬻魔踪同类别的工作负载体现出的特征有时会与常曲的WBPTl作负载苏嘤（小块 需涉例如，我们发现了以下情况：2,5勤浦镭藕访问 过，之后又重新启动的VMo 登瓣U辨的始小诡隹颜4由 Liquidware Labs UX 衡量的用户 Data ONTAP 8.0.1 : 100% 的用户获体验得“好”用户体验。义VDI环境的存储大KB以下

23、到1024 KB.同时随机读取和函序期存魏筋弱懒户获得工作负载确实会生成较小的随机工作负载,疸篡翻卷量生成较大的随机操作E杰由（和鞠踊寻 笛礴扬扁i蘸决香墓匿舲它们遍布的即a胸甲帼卧的崩殿环 墉瞄娜里叫瞒解I某无吃周发生（以,生命周期中的一夫格哦睡祠户体套最初的50,000 使用顶尖技术构建的。我们已对原始H因此对新版本也进行了测试。尽管原始测试的结匕出于本报告的目的，该架梅伐赛我上通号金牌”配置：之所以称“是因为该特定配置能 Data ONTAP 8.0.1 : 36 分钟 Data ONTAP 8.1 : 21 分钟VMwarevCenter控制2,500启动所用的总时间个虚拟桌面批量启动

24、无论是配置刷幅部病35,000席位性能报告DLL都不必从磁盘加载。50,00040,00030,00020,00010,0000NFS读取痴作散/秒NFS写入操作数/秒后动Data ONTAP 8.1.0Lo 6 QO 卜 99 - Z 6 ZSNOCL T-S 寸 6ClC600Z9S 寸 S(MLo 68IDLZC 6GO9Z8r69ZC0 寸 69InOoOmIncOLSgCoLTfg6 十寸 96LLZCMcMcimeoSS 寸寸 QbiDgirg。68卜96寸(*)0|。682910寸801。6829 寸 ZLg 6C0Zl96E9。寸 OOZ 9(0b OOZ 96 COZ CM

25、 寸16-寸 96 LG 98 LeScOOg InZOe 寸1 6 LT-LLeMCSlZemC1OS 桶寸寸寸 tgsSsS读取（MB/秒） 一写入（MB/秒）够带来最佳用户体验、最高吞吐量和最低延迟，而且它达到以上目标所需的每次IO操作成本最低。这些图表从存储控制器的角度展示吞吐量和IOPSo请观察从每秒操作数和吞吐量角度衡量的各工作负载阶段之间的明确界限。请注意，在启动场景中，占主导地位的是相对大量的读取操作，这些操作使吞吐量超过了每秒700MB的峰值。另外，初始登录场景中读取/写入的操作数较为均衡，读取操作使峰值吞吐量超过了每秒400MB。最后，用户启动自己的VM并且登录桌面之后，相

26、较于启动场景和登录场景，稳定状态工作负载在IOPS和吞吐量方面均出现大幅下滑。另请注意，如图1和图2所示，进入稳定状态之后，读取/写入操作的工作负载分配比会变为20:80,但是，吞吐量分配会随着与初始读取活动相关的更多工作（例如加载应用程序库和打开/读取文件）缓存在VM来宾操作系统（OS）中而渐趋平衡。图1）每秒读取和写入操作数。每秒读取和月入操作数虚拟桌面环境生命周期中的一天启动/初始登录/稳定状态（时间以秒为就位）图2）读取和写入吞吐量。读取和写入吞吐量虚拟桌面环境生命周期中的一天启动/初始登录/稳定状态（时闾以秒为破位）DataONTAP8.1.0图3到图5中的图表突出显示了存储控制器所

27、报告的操作大小。请注意，工作负载分配及其数量会随工作负载场景、操作大小以及顺序混合的改变而改变。在这些工作负载中保持不变的是随机/顺序读取操作百分比，这个数字一直保持较为均衡的状态。图3）启动时的读取操作细分。启动读取操作的分操作大小和操作Ie序45% 总读取操作百分比40%10%4%4%8%1%1%7%13%0%0%11%IWl序读取操作占读取操作的百分比15%6%2%2%5%0%0%4%8%0%0%10%随机读取操作占读取掾作的百分比24%3%1%2%2%0%0%3%5%0%0%1%图4）初始登录时的读取操作细分。初始金录（配置文件加栽登录）读取操作细分操作大小和操作咂序总读取操作百分比2

28、3%4%3%8%17%1%0%19%22%0%0%1%顺序读取操作占读取操作的百分比9%2%1%5%10%1%0%11%10%0%0%1%随机读取操作占读取操作的百分比14%2%2%3%7%1%1%8%12%0%0%0%图5）稳定状态时的读取操作细分。稳定状态读取攥作细分操作大小和操作序ii6KDe* *M 修总读取操作百分比26%8%4%10%9%1%2%17%18%0%0%4%喉杼读取探作占读取操作的百分比11%3%2%7%4%0%0%12%6%0%0%4%随机读取操作占读取操作的百分比15%5%2%4%5%1%1%4%12%0%0%1%2环境NetApp在由2,500个虚拟桌面构成的“半

29、POD”单元中执行测试，这些虚拟桌面分布于45台ESX4.1服务器中，拥有一个NetAppHA对控制器。由一个VMwarevCenterVM管理整个PODo图6)“半POD”架构。VMwareView4.5HVMwareView4.5个连接服务器(2500个桌面)HA/DRS集群HA/DRS集群HA/DRS集群,500个VMvCenterM（45个ESX主机）使用由两个连接代理和10个池组成的VMwareView4.5连接代理池，将虚拟桌面注册为专用桌面。每个池均使用默认设置，包括PCoIP连接协议。为了创建在测试中使用的2,500个VM1我们使用64位Windows7作为来宾操作系统创建了黄

30、金级主映像VM1并且应用了面向WindOWS7的VMWareVieW优化指南中定义的一系列优化以及VMwareVieW管理员指南中建议的优化。然后，我们使用NetAppRapidCloneUtility(RCU)克隆2,500个VMvCenter负责管理VM启动操作；登录和虚拟桌面工作负载由VMWareDesktopRAWC发起。所有测试均使用的是NetAPPFAS3270,但是测试了包括固态驱动器(SSD),串行高级技术连接(SerialAdvancedTechnologyAttachment,SATA)以及15KFC驱动器在内的多种驱动器。所有测试均使用DataONTAP8.0.1和8.1

31、执行。3测试、方法和工具该报告执行的测试代表客户期望体验的某些最常见工作负载。3.1 场景测试中的场景遵循AcmeCorporation中典型的双周曰历。初始登录场景在该场景中，2,500个用户在半个小时之内登录，因为是首次登录，所以测试存储控制器上的负载并衡量这种最差登录情况下的用户体验。（之所以认为这种情况最糟糕，是因为在所有测试场景中，该登录场景生成的负载最多。）这些登录伴随着创建配置文件，将默认的15MB配置文件复制到用户目录并且创建包含22MB文件的WindowsMail子目录。登录之后，每个虚拟桌面的用户均开始以下工作：配置Outlook、发送邮件、创建Word和Excel文件以及

32、查看PowerPoint和Acrobat文档。典型（“星期二早晨”）登录场景与初始登录场景一样，2,500个用户在半个小时之内登录。该场景模仿以下登录场景：用户登录之前已登录过并且登录后未进行硬重启的虚拟桌面，因此用户的应用程序库和配置文件保存在内存中,由于配置文件和应用程序库已经位于内存中，因此预计存储输入/输出（I/O）极少。在此测试中，用户像“初始登录”那样登录，但是由于之前已经对OUtIook进行配置，所以此时不会再对其进行配置。该测试的目的同样是衡量存储控制器上的负载以及用户体验。启动场景此测试选中VCenter内全部2,500个虚拟桌面、选择启动、监控结果并且计时。除测试用户体验之

33、外，该测试还衡量启动时间。像在其他场景中一样，还衡量存储控制器上的负载。配置文件加载（“星期一早晨”）登录场景与在其他登录场景中一样，2,500个用户在半个小时之内登录。该场景模仿以下登录场景：用户登录之前已经登录过的永久虚拟桌面（与其他用户一样），但是由于之后曾经对其硬重启，因此每台机器的内存已清除。内存清除之后，由于登录时需要从磁盘加载用户的配置文件，因而会生成存储0o在该测试中，用户所做的工作与在“星期二早晨”登录场景中做的工作相同。但是由于之前没有将应用程序库加载到内存中，这样就必须打开每个应用程序，因此该工作会生成先前场景中未出现的Oo与接受测试的其他登录场景一样，该测试的目的在于衡

34、量存储控制器上的负载以及用户体验。稳定状态场景稳定状态是指以下环境状态：所有用户已经完成登录并且打开了开展每日工作所必需的应用程序。在该场景中，每位用户执行的工作与在星期一早晨”和“星期二早晨”场景中登录后所做的工作完全一样。此处的目标与登录场景中的一样，即衡量用户体验和存储控制器负载。我们执行该测试是为了回应以下观点，即应该在“稳定状态”场景中而不是在登录或启动场景中衡量环境。因此我们执行该测试的目的仅仅是确定工作负载情况。创建场景在执行任何测试之前必须存在虚拟桌面。因此，NetApp使用自己的RCU克隆桌面。尽管该测试不是实际测试，但是我们仍然记录创建虚拟桌面（从开始到准备好启动）花费的时

35、间。为了让该测试结果与真实用户体验具有较强相关性，我们将测试案例映射到称为“AcmeVDI用户一周的工作”的场景中。例如，在该周的第一天，大量用户可能会同时登录他们的VM1为一周的工作进行准备.二该工作可能包括启动各种应用程序和执行不同级别的工作。为了清晰起见，本报告中所述的所有测试均指的是日历上的相应日期，就像管理员将系统排定为在这些日期执行这些事件一样。每个测试均可回溯到表7中介绍的日历。表7)ACmeCOrPOratiOn日历。周日1周一周二周三周四周五周六29部署2,500个桌面30上午8点2,500次登录+配置文件加载（30分钟）典型工作日31上午8点2,500次登录（30分钟）典型

36、工作日23456凌晨1点网络维护凌晨2点网络中断上午7点重新启动所有VM上午8点2,500次登录（30分钟）（启动后）7上午8点2,500次登录（30分钟）典型工作日910services.exe进程生成的。出于本报告的E 会生成少量但持蟠工祚负蠢因此大量VM “观察结果和经验总结”中对此进行详细介绍。尽可能分散地执行所有测试。我们的测试显示，即使没有任何额外工作负载发生，已启动的VM也会生成少量磁盘Oo我们发现该工作负载主要针对写入并且主要由系统生成，其次是由svchost.exe和魏图生臀耀瀛落整番花息为魏/野5节的所有测试均使用SSD.SATA和15KRPM光纤通道驱动器在DataONT

37、AP8.0.1上执行。考虑到每次IO操作成本的原因（内容提要中提及的原因），在DataONTAP8.1上执行的测试仅采用15KRPM光纤通道驱动器。为简便起见，通过SATA和SSD执行的测试的结果包括在该报告的附录而不是正文中。为了将环境恢复到基准状态，在各次测试之间要关闭所有虚拟桌面，并且将聚合恢复到测试之前的Snapshot.副本并且/或者刷新存储控制器的内存。以下章节将提供有关如何执行每个测试案例的详细信息。3.2 创建测试该测试的唯一目标是，记录使用NetApp虚拟存储控制台2.1以及配置和克隆功能来创建2,500个虚拟桌面所花费的时间。该测试向客户展示如何在相对较短的时间内，轻松快速

38、地部署或重新部署数千个虚拟桌面。例如，AcmeCorporation收购WidgetCorporation并且希望轻松整合新员工。以快速方式进行部署.这样公司便可以节省新员工入职的时间。在第二个案例中，客户对主模板进行了修补并且决定重新部署基础架构。3.3 启动测试启动测试的主要目标是确定在发生诸如中断、维护、修补等事件或任何其他需要快速启动的场景后，恢复环境所花费的时间。当VMware工具已在所有虚拟桌面上签入，并且存储控制器上的网络文件系统（NFS）操作数和CPU利用率都已下降到较低的稳定状态时，则视为启动测试已经完成。这些测试的次要目标如下： 获取工作负载概况，涉及读取/写入和随机/顺序

39、的混合情况以及它们各自的操作大小 根据资源利用率和响应时间，评估存储控制器在有大量VM同时启动时的性能 对比完全启动所有虚拟桌面所花费的总时间控制启动操作时，VCenter限制每次只能启动128台机器。各个虚拟桌面完成启动进程之后，它们就会在服务中心内被其他实体替换，以保持服务中心满载。注意：请记住，衡量每秒操作数和每秒MB时，均会使用128这一限制作为因数。此测试选中VCenter内的所有2,500个虚拟桌面、选择启动操作、监控结果并且计时。对启动测试执行情况进行衡量需要借助VCenter日志、数据包跟踪以及由存储控制器收集并封装在Perfstat中的统计数据。3.4 登录后执行工作负载测试

40、除了确定先前所述启动场景的特征之外，我们还观察了大量用户登录后立即开展日常工作这样的登录场景。这些功能包括打开/加载各种应用程序（包括MicrosoftOffice应用程序、MicrosoftInternetExplorer.Outlook和AdobeReader）以及使用这些应用程序编写各种文档。这些测试的主要目标是通过LiquidwareLabsUX衡量用户体验。次要目标是了解不同场景的工作负载概况；获取工作负载概况（涉及读取/写入和随机/顺序的混合情况，以及它们各自的操作大小），并根据资源利用率和响应时间，评估每个场景中存储控制器的性能。本测试中选择用户登录和工作负载场景，代表在实际环境

41、中可能遇到的典型的生命周期中某周”活动。下面列出的是登录和工作负载场景：场景1：初始登录和工作在星期一早晨8点到8:30之间，2,500个用户首次登录。用户登录后就开始工作。此工作负载代表在虚拟桌面刷新或初始部署之后进行初始登录时可能发生的情形。之所以挑出这个工作负载进行测试是因为在每次登录完成之前均需要创建配置文件。要创建配置文件，至少需要以下两步：1 .将每个VM的C:驱动器中的1.5MB默认配置文件复制到用户的主目录2 .在新的用户配置文件内创建WindowsMail目录，然后大约写入22MBWindowsMail文件在所有受试工作负载中，该工作负载的独特之处不仅因为需要创建配置文件，还

42、是因为每个用户将Outlook配置为应用程序工作负载。场景2:星期二早晨登录和工作在星期二或星期二之后某天的早晨8点到8:30之间，2,500个用户登录。用户登录后就开始工作。在该场景中，用户之前曾经登录并打开过应用程序。由于之前已经将配置文件和应用程序库加载到内存中，因此与首次登录场景或虚拟桌面登录之后的登录场景相比，该场景生成的I/O要少得多。场景3:星期一早晨登录和工作完成重新启动事件之后，2,500个用户在星期一早晨8点到8:30之间登录。该登录场景发生时，每个用户的配置文件已经存在于各自指定VM中的磁盘上，但是未加载到内存中。因此该登录场景需要存储I/O,从内存加载配置文件。用户登录

43、后就开始工作。由于每个应用程序均需要将各自的库加载到内存，因此该场景的工作负载会进一步增加，而且这个场景包含在这一周剩下的几天或这一天剩下的几小时里看不到的应用程序交互I/O。该测试的结果显示，所用带宽以及产生的I/O均比首次登录场景少，但是比“星期二早晨”登录场景多。关闭所有2,500个VM并重新启动之后再开始该测试。该测试显示用户在开始一天的工作之前不得不登录已经硬重启过的环境时会出现的情况。之前在“启动场景”一节中所述的任何场景出现之后，可能会发生该场景。在开始该测试之前，我们不仅确认了系统负载已经恢复到正常，而且检查了VCenter日志以确认所有VM已经重新启动，并且查看了VCente

44、r以确保VMware工具已经登录所有VM0换句话说,在开始该测试之前，我们仔细确认了启动进程已经彻底完成。场景4:用户已经登录，工作负载处于稳定状态2,500个用户均已完成登录进程，并且已打开当天所需的所有应用程序。该测试衡量早晨高峰期结束之后的工作负载。尽管用户这个时候仍然在打开和关闭应用程序、读取/写入文件、发送电子邮件和搜索Web,但是由于之前已经将所需的内容存储在内存中，因此这个时候的存储工作负载处于最低点。该测试中的工作负载特征与“星期二早晨”登录场景中的工作负载特征非常相似。鉴于二者非常相似，下面的章节将对“星期二早晨”场景与稳定状态结果一同报告。3.5工具如图7中屏幕截图所示，R

45、AWC生成环境中的所有工作负载。根据VMware的建议使用所选的应用程序。VMware告知我们该应用程序混合将生成“有经验用户”的工作负载（即12IOPS/桌面）。以下信息也非常重要： MicrosoftOffice的版本为2007。 MicrosoftExchange的版本为2010。 虚拟桌面设置为在缓存模式下运行Outlook。所有登录后执行工作负载的场景均以相同方式执行。用户通过RAWC,使用PCoIP登录。平均每3秒进行5次登录，在28分钟内完成了所有登录。为完成以上工作，使用了25个RAWC启动器。每个启动器都被配置为每15秒登录一个虚拟桌面。启动器按顺序每隔3秒进行一次自身登录。7