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

负载均衡故障排错指南(6) - 案例分析：谁动了我的配置？ 2012-11-25 21:50:29 标签： 负载均衡 故障排查 slb troubleshooting 添加标签 原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 /3027116/1070469 ? 很久没有更有关负载均衡排错指南的系列文章了。这一次，我将和大家一起分享一个有意思的案例。在这个案例中，我们像一个侦探一样，利用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需要解析的域名，我们假定为。 由于该用户的A10设备刚刚上线，客户怀疑是A10的设备功能存在问题，因此，责成厂家的工程师立即解决。 通过远程方式登录AX设备，我发现以下几个问题（为了方便描述问题，我将两台AX1000分别命名为A和B）： 1）????? A设备无法远程登录，登录B设备后，发现B设备处于Active状态，因此，判断设备曾经做过HA切换，并且顺利切换至B设备。 2）????? 通过A10的GSLB功能，无法对 域名进行解析，该域名对应的两个VIP地址健康检查结果为Down状态； 3）????? 进一步检查，发现B设备上并没有配置 域名对应的以及 这两个地址； 经过以上分析，我们建议用户重新添加这两个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??()?is?up? Jul?12?2012?10:36:46?Info????[HMON]:GSLB?server??()?