《CSNA網(wǎng)絡(luò)分析認證專家實戰(zhàn)案例》課件-第36章

第36章某移動公司虛擬化遷移后應(yīng)用緩慢分析案例36.1故障描述 36.2分析過程36.3總結(jié)

某省移動公司的業(yè)務(wù)管理系統(tǒng)目前已遷移到Citrix虛擬化平臺，但個別業(yè)務(wù)應(yīng)用在遷移之后使用者感覺非常緩慢，因此需要通過網(wǎng)絡(luò)回溯分析技術(shù)對這些業(yè)務(wù)訪問緩慢的原因進行分析。36.1故障描述用戶的內(nèi)部信息系統(tǒng)拓撲示意圖如圖36-1所示。其中，Citrix虛擬化平臺服務(wù)器位于“網(wǎng)管核心業(yè)務(wù)區(qū)”，各業(yè)務(wù)系統(tǒng)維護人員在“維護終端區(qū)”通過Citrix客戶端連接到虛擬化平臺，再通過虛擬化平臺訪問數(shù)據(jù)業(yè)務(wù)區(qū)的應(yīng)用系統(tǒng)服務(wù)器。

圖36-1使用者感覺緩慢的應(yīng)用主要是某應(yīng)用管理平臺(具體名稱隱去)，其核心服務(wù)器IP為10.16.8.41，虛擬化平臺IP為10.16.3.112，該應(yīng)用為C/S架構(gòu)。

在“網(wǎng)管核心業(yè)務(wù)區(qū)”核心交換機旁路部署科來回溯分析系統(tǒng)(見圖36-1)，鏡像交換機上聯(lián)端口雙向流量。

通過科來回溯分析系統(tǒng)7

×

24小時采集“網(wǎng)管核心業(yè)務(wù)區(qū)”的流量，針對出現(xiàn)緩慢的業(yè)務(wù)和發(fā)生訪問緩慢時段的數(shù)據(jù)進行重點分析。通過捕獲Citrix平臺與管理終端及業(yè)務(wù)服務(wù)器的交易過程，評估訪問緩慢應(yīng)用交易過程的網(wǎng)絡(luò)傳輸延時和應(yīng)用系統(tǒng)應(yīng)答延時等性能參數(shù)，從而判斷業(yè)務(wù)訪問緩慢的根本原因。36.2分析過程36.2.1鏈路流量狀況分析

首先，通過科來回溯分析系統(tǒng)對“網(wǎng)管核心業(yè)務(wù)區(qū)”出口的鏈路流量狀況進行整體評估，目的是判斷在交換機上聯(lián)鏈路上是否存在擁塞現(xiàn)象，如圖36-2所示。

通過圖36-2中展示的上午4小時流量趨勢及流量統(tǒng)計數(shù)據(jù)來看，“網(wǎng)管核心業(yè)務(wù)區(qū)”出口的流量并不大，峰值流量為37.51Mbps，遠小于鏈路總帶寬，因此可以排除“網(wǎng)管核心業(yè)務(wù)區(qū)”出口帶寬利用率過高導(dǎo)致應(yīng)用訪問緩慢的可能性。

圖36-236.2.2故障應(yīng)用管理平臺通信數(shù)據(jù)分析

1.實測訪問流量趨勢分析

根據(jù)用戶中一些相關(guān)技術(shù)人員介紹，故障應(yīng)用管理平臺從打開客戶端程序到終端顯示初始界面，大約需要1分鐘左右時間，嚴重影響使用者感受。我們請用戶技術(shù)人員實際訪問一次故障應(yīng)用管理平臺，從終端打開Citrix客戶端程序，到連接到虛擬化平臺，再到打開故障應(yīng)用客戶端顯示初始界面，全部過程共用了50多秒。通過對Citrix平臺IP10.230.3.112的流量趨勢進行精細分析，如圖36-3所示，這一次測試訪問從15時58分30秒測試開始到初始界面顯示(當測試人員看到初始界面時，我們從流量趨勢圖上看到明顯的流量突發(fā))大約持續(xù)50多秒，期間10.230.3.112主要與10.230.3.125(測試終端)、10.230.3.86(域控制器)和10.161.8.41(業(yè)務(wù)服務(wù)器)等3個IP通信，其他幾個IP經(jīng)過后續(xù)數(shù)據(jù)分析確認與本次測試訪問無關(guān)。整個訪問過程所產(chǎn)生的流量不到1MB，峰值速率約為4Mbps，而15時48分45秒至15時49分22秒這段時間幾乎沒有什么流量，因此我們需要對這段時間通信量很少的原因進行深入分析。

圖36-3

2．通信會話深入分析

我們下載了這段時間IP10.230.3.112的原始數(shù)據(jù)包，利用科來回溯分析系統(tǒng)“專家分析”模塊的“TCP會話重組”功能分析本次測試訪問所觸發(fā)的TCP會話流。

在圖36-4中，我們使用了TCP會話“開始發(fā)包時間”進行會話排序，可以看到在15時58分34秒這一時刻，測試終端10.230.3.125向10.230.3.112發(fā)起建立了Citrix會話，該會話一直持續(xù)到采樣結(jié)束；在Citrix會話建立之后，10.230.3.112向域控制器10.230.3.86發(fā)起建立了若干TCP會話，從其通信端口和協(xié)議類型來看是域身份驗證相關(guān)的會話；在15時58分45秒這一時刻，10.230.3.112向故障應(yīng)用平臺服務(wù)器10.161.8.41發(fā)起建立了兩個TCP會話，通信服務(wù)端口為8006，經(jīng)過核實這是故障應(yīng)用管理平臺的服務(wù)端口。

