很久没有更有关负载均衡排错指南的系列文章了。这一次，我将和大家一起分享一个有意思的案例。在这个案例中，我们像一个侦探一样，利用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.
本文转自 virtualadc 51CTO博客，原文链接:
http://blog.51cto.com/virtualadc/1070469
