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

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
日志服务 SLS,月写入数据量 50GB 1个月
简介:
很久没有更有关负载均衡排错指南的系列文章了。这一次,我将和大家一起分享一个有意思的案例。在这个案例中,我们像一个侦探一样,利用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
相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
4天前
|
弹性计算 负载均衡 算法
slb配置监听器
【10月更文挑战第18天】
14 3
|
27天前
|
负载均衡 应用服务中间件 Apache
Tomcat负载均衡原理详解及配置Apache2.2.22+Tomcat7
Tomcat负载均衡原理详解及配置Apache2.2.22+Tomcat7
31 3
|
27天前
|
负载均衡 Java 应用服务中间件
Nginx负载均衡配置
Nginx负载均衡配置
|
24天前
|
负载均衡 算法 Java
java中nginx负载均衡配置
java中nginx负载均衡配置
35 0
|
27天前
|
负载均衡 算法 应用服务中间件
【nginx】配置Nginx实现负载均衡
【nginx】配置Nginx实现负载均衡
|
2月前
|
负载均衡 网络协议 Unix
Nginx负载均衡与故障转移实践
Nginx通过ngx_http_upstream_module模块实现负载均衡与故障转移,适用于多服务器环境。利用`upstream`与`server`指令定义后端服务器组,通过`proxy_pass`将请求代理至这些服务器,实现请求分发。Nginx还提供了多种负载均衡策略,如轮询、权重分配、IP哈希等,并支持自定义故障转移逻辑,确保系统稳定性和高可用性。示例配置展示了如何定义负载均衡设备及状态,并应用到具体server配置中。
|
3月前
|
负载均衡 算法 调度
负载均衡原理分析与源码解读
负载均衡原理分析与源码解读
|
3月前
|
消息中间件 负载均衡 Kafka
Kafka 实现负载均衡与故障转移:深入分析 Kafka 的架构特点与实践
【8月更文挑战第24天】Apache Kafka是一款专为实时数据处理和流传输设计的高性能消息系统。其核心设计注重高吞吐量、低延迟与可扩展性,并具备出色的容错能力。Kafka采用分布式日志概念,通过数据分区及副本机制确保数据可靠性和持久性。系统包含Producer(消息生产者)、Consumer(消息消费者)和Broker(消息服务器)三大组件。Kafka利用独特的分区机制实现负载均衡,每个Topic可以被划分为多个分区,每个分区可以被复制到多个Broker上,确保数据的高可用性和可靠性。
59 2
|
5月前
|
缓存 负载均衡 算法
解读 Nginx:构建高效反向代理和负载均衡的秘密
解读 Nginx:构建高效反向代理和负载均衡的秘密
115 2
|
4月前
|
负载均衡 算法 应用服务中间件
nginx自定义负载均衡及根据cpu运行自定义负载均衡
nginx自定义负载均衡及根据cpu运行自定义负载均衡
47 1