圖36-4

3．域登錄過程響應(yīng)時間分析

從會話列表中我們可以看出，與域登錄相關(guān)的若干會話中，有個別會話持續(xù)時間比較長。因此，我們接下來對登錄過程中觸發(fā)的各會話進行精細分析。

由于TCP通信過程中三次握手是由操作系統(tǒng)的TCP進程執(zhí)行的，不需要應(yīng)用系統(tǒng)干預(yù)，因此我們可以將三次握手延時看作客戶端到服務(wù)端的網(wǎng)絡(luò)響應(yīng)時間(RTT)。圖36-5中，10.230.3.112與域控制器的445端口的會話三次握手延時為2.97毫秒，網(wǎng)絡(luò)延時非常小。從后續(xù)應(yīng)用層數(shù)據(jù)交互過程中我們可以看出，域控制器的服務(wù)端應(yīng)答時間也非常小(1毫秒左右)。

圖36-5整個會話在開始約996毫秒后事務(wù)處理完成，其后有約20秒的空閑時間，會話應(yīng)用層關(guān)閉，如圖36-6所示。

圖36-6從這個會話交互過程我們可以判斷，該會話雖然持續(xù)20多秒時間，但在1秒之內(nèi)已經(jīng)完成了登錄過程必須的數(shù)據(jù)交互。

通過對其他域登錄所觸發(fā)的會話分析我們發(fā)現(xiàn)，這些會話均在1秒之內(nèi)完成了有效數(shù)據(jù)交互，可以確定整個域身份驗證過程從15時58分34秒開始，到15時58分36秒已經(jīng)驗證完成。因此，Citrix平臺客戶端登錄的身份驗證過程并不會直接導(dǎo)致用戶感覺緩慢。

4．故障應(yīng)用管理平臺應(yīng)用會話響應(yīng)時間分析

Citrix虛擬化平臺與10.161.8.41應(yīng)用服務(wù)器之間建立的兩個TCP會話，三次握手延時和服務(wù)器應(yīng)用層響應(yīng)時間也很短，如圖36-7所示。

但是，從會話整體延時統(tǒng)計中我們可以看出，整個會話的主要時間占用源自“客戶端空閑時間”，如圖36-8所示。

圖36-7

圖36-8“客戶端空閑時間”是指客戶端與服務(wù)端一次應(yīng)用層交互完成后，到下一次發(fā)起應(yīng)用層請求的間隔時間。在故障應(yīng)用平臺客戶端打開的過程中并沒有額外需要人工干預(yù)的過程，因此，出現(xiàn)大量“客戶端空閑時間”說明客戶端系統(tǒng)(10.230.3.112)或客戶端程序處理出現(xiàn)問題，導(dǎo)致不能及時向服務(wù)端發(fā)送下一次應(yīng)用層請求。

從會話交易時序圖中我們可以看到，兩個會話均有一次明顯的客戶端空閑，如圖36-9和圖36-10所示。

圖36-9

圖36-10可以判斷，這些客戶端空閑是使用者感覺緩慢的直接原因，很可能是這段時間客戶端程序處理過于緩慢，導(dǎo)致很長一段時間沒有發(fā)送應(yīng)用層請求。

在其他時段，我們隨機選擇了一些10.230.3.112與10.161.8.41的TCP會話，均發(fā)現(xiàn)了相同的客戶端空閑，如圖36-11所示。我們還發(fā)現(xiàn)，在較長的客戶端空閑后，10.230.3.112發(fā)起的主要是兩個應(yīng)用層請求：

selectright_id,right_type,module_id,module_name,right_name,right_valuefromtco_role_rightswhererole_id=…andright_type=…

selectuserid,config_class_name,config_version,configfromtap_wf_userRelatedConfigswhereuserid=…andconfig_class_name=…andconfig_version=…

圖36-11至此，我們推斷故障應(yīng)用平臺的客戶端程序在發(fā)送上述兩個查詢之前的處理過程過于緩慢，建議系統(tǒng)研發(fā)人員對程序處理過程進行深入分析。

5．Citrix平臺響應(yīng)時間分析

用戶終端與Citrix平臺(10.230.3.112)之間的會話，三次握手和應(yīng)用層響應(yīng)時間也非?？?，如圖36-12所示。

圖36-12在故障應(yīng)用管理平臺會話的客戶端空閑時間內(nèi)，10.230.3.112與10.230.3.125之間只有少量的數(shù)據(jù)交互，在15:59:21.336時刻可以看到10.230.3.112向10.230.3.125發(fā)送了大量大數(shù)據(jù)包，如圖36-13所示。

圖36-13而這一時刻與10.230.3.112在長時間等待后向10.161.8.41發(fā)送新的應(yīng)用層請求的時間點比較吻合(滯后3毫秒)，這說明Citrix平臺在應(yīng)用軟件處理完成后能夠很快地將處理后的圖像數(shù)據(jù)發(fā)送給用戶終端。

可以判斷，Citrix平臺并沒有對用戶訪問造成明顯的延時(以上延時不包括Citrix客戶端程序處理圖像數(shù)據(jù)到最終顯示出來的時間)。

故障應(yīng)用管理平臺用戶感受緩慢的原因與網(wǎng)絡(luò)基礎(chǔ)設(shè)施、Citrix平臺、10.161.8.41服務(wù)器無關(guān)，造成緩慢的主要原因是10.23