問題描述
某省移動公司的業務管理系統目前已遷移到Citrix虛擬化平臺，但個別業務應用在遷移之后使用者感受非常緩慢，因此需要通過網絡回溯分析技術對這些業務訪問緩慢的原因進行分析。
用戶的內部信息系統拓撲示意圖如下：
圖 1
其中Citrix虛擬化平臺服務器位于“網管核心業務區”，各業務系統維護人員在“維護終端區”通過Citrix客戶端連接到虛擬化平臺，再通過虛擬化平臺訪問數據業務區的應用系統服務器。
使用者感受緩慢的應用主要是：
分析結論
故障應用管理平臺用戶感受緩慢的原因與網絡基礎設施、Citrix平臺、10.161.8.41服務器無關；主要造成緩慢的原因是10.230.3.112上的故障應用管理客戶端程序處理緩慢造成的，這一問題以下兩種可能性：
- 運行在10.230.3.112上的應用客戶端程序在開啟時需要占用大量系統資源，導致處理緩慢。（需要研發人員對客戶端程序進行優化）
- 10.230.3.112虛機的處理性能不足，影響了客戶端程序運行效率。（為該業務的客戶端程序分配更多的虛擬機資源）
價值
在應用向虛擬化遷移后出現的應用訪問故障，由于虛擬主機、網絡等都處于良好的運行狀態，大多數情況下會考慮虛擬化平臺的兼容性問題，很難在短時間內定位故障。通過網絡分析，我們可以快速定位到故障原因的根源，提升了故障恢復效率。
分析過程
在“網管核心業務”區核心交換機旁路部署科來網絡回溯分析系統，鏡像交換機上聯端口雙向流量。通過科來網絡回溯分析系統7×24小時采集“網管核心業務區”的流量，針對出現緩慢的業務和發生訪問緩慢的時段進行重點數據分析。通過捕獲Citrix平臺與管理終端及業務服務器的交易過程，評估訪問緩慢應用交易過程的網絡傳輸延時和應用系統應答延時等性能參數，從而判斷業務訪問緩慢的根本原因。
鏈路流量狀況分析
首先通過科來網絡回溯分析系統對“網管核心業務區”出口的鏈路流量狀況進行整體評估，其目的是在交換機上聯鏈路上是否存在擁塞現象。
圖 2
圖 3
通過上圖中展示的上午4小時流量趨勢及流量統計數據來看，“網管核心業務區”出口的流量并不大，峰值流量為37.51Mbps，遠小于鏈路總帶寬，因此可以排除“網管核心業務區”出口帶寬利用率過高導致應用訪問緩慢的可能性。
故障應用管理平臺通訊數據分析
01實測訪問流量趨勢分析
根據用戶運維人員介紹，故障應用管理平臺從打開客戶端程序到終端顯示初始界面大約需要1分鐘左右時間，嚴重影響使用者感受。
首先請用戶運維人員實際訪問一次故障應用管理平臺，從終端打開Citrix客戶端程序，到連接到虛擬化平臺，再到打開故障應用客戶端顯示初始界面，全部過程共用了約50多秒。
圖 4
通過對Citrix平臺IP10.230.3.112的流量趨勢進行精細分析，從上圖中我們可以看出在這一次測試訪問時，從流量趨勢圖中可以看出從15：58：30秒測試開始到初始界面顯示(當測試人員看到初始界面時，我們從流量趨勢圖上看到明顯的流量突發)大約持續50多秒。期間10.230.3.112主要與10.230.3.125(測試終端)、10.230.3.86(域控制器)和10.161.8.41(業務服務器)等3個IP通訊。注：其他幾個IP經過后續數據分析確認與本次測試訪問無關。
整個訪問過程所產生的流量不到1MB，峰值速率約4Mbps，期間15：48：45~15：49：22這段時間幾乎沒有什么流量，因此我們需要對這段時間通訊量很少的成因進行深入分析。
02通訊會話深入分析
我們下載了這段時間10.230.3.112的原始數據包，利用科來網絡回溯分析系統專家分析模塊的TCP會話重組功能分析本次測試訪問所觸發的TCP會話流。
圖 5
在上圖中我們使用了TCP會話開始發包時間進行會話排序，從中可以看出在15：58：34時刻測試終端10.230.3.125向10.230.3.112發起建立了Citrix會話，該會話一直持續到采樣結束；在Citrix會話建立之后，10.230.3.112向域控制器10.230.3.86發起建立了若干TCP會話，從其通訊端口和協議類型來看是域身份驗證相關的會話；在15：58：45時刻，10.230.3.112向故障應用平臺服務器10.161.8.41發起建立了兩個TCP會話，通訊服務端口為8006，經過核實這是故障應用管理平臺的服務端口。
03域登錄過程響應時間分析
從會話列表中我們可以看出和域登錄相關的若干會話中有個別會話持續時間比較長，因此我們首先對登錄過程中觸發的各會話進行精細分析。
圖 6
由于TCP通訊過程中三次握手是由操作系統的TCP進程執行的，不需要應用系統干預，因此我們可以將三次握手延時看作客戶端到服務端的網絡響應時間(RTT)。上圖中10.230.3.112與域控制器的445端口的會話三次握手延時為2.97ms，網絡延時非常小。
后續應用層數據交互過程中，我們可以看出域控制器的服務端應答時間也非常小(1ms左右)。
整個會話在開始后約996ms后事務處理完成，其后有約20s的空閑時間，會話應用層關閉。如下圖：
圖 7
從這個會話交互過程我們可以判斷，該會話雖然持續20多秒時間，但在1秒之內已經完成了登錄過程必須的數據交互。
通過對其他域登錄所觸發的會話分析，我們發現這些會話均在1秒之內完成了有效數據交互，可以確定整個域身份驗證過程從15：58：34開始，到15：58：36已經驗證完成。因此Citrix平臺客戶端登錄的身份驗證過程并不會直接導致用戶感受緩慢。
04故障應用管理平臺應用會話響應時間分析
Citrix虛擬化平臺與10.161.8.41應用服務器之間建立的兩個TCP會話，三次握手延時和服務器應用層響應時間也很短，如下圖。
圖 8
但是從會話整體延時統計中，我們可以看出整個會話的主要時間占用源自“客戶端空閑時間”，如下圖。
圖 9
“客戶端空閑時間”是指客戶端與服務端一次應用層交互完成后，到下一次發起應用層請求的間隔時間，在故障應用平臺客戶端打開的過程中并沒有額外需要人工干預的過程，因此出現大量“客戶端空閑時間”說明客戶端系統(10.230.3.112)或客戶端程序處理出現問題，導致不能及時向服務端發送下一次應用層請求。
從會話交易時序圖中，我們可以看到兩個會話均有一次明顯的客戶端空閑，如下圖。
圖 10
圖 11
可以判斷，這些客戶端空閑是使用者感受緩慢的直接原因，很可能是這段時間客戶端程序處理過于緩慢，導致很長一段時間沒有發送應用層請求。
在其他時段，我們隨機選擇了一些10.230.3.112與10.161.8.41的TCP會話，均發現了相同的客戶端空閑，如下圖。
圖 12
并且我們發現在較長的客戶端空閑后，10.230.3.112發起的主要是兩個應用層請求：
select right_id， right_type， module_id， module_name， right_name， right_value from tco_role_rights where role_id =… and right_type=….
select userid， config_class_name， config_version， config from tap_wf_userRelatedConfigs where userid=… and config_class_name=… and config_version=…
至此，我們推斷故障應用平臺的客戶端程序，在發送上述兩個查詢之前的處理過程過于緩慢，建議系統研發人員對程序處理過程進行深入分析。
05Citrix平臺響應時間分析
用戶終端與Citrix平臺(10.230.3.112)之間的會話，三次握手和應用層響應時間也非常快，如下圖。
圖 13
在故障應用管理平臺會話的客戶端空閑時間內，10.230.3.112與10.230.3.125之間只有少量的數據交互，在15：58：21.336時刻可以看到10.230.3.112向10.230.3.125發送了很多大數據包，如下圖。
圖 14
而這一時刻與10.230.3.112在長時間等待后向10.161.8.41發送新的應用層請求的時間點吻合(滯后3ms)，這說明Citrix平臺在應用軟件處理完成后能夠很快的將處理后的圖像數據發送給用戶終端。
可以判斷Citrix平臺并沒有對用戶訪問造成明顯的延時(以上延時不包括Citrix客戶端程序處理圖像數據到最終顯示出來的時間)。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.vmgcyvh.cn/
本文標題：案例｜如何解決虛擬化業務訪問緩慢問題
本文網址：http://www.vmgcyvh.cn/html/consultation/10839420745.html
相關文章
