很久没有更有关负载均衡排错指南的系列文章了。这一次,我将和大家一起分享一个有意思的案例。在这个案例中,我们像一个侦探一样,利用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