【VMware虚拟化解决方案】 基于VMware虚拟化平台VDI整体性能分析与优化

一、说一说

       本来打算将前期项目里面出现的问题的分析思路与解决方法写出来，第一、疏导一下自己的思路，第二、分析并找出自身在技术层面所存在欠缺。但由于每个人都有一根懒经所以迟迟未动。今天突然发现51CTO在做VMware【展现虚拟化商业价值】解决方案的征文活动，看着那丰厚的奖品，让我这根懒经顿时兴奋！决定将前期的一个分析思路与解决方法写下来，一来供朋友们参考，二来借助专业大师帮忙分析分析思路是否正确。由于其中涉及公司的一个相关机密所以相应的资料信息会明确的更少一些还请见谅！由于我们的服务器虚拟化、桌面虚拟化都是采用一套存储，本来想将整盘的分析过程写下来，但发现如果加上服务器虚拟化与RDS虚拟化以后篇幅太长了，为此这里仅仅只说VID平台。

二、项目背景

       13年5月份我刚刚来到现在的这家公司，主要负责项目规划、设计、实施。刚过来没几个月，就跟着两个领导和几个同事在讨论关于购买新存储的问题，由于刚开始进去不是很了解发生了什么情况，大约听了半小时才听出了一些眉目，原来是因为虚拟化平台的性能不够，造成用户反馈服务器端、VDI、RDS速度慢，所以要购买新的存储解决这个问题。这时候CIO问我什么看法，都说初生牛犊不怕虎，当然本身个人也是一个只对技术不对人的，所以直接说了一些自己的看法：“我个人觉得，虚拟化平台的性能不行不能单纯的说是存储上面的性能出现了问题，由于其本身是一个复杂的系统涉及服务器、存储、网络、应用、客户端等多方面因素，所以我觉得我们首先应该去分析造成这个事情的真正原因，假如我们将存储买回来，结果还是未能够解决这个问题，怎么办了？到时候BOSS们怪罪下来，不说个人就整个部门而来带给领导的都是一种非可信的影响，到时候我们要再申请项目想得到公司的支持，将是一件比较痛苦的事情，所以我觉得应该从最基础的原因分析找到解决方法，这时候我们再去提出需求将不失为一个可行的方法。”CIO听了我的话大概觉得我这个想法和思路的可行性比较好，立马传音“东妮，这个就由你来带头处理吧，有什么需求你直接提出来！”，这不是坑我吗？顿时让我一身冷汗，心想我就这么一说，这就让我来处理，我还不了解情况了，用网络语言说这不是坑爹吗？！CIO发话不愿意也不行啊，除非你不想混了。后来才知道这个问题已经存在于公司快一年了，而且之前也有请过一些做虚拟化的公司来分析过，但最终都不了了知！不愧是全国十佳CIO，做事就是不一样，这么难吭的骨头给我吭，还让我活吗！从那以后的三个月的时候我基本上没有很好的休息过，就连晚上做梦还在想怎么解决这个问题。那是一段痛苦的回忆，也是一段让我磨练的经历。

说了这么多废话，开始进行正题吧！

三、性能分析

       由于刚刚进入公司不久，对于整体的虚拟化架构不是很了解，所以在此之前我对虚拟化架构进行了深入的了解，包括服务器、存储、网络、应用、虚拟化技术等。

       服务器方面：采用的是服务器端虚拟化采用的是IBM x86服务器，桌面虚拟化（VDI）、RDS虚拟化采用的是HP服务器（前期淘汰下来的一批服务器利旧）。

       存储方面：采用了两台EMC存储VNXe3100，这个存储型号现在已经停产了，为iSCSI存储档次有一点低。为了实现存储容灾我们在两个不同的机房做了DataCore软件镜像同步，实现对存储的高可用，以保证在一边存储故障的时候，不影响生产业务。

       网络方面：服务器之间双线路千兆网络、核心交换采用千兆交换、大数据采用光纤存储、百兆到桌面。

       应用系统方面：目前跑在虚拟化上面的应用系统大约有十个左右用户量2000人左右，所有的数据都存放在这两台存储上面，其实RDS、VDI、虚拟服务器系统都存放在这上面，所以相对来说存储的压力是比较大的。

       服务器应用方面：基本上所有的服务都跑在这两台存储上，包含Web、DHCP、DNS、AD等等

       虚拟化技术：采用VMware虚拟化技术，服务器虚拟化采用ESXI5.0，桌面虚拟化与RDS采用ESXI5.1双平台。

