技术报告netappvmware view席位性能

123内容提 环 测试、方法和工 场 创123内容提 环 测试、方法和工 场 创建测 启动测 登录后执行工作负载测 工 45最终用户体 详细测试结 创建进 初始登 星期二早晨登 重新启 星期一早晨登 稳定状 观察结果和经验总 6附 SSD和 应用程序工作负 78参 致 表格表1)创建场景 表2)初始登录场景 表3)“星期二早晨”或典型登录场景 表4)启动场景 表5)“星期一早晨”或配置文件加载登录场景 表6)稳定状态场景 表7)AcmeCorporation日历 表8)初始登录的用户体验（以秒为单位） 表9)初始登录用户体验（“好”、“一般”和“差”登录时间的百分比） 表10)初始登录期间DataONTAP8.0.1与8.1的对比结果 表11)初始登录时的I/O并发数、速率以及读取和写入操作大小 2表12)星表12)星期二早晨登录的用户体验（以秒为单位） 表13)星期二早晨登录用户体验（“好”、“一般”和“差”登录时间的百分比） 表14)星期二早晨登录期间DataONTAP8.0.1与8.1的对比结果 表15)星期二早晨登录时的I/O并发数、速率以及读取和写入操作大小 表16)重新启动期间DataONTAP8.0.1与8.1的对比结果 表17)星期一早晨登录的用户体验（以秒为单位） 表18)星期一早晨登录的用户体验（“好”、“一般”和“差”登录时间的百分比） 表19)星期一早晨登录期间DataONTAP8.0.1与8.1的对比结果 表20)星期一早晨登录时的I/O并发数、速率以及读取和写入操作大小 插图图1)每秒读取和写入操作数 图2)读取和写入吞吐量 图3)启动时的读取操作细分 图4)初始登录时的读取操作细分 图5)稳定状态时的读取操作细分 图6)“半POD”架构 图7)RAWC屏幕，显示登录后执行工作负载场景 图8)Stratusphere（图片由LiquidwareLabs提供） 图9)显示机器体验指标的VDIUX配置文件屏幕 图10)显示I/O体验指标的VDIUX配置文件屏幕 图11)克隆虚拟桌面各阶段花费时间细分 图12)初始登录时的读取和写入吞吐量 图13)初始登录时的每秒读取和写入操作数 图14)初始登录中的读取/写入协议延迟 图15)初始登录时的读取和写入延迟 图16)初始登录时的CPU利用率 图17)初始登录时的读取操作细分 图18)初始登录时的读取和写入操作大小 图19)星期二早晨登录的读取和写入吞吐量 图20)星期二早晨登录时的每秒读取和写入操作数 图21)星期二早晨登录的读取和写入协议延迟 图22)星期二早晨登录的读取和写入延迟 图23)星期二早晨登录的CPU利用率 图24)星期二早晨登录的读取操作细分 图25)星期二早晨登录的读取和写入操作大小 3图图26)启动时的读取和写入吞吐量 图27)启动时的每秒读取和写入操作数 图28)启动时的读取和写入协议延迟 图29)启动期间的CPU利用率 图30)启动时的读取操作细分 图31)星期一早晨登录的读取和写入吞吐量 图32)星期一早晨登录的每秒读取和写入操作数 图33)星期一早晨登录的读取和写入延迟（以秒为单位） 图34)星期一早晨登录的来宾操作系统读取和写入延迟 图35)星期一早晨登录的CPU利用率 图36)星期一早晨登录的读取操作细分 图37)星期一早晨登录的读取和写入操作大小 图38)滴水工作负载（每秒操作数） 图39)滴水工作负载（每秒MB） 图40)显示“滴水效应”工作负载的屏幕 图41)启动时间对比（按驱动器类型） 图42)使用SATA驱动器的用户的初始登录体验 图43)使用SATA驱动器的用户在星期一早晨的体验 图44)首次打开和关闭MicrosoftWord时的读取操作数 图45)首次打开和关闭MicrosoftWord时的写入操作数 图46)后续打开和关闭MicrosoftWord时的读取操作数 图47)后续打开和关闭MicrosoftWord时的写入操作数 图48)首次打开WindowsMediaPlayer并播放影片时的读取操作数 图49)首次打开WindowsMediaPlayer并播放影片时的写入操作数 图50)后续打开WindowsMediaPlayer并播放影片时的读取操作数 图51)后续打开WindowsMediaPlayer并播放影片时的写入操作数 图52)保存Excel工作簿时的读取操作数 图53)保存Excel工作簿时的写入操作数 4 内容提20108月，NetApp联合若干合作伙 内容提20108月，NetApp联合若干合作伙伴共同发布了一份白皮书，其中介绍了如何部署使用NetApp存储、CiscoUnifiedComputingSystem™(CiscoUCS™)、CiscoNexus®、VMware软件和Fujitsu服务器的50,000席位虚拟桌面基础架构(VDI)环境。这份初始白皮书仅关注每个合作伙伴为支持此部署而提供的高级别的架构设计和技术详情。根据在虚拟化基础架构中部署5,000席位的硬件和软件需求，最初需要使用NetAppFAS3170存储控制器，以及界定好的模块化存储单元和服务器（称为“桌面池”[POD]）。初始白皮书将POD定义如下：60ESX®4.1主机（CiscoUCSFujitsu1FAS3170A高可用性(HA)集9615KRPM光纤通道驱动2512GB闪存VMwarevCenter™个运行PC-over-IP(PCoIP)连接协议的VMwareView™ConnectionServer5,000个Microsoft®Windows®7虚拟桌面虚拟机(VM)发布初始白皮书后不久，NetApp便更新了其中端存储产品，用FAS3270存储系统取代初始白皮书中使用的FAS3170存储系统，提高了容量和性能。因此，在本技术报告所述的测试中，我们使用FAS3270存储系统而不是初始白皮书中所用的FAS3170（因为FAS3270显著提升了解决方案的性能和可扩展性）。除此之外，后续的早期测试也表明：要想能够有效支持5,000个VDI桌面，需要我们再添加30台服务器，以保证测试期间有充足的内存资源。因此，我们现在将POD定义如下：90ESX4.1服务器2个具有超线程功能的四核心NehalemCPUFujitsuPRIMERGYRX200-48GB主内1FAS3270AHA集9615KRPM光纤通道驱动2512GB闪存模2VMwarevCenter3个运PC-over-IP(PCoIP)连接协议的VMwareViewConnection5,000个MicrosoftWindows7虚拟桌面根据这一新定义，每个NetAppFAS3270控制器支持45ESX服务器和2,500Windows7永久虚拟桌面。由于创建一个完整的POD需要满足众多硬件要求，因此我们决定对这些后续测试作出限制：使用相当于二分之一个POD所要求的上述硬件，或者使用由两个FAS3270存储控制器中的一个提供服务的2,500个虚拟桌面。由于每个FAS3270存储控制器实际上独立服务于2,500个虚拟桌面，因此针对2,500个虚拟桌面衡量得到的性能直接加倍，就能得到支持5,000个虚拟桌面的完整POD的性能在这些测试中，我们使用VMwareView4.5和VMwarevSphere4.1部署由2,500个虚拟桌面组成的场景。除此之外，我们还使用VMwareReferenceArchitectureWorkloadCode(RAWC)工具生成VDI我们针对最新的公开发布(GA)版本(DataONTAP®8.0.1)和DataONTAP8.1进行测试。之所以选择使用DataONTAP8.1，是因为它能进一步提升NetApp虚拟存储分层(VST)功能的性能，同时减少所需的磁盘轴数量。借助VST，客户不仅可以从NetApp存储效率中受益，而且还可以显著提高I/O性能。DataONTAP操作系统本身内置有VST，并且通过利用NetApp主存储重复数据删除和文件/卷FlexClone等块共享技术应用VST，可以减少所需的缓存量并消除重复磁盘读取。对于任意重复块，仅将一个实例读入缓存，因而所需的缓存少于传统存储解决方案。由于使用节省空间的NetApp克隆技术，5VMeViw的实施最初可节省高达%的空间，这意味着更高的缓存重复数据删除率和高缓存命中率。在处理并发系统启动（”）和登录成百上千个虚拟桌面系统（可能导致传统旧式存储系统超负荷工作）VST特别有效。与以前版本的DtaVMeViw的实施最初可节省高达%的空间，这意味着更高的缓存重复数据删除率和高缓存命中率。在处理并发系统启动（”）和登录成百上千个虚拟桌面系统（可能导致传统旧式存储系统超负荷工作）VST特别有效。与以前版本的DtaAP.1版本可以更加高效地共享主内存中经过重复数据删除的块。这样，存储控制器的主内存就可以处理更大型的工作集，从而加快访问速度并减少占用P。VDI工作负载远远超出了稳定状态下的工作负载。了解该阶段的特征非常重要，但是在某些情况下重新启动、登录、创建配置文件和操作大量虚拟桌面也会给支持整个VDI环境的存储带来沉重压力。如果没能理解和计划这些工作负载，会对最终用户体验和项目成功产生严重的负面影响。在本报告接下来的内容中，我们将从Acmeopotion这个虚构公司的视角查看一些不同的VDI常见场景。Acme已经借助tApp存储部署了,0VDIAcme希望了解在一个典型工作周内可能遇到的不同类型的工作负载（极具代表性的用户大量登录、启动和停止应用程序，以及借助为其提供的应用程序执行日常任务）。另外，日常维护有时会要求关闭所有虚拟桌面，然后又需要同时打开并启动大量VM。在表1到表6中，这些场景及结果都根据用户体验进行了衡量，并且从一个较高的水平进行了定义。在整个报告中，用户体验均由LiquidwareLabsStratusphereUX使用加权算法确定是不是“好”。启动场景和创建场景的用户体验用启动和创建所用的时间来衡量。请注意，测试中选择的是VMware建议的应用程序混合，这些应用程序产生的工作负载为：每秒的“有经验用户”的工作负载）次输入/输出操(IOPS)/桌面（即预期表1创建场2)初始登录场表表3)星期二早6测成功的主要衡量标用户体2,500个用户登录以前访问的VM。登录后，用户开LiquidwareLabsUX衡量的用户DataONTAP8.0.1：100的用户获DataONTAP8.1：100的用户获得测成功的主要衡量标用户体2,500个用户在半个小时之该登录触发2,500份配LiquidwareLabsUX衡量的用户DataONTAP8.0.1：62的用户获得“好”用户体验，38%的用户获得DataONTAP8.1：97的用户获得“好”用户体验，3%的用户获得测成功的主要衡量标创建时创建2,500VM并衡量花从克隆进程开始到准备好启动2,500VM共花费3个小表4启动场 5)“星期一早晨”或配置文件表4启动场 5)“星期一早晨”或配置文件加载登录场景表6)稳定状态场我们在测试中从一个较高的水平确定了每个场景均会生成各自独特的工作负载。启动工作负载的特征是PS计数较高。“星期一早晨”场景以及初始登录场景生成的工作负载的读取和写VM的启动通常不会影响最终用户体验，但发生A、灾难恢复D)或任何计划外维护之类的事件时除外。在这种情况下，快速启动对最终用户来说尤为重要。在登录时，无论是星期几，用户都不可能忍受等待5分钟才能使用桌面。当用户使用自己的桌面时，他们希望自己桌面的性能能与物理桌面媲美，甚至超出物理桌面。如果不能正确了解这些不同工作负载的特征以及它们对基础架构和最终用户的影响，最终将影响项目的成功。除此之外，我们发现这些不同类别的工作负载体现出的特征有时会与常说的VDI工作负载分类（小块磁盘写入块通常很小（一般为4KB），但也可能大很多；在大型文件保存操作期间曾有过1写入操作的记录读取操作的大小范围从4KB以下到1024KB，同时随机读取和顺序读取在数量上较为均衡。换句话说，尽管虚拟桌面工作负载确实会生成较小的随机工作负载，但是它们也会生成较大的随机操以及大小不一的顺序操作。我们的测试显示，VDI工作负载的行业标准定义（仅考虑IOPS）过于简单，正确定义VDI环境的存储大小需要考虑更多方面。图12中的图表显示文中所述场景之间的工作负载区别，它们可能在Acmeopotion的VDI环境生命周期中极具代表性的某天或某周发生（以“生命周期中的一天”格式显示。在最初的,0席位VDI白皮书中，环境是使用顶尖技术构建的。我们已对原始配置进行测试，但是由于软件和硬件进行了多次修订，因此对新版本也进行了测试。尽管原始测试的结果已验证了架构，但本报告中详细介绍的所有结果均是使用转速为k的FASA驱动器在DtaAP..1和.1系统上测试得到7测成功的主要衡量标用户体2,500个用户已经完成登录LiquidwareLabsUX衡量的用户DataONTAP8.0.1：100的用户获DataONTAP8.1：100的用户获得测成功的主要衡量标用户体2,500个用户登录之前访问过，之后又重新启动的VM。DLL都必须从磁盘加载。LiquidwareLabsUX衡量的用户DataONTAP8.0.1：100的用户获DataONTAP8.1：100的用户获得测成功的主要衡量标启动时VMwarevCenter控制2,500DLL都不必从磁盘加载。启动所用的总时间DataONTAP8.0.1：36分DataONTAP8.1：21分够带来最佳用户体验够带来最佳用户体验、最高吞吐量和最低延迟，而且它达到以上目标所需的每次IO操作成本最低。这些图表从存储控制器的角度展示吞吐量和IOPS。请观察从每秒操作数和吞吐量角度衡量的各工作负载阶段之间的明确界限。请注意，在启动场景中，占主导地位的是相对大量的读取操作，这些操作使吞吐量超过了每秒0MB的峰值。另外，初始登录场/写入的操作数较为均衡，读取操作使峰值吞吐量超过了每秒0MB。最后，用户启动自己的VM并且登录桌面之后，相较于启动场景和登录场景，稳定状态工作负载在PS和吞吐量方面均出现大幅下滑。另请注意，如图12/写入操作的工作负载分配比会变为:，但是，吞吐量分配会随着与初始读取活动相关的更多工作（例如加载应用程序库和打开/读取文件）缓存在VM来宾操作系(OS)中而渐趋平衡图1)每秒读取和写入操作图2)读取和写入吞吐图35中的图表突出显示了存储控制器所报告的操作大小。请注意，工作负载分配及其数量会随/顺序读取操作百分比，这个数字一直保持较为均衡的状态。83)启动时的读3)启动时的读取操作细图图4)初始登录时的读取操作细分9图5)稳定状图5)稳定状态时的读取操作细基于该目标，本报告的着重点包括详实记录使用的测试方对各种配置进行比照，展示NetApp技术的功能最后，验证50,000席位报告中所详述的性这些重点的共同目的在于让读者能够重现我们的测试、选择适合其环境的最佳技术、正确调整工作负载的大小并且更好地从总体上了解VD。最后，我们的测试显示，在VDI环境中实现出色性能需要的不只是支持稳定状态工作负载（通常认为每个虚拟桌面达到2个PS）的能力这么简单。我们发现，要实现总体良好的用户体验，还必须考虑许多其他方面。本报告接下来的内容提供与测试场景相关的详细信息，其中不仅包括各种工作负载的细节和各个测试结果，而且还包括用户体验预测。 环NetApp在由2,500个虚拟桌面构成的“半POD”单元中执行测试，这些虚拟桌面分布于454.1服务器中，拥有一个NetAppHA对控制器。由一个VMwarevCenterVM管理整POD图6)PODVMware®ViewVMwareView2个连接服务器（2500个桌面45个ESX服务器1使用由两个连接代理和10个池组成VMwareView4.5连接代理池，将虚拟桌 环NetApp在由2,500个虚拟桌面构成的“半POD”单元中执行测试，这些虚拟桌面分布于454.1服务器中，拥有一个NetAppHA对控制器。由一个VMwarevCenterVM管理整POD图6)PODVMware®ViewVMwareView2个连接服务器（2500个桌面45个ESX服务器1使用由两个连接代理和10个池组成VMwareView4.5连接代理池，将虚拟桌面注册为专用桌面。每个池均使用默认设置，包括PCoIP连接协议映像VM，并且应用了《面向Windows7VMwareView优化指南》中定义的一系列优化以及《VMwareView管理员指南》中建议的优化。然后，我们使用NetAppRapidCloneUtilityRCU)克隆2,500VM。vCenter负责管理VM启动操作；登录和虚拟桌面工作负载由VMwareDesktopRAWC所有测试均使用的是NetAppFAS3270，但是测试了包括固态驱动器(SSD)、串行高级技术连接(SerialAdvancedTechnologyAttachment,SATA)15KFC驱动器在内的多种驱动器。所有测试均使用DataONTAP8.0.1和8.1执行。 测试、方法和工具该报告执行的测试代表客户期望体验的某些最常见工作负载场测试中的场景遵循AcmeCorporation中典型的双周日历HA/DRS集 HA/DRS集 HA/DRS集2,500VM/vCenterTM（45ESX主机初始登录,初始登录,0个用户在半个小时之内登录，因为是首次登录，所以测试存储控制器上的负载并衡量这种最差登录情况下的用户体验。（之所以认为这种情况最糟糕，是因为在所有测试场景中，该登录场景生成的负载最多。）这些登录伴随着创建配置文件，将默认的1.5MB配置文件复制到用户目录并且创建包含22MB文件的WindowsMail子目录。登录之后，每个虚拟桌面的用户均开始以下工作：配置Outlook、发送邮件、创建Word和Excel文件以及查看PowerPoint和Acrobat文档。典型（星期二）,0个用户在半个小时之内登录。该场景模仿以下登录场景：用户登录之前已登录过并且登录后未进行硬重启的虚拟桌面，因此用户的应用程序库和配置文件保存在内存中。由于配/输出/)极少。在此测试中，用户像“初始登录”那样登录，但是由于之前已经对Outlook进行配置，所以此时不会再该测试的目的同样是衡量存储控制器上的负载以及用户体验启动此测试选中vCenter内全部2,500个虚拟桌面、选择“启动”、监控结果并且计时。除测试用户体验之外，该测试还衡量启动时间。像在其他场景中一样，还衡量存储控制器上的负载配置文件加载（）,00个用户在半个小时之内登录。该场景模仿以下登录场景：用户登录之前已经登录过的永久虚拟桌面（与其他用户一样），但是由于之后曾经对其硬重启，因此每台机器的内存已清除。内存清除之后，由于登录时需要从磁盘加载用户的配置文件，因而会生成存储/。在该测试中，用户所做的工作与在“星期二早晨”登录场景中做的工作相同。但是由于之前没有将应用程序库加载到内存中，这样就必须打开每个应用程序，因此该工作会生成先前场景中未出现的/。与接受测试的其他登录场景一样，该测试的目的在于衡量存储控制器上的负载以及用户体验稳定状态稳定状态是指以下环境状态：所有用户已经完成登录并且打开了开展每日工作所必需的应用程序。在该场景中，每位用户执行的工作与在“星期一早晨”和“星期二早晨”场景中登录后所做的工作完全一样。此处的目标与登录场景中的一样，即衡量用户体验和存储控制器负载创建在执行任何测试之前必须存在虚拟桌面。因此，NetApp使用自己的RCU克隆桌面。尽管该测试不是实际测试，但是我们仍然记录创建虚拟桌面（从开始到准备好启动）花费的时间。AcmeVDI用户一周的工作”的场景中。例如，在该周的第一天，大量用户可能会同时登录他们的VM，为一周的工作进行准备。该工作可能包括启动各种应用程序和执行不同级别的工作。为了清晰起见，本报告中所述的所有测试均指的是日历上的相应日期，就像管理员将系统排定为在这些日期执行这些事件一样。每个测试均可回溯到表7中介绍的日历。7AcmeCorporation日历。尽可能分散地执行所有测试。我们的测试显示，即使没有任何7AcmeCorporation日历。尽可能分散地执行所有测试。我们的测试显示，即使没有任何额外工作负载发生，已启动VM也会成少量磁盘I/O。我们发现该工作负载主要针对写入并且主要由系统生成，其次是由svchost.exe和services.exe进程生成的。出于本报告的目的，我们将此称为“滴水”效应，这是因为每个VM均会生成少量但持续的工作负载，因此大量VM生成的这种工作负载足以影响整体性能。将在第5.7节的所有测试均使用SSD、SATA15KRPM光纤通道驱动器在DataONTAP8.0.1上执行。考虑到每IO操作成本的原因（内容提要中提及的原因），在DataONTAP8.1上执行的测试仅采用15KRPM光纤通道驱动器。为简便起见，通过SATA和SSD执行的测试的结果包括在该报告的附录而不是正文中。为了将环境恢复到基准状态，在各次测试之间要关闭所有虚拟桌面，并且将聚合恢复到测试之前Snapshot™副本并且/或者刷新存储控制器的内存以下章节将提供有关如何执行每个测试案例的详细信息创建测试该测试的唯一目标是，记录使用tApp虚拟存储控制台.1以及配置和克隆功能来创建,0个虚拟桌面所花费的时间。该测试向客户展示如何在相对较短的时间内，轻松快速地部署或重新部署数千个虚Acmeopotionidgtopotion并且希望轻松整合新员工。以快速方式进行部署，这样公司便可以节省新员工入职的时间。在第二个案例中，客户对主模板进行了修补并且决定重新部署基础架构。启动测试启动测试的主要目标是确定在发生诸如中断、维护、修补等事件或任何其他需要快速启动的场景后，恢复环境所花费的时间。当VMe工具已在所有虚拟桌面上签入，并且存储控制器上的网络文件系统FS)操作数和PU利用率都已下降到较低的稳定状态时，则视为启动测试已经完成。这些测试的次要目标如下//顺序的混合情况以及它们各自的操作大小根据资源利用率和响应时间，评估存储控制器在有大量VM同时启动时的性能对比完全启动所有虚拟桌面所花费的总时周周周周周周周2,50082,500次登82,50012345682,500（30分钟（启动后782,50089控制启动操作时，vCenter限制控制启动操作时，vCenter限制每次只能启动128台机器。各个虚拟桌面完成启动进程之后，它们就会注意：请记住，衡量每秒操作数和每秒MB时，均会使用128这一限制作为因数。此测试选中vCenter内的所有2,500个虚拟桌面、选择启动操作、监控结果并且计时。对启动测试执行情况进行衡量需要借助vCenter日志、数据包跟踪以及由存储控制器收集并封装perfstat中的统计数据登录后执行工作负载测试除了确定先前所述启动场景的特征之外，我们还观察了大量用户登录后立即开展日常工作这样的登录场/加载各种应用程序（包括MicosoftfficeMicosoftttExplo、tlook和Adobed）以及使用这些应用程序编写各种文档。这些测试的主要目标是通过iqidebsX衡量用户体验。次要目标是了解不同场景的工作负载概况；获取工作负载概况（涉及读取/写入和随机/顺序的混合情况，以及它们各自的操作大小），并根据资源利用率和响应时间，评估每个场景中存储控制器的性能。场景1：初始登录工作在星期一早晨8点到8:30之间，2,500个用户首次登录。用户登录后就开始工作。此工作负载代表在虚拟桌面刷新或初始部署之后进行初始登录时可能发生的情形。之所以挑出这个工作负载进行测试是因为在每次登录完成之前均需要创建配置文件。要创建配置文件，至少需要以下两步：将每个VMC驱动器中的1.5MB默认配置文件复制到用户的主目在新的用户配置文件内创建WindowsMail目录，然后大约写入22MBWindowsMail文在所有受试工作负载中，该工作负载的独特之处不仅因为需要创建配置文件，还是因为每个用户Outlook配置为应用程序工作负载场景2星期二早在星期二或星期二之后某天的早晨8:0,0个用户登录。用户登录后就开始工作。在该场景中，用户之前曾经登录并打开过应用程序。由于之前已经将配置文件和应用程序库加载到内存中，因此与首次登录场景或虚拟桌面登录之后的登录场景相比，该场景生成的/O要少得多。场景3星期一早完成重新启动事件之后，2,500个用户在星期一早晨8点到8:30之间登录。该登录场景发生时，每个用户的配置文件已经存在于各自指定VM中的磁盘上，但是未加载到内存中。因此该登录场景需要存储由于每个应用程序均需要将各自的库加载到内存，因此该场景的工作负载会进一步增加，而且这个场景包含在这一周剩下的几天或这一天剩下的几小时里看不到的应用程序交互/。该测试的结果显示，所用带宽以及产生的I/O均比首次登录场景少，但是比“星期二早晨”登录场景多关闭所有2,500个VM并重新启动之后再开始该测试。该测试显示用户在开始一天的工作之前不得不登录已经硬重启过的环境时会出现的情况。之前在“启动场景”一节中所述的任何场景出现之后，可能会发生该场景。在开始该测试之前，我们不仅确认了系统负载已经恢复到正常，而且检查了vCenter日志以确认所有VM已经重新启动，并且查看了vCenter以确保VMware工具已经登录所有VM。换句话说，在开始该测试之前，我们仔细确认了启动进程已经彻底完成。场景4用户已经,0场景4用户已经,0个用户均已完成登录进程，并且已打开当天所需的所有应用程序。该测试衡量早晨高峰期结束之/写入文件、发送电子邮件和搜索b，但是由于之前已经将所需的内容存储在内存中，因此这个时候的存储工作负载处于最低点。该测 工7中屏幕截图所示生成环境中的所有工作负载。根据VMware的建议使用所选的应用序。VMware告知我们该应用程序混合将生成“有经验用户”的工作负载（即12IOPS/桌面）。以下MicrosoftOffice的版本为2007。MicrosoftExchange的版本为2010。虚拟桌面设置为在缓存模式下运行Outlook所有登录后执行工作负载的场景均以相同方式执行。用户通过RAWC，使用PCoIP登录。平均每3秒5次登录，在28分钟内完成了所有登录。为完成以上工作，使用了25RAWC启动器。每个启动器都被配置为每15秒登录一个虚拟桌面。启动器按顺序每隔3秒进行一次自身登录。75秒之后，所有启动器都会每15秒同时建立新PCoIP会话。也就是说，我们的测试使用提供给VMware合作伙 管理指南》中定义的默认登录速率。在每个虚拟桌面上，应用程序的运行顺序是随机的。图7)屏幕，显示登录后执行工作负载场景 最终用户体验我们 最终用户体验我们使用LiquidwareLabsStratusphereUX报告所有登录测试中的用户体验此应用程序套件为衡量桌面和概念验证(POC)环境下的用户体验提供了准确的系统化方法。该应用程VM、用户和应用程序导致I/O风暴登录延迟、应用程序启动时间、没有响应的应用程序、磁盘和CPU队在具有指定的用户和应用程序关联的多租户环境中，端点、桌面和服务器的流VM、用户和应用程序工作负载：CPU/内存/磁盘/显卡/网络，包括磁IOPS和存储要8显示Stratusphere的功能如何改进桌面支持图8)Stratusphere（图片由LiquidwareLabs提供）如图9中屏幕截图所示，LiquidwareLabsStratusphereUX按照“好”、“一般”和“差”定义用户体验：花费时间少于15秒的登录定义为“好”；少于60秒但多于15秒的为“一般”；多于60秒的为“差”。在以下图表中，用户体验采用LiquidwareLabs标准。注意：无论登录类型或配置文件大小怎样，“好”、“一般”和“差”的定义都严格遵照标准。因此，无论配置文件的大小或状态如何，只要花费时间少于15秒就属于“好”。图9)显示机器体验图9)显示机器体验指标的VDIUX配置文件屏幕。10中屏幕截图所示，LiquidwareLabsStratusphereUX将少于或等150毫秒阈值的网络延迟义为“好”；少于或等于300毫秒但多于150毫秒的为“一般”；多于300毫秒的为“差”图10显示I/O体验指标的VDIUX配置文件屏幕。我们使用vSpe.1VMevscsiStts实用程序，利用其跟踪标记来确定ESX服务器内VM磁盘/OvscsiStts特别引人关注，它具有跟踪选项，可以记录/O块大小和命令类型。我们利用这些数据确定在各种测试中遇到的操作混合和操作大小。这样，我们就可以记录每个应用程序自重新启动后首次使用时的行为，并将其与每个应用程序在第二次使用时的行为进行比较。我们还使用由NetApp开发的诊断数据收集工具Perfstat 详细测试结果本报告接下来的内容将重点介绍多项改进并确定工作负载从启动到稳定状态的特征。为了保持报告的完/生成工作负载的工具。接下来还有一节会介绍使用tApp配置和克隆功能来创建VM，另有一节介绍各个Micosoft应用程序的特征请参见附录中的第.2节“应用程”）。本报告将比较性能结果，并在适当时添加用户体验类别。本报告还会重点介绍在每个工作负载中观察到//顺序混合情况。为了便于阅读，所有NetApp测试都被叠加在一个排定本报告将比较性能结果，并在适当时添加用户体验类别。本报告还会重点介绍在每个工作负载中观察到//顺序混合情况。为了便于阅读，所有NetApp测试都被叠加在一个排定了所有事件的双周日历上。这样叠加的目的是让读者了解虚构的AcmeCorporation中View管理员“生命周期中的一天”。报告的所有事件均在NetApp测试中发生；所有时间表都是真实的；只有叠加AcmeCorporation案例是虚构的 创建进程AcmeCorporation的变更控制委员会批准了于29日（星期天）创建另外2,500个虚拟桌面。在星期天早晨，物理环境、View连接代理、所需数量的ESX服务器和新vCenterVM均已就绪。Windows764位映像之前就已根据VMware和Microsoft最佳实践进行了优化，并且安装了所有需要的应用程序。AcmeCorporation从众多技术中选择了利用NetApp克隆技术进行部署。星期天早晨，View管理员准实际扩建环境时利用的是虚拟存储控制台(VSC)套件的子组件NetApp配置和克隆功能(PNC)。该环境的2,500个虚拟桌面分布于10个卷（NFS数据存储库）上，另有一个卷用作“暂存”卷。第一步，VSC先将模板实际复制到VSC专门为此创建的暂存卷。然后，VSC对暂存卷中新创建的flat-vmdk进行249次文件级克隆，最后对暂存卷本身进行10次克隆。将模板复制到暂存卷的过程由网络数据管理协议(NDMP)以备份和恢复的形式完成。1NtAppDMP和fltvmdk文件克隆属于最早的两个阶段。完成这些阶段之后，控制权会根据虚拟桌面启动之前的自定义规范交回虚拟中心，并执行其DMP进程花费3分钟共2分钟来备份和恢复0BfltvmdkC:，文件克隆阶段花费9分钟而卷克隆阶段仅花费6秒。周周周周周周周2,50082,500123456凌晨2点网络中断VM82,500（30分钟（启动后782,50089图11)克隆虚拟桌面各阶段花费间细 初始登录AcmeCorporation的图11)克隆虚拟桌面各阶段花费间细 初始登录AcmeCorporation的员工通常在每天上午8点到8:30之间抵达公司，星期一早晨也不例外。但是于有2,500个虚拟桌面是新部署的，因此星期一（30日）早晨会与其他早上略有不同。在这天早晨，View连接代理会为2,500位用户都分配新桌面，而且由于AcmeCorporation尚未使用任何配置文件管实际所有用户均使用第3.5节“工具”中所述的方法，在28分钟内登录初始登录后，所有用户便开始自己当天的工作。VMwareDesktopRAWC控制环境中的所有工作负载，它会打开应用程序并代替人工键盘控制。RAWC在每个虚拟桌面上执行以下任务：配置Outlook，将Outlook客户端设置为缓存模为每个用户打开MicrosoftWordExcel，并在其中创建新文档并保打开MicrosoftPowerPointAdobeAcrobatReader，查看其中现有的文档打开MicrosoftInternetExplorer周周周周周周周2,50082,500123456凌晨2点网络中断VM82500（30分钟（启动后782,50089从Outlook客户端写三封电子邮件并发RAWC随机确定每个虚拟桌面上的各个应用程序的运行顺序用户表从Outlook客户端写三封电子邮件并发RAWC随机确定每个虚拟桌面上的各个应用程序的运行顺序用户表8报告用户群体在星期一早晨初始登录场景期间登录所花费的时间通过LiquidwareLabsStratusphereUX获取登录时间。如前所述，LiquidwareLabs将登录时间少15秒阈值的用户登录体验定义为“好”，少于60秒但多于15秒的用户登录体验定义为“一般”，60秒的用户登录体验定义为“差”表8)初始登录的用户体验（以为单）注意：48450GBFC15K驱动器的FAS3270，环路速率：4Gbps因此，体验为“差”的用户数量减少，即使体验仍然为“差”的用户的情况也有所改善。表9显示环境中的用户的登录体验。例如，45%的用户的登录体验为“好”，他们的平均登录时间为5秒。 9)初始登录用户体验（“好”、“一般”和“差”登录时间的百分比）注意：48450GBFC15K驱动器的FAS3270，环路速率：4Gbps在下一节中，请注意存储控制器的利用率达到或接近容量上限。同时，在应用程序加载时间方面LiquidwareLabsStratusphereVDIUX所报告的用户体验是可接受的系统如表10中所述，存储控制器的性能处于较高水平。请注意，从DataONTAP8.0.1升级到8.1之后吞吐量增加了140%，但是由于CPU利用率略有提升，因此存储控制器延迟反而缩短了80%。有关促成这一性能提升的关键技术进步的详情，请参阅第1节“内容提要”中有关虚拟存储分层的讨论。配用户总超过15秒）用户百分“一般”登录时（15秒且不60秒）用户百分少于60秒）用户百分DataONTAP27%（平均6秒35%（平均35秒38%（平均86秒DataONTAP45%（平均5秒52%（平均40秒3%（64秒要DataONTAP8.0.1升级到DataONTAP8.1之后，初始登录体验为“差”的用户数量大幅较（从38%减少到3%）DataONTAP8.0.1升级到DataONTAP8.1之后，体验为“差”的用户的登录耗时也缩短了25%（从86秒缩短到64秒）配登录耗时用户体验最长耗登录耗时用户登录体验标准偏DataONTAP4612434DataONTAP257720DataONTAP8.0.1升级到DataONTAP8.1之后，用户的平均登录时间缩短46%（从46秒缩短25秒）要在初始登录场景中，主要瓶颈是只有一个万兆以太网网络接口卡(NIC)。该网卡发送的传输-暂停帧占接收在初始登录场景中，主要瓶颈是只有一个万兆以太网网络接口卡(NIC)。该网卡发送的传输-暂停帧占接收到的数据包的5%。这样会导致客户端延迟远远超出存储控制器报告的延迟。为了缓解这种阻塞状况，NetApp建议将工作负载分流到两个单独的万兆以太网网卡。10从吞吐量、每秒操作数和延迟方面，对DataONTAP8.0.18.1进行对比10初始DataONTAP8.0.18.1的对比结果。注意：48450GBFC15K驱动器的FAS3270，环路速率：4Gbps为简洁起见，从现在开始，本节将使用图形详细介绍DataONTAP8.1配置。我们观察到似的曲线和指标，但吞吐量较低，如表10中所述。8.0也具有图12显示由2500个用户的初始登录及登录之后的每日准备工作的工作负载生成的读取和写入吞吐量。用户登录后就开始工作，因此应用程序负载与登录和配置文件负载产生重叠。读取操作占网络传输数据的71%（平均311MB/秒），写入操作占剩余的29%（平均129MB/秒）。图12)初始登录时的读取和写入吞13显示由2500个用户的初始登录及登录之后的每日准备工作的工作负载生成的每秒读取/写入操作数。读取操作占NFS工作负载的53%，写入操作占43%。查找操作（未显示）约占剩余的2%。注意：用户登录后就开始工作，因此应用程序负载与登录和配置文件负载产生重叠。Data每秒读取操作每秒写入操作216秒98秒5.0644.3DataONTAP311秒129秒0.9511.2吞吐量增加140%会直接影响全部2500个虚拟桌面完成登录所需的时间，这使个人用户体验和整体存储控制器延迟缩短CPU利用率仅略有提升（提升幅度少于用户延迟完全符合由LiquidwareLabsUX定义为“好”的标（“好”不超过150毫秒，“一般”多于150毫秒且不超过300毫秒，“差”多于300毫秒）要图13)初始登录时的每秒读取图13)初始登录时的每秒读取和写入操作数。14显示存储控制器为NFS协议报告的延迟。其中显示整个登录期间的读取（平均入（平均1.2毫秒）协议延迟。0.9毫秒）和图14)初始登录中的读/图15显示由ESXTOP批处理模式报告并由ESXTOP编译的来宾操作系统延迟。ESXTOP批处理式使用3秒最小取样率。X轴是取样数。由于该图代表3秒取样率，因此X轴的值乘以3即可得要来宾操作系统遇到的延迟远高于存储控制器报告的延迟，但是仍然在SttspeX暂停帧占接收到的数据包的%。这样会导致如图5所示的客户端延迟。在接受测试的每个DtaAP版本中，该问题只会在初始登录场景中出现。）为了缓解这种阻塞状况，NtApp建议将工作负载分流到两个单独的万兆以太网网卡。图15)初始登录时的读图15)初始登录时的读取和写入如图16所示，在此期间，平均占用了全部四个物理保持在较低水平，CPU利用率仍然会是这样。CPU容量的95%。请注意，即使存储控制器延图16初始CPU利用工作负载开始此测试时，NetApp接受了针对虚拟桌面的行业标准规模调整做法，也就是，根据期望用户生成的操作数将所有用户分组为多个操作数分段。另外，虚拟桌面工作负载被定义为不包含顺序I/O，而且其I/O增量4KB8KB。此外整虚拟桌面I/O大小时，我们以往认为100100%的时间内生成IOPS。但是，数据包跟踪、vscsiStats、存储控制器统计和ESXTOP已证实并非如此。/顺序混合和并发用户操作。在本报告中，并发被定义为同时生成以存储为目标的/O的虚拟桌面的数量。在图17的图表中列出了读取操作大小及其各自的特征（顺序或随机）。统计数据本身取自计数器管理工作负载并不都是同一大小图17中的图表就是细分成了多个操作数分段。每个分段包含介于指定大小与下一报告操作大小并非所有工作负载都是随机的：在所有读取操作中，有50%是顺序读取要图初始登录时的读取操作细图初始登录时的读取操作细表11记录从虚拟桌面自身角度记录的工作负载（也就是ESXTOP中捕获的工作负载）。在测试间，ESXTOP在环境中的所有服务器上持续以批处理模式运行，采用最低取样间隔：3秒我们从ESXTOP输出中提取到以下信息在特定测试中以不同时间间隔同时执行读取或写入操作的虚拟桌面的数量。这就让我们有了在给定每个活动桌面生成的平均读取和写入操作和吞吐量（以MB/秒为单位）每个读取和写入操作的平均大小1ESXP生成的图表记录从虚拟桌面的角度记录的并发数、/O速率和操作大小，如ESXP所报告。该表格的目的是解释并发的重要作用，个别工作中的虚拟机可能会非常繁忙，但是从整体上评估所有虚拟机得到的结果就没有如此繁忙。平均来讲，在任意指定的一秒，只有20%的虚拟桌面生成读取操作，70%的虚拟桌面生成写入操作。因此，无法实现100%并发。如果忽略并发，在初始登录场景中平均每个虚拟桌面生成的IOPS为12ESXTOP进一步印证了来自存储控制器的数据，该数据表明IOPS高于最初认定的VDI常见工作负载（即4KB或8KB）。ESXTOP报告的平均IOPS和吞吐量会密切跟踪由存储控制器报告的值。要表11)初始登录时的并发数、速率以及读取和入操作大小在图18中，由ESXTOP生成的图表还显示由来宾操作系统表11)初始登录时的并发数、速率以及读取和入操作大小在图18中，由ESXTOP生成的图表还显示由来宾操作系统自身在整个登录场景中发布的平均读取和图18)初始登录时的读取和写入作大要18中图表显示读取和写入操作在低于4K到大于60KB的大范围内出现波动测量指值VM总IOPS平均平均读取平均写入平均读取吞吐量（MB/秒平均写入吞吐量（MB/秒正在进行读取的VM正在进行写入的VM平均读取大小平均写入大小平均读取延迟（毫秒平均写入延迟（毫秒针对一针对所每个正在进行读取的VM的平均读取6每个正在进行写入的VM的平均写入64每个正在进行读取的VM的平均读取吞吐量（KB/秒每个正在进行写入的VM的平均写入吞吐量（KB/秒 星期二早晨登录星期一傍晚，AcmeCorporation员工完成各自当天的工作之后停止工作，全都退出 星期二早晨登录星期一傍晚，AcmeCorporation员工完成各自当天的工作之后停止工作，全都退出。之后虚拟桌面便主要处于闲置状态，并准备迎接用户在星期二早晨像往常一样在上午8点到8:30之间来上班并登录。即使用户在星期一夜间退出，每个虚拟桌面的内存仍会保留用户数据（库、缓存数据等）。实际在前一天初始登录时，用户已经被分配给虚拟桌面。用户在前一天已经登录并打开各自的应用程序，尽管他们已经关闭应用程序并退出，但应用程序库和每个用户的大部分配置文件仍保留在内存中。因此，此次登录和每日准备工作所生成的工作负载会有所减少。在该报告获取的所有登录和工作负载场景中，用户登录速率为每秒大约3次，而首次登录与最后登录间隔6分钟。在星期二早晨登录之后，所有用户均开始各自当天的工作。VMwareDesktopRAWC控制环境中的所有工作负载，它会打开应用程序并代替人工键盘控制。RAWC在每个虚拟桌面上执行以下任务：为每个用户打开MicrosoftWordExcel，并在其中创建新文档并保打开MicrosoftPowerPointAdobeAcrobatReader，查看其中现有的文档打开MicrosoftInternetExplorer从Outlook客户端写三封电子邮件并发RAWC随机确定每个虚拟桌面上的应用程序的运行顺序用户表12报告用户群体在星期二早晨的典型登录场景期间登录所花费的时间表12)星期二早晨登录的用户体（以秒为单位）配DataONTAP110无论使用何种版本的DataONTAP，多数用户在星期二早晨登录时用时均为1秒要周周周周周周周2,500123456凌晨2点网络中断VM（30分钟（启动后789注意：48450GBFC15K驱动器的FAS3270，环路速率：4Gbps星期二早晨登录场景带来的用户登录体验全部为“好”（根据LiquidwareLabsStratusphereUX衡量标准，这意味着登录所花费注意：48450GBFC15K驱动器的FAS3270，环路速率：4Gbps星期二早晨登录场景带来的用户登录体验全部为“好”（根据LiquidwareLabsStratusphereUX衡量标准，这意味着登录所花费的时间少于15秒）。表13)星期二早晨登录用户体验（）注意：48450GBFC15K驱动器的FAS3270，环路速率：4Gbps在应用程序加载时间方面，LiquidwareLabsStratusphereVDIUX所报告的用户体验是可接受的系统如表4中所述，存储控制器的性能处于较高水平。请注意，虚拟桌面和存储控制器之间传输的工作量（因为虚拟桌面实际上利用保留在来宾操作系统缓存中的大量信息）（例如系统、svchost.exe和服务）。为获取进一步的详情，表14从吞吐量、每秒操作数和延迟方面，对DataONTAP8.0.18.1进行对比表14星期二早晨登录期间DataONTAP8.0.1与8.1的对比结果为简洁起见，从现在开始，本节将使用图形详细介绍DataONTAP8.1配置。我们观察到DataONTAP8.0也具有类似的曲线和指标，但吞吐量较低，如表14中所述。图9中的图表显示由0个用户的星期二早晨登录及登录之后的每日准备工作的工作负载生成的读取和写入吞吐量。用户登录后就开始工作，因此应用程序负载与登录和配置文件负载产生重叠。读取操作占网络传输数据的%（7MB），写入操作占剩余的%（0MB）。Data26秒18秒0.90.4DataONTAP17秒20秒0.30.2要如表14所示，即使在操作中写入占主导地位，无需从磁盘加载应用程序DLL或配置文件，对存储控制配用户总超过15秒）用户百分“一般”登录时（15秒且不60秒）用户百分少于60秒）用户百分DataONTAP100%（平均1秒DataONTAP100%（平均1秒配DataONTAP11.50图19)星期二早晨登录的读图19)星期二早晨登录的读取和写入吞吐量。图20中的图表显示由2,500个用户的登录及登录之后的每日准备工作的工作负载生成的每秒读取写入操作数。读取操作占 工作负载的 15%，写入操作占 77%。查找操作（未显示）约占剩余的由于用户登录后便开始工作，因此用户的工作负载和后台工作会与登录事件发生重叠。6图20)星期二早晨登录时的每秒取和写入操作数21显示存储控制器为NFS协议报告的延迟。其中显示整个登录期间的读取（平均入（平均0.2毫秒）协议延迟。0.3毫秒）和要与前面的案例一样，在图表上，首次登录时间采用3秒最小取样率在尝试进行首次登录之前，每秒大约有2,000次写入操作，而读取操作寥寥无几。我们对这些操作的来源进行了研究，发现在各VM上运行的系统、svchost.exeservices.exe是这些I/O的来源。有关更多信息，请参见第5.7节的“观察结果和经验总结”。即使每秒操作数增加约100%，登录后的平均写入大小仍然保持4KB图21)星期二早晨登录图21)星期二早晨登录的读取和入协议延迟图22中的图表显示由ESXTOP批处理模式报告并由ESXTOP编译的来宾操作系统延迟。ESXTOP批处理模式使用3秒最小取样率。X轴是取样数。由于该图代表3秒取样率，因此将即可得到真正的运行时间。请注意，延迟对应存储控制器上的延迟（这毫不奇怪）。X轴的值乘3图22)星期二早晨登录的读取和入延如图23中的图表所示，在此期间，平均占用了全部四个物CPU容量的23%图23)星期二早晨登录图23)星期二早晨登录的CPU利用率工作负载和本报告中所列的其他工作负载一样，在I/O大小、顺序和并发数方面，星期二早晨登录场景的工作负载特征也不同以往。回想一下“并发数”的定义，在这里它还是指同时生成以存储为目标的I/O的虚拟图24中列出了读取操作大小及其各自的特征（顺序或随机）。统计数据本身取自计数器管理程序预读图星期二早晨登录的读取操作细要工作负载并不都是同一大小图24中的图表就是细分成了多个操作数分段。每个分段包含介于指定大小与下一报告操作大小并非所有工作负载都是随机的：在所有读取操作中，有50%是顺序读取15记录从虚拟桌面自身角度记录的工作负载（也就是在ESXTOP中捕获的工作负载）。在测试期间，ESXTOP在环境中的所有服务器上持15记录从虚拟桌面自身角度记录的工作负载（也就是在ESXTOP中捕获的工作负载）。在测试期间，ESXTOP在环境中的所有服务器上持续以批处理模式运行，采用最低取样间隔：3秒。在表15中，由ESXTOP生成的图表记录从虚拟桌面的角度记录的并发数、I/OESXTOP所报告。速率和操作大小，表星期二早晨登录时并发数、速率以及读取和写入操作大小在图25中，由ESXTOP生成的图表还显示由来宾操作系统自身在整个登录场景中发布的平均读取和要25中图表显示读取和写入操作在低于4K到大于100KB的大范围内出现波动测量指值VM总IOPS平均平均读取平均写入平均读取吞吐量（MB/秒平均写入吞吐量（MB/秒正在进行读取的VM正在进行写入的VM平均读取大小平均写入大小8平均读取延迟（毫秒平均写入延迟（毫秒1针对一针对所每个正在进行读取的VM的平均读取每个正在进行写入的VM的平均写入2每个正在进行读取的VM的平均读取吞吐量（KB/秒9每个正在进行写入的VM的平均写入吞吐量（KB/秒要平均来讲，在任意给定的一秒，只有4%的虚拟桌面生成读取操作，62%的生成写入操作。因此，无法实现100%并发。如果忽略并发，在星期二早晨登录场景中平均每个虚拟桌面生成的IOPS为2ESXTOP进一步印证了来自存储控制器的数据，该数据表明IOPS高于4KB8KBESXTOP报告的平均IOPS和吞吐量会非常贴近由存储控制器报告的数值图25)星期二早晨登录的读取和入操作大小星期二早晨登录场景的工作图25)星期二早晨登录的读取和入操作大小星期二早晨登录场景的工作负载特征既不4KB也不8KB，而是所有大小的混合 重新启动在星期一清晨，AcmeCorporation在排定的维护时间内遇到网络错误。这一中断对存储控制器服务器之间的通信产生了影响。中断大约在清晨:0时结束，距离员工8点之后陆续上班开始一天的工作，虚拟桌面管理员只有一个多小时的时间来确保所有,0个虚拟桌面均可用。为了确认虚拟桌面全部可用，管理员选择了完全重启。首先关闭所有的虚拟桌面并确认已关闭，然后再次启动。启动所,0个虚拟桌面，直到所有/O稳定处于正常的用户登录前状态，仅仅用了0多分钟。所有用户均不受影响。实际vtr集中控制：选择所有,0个虚拟桌面并由vtrVtr限定每次只能并发执行8个启动操作，每个虚拟桌面成功启动之后会退出服务中心，等待队列中的剩余操作就会填补空缺。因此，确定启动操作大小时，每个桌面生成的总PS，而不是乘以环境中剩下的所有虚拟桌面。批量启动成功之后，虚拟桌面便会处于闲置状态，等待开始一天的工作。周周周周周周周2,500登录+82,5001234562有VM82,500（30分钟（启动后782,50089系统如表16中所述，存储控制器的性能处于较高水平。请注意，在整个启动过程中，读取系统如表16中所述，存储控制器的性能处于较高水平。请注意，在整个启动过程中，读取操作占主导地位，存储控制器对CPU的利用一直处于完全利用状态。批量启动场景的目标是尽快启动所有虚拟桌面。请注意，吞吐量和并发（而不是延迟）是批量启动场景中的主导因素。要了解更多详细信息，表16可以从吞吐量、每秒操作数和延迟以及启动时间等方面，对Data8.0.18.1进行对比16重新DataONTAP8.0.18.1的对比结果为简洁起见，从现在开始，本节将使用图形详细介绍DataONTAP8.1配置。我们观察到8.0也具有类似的曲线和指标，但吞吐量较低，如表16中所述。26中的图表显示启动2,500个虚拟桌面时生成的读取和写入吞吐量。读取操作占网络传输数据的（569MB），写入操作占剩余的9%（56MB）图26)启动时的读取和写入吞吐图27中的图表显示启动2,500个虚拟桌面时生成的每秒读取和写入操作。读取操作占NFS工作负载的80%，写入操作占10%。查找操作（未显示）约占剩余的10%。由于用户登录后便开始工作，因此秒55秒4毫3毫36分秒56秒2毫1毫21分8.1新增了虚拟存储分层等技术增强功能，因此从DataONTAP8.0.1升级到8.1之后，启动时缩短42%（从36分钟缩短到21分钟）要图27)启动时图27)启动时的每秒读取和写入操图28中的图表显示存储控制器为NFS协议报告的延迟。其中显示整个启动期间的读取（平均2毫秒）和写入（平均1毫秒）协议延迟。这些延迟之所以都很低，是因为VM全都是共享磁盘上、闪存中（从DataONTAP8.1开始因受益于虚拟存储分层功能还包括RAM中）许多相同数据块的克隆副本。克隆VM的这些特性可以实现极其快速的访问。图28)启动时的读取和写入协议ESXP不能获取启动操作，因此没有从虚拟桌面角度记录启动工作负载的图表。由于虚拟桌面开始启动之后，首先显示在ESXP中，而且由于批处理模式中的ESXP只打印一次标题行，因此我们没有有效的方法来获取数据并输出有意义的数据。29中的图表所示，在此期间，平均占用了全部四个物理CPU容量的97%图29启动期间的CPU图29启动期间的CPU利用率工作负载和本报告中所列的其他工作负载一样，在I/O大小、顺序和并发数方面，启动场景的工作负载特征也不同以往。“并发数”在此指的是同时执行启动操作的虚拟桌面的数量。请记住，当前的vCenter只允许同时启动128个虚拟桌面，其余的要排队等候。图30中列出了读取操作大小及其各自的特征（顺序或随机）。统计数据本身取自计数器管理程序预读图30)启动时的读取操作细分。要工作负载并不都是同一大小图30中的图表就是细分成了多个操作数分段。每个分段包含介于指定大小与下一报告操作大小并非所有工作负载都是随机的：在所有读取操作中，有50%是顺序读取尽管ESXTOP可能不会用于该特殊工作负载，但是会收集以下信息8个虚拟桌面同时启动时每个桌面每秒的平均读取和写入操作数。该数值不会考虑虚拟桌面启动后生成的操作，但是基本上满足我们的目的：128个虚拟桌面中尽管ESXTOP可能不会用于该特殊工作负载，但是会收集以下信息8个虚拟桌面同时启动时每个桌面每秒的平均读取和写入操作数。该数值不会考虑虚拟桌面启动后生成的操作，但是基本上满足我们的目的：128个虚拟桌面中每个桌面每秒的总操作数：323次操作/（读取操作：281次操作/秒，写入操作：42次操作/秒如果忽略由vCenter规定的128个虚拟桌面同时启动的限制，将上面的每秒操作数除以全部个虚拟桌面，每个桌面每秒的操作数将计算如下128个虚拟桌面中每个桌面每秒的总操作数：16次操作/（读取操作：14次操作/秒，写入操作：2次操作/秒但是这样做并不安全。随着环境中虚拟桌面数量的减少，该方法计算的每秒操作数会增加；而实际上当虚拟桌面数量增加时，每秒操作数应该是减少的。星期一早晨登录对,0个虚拟桌面进行硬重启会清除每台机器内存中的内容。正因为如此，每个用户的配置文件均需/实际在该报告获取的所有登录和工作负载场景中，用户登录速率确定为每秒大约3次，而首次登录与最后录间26分钟在星期一早晨登录之后，所有用户均开始各自当天的工作。VMwareDesktopRAWC控制环境中的所有工作负载，它会打开应用程序并代替人工键盘控制。RAWC在每个虚拟桌面上执行以下任务：为每个用户打开MicrosoftWordExcel，并在其中创建新文档并保打开MicrosoftPowerPointAdobeAcrobatReader，查看其中现有的文档打开MicrosoftInternetExplorer从Outlook客户端写三封电子邮件并发RAWC随机确定每个虚拟桌面上的各个应用程序的运行顺序用户表17报告用户群体在星期一早晨的启动后登录场景期间登录所花费的时间周周周周周周周2,50082,500123456凌晨2点网络中断VM82,500（30分钟（启动后782,50089表17)星期一早晨登录的用户体（以秒为单位）注意：48450GBFC15K驱动器的FAS3270，环路速率：4GbpsLiquidwareLabsStratusphereUX衡量标准，100%用户获得“好”登录体验（花费时表17)星期一早晨登录的用户体（以秒为单位）注意：48450GBFC15K驱动器的FAS3270，环路速率：4GbpsLiquidwareLabsStratusphereUX衡量标准，100%用户获得“好”登录体验（花费时间少于秒）。表18显示星期一早晨登录的用户体验表18)星期一早晨登录的用户体验（）注意：48450GBFC15K驱动器的FAS3270，环路速率：4Gbps系统如表19中所述，存储控制器的性能处于较高水平。请注意，无论从每秒MB角度还是从IOPS角度说，虚拟桌面和存储控制器之间传输的工作量都是读取操作占大部分。总体来讲，读取操作占数据传输量的80%，60%的IOPS传输给存储控制器。要了解更多详细信息，表19可以从吞吐量、每秒操作数和延迟方面，对DataONTAP8.0.18.1进表19星期一早晨登录期间DataONTAP8.0.1与8.1的对比结果为简洁起见，从现在开始，本节将使用图形详细介绍DataONTAP8.1配置。我们观察到8.0也具有类似的曲线和指标，但吞吐量较低，如表19中所述。130秒40秒1.20.9DataONTAP180秒49秒0.40.5要无论是读取请求还是写入请求，存储控制器在协议级别的平均响应速度均小于1毫秒配用户总超过15秒）用户百分“一般”登录时（15秒且不60秒）用户百分“差”登录时（不少60秒）DataONTAP100%（平均1秒DataONTAP100%（平均1秒配DataONTAP150.3DataONTAP120.3要无论使用何种版本的DataONTAP，多数用户在星期一早晨登录时用时均为1秒图1中的图表显示由0图1中的图表显示由0个用户的星期一早晨登录及登录之后的每日准备工作的工作负载生成的读取和写入吞吐量。用户登录后就开始工作，因此应用程序负载与登录和配置文件负载产生重叠。读取操作占网络传输数据的%（0MB）%（9MB）。图31)星期一早晨登录的读取和写入吞吐量。图32中的图表显示启动2,500个虚拟桌面时生成的每秒读取和写入操作。读取操作占NFS工作负载的62%，写入操作占37%。查找操作（未显示）剩余的1%左右。用户登录后便开始工作；因此用户图32)星期一早晨登录的每秒读取写入操作数图33中的图表显示存储控制器为NFS协议报告的延迟。其中显示整个启动期间的读取（平均和写入（平均0.5毫秒）协议延迟。0.5毫秒图33)星期一早晨登录图33)星期一早晨登录的读取和写延迟（以秒为单）图34中的图表显示由ESXTOP批处理模式报告并由ESXTOP编译的来宾操作系统延迟。ESXTOP批处理模式使用3秒最小取样率。X轴是取样数。由于该图代表3秒取样率，因此将X轴的值乘以3即可得到真正的运行时间。请注意，尽管有一些异常值，但是这些异常值并未超出LiquidwareLabsStratusphere所定义的“好”延迟限值范围，而且绝对不会在取样时间间隔内长时间出现。此图表中的平均延迟如下读取操作：1.7毫写入操作：1.9毫图34)星期一晨登录的来宾操作系读取和写入延迟如图35的图表中所示，在此期间，平均占用了全部四个物CPU容量的61%图35)星期一早晨登录的CPU图35)星期一早晨登录的CPU利用率工作负载星期一早晨登录场景还显示广泛分布的操作大小，并且I/O中包含的随机/顺序操作数较为均衡。回想一下“并发数”的定义，在这里它还是指同时生成以存储为目标的I/O的虚拟桌面数。图36中列出了读取操作大小及其各自的特征（顺序或随机）。统计数据本身取自计数器管理程序预读图星期一早晨登录的读取操作细表20记录从虚拟桌面自身角度记录的工作负载（也就是ESXTOP中捕获的工作负载）。在测试间，ESXTOP在环境中的所有服务器上持续以批处理模式运行，采用最低取样间隔：3要工作负载并不都是同一大小图36中的图表就是细分成了多个操作数分段。每个分段包含介于指定大小与下一报告操作大小随机和顺序操作的工作负载较为均衡：在所有读取操作中，有56%属于顺序操作在表20中，由ESXTOP生成的图表记录从虚拟桌面的角度记录的并发数、I/OESXTOP所报告。速率和操作大小，表星期一早晨登录时并发数、速在表20中，由ESXTOP生成的图表记录从虚拟桌面的角度记录的并发数、I/OESXTOP所报告。速率和操作大小，表星期一早晨登录时并发数、速率以及读取和写入操作大小在图37中，由ESXTOP生成的图表还显示由来宾操作系统自身在整个登录场景中发布的平均读取和要读取和写入操作在低于4K