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