通过前期的了解，我们大概知道了整体的虚拟化架构情况，下面我们从以下几点开始入手进行分析：

• 整体网络架构

• 存储设备分析

• 服务器设备性能分析

• 网络设备性能分析

• 用户端问题分析

• 应用系统分析

• vCenter Operations Manager数据分析

（一）、整体网络架构

       为了让博友能够更加的了解网络情况，我画了一个简单的网络拓扑，如上图所示，具体情况我这里简单叙述一下：

VDI、RDS服务器：分别采用两条千兆双绞线连接到网络，然后通过iSCSI协议读取相应的用户数据与系统数据，用户数据与系统数据分别存放于VNXe3100不同的LUN上，主机房与容灾机房之间前的数据同步通过存储同步服务器实现复写。

存储磁盘配置：600GBSAS 15KRPM、2个热备盘、2组5个盘的Raid5。

存储同步服务器：采用软件DataCore实现数据复写，部署于刀片上。

虚拟化用户量：RDS用户150、VDI用户120

简单分析：

从架构上来说，没有什么太大的问题，实现了机房容灾。但需要注意以下几点：

• 存储磁盘的配置是否满足现有业务系统需求;

• 千兆线路的服务器与存储接入是否满足需求;

• DataCore同步复写情况下的，数据写入写出情况与响应速度是否正常;

• VDI、RDS、包括服务器虚拟化整体平台的服务器平台硬件本身性能是否正常;

• 网络设备的吞吐量是否能够满足现有需求;

• 用户端百兆接入是否正常;

• 瘦客户机性能是否满足需求;

带着以上问题，我们对现有存储、服务器、用户端、网络、应用系统从软件到硬件进行一次大的盘查。

（二）、存储设备分析

       为了提高分析数据的准确性，我们在公司业务最繁忙的时候，提取了存储一个月的相关信息进行分析，结果如下所示：

主机房存储SPA CPU：

结论：

     从上图我们可以看到，A控制器的CPU使用率并不是太高，空闲率大于50%，说明CPU的使用情况正常。

主机房存储SPA Network：

结论：

     通过分析bond0（即eth2+eth3）的网络性能，基于现在使用的是千兆的网络适配，相应的值使用均在一个正常的范围，并没有负载过高的情况。

主机房存储SPA Disk：

结论：

     通过Avg Response Time (平均响应时间)，我们可以发现在SPA上所有的LUN平均时间均在5ms以下，全在一个正常的响应范围。如果平均响应时间大于50ms那说明相应的磁盘可能存在问题。

主机房存储SPB CPU：

主机房存储SPB Network：

主机房存储SPB Disk：

结论：

     由于所有的应用全部是在SPA上，所以SPB上相应的使用率均非常低，有些数据由于没有使用到所以为0，由此我们可以看出在存储的配置上面存在一些问题，未能充分发挥其存储性能。

容灾机房存储SPA CPU：

结论：

     从上图我们可以看到，A控制器的CPU使用率并不是太高，空闲率大于50%，说明CPU的使用情况正常。由于容灾机房存储主要用于与主机房存储进行同步，所以其性能消耗基本上与主机房无异。

容灾机房存储SPA Network：

结论：

     通过分析bond0（即eth2+eth3）的网络性能，基于现在使用的是千兆的网络适配，相应值的使用均在一个正常的范围，并没有负载过高的情况。

容灾机房存储SPA Disk：

