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

 

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