负载均衡故障排错指南(6) - 案例分析:谁动了我的配置?

  1. 云栖社区>
  2. 博客>
  3. 正文

负载均衡故障排错指南(6) - 案例分析:谁动了我的配置?

科技小能手 2017-11-22 14:01:00 浏览723
展开阅读全文
很久没有更有关负载均衡排错指南的系列文章了。这一次,我将和大家一起分享一个有意思的案例。在这个案例中,我们像一个侦探一样,利用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地址的。但是,为什么会丢失呢?
 

  1. ========== Health Check log ================== 
  2. Jul 12 2012 10:41:13 Info    [HMON]:GSLB server 1.1.1.1 (1.1.1.1) is up 
  3. Jul 12 2012 10:36:46 Info    [HMON]:GSLB server 2.2.2.2 (2.2.2.2) is up 
  4. Jul 12 2012 10:32:29 Info    [HMON]:GSLB server 2.2.2.2 (2.2.2.2) is down 
  5. Jul 12 2012 10:31:44 Info    [HMON]:GSLB server 2.2.2.2 (2.2.2.2) is up 
  6. Jul 12 2012 08:28:39 Info    [HMON]:GSLB server 1.1.1.1 (1.1.1.1) is down 
  7. Jul 12 2012 08:28:39 Info    [HMON]:GSLB server 2.2.2.2 (2.2.2.2) is down 
  8.  
  9. ====================== END ============== 
 

简单的查询syslog已经无法提供答案了,看来只能查询Backup log数据了。Backup log是A10设备上更为详细的系统数据,它保存了最近一个月内,每个15分钟的系统showtech信息。从Backup log中,我们可以详细了解发生问题的前后系统的状态信息、配置变化等等。在一些较为复杂的系统诊断中,我们可以通过A10的Backup log发现系统运行中的一些蛛丝马迹。经过查询,我们发现了以下事实:

在7月6日下午,主备系统之间进行配置同步后(AB同步),B上的有关VIP 1.1.1.1和2.2.2.2的配置莫名其妙的丢失了;

 


  1. ================= B 上执行配置同步的日志 ====================== 
  2.  
  3. Jul  6 18:24:23 B a10logd: [CLI]<5> CONFIG SYNC: Received config sync file 
  4. Jul  6 18:24:23 B a10logd: [CLI]<5> CONFIG SYNC: Sync running-config 
  5. ===================================================================== 
 
另外,我查阅了当初现场实施时我的命令行操作记录(这是我做工程师以来的一个习惯,每次通过命令行操作设备,我都会让我的SSH自动记录整个操作的输入和输出,这次它又一次帮了我大忙)。从我当时的命令行操作记录来看,当时现场实施时,的确配置了1.1.1.1和2.2.2.2这两个VIP。
 

  1. ===== 7/3现场工程师实施后的 VIP-1.1.1.1的配置 (取自B的backup log) ===== 
  2. slb virtual-server 2.2.2.2 2.2.2.2 
  3.    ha-group 1             ==> 用于同步的ha-group属性 
  4.    port 80  http 
  5.       name _2.2.2.2_HTTP_80 
  6.       service-group sg-www1 
  7.       use-rcv-hop-for-resp 
  8. slb virtual-server 1.1.1.1 1.1.1.1 
  9.    ha-group 1                ==> 用于同步的ha-group属性 
  10.    port 80  http 
  11.       name _1.1.1.1_HTTP_80 
  12.       service-group sg-www1 
  13.       use-rcv-hop-for-resp 
  14. =============================== END ================================ 
 
在7月7日的远程SSH操作记录上,可以发现这两个VIP的配置发生了变化。
 

  1. ========= 7/7 调试时的log记录 (来自7/7日我调试A时的操作记录)========== 
  2. slb virtual-server 2.2.2.2 2.2.2.2 
  3.    port 80  http         ==> ha-group配置命令丢失 
  4.       name _2.2.2.2_HTTP_80 
  5.       service-group sg-www1 
  6.       use-rcv-hop-for-resp 
  7.    port 8080  tcp 
  8.       name _2.2.2.2_HTTP_8080 
  9.       service-group top8080 
  10. slb virtual-server 1.1.1.1 1.1.1.1 
  11.    port 80  http         ==> ha-group配置命令丢失 
  12.       name _1.1.1.1_HTTP_80 
  13.       service-group sg-www1 
  14.       use-rcv-hop-for-resp 
  15.    port 8080  tcp 
  16.       name _1.1.1.1_HTTP_8080 
  17.       service-group top8080 
  18. =================== END ============================================ 
 
再次查询Backup log中的审计日志,发现有人在7月5日下午16:39左右,通过内网地址(192.168.82.243)登录设备的Web页面,修改了两个VIP的配置。可能由于修改不当,误删除了VIP下的ha-group信息,导致7月6日同步时,删除了B上相应的VIP及配置信息。
 

  1. ============== B上用户修改VIP的审计日志 ========================= 
  2. Jul 05 2012 16:53:04  [admin] web: logout system. successfully. 
  3. Jul 05 2012 16:42:57  [admin] web: add virtual service [name:_1.1.1.1_HTTP_8080, vport:8080(TCP).] successfully. 
  4. Jul 05 2012 16:42:07  [admin] web: add virtual service [name:_2.2.2.2_HTTP_8080, vport:8080(TCP).] successfully. 
  5. Jul 05 2012 16:39:54  [admin] web: add service group [name:top8080, type:TCP, member1:(192.168.98.11:8080). ] successfully. 
  6. Jul 05 2012 16:36:12  A web session[1] opened,  username: admin, remote host: 192.168.1.243 
  7. ========================= END ================================ 
至此,整个事件真相大白。在整个事件的分析过程中,系统日志帮助我们还原了整个事件发生的经过。通过对比前后的配置变化、查询相关的日志记录,我们成功的还原了整件事情的发生过程。
 
E.S.

本文转自 virtualadc 51CTO博客,原文链接:
http://blog.51cto.com/virtualadc/1070469

网友评论

登录后评论
0/500
评论
科技小能手
+ 关注