结论：

     通过Avg Response Time (平均响应时间)，我们可以发现在SPA上所有的LUN平均时间均在9ms以下，全在一个正常的响应范围。如果平均响应时间大于50ms那说明相应的磁盘可能存在问题。

容灾机房存储B控：

     由于所有的应用全部是在SPA上，所以SPB上相应的使用率均非常低，有些数据由于没有使用到所以为0，这不再截图说明。

分析总结：

     通过分析此两台EMC VNXe3100设备的相应性能数据，确认设备本身并没有存在相应的性能问题，目前设备性能均在一个正常的范围。但是我们发现所有的资源均配置在单边的SP上（即SPA上），这种配置会导致SP负载不平衡。所以我们可以将数据平均的分配到不同的SP上（即SPA、SPB上），这样对于设备的性能将会有一定的帮助。

但有一点值得我们深思的问题就是，存储本身性能数据显示并未存在太大问题的情况下，用户端反应为什么会比较慢了，根据用户端的现象是因为存储的响应速度太慢造成的啊！带着这个问题我们继续后面的分析，看看在后面否找到答案。

     从存储的磁盘配置性能来看，存储由600GBSAS 15KRPM、2个热备盘、2组5个盘的Raid5，我们可以通过上述分析得到它的IPOS值大约为：8*175+4*175=2100IOPS，根据原厂的说法大约IOPS值在2160IPOS左右，我们可以看到其实本身存储的IPOS值不是很高。

      而就iSCSI传输协议来看，其本身的命中率与传输速度而言比较低，从下图中我们可以看出，iSCSI协议下数据的传输过程中需要经过多次的封装与拆解包的过程，就目前而言iSCSI 1Gb/s的网络带宽所能够输入的数据大小为80MB-90MB/s采用全双工模式在160MB/s,而FC 1Gb/s的网络带宽所能够输入的数据磊小为190MB/s采用全双工模式在360MB/s，速度是iSCSI的好几倍，所以iSCSI存储是不是造成存储性能的瓶颈需要我们更加深入的分析了。

（三）、服务器设备性能分析

VDI服务器规格

主机型号：HP DL380G5

CPU：Intel Xeon E5405 4C*2

RAM：8G*8

DISK：300G*2

Raid配置：Raid1（主要用于存放ESXI系统）

VDI01和VDI02服务器CPU使用性能如下所示：

结论：

     从性能图观察得知，两台VDI主机在使用高峰期均处于超负荷运行，各物理服务器CPU远远无法满足现有虚拟机需求(需求超过180%，接近已有CPU资源近2倍)。这是造成用户端反应慢的原因之一。

VDI01和VDI02服务器内存、网络使用性能如下所示：

结论：

     VDI主机网络资源明显不足，网络流量负载持续居高不下。这也是造成用户端反应慢的原因之一。

     另在分析的过程中，我们发现用户的资源配置合理化程度不够理想，简单说就是有些用户配置4个vCPU,有些用户配置4G内存，而这样子的资源配置，是造成资源调度紧张的另一个重要原因。

（四）、网络设备性能分析

     为验证整个平台的网络状况，为此我们对网络的流量、网络延时进行了分析、汇总，发现整体用户应用平台网络未见大数据异常。

结论：

     整体网络并未存在瓶颈，需要单独分析各服务器网卡的性能。

（五）、用户端问题分析

1) 电脑反应很慢，无法得知原因，打开文件都很难;

2) 在快下班的时候，还没关机就被自动退出了。提示为（见截图）已经连续 2天，重新登陆还可以继续用;

3) 打开的网页太多，导致登陆时链接不到桌面（显示蓝屏）;

4) 打开人力资源管理系统，进行数据修改导入导出时速度较慢，测试实体机正常;

5) 当打开大图片，如100MB左右的图片时显示会一格一格跳动显示出来，速度较慢;

6) 当打开较大PPT时，如20页面左右的时候OFFICE PPT软件会出现卡死的情况;

7) 当EXCHEL文件拖动时，会出现拖动卡住的情况;

