一、說一說

? ? ? ?本來打算將前期項目里面出現的問題的分析思路與解決方法寫出來，第一、疏導一下自己的思路，第二、分析并找出自身在技術層面所存在欠缺。但由于每個人都有一根懶經所以遲遲未動。今天突然發現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的整體性能。

六、寫在最后面

? ? ?從開始的性能分析到后期的調優，這是一個漫長的過程，其中你會遇到以前從來沒有遇到過的問題，包括以前并不會去更深入研究的知識點。這是一種磨礪，在這個過程中我收獲了很多。當然在這個過程中我們也說明了一個問題，任何問題不能夠只從單點出發考慮，需要全盤分析才能夠真正解決問題。

轉載于:https://www.cnblogs.com/zb9222/p/5935892.html

總結

以上是生活随笔為你收集整理的【VMware虚拟化解决方案】 基于VMware虚拟化平台VDI整体性能分析与优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。