很久沒有更有關負載均衡排錯指南的系列文章了。這一次，我將和大家一起分享一個有意思的案例。在這個案例中，我們像一個偵探一樣，利用AX設備詳細的日誌系統，去看看到底是誰動了我的配置。
書歸正傳，話說某天上午，我們接到某個用戶的工程師反應，報告說他們的網站無法訪問，根據他們初步的故障排查，認爲問題出在A10的設備上。並且報告說，他們通過A10進行DNS的解析測試時，發現A10的GSLB不能解析域名（實際上準確的描述是A10的DNS解析結果中不包含有效的IP地址，這個問題後面還會提到）。
這個用戶在前期考察了多家主要的負載均衡廠商，最終選擇部署2臺A10的AX1000設備，以解決廣域網多條鏈路的智能接入問題。通過AX，主要實現以下四個需求：
1） 實現內部終端訪問互聯網時的智能選路問題，主要是依據目標地址所屬的運營商來進行選路。
2） 利用AX的GSLB，實現互聯網客戶訪問該公司網站時的智能選路。同樣，選路的策略也主要是依據客戶所屬的運營商進行選路
3） 利用AX實現內部服務器的負載均衡功能。
4） 當鏈路出現故障時，對需求1和2，要自動切換至備份鏈路，保證網站的業務連續性。
爲了防止單點故障，兩臺AX1000採用HA方式進行部署，以避免單點故障。我們今天的故事，就要從這個HA說起。下面的文章中，爲了保護客戶隱私，我們對IP地址做了變性處理，並且，對A10需要解析的域名，我們假定爲a10test.com。
由於該用戶的A10設備剛剛上線，客戶懷疑是A10的設備功能存在問題，因此，責成廠家的工程師立即解決。
通過遠程方式登錄AX設備，我發現以下幾個問題（爲了方便描述問題，我將兩臺AX1000分別命名爲A和B）：
1） A設備無法遠程登錄，登錄B設備後，發現B設備處於Active狀態，因此，判斷設備曾經做過HA切換，並且順利切換至B設備。
2） 通過A10的GSLB功能，無法對www.a10test.com域名進行解析，該域名對應的兩個VIP地址健康檢查結果爲Down狀態；
3） 進一步檢查，發現B設備上並沒有配置www.a10test.com 域名對應的1.1.1.1以及2.2.2.2 這兩個地址；
經過以上分析，我們建議用戶重新添加這兩個VIP地址，隨即網站訪問恢復正常。
由於用戶非常確認他們已經在A10上正確的添加過這兩個IP地址，並且按照要求做過主備設備的配置同步工作，因此，他們難以理解爲什麼配置沒有從A設備同步到B設備，進而，懷疑A10的同步機制有問題。要想洗清冤屈，那我們必須自己尋找證據。好吧，我要做一次偵探，查查到底是誰動了我的配置。
我在前面的文章中說過，要想解決問題，關鍵是思路。一切方法論、技巧，不過都是我們用來解決問題的工具。而這一次，我的武器將是AX上強大的系統日誌功能。我將按圖索驥，還原事件發生前後的真相。
GSLB怎麼失效了？
我們需要解決的第一個問題是，爲什麼A10的GSLB解析不出有效的IP地址？要解答這個問題，我們需要要了解GSLB中有關選路策略的優先級。
根據該用戶的需求，我們配置的GSLB選路策略，首要條件是要求服務對應的IP地址（即A10上的Service-IP要能夠正常訪問），其次，纔是根據客戶的來源來選擇對應的運營商。A10的GSLB解析結果中沒有包含有效的IP地址，但是，卻能正常響應客戶端的DNS查詢請求。（請注意！！！ 用戶很有可能在一開始就誤導你，用戶剛開是報告的是GSLB不能解析域名了，所以，我在進行了一些驗證後，發現準確的說法應該是DNS的響應中沒有有效的IP地址）
查找A10的GSLB解析結果爲什麼沒有返回有效的IP地址很簡單，查看了一下Service-IP的狀態，發現該域名對應的兩個IP地址狀態均爲Down的狀態。
再深入的查詢系統syslog日誌，發現這兩個IP地址健康檢查失敗是從早上8:28開始的，也就是設備進行HA切換之後。因此，我們猜測用戶當時在A設備上應該是配置過這兩個IP地址的。但是，爲什麼會丟失呢？
- ========== Health Check log ==================
- Jul 12 2012 10:41:13 Info [HMON]:GSLB server 1.1.1.1 (1.1.1.1) is up
- Jul 12 2012 10:36:46 Info [HMON]:GSLB server 2.2.2.2 (2.2.2.2) is up
- Jul 12 2012 10:32:29 Info [HMON]:GSLB server 2.2.2.2 (2.2.2.2) is down
- Jul 12 2012 10:31:44 Info [HMON]:GSLB server 2.2.2.2 (2.2.2.2) is up
- Jul 12 2012 08:28:39 Info [HMON]:GSLB server 1.1.1.1 (1.1.1.1) is down
- Jul 12 2012 08:28:39 Info [HMON]:GSLB server 2.2.2.2 (2.2.2.2) is down
- ====================== END ==============
簡單的查詢syslog已經無法提供答案了，看來只能查詢Backup log數據了。Backup log是A10設備上更爲詳細的系統數據，它保存了最近一個月內，每個15分鐘的系統showtech信息。從Backup log中，我們可以詳細瞭解發生問題的前後系統的狀態信息、配置變化等等。在一些較爲複雜的系統診斷中，我們可以通過A10的Backup log發現系統運行中的一些蛛絲馬跡。經過查詢，我們發現了以下事實：
在7月6日下午，主備系統之間進行配置同步後（A向B同步），B上的有關VIP 1.1.1.1和2.2.2.2的配置莫名其妙的丟失了；
- ================= B 上執行配置同步的日誌 ======================
- Jul 6 18:24:23 B a10logd: [CLI]<5> CONFIG SYNC: Received config sync file
- Jul 6 18:24:23 B a10logd: [CLI]<5> CONFIG SYNC: Sync running-config
- =====================================================================
另外，我查閱了當初現場實施時我的命令行操作記錄（這是我做工程師以來的一個習慣，每次通過命令行操作設備，我都會讓我的SSH自動記錄整個操作的輸入和輸出，這次它又一次幫了我大忙）。從我當時的命令行操作記錄來看，當時現場實施時，的確配置了1.1.1.1和2.2.2.2這兩個VIP。
- ===== 7/3現場工程師實施後的 VIP-1.1.1.1的配置 (取自B的backup log) =====
- slb virtual-server 2.2.2.2 2.2.2.2
- ha-group 1 ==> 用於同步的ha-group屬性
- port 80 http
- name _2.2.2.2_HTTP_80
- service-group sg-www1
- use-rcv-hop-for-resp
- !
- slb virtual-server 1.1.1.1 1.1.1.1
- ha-group 1 ==> 用於同步的ha-group屬性
- port 80 http
- name _1.1.1.1_HTTP_80
- service-group sg-www1
- use-rcv-hop-for-resp
- !
- =============================== END ================================
在7月7日的遠程SSH操作記錄上，可以發現這兩個VIP的配置發生了變化。
- ========= 7/7 調試時的log記錄 (來自7/7日我調試A時的操作記錄)==========
- slb virtual-server 2.2.2.2 2.2.2.2
- port 80 http ==> ha-group配置命令丟失
- name _2.2.2.2_HTTP_80
- service-group sg-www1
- use-rcv-hop-for-resp
- port 8080 tcp
- name _2.2.2.2_HTTP_8080
- service-group top8080
- !
- slb virtual-server 1.1.1.1 1.1.1.1
- port 80 http ==> ha-group配置命令丟失
- name _1.1.1.1_HTTP_80
- service-group sg-www1
- use-rcv-hop-for-resp
- port 8080 tcp
- name _1.1.1.1_HTTP_8080
- service-group top8080
- !
- =================== END ============================================
再次查詢Backup log中的審計日誌，發現有人在7月5日下午16:39左右，通過內網地址（192.168.82.243）登錄設備的Web頁面，修改了兩個VIP的配置。可能由於修改不當，誤刪除了VIP下的ha-group信息，導致7月6日同步時，刪除了B上相應的VIP及配置信息。
- ============== B上用戶修改VIP的審計日誌 =========================
- Jul 05 2012 16:53:04 [admin] web: logout system. successfully.
- Jul 05 2012 16:42:57 [admin] web: add virtual service [name:_1.1.1.1_HTTP_8080, vport:8080(TCP).] successfully.
- Jul 05 2012 16:42:07 [admin] web: add virtual service [name:_2.2.2.2_HTTP_8080, vport:8080(TCP).] successfully.
- Jul 05 2012 16:39:54 [admin] web: add service group [name:top8080, type:TCP, member1:(192.168.98.11:8080). ] successfully.
- Jul 05 2012 16:36:12 A web session[1] opened, username: admin, remote host: 192.168.1.243
- ========================= END ================================
至此，整個事件真相大白。在整個事件的分析過程中，系統日誌幫助我們還原了整個事件發生的經過。通過對比前後的配置變化、查詢相關的日誌記錄，我們成功的還原了整件事情的發生過程。
E.S.