8) VDI无法连接到远程桌面，提示桌面源正忙;

9) VDI虚拟机CPU使用率经常会到100%无法操作;

10) VDI部分用户因资料较多，经常反馈因空间不足而无法正常使用的问题;

11) VDI计划任务有时会执行不成功;

12) VDI直接连接打印机易出现无法打印的现象;

13) VDI用户从VDI01主机无法迁移到VDI02主机;

14) VDI个别用户出现在登陆后无法显示D盘（映射盘），处理正常后打开邮箱邮件出现丢失现象，使用的是foxmail客户端;

15) VDI有个别用户在登录后桌面文件不见，打开我的电脑无盘符;

16) VDI ESXI主机经常出现cpu高负载报警，后续增加虚拟机性能无法满足;

17) VDI用户使用速度慢，出现系统卡机以致无法登陆系统;

18) VDI用户在使用时慢时，迁移至另一台主机或者更换存储后速度有所提升，但是过几天之后又会变慢，再迁回原来的上面时，速度又有所改善，始终无法解决这个问题;

19) VDI性能不够稳定，偶发故障较多;

用户问题汇总：

在这里我们看到的只是整个问题的五分之一，但从用户的角度出发这现问题确实是存在的，我们需要找到对应的问题点所发生的原因，通过以上的问题我们可以很清楚的发现其实很多问题是因为并发症产生的，就是人生病一个道理，本来这个人只有胃病，结果因为胃功能不行，造成肠胃出现问题等，而我们需要从这些用户提出的问题里面去剥丝抽茧，发现真正的病症所在。

为此我们分析了用户提出的所有问题，并进行分类汇总大概分为以下几类：

• VDI操作系统本身问题

• 瘦客户机问题

• VDI服务器问题

• View软件配置问题

• 网络问题

• 存储问题

• 用户端作业问题

• 服务器端作业问题

• 应用系统问题

      我们将以上出现的问题，全部按号入位，也许有些朋友可能觉得这样子处理没有什么用，因为上面所提到汇总可能性都会有，其实如果我们对号入位，再进行分析就更加有利于我们做故障排除了！

     通过对于以上用户问题分类汇总，为了确认用户端的问题点所在，我们通过采用PCoIP协议客户端分析工具对一些问题客户端进行了数据采集，详细如下所示：

根据上面的分析我们可以结合VMware官方图例进行整合分析：

通过数据采集我们可以得到类似如下数据：

Imaging Bytes Sent（图像发送字节数）：30MB

Bytes Sent（发送字节数）：29MB

Imaging Encoded Frames/Sec（每秒的图像编码帧数）：12（峰值）

Imaging Active Minimum Quality（图像存活最低值）：90（峰值）

Imaging Decoder Capability（图像解码值）：600 （峰值）

Packets Sent（包发送值）：150000

TX Packets（发送数据包）：1

RX Packet Loss（接收数据包损失值）：1

TX BW Limit kbit/sec（发送限量千比特值每秒）：90000

TX BW Active Limit kbit/sec（发送活动限量千比特值每秒）：10000

RX Packets（接收数据包）：1

结论：

     通过以上数据显示，我们再根据本身VDI客户端即瘦客户机的性能参数进行对比分析（如果官方不能提供专业的数据，你需要自身去检测并分析这些数据，简单说当用户在反应很慢的时候进行数据采集，再在用户端正常的情况下做一次数据采集进行对比），为此我们对用户反应慢的进行了数据采集并分析，发现当用户慢的时候有不同情况发生，有些用户显示状态为网络流量瞬间高峰（在Excel大数据100MB左右的进行上下拖动时），有些显示图像解码数据高峰（在用户端查看100MB左右的图档时）。所以我们需要根据不同用户的应用作业再进行分析。

（六）、应用系统分析

