排除網(wǎng)絡(luò)問(wèn)題可能很棘手，要是網(wǎng)絡(luò)中多了負(fù)載均衡系統(tǒng)會(huì)帶來(lái)另外的挑戰(zhàn)。試圖識(shí)別負(fù)載均衡系統(tǒng)是否在丟失數(shù)據(jù)包、以某種方式更改數(shù)據(jù)包或者添加更多的延遲可能并非易事。不過(guò)可以運(yùn)用一些訣竅讓你更容易發(fā)現(xiàn)問(wèn)題。

任何故障排除工作的第一步就是檢查相應(yīng)網(wǎng)絡(luò)部件的統(tǒng)計(jì)數(shù)字。然而，如果那些統(tǒng)計(jì)數(shù)字表明一切都很好，可是網(wǎng)絡(luò)問(wèn)題依然出現(xiàn)，那么你就只好引入故障排除界的“瑞士軍刀”――數(shù)據(jù)包分析。雖說(shuō)市面上有好多出色的收費(fèi)產(chǎn)品可用于分析數(shù)據(jù)包，不過(guò)我還是青睞開(kāi)源工具Wireshark(https://www.wireshark.org/download.html)。

在分析涉及負(fù)載均衡系統(tǒng)的問(wèn)題時(shí)，需要解答的第一個(gè)問(wèn)題就是負(fù)載均衡系統(tǒng)是不是處于透明模式下。在透明模式下，負(fù)載均衡系統(tǒng)會(huì)將原始客戶機(jī)的IP地址作為源IP地址來(lái)傳送。而在非透明模式下，負(fù)載均衡系統(tǒng)會(huì)使用負(fù)載均衡系統(tǒng)的虛擬IP地址(VIP)對(duì)服務(wù)器請(qǐng)求進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)處理。非透明模式是最常見(jiàn)的實(shí)施模式。

現(xiàn)在你準(zhǔn)備獲取跟蹤文件。在理想情況下，下圖中的每一個(gè)點(diǎn)都會(huì)插入分路器(tap)。要是你沒(méi)有分路器，可以使用SPAN(交換機(jī)端口分析器)或交換機(jī)上的鏡像端口來(lái)捕獲流量。或者你也可以對(duì)防火墻和負(fù)載均衡系統(tǒng)的入站和出站端口使用tcpdump命令。關(guān)鍵在于同時(shí)捕獲所有四個(gè)位置的數(shù)據(jù)包，分析來(lái)自四個(gè)不同有利位置的會(huì)話。

你捕獲了數(shù)據(jù)后，必須找到出現(xiàn)在所有四個(gè)跟蹤文件中的單一會(huì)話。通常，你只要過(guò)濾相應(yīng)的兩個(gè)IP地址就可以了。但是記住負(fù)載均衡系統(tǒng)在服務(wù)器端執(zhí)行NAT，所以過(guò)濾客戶機(jī)IP地址并不適用于服務(wù)器端痕跡。

進(jìn)入到第4層可以解決這個(gè)問(wèn)題。你可以按照TCP報(bào)頭中的序列號(hào)進(jìn)行過(guò)濾。不過(guò)要小心;Wireshark在默認(rèn)情況下顯示相對(duì)序列號(hào)，你到頭來(lái)會(huì)遇到數(shù)百個(gè)序列號(hào)為1的數(shù)據(jù)包。關(guān)鍵在于關(guān)閉TCP參數(shù)選項(xiàng)中的相對(duì)序列號(hào)。只要只要取消勾選該選項(xiàng)，實(shí)際的十進(jìn)制數(shù)就會(huì)顯示，而不是相對(duì)會(huì)話開(kāi)始的序列號(hào)。一旦你過(guò)濾了所有四個(gè)痕跡文件中的同一序列號(hào)，你在每個(gè)文件中應(yīng)該有一個(gè)數(shù)據(jù)包。

如果你的負(fù)載均衡系統(tǒng)在NAT端創(chuàng)建自己的數(shù)據(jù)包發(fā)往服務(wù)器，棘手問(wèn)題就來(lái)了。序列字段然后不再?gòu)念^到尾都一樣。這種場(chǎng)景下使用的最佳字段就是應(yīng)用層所特有的字段。如果是HTTP，我建議使用Cookie字段;如果是HTTPS，則建議使用Client Hello中的Random Bytes字段。

最后，你面對(duì)在多個(gè)地方捕獲的單一會(huì)話，可以分析其痕跡了。首先，尋找數(shù)據(jù)包丟失現(xiàn)象。在Wireshark的專家分析語(yǔ)言中，那些丟失的數(shù)據(jù)包會(huì)被標(biāo)為“Previous segment not captured”(未捕捉到的先前片段)。這會(huì)出現(xiàn)在一個(gè)或多個(gè)痕跡文件中，但并不出現(xiàn)在所有痕跡文件中。比如說(shuō)，如果你在防火墻痕跡的出站端(而不是入站端)看到來(lái)自服務(wù)器的響應(yīng)，就知道防火墻丟失了數(shù)據(jù)包。

分析數(shù)據(jù)包丟失現(xiàn)象后，檢查TCP握手機(jī)制，確保TCP選項(xiàng)在一路當(dāng)中并沒(méi)有被篡改。當(dāng)沿途中的某個(gè)設(shè)備創(chuàng)建自己的數(shù)據(jù)包，而不是以透明方式一路傳送時(shí)，窗口縮放(windows scaling)和選擇性確認(rèn)(Selective Acknowledgements)往往會(huì)消失。那兩個(gè)選項(xiàng)對(duì)吞吐量而言很重要，不應(yīng)該去掉。

在痕跡中要關(guān)注的最后一個(gè)問(wèn)題是很高的增量時(shí)間(delta time)。如果捕獲了四個(gè)不同位置的數(shù)據(jù)，你就真正能夠查看什么東西在添加延遲(要是果真有什么東西的話)。先看一下握手機(jī)制。使用同步請(qǐng)求(SYN)與同步響應(yīng)(SYN/ACK)的間隔時(shí)間作為基準(zhǔn)。看一下離客戶機(jī)最近的防火墻入站端留下的痕跡中的其余請(qǐng)求和響應(yīng)。

針對(duì)那些增量時(shí)間為一秒或更長(zhǎng)的請(qǐng)求/響應(yīng)組合，逐步檢查每個(gè)痕跡，直到你找到哪個(gè)端口在增添延遲為止。是處理器使用激增的防火墻嗎?還是跟蹤NAT表有問(wèn)題的負(fù)載均衡系統(tǒng)?也許是并發(fā)連接數(shù)量太多的服務(wù)器。仔細(xì)檢查痕跡，可以告訴你哪里有問(wèn)題，哪里沒(méi)有問(wèn)題。

設(shè)置數(shù)據(jù)包捕獲機(jī)制可能在網(wǎng)絡(luò)滅火行動(dòng)中會(huì)占用寶貴的時(shí)間，不過(guò)從長(zhǎng)遠(yuǎn)來(lái)看它可以節(jié)省大量的時(shí)間。

英文：Network Troubleshooting: Consider The Load Balancer