DataCore下存储的性能分析：

     统计数据显示，存储负载情况无论服务器虚拟化平台还是桌面虚拟化对应的磁盘均存在性能瓶颈，在使用高峰期表现更突出。

       根据各存储中运行的虚拟机所跑的应用不同，其IOPS值也不同，IOPS很大程度上制约和影响VM虚拟机性能。图中红色曲线为Datacore总IOPS值，可以看出峰值基本在2500 IOPS，而我们在前面预算EMC VNXe3100的时候总IOPS大约在2100左右，这是的值已经超过了存储本身的IOPS值，为什么他还能达到这么多了？而且前面我们分析EMC存储性能的时候，它根本没有多大的压力，这就是问题的所在点之一了。

       同上图一样，VDI、RDS用户对IOPS的需求并不大，此图也可看出其存储写入最长滞后时间也不明显，表明VDI用户写数据需求并不高，结合下图的读取滞后时间，可看出虚拟桌面用户对读数据的需求明显高于写数据的需求，而服务器对读、写则表现得并不明显，均不够理想。另外可从该图观察到，高峰期黄色、蓝色曲线很多地方重合，可以看出相互之间出现制约(争用)情况，存储资源不足。

      主存储因此无论是读取滞后时间还是写入滞后时间较其他存储LUN需求均要高，这也是导致业务系统高峰期出现访问慢之重要因素之一。紫色曲线代表的是存放VDI、RDS用户配置读取滞后时间,可以看出桌面用户对读取的需求明显大于写入，此部分有待改善存储性能。

DataCore服务器性能查看：

结论：

由于我们的DataCore版本不具有Recording的功能，所以只能分析出部分静态点的数据。

从既得数据中大致可以看到如下的情况：

• 本身的磁盘系统性能低下已经不太能适应主机HOST系统的需求;

• Datacore软件本身已经达到链路的最高负载;

• DataCore内存资源使用奇高，这个DataCore的机制有关系，采用内存做为Cache;

• DataCore的实现机制和普通的Raid的Block块大小的实现是不一样的，DC在针对OS HOST做了优化不是应用层。SAU（storage allocation unit）在PDISK固定后无法做到在线无影响业务系统的调整，而是采用针对SAU在Reclamation后将PDISK进行切片进入Caching 和聚合写入。除非应用是裸设备级别（比如Linux上的Oracle）的，这个得需要根据你们DBA的需求进行调整。

（七）、vCenter Operations Manager分析

       由于没有vCenter Operations Manager for Horzion View 许可，所以在分析的时候我们借助vCenter Operations Manager来进行分析，它可以提供对应的服务器的使用情况与使用性能等信息，通过此查看到对应的服务器使用情况，如下图所示：

存储磁盘I/O:

服务器的CPU:

结论：

       从这里我们不难看出桌面虚拟服务器与数据存储的性能已经完全超出了服务器与存储本身的性能，而且CPU的使用情况等与之前我们对VDI服务器性能分析基本一致，所以服务器慢是必然的。

通过以上一系列的系统性能数据采集、用户问题反馈分析并整理，从里面我们不难看出这个虚拟化平台在整体上都存在比较大的问题，我们可能需要对他的整体架构进行调整并优化以达到目标需求。

四、解决方案

（一）、网络资源调整

     就整个结构而言它是正确的一种方式，能够实现对于高可用性、容灾性的一个需求，但是对于局部我们还需要调整，即千兆光纤由于此光纤上承载着大数据与生产数据，在整体网络流量与吞吐量上我们发现光纤流量较大，我们需要扩展光纤到万兆以保证DataCore数据在复写过程中的高速。

另VDI服务器的网卡我们做了四个网卡的聚合配置，两两一组，一组用于跑系统数据，一组用于跑用户数据，实现数据的合理化走向，实现数据分流负载效果。

（二）、VDI服务器配置

     本想通过View Composer 来减低系统对于存储的压力，但是由于License原因，未能进行调整，还是采用全克隆模式进行配置。

     在分析过程中我们发现VDI用户的配置是一个比较乱的状态，用户硬件配置没有一个有效的标准，这时候造成有些用户资源过剩，有些用户资源欠缺，用户系统空间与数据空间缺乏，为了平衡用户的需求，我们制定了相应的标准，即将用户分为两个等级，不同用户给于不同等级的资源需求。为此我们调整了用户的标准系统硬件配置，以保证硬件资源的合理化分配，具体资源分配情况如下：

     当然我们也可以参考官方的一个配置方法，这个可以根据公司的需求进行灵活调整，最终目的即保证资源的合理化分配。

     在对View服务器的检测过程中我们发现对应的Cache功能未打开。通过VMware View administrator 管理平台进行设置，详细设置如下：

     此功能用于实现将内存做为Cache使用即内存Cache技术，当有多个VDI或RDS用户同时打开相同的数据时，它将直接从Cache中调取，而不需要再打开相同的数据，以提高响应速度和减轻存储负担。并且采用重复数据删除技术，将同样的数据只保留一份。

     通过使用VMware提供的存储优化技术，将以往存储设备的读写操作转移到虚拟化服务器的内存中，存储设备的IOPS数量以及带宽开销大幅下降：

• 消减超过80% IOPS峰值

• 消减超过45% 平均IOPS值

• 消减超过65% 吞吐量峰值

• 消减超过25% 平均吞吐量

     存储优化设置，将不同类型的数据分别放至到不同类型的存储中，可以减少存储成本，提高整体环境的性能，我们将用户数据与操作系统数据放于不同的LUN中，以提高用户的访问速度，这里我们可以根据公司情况分析，再进行LUN下的RAID调整，例如：用户数据采用RAID1+0，系统数据采用RAID5，这样子以提升整体速度。

（三）、存储系统配置

     虽然在存储系统的整体上面并未显示出来存储本身存在问题，但似乎我们看到的仅仅是表面现象，造成这个的原因在于DataCore，你可以说它是一个好东西，能够提到Cache功能，但你又可以说到是坏东西的，因为它造成了本身存储的性能发挥，当然这里指的是未调优的DataCore,在调整DataCore的过程中，我们发现调整以后的DataCore对于存储的链路带宽要求会比之前要求更高，为此我们调整了存储的存储链路：即采用A、B两控制器同时工作负载，以降低存储本身单控模式下的链路负载过高问题。

1）基于DataCore下的ESXI服务器性能调优

ESXI高级设置调整：

• Disk.DiskMaxIOSize to 512  

• Disk.QFullSampleSize to 32  

• Disk.QFullThreshold to 8  

说明：

• 同一虚拟磁盘上运行的虚拟机数量过多可能会导致主机之间SCSI预留冲突，继而导致性能下降。

• DataCore软件建议每个虚拟磁盘最多不超过十五虚拟机。 当然，这仅仅是一个建议因为每个用户的要求将是不同的，并且不应当被作为DataCore的服务器软件的限制。

• DataCore软件还建议用“最接近”的IO路径DataCore的服务器的主机，访问同样的共享虚拟磁盘，因为这也将有助于减少过度的SCSI预留冲突的可能性。

• “固定”和”轮转”路径选择策略只支持在具有“ALUA支持”主机启用。

• 在不同的主机,不同的路径选择策略不能使用到相同的虚拟磁盘。

1.在主机配置存储阵列规则，任何DataCore磁盘映射到主机。在ESX控制台运行以下命令：

For SANsymphony-V：

esxcli storage nmp satp rule add -V DataCore -M "Virtual Disk" -s VMW_SATP_DEFAULT_AP -e "DataCore"  

For SANsymphony：

esxcli storage nmp satp rule add -V DataCore -M "SANsymphony" -s VMW_SATP_DEFAULT_AP -e "DataCore SANsymphony"  

For SANmelody：

esxcli storage nmp satp rule add -V DataCore -M "SANmelody" -s VMW_SATP_DEFAULT_AP -e "DataCore SANmelody"  

2.通过运行验证命令：

esxcli storage nmp satp rule list -s VMW_SATP_DEFAULT_AP  

确保正确的模型类型为宜。如果你需要删除存储阵列式，索赔规则在主机再使用相同的命令，而是添加使用去除如

esxcli storage nmp satp rule remove -V DataCore -M "SANsymphony" -s VMW_SATP_DEFAULT_AP -e "DataCore SANsymphony"  

3.DataCore建议你总是验证正确的存储阵列的类型和路径选择策略，在主机选择，要么使用vSphere客户端GUI或从主控制台，例如：

esxcli storage nmp device list | grep -C 3 DataCore  

这个命令将列出配置各自的存储阵列的类型和路径的DataCore设备选择策略。

2）ESXI5.5 HBA QD与ET

     QD与ET是影响整体性能的一个最大因素，设置阀值决定了HBA端口同时能流入到SAN最大的I/O的数量。它的设置直接影响到前端应用的存储性能，例如对于典型的关系数据库应用，如果队列深度设置过低，则应用的I/O吞吐量则会受到影响。如果这个值设置得过大，则单台服务器可能会影响到整个SAN网络的性能表现。设置队列深度需要根据不同的应用与性能要求综合考虑决定。

该表列出了默认队列深度值QLogic HBA上各种的ESXi/ESX版本：

详细配置说明：

1、查看HBA卡的类型

For QLogic:  
# esxcli system module list | grep qla    
For ESXi 5.5 QLogic native drivers:    
# esxcli system module list | grep qln

For Emulex:  
# esxcli system module list | grep lpfc

For Brocade:  
# esxcli system module list | grep bfa

2、设置并调整对应队列深度

For QLogic:  
# esxcli system module parameters set -p ql2xmaxqdepth=64 -m qla2xxx    
For ESXi 5.5 QLogic native drivers:    
# esxcli system module parameters set -p ql2xmaxqdepth=64 -m qlnativefc

For Emulex:  
# esxcli system module parameters set -p lpfc0_lun_queue_depth=64 -m lpfc820    
For ESXi 5.5 Emulex native drivers:    
# esxcli system module parameters set -p lpfc0_lun_queue_depth=64 -m lpfc

For Brocade:    
# esxcli system module parameters set -p bfa_lun_queue_depth=64 -m bfa

当然这个需要根据应用的不同去调整，如果你不是很了解对应的需I/O的话，你的调整有可能更加影响ESXI与存储之间的本身性能，为此你不需要不断的去尝试并逐步修改，以满足自身需求。

3）IOPS与RAID

     为实现每个用户的合理需求，我们重新对IOPS值进行评估并规划，为此我们重新调整存储阵列与用户应用、系统、数据之间的关系，当然这只是对于后期大并发用户需求的一个规划：

     如果你需要更加清楚的规划VDI的话，你可以尝试使用这种方法，他的好处在于将不同的数据存储于不同的存储阵列，根据用户数据的属性进行规划，即读写IOPS需求。

     这里说明一下，存储的性能不能够单单从存储的IOPS值进行计算，它涉及到其它更多方面，包括：存储、网络、主机、Cache、HBA卡、Raid类型等多方面，这里简单说一下IOPS的计算方法：磁盘类型数据*单盘IOPS值=IOPS总值，当然这仅仅只是对于磁盘方向的考虑。还有另外一种计算方法，与RAID阵列的块大小有关系，块的大小不同得能提供的读写IOPS也不一样。在涉及到应用系统存储规划时需要根据不同的应用系统的IOPS需求进行分析并规划。

     简单的说如果你的HBA卡只有1Gbps的带宽，而你的IOPS值再高也没有什么太多用，因为它在HBA卡处已经受限制了，此外IOPS的值与本身CPU处理IOPS的能力也有关系，CPU处理不过来也是白搭。为此你需要全面分析这里面的所有可能避免造成性能瓶颈的环境因素。

（四）、网络系统配置

     在分析中我们发现VDI服务器在千兆网卡模式下的数据带宽不能满足需求，为此我们增加了新千兆网卡，并做了网络聚合捆绑。以解决VDI服务器本身网络瓶颈。

     由于交换机的配置比较多，这里略过仅举例说明。当然你还需要在对应的VDI服务器上做vSwitch以实现数据分流。

（五）、用户作业系统配置

     其实我们会发现用户作业系统的配置是造成整体VDI性能下降的一个非常关键的因素，举例：你会发现当一个用户因为某个应用系统的问题，造成应用程序卡死，这时候用户对应的CPU、内存会100%的运行，这无疑为VDI服务器增加了不必要的压力，为此我们花了大量的时候去进行分析，测试、调整、再测试、再调整，终于测试出一个符合我们自身需求的配置，当然对于不同企业不同环境而言需求可能不一样。调试过程也会有所不同，这里我们分为三个方面进行分析并进行调整：

1）VDI系统模板优化

     此优化基于Win7，优化工作完成之后请记得将该用户的所有配置文件COPY到DEFAULT USER目录下，因为虚拟桌面用户会以各自域用户的身份登录，如果仅仅在当前用户下进行了性能优化，将该机器以克隆模板发布出去的时候，其它用户登录进来，并不会自动应用这些优化设置。这个是VMware官方给到的优化方案，详细情况请查看官方文档。

     此优化可用于WinXP、Win7、Win8，当然你还可以往里面添加优化项，为此我们验证了此优化项相对于各相指标的优化情况，减少90%的IPOS需求，节省10%内存需求，降低37%的CPU需求。

2）PCoIP协议优化

     用于对PCoIP协议优化，如果你在域环境，你可以将对应的vdm添加到域服务器的策略里面，进行统一管理，方便统一策略调整。另如果你有PCoIP硬件加速卡对应进行调优会更好一些。

3）零客户机

     在PCoIP会话数据采集的过程中，我们发现对于大图档的数据进行解码瘦客户机的性能会比较差，采用零客户机测试使用正常无异常，建议后期通过对于图形解码要求比较高的用户，采用此零客户机。

（六）、应用系统调优

     大家都知道应用系统的好坏，第一直接响应用户端的响应、第二影响存储的性能，在测试的过程中我们发现当用户做一个数据库查询动作时，用户端的响应过程会延时更长，为此我们进行了长时间分析，发现对应的数据库索引完整性、数据库索引的大小，会直接影响整体的存储性能。为此我们让应用系统工程师进行对数据库部份进行优化，以减低整体的存储性能需求，提高用户响应速度。当然这仅仅只是一部份。

五、验证并测试成效

     任何东西都得有产出比，即你做了任何动作以后能够达到什么成效，如果没有成效那你做的一切不就是白搭，为此我们对调优后的服务器性能进行了再次查询，结果显示CPU下降到70%左右、存储I/O性能明显降低至60%以下，以达到前期目标之成效。

I/O对比分析：

                  调优以后                         调优以前

     说明：由于前期的调优报告的截图找了半天没有找到I/O的性能报告，所以这个截图是2014年4月3日从服务器上截取的，调优后在原有的基础上添加了15台VDI用户左右，对应的磁盘空间已经没有空间了（正准备添加磁盘），但是从I/O对比来看，在后续添加15台VDI用户以后存储的I/O仅仅只有60%左右。

     说明：此图为CPU在调优过程中的性能图标，从中我们可以看出对应的CPU性能从之前的195%逐步下载到60%-70%之间。

     通过前期的一系列性能分析与优化，VDI服务器性能从前期的超负荷运行到最终的正常运行，在未增加成本的前提下，提升VDI的整体性能。

六、写在最后面

     从开始的性能分析到后期的调优，这是一个漫长的过程，其中你会遇到以前从来没有遇到过的问题，包括以前并不会去更深入研究的知识点。这是一种磨砺，在这个过程中我收获了很多。当然在这个过程中我们也说明了一个问题，任何问题不能够只从单点出发考虑，需要全盘分析才能够真正解决问题。