应用交付工程师Troubleshooting经验分享

来源：http://blog.51cto.com/virtualadc/1188328

来源：http://blog.51cto.com/virtualadc/986682

来源：http://blog.51cto.com/virtualadc/1070469

应用交付设备在网络中的作用比较特殊，一边跟客户端通信，需要支持二三层交换机的功能，另一边跟后面的服务器或者其他应用设备相连，需要支持Layer 4的协议转换，但是这只是基本功能，应用交付设备作为具体应用的代理或者中转器，需要支持Layer7的功能，根据不同的应用协议，做出不同的分析处理或者优化。

以上特点决定了一个应用交付工程师不是简单地学习一下手册或者接受一下培训，再加上一定的知识基础就立刻能够胜任，必须不断地丰富知识范围，并且对各方面精研原理，才能成为专家。

能力的缺陷在Troubleshooting的时候特别能够显现出来，做技术的每个人都经历过菜鸟阶段，不同的人可能出过不同的丑，前人栽树，后人乘凉，希望本文的经验能够对从事这一行业的同行有一些启示和帮助。

下面我们来对具体问题一一分析：

1. 登录问题

某一天你去客户那儿做测试，你对设备并不熟悉，因此心里有些胆怯，然而怕什么来什么，倒弄了半天，连设备都没登录上去，客户一脸愠色地在旁边看着，你的心越来越乱，这是很多人曾经经历过的场面。今天颇有经验的你，对此有何对策？我们分为各种现象讨论：

1）设备加电了吗？

切莫笑，这个低级错误真有人犯过。一个场景是设备之前就拿到了客户机房，你是后来去做配置，机房嘈杂，你以为已经加电，加上客户在旁边看着，心里慌张，上前连上电脑就开始登录，试了Web界面不行，命令行还是不行，Console口仍然没有反应，弄了半天，反而是客户在旁边说了句:还没开机吧? 你恍然大悟，继而无地自容。这种事没什么可说的，没有任何技术因素，克服心理慌张即可。

2）Console口无法登录

设备确认已经启动，但是Console口无法登录，终端上没有任何显示，这也是很急人的事情。不慌张，检查一下：

l 波特率等配置是否跟设备手册要求的一致？

l 你是不是把Console线插到了Mgmt口？（某些设备Console口和Mgmt口外观是一样的）

l 换根Console线试试：Console线可能坏了？或者你的Console线是不是电脑城买的便宜货？（某些厂家的设备对Console线有一定要求，不是什么线都行）

l 如果可能，重启一下设备试试？

l 先不管Console口，试试从管理口登录一下？

3）管理口没有回应

l 你电脑配地址了吗？

l 如果电脑配了地址仍然没有显示，管理口的地址是否被人改过？先试着从Console口进去看一下，如果console口也登录不上，那么赶紧问问是否有人改了管理口地址吧。

l 设备启动成功了吗？

４）管理口无法登录

命令行和Web界面都有登录提示，但用默认密码登录不进去，最大的可能是密码被人改了，小部分可能是设备启动的不完全，登录认证模块有问题。

如何恢复默认密码？

一般设备都有reset password的方法，打电话问人也好找资料也好，学会恢复初始密码即可。

５）无法通过数据口登录

l 你的电脑上IP地址配对了吗？

l 电脑连接的设备端口是否是UP的？有些设备需要Enable端口才能通。

l Web登录不了？配置中开放了Web访问吗？

l Telnet登录不了？配置中开放了Telnet访问吗？

l SSH登录不了？配置中开放了SSH访问吗？

2. 网络问题

设备能够登录，我们开始进行配置，先根据客户的规划，配置网络，划分vlan，配好地址，然后测试连通性，问题又出现了。

1） 网关不通

直接ping对端网关不通，有多个因素需要检查，最基本的我们应该首先验证设备是否学到了对端的mac地址，这个通过show arp或者show mac这样的命令可以看到，如果本机根本没有学到对端的mac地址，那么必须注意如下几点：

l 端口是否up的？无论是本设备端口还是对端设备端口，如果没有up，自然网络不通，这个通过类似show interface的命令看一下就知道了。

l 对端网关配地址了吗？客户告诉你网关是某某地址，但不见得已经配好或者启用。

l 自己配的地址是否不小心配错了？总有这样粗心大意的工程师。

l 是否把线错误地插到了别的vlan/端口？

2） 路由不通

从设备上ping跟设备非直连的内部服务器或者ping外部公网地址不通。检查如下几方面：

l 设备上配了到目的地址的路由吗？

l 中间的交换机/路由器等配了返回路由吗？

l 中间是否有防火墙没有开放访问策略？

l 你访问的地址存在吗？

3） 网络问题Troubleshooting工具/命令

l Arp : 检查二层连通性。

l Ping: 检查三层连通性。

l Traceroute: 在到达某一目的地址存在多条路由的情况下，验证数据包路径。

l Debug: 某些设备厂家会内置Debug命令，可以做到二到七层的数据包检查，通过Debug命令，数据包的流向等一清二楚，这是应用交付工程师的终极工具，在后面分析应用问题时还要提到它，一定要掌握。

（未完待续，后文将讲述跟应用相关的各种问题）

前面讲述了设备登录管理以及可能遇到的网络问题，下面继续讲述4-7层配置及调试中可能遇到的问题：

（一）服务器负载均衡

1. 虚拟服务器(VIP)访问不通

常常有人打来电话，一开口就是我配了VIP后，为什么访问不通呢？这是个很低级而操蛋的问题，我知道你想问为什么访问不通？但一没告诉网络结构是怎样，二没告诉你是怎样配的，三没告诉你已经做了哪些分析和调试，鬼才知道是为什么。但是不解决是不行的，因为打给你电话的可能是客户，所以我们必须要整理思路，循循善诱。

1) 配置正确吗？

这个是首先要检查的，是自己在现场解决问题，就需要自己细心检查，如果自己搞不定，请人帮忙一定要先把你做的配置发给别人，并且说清楚如下几样事情：

l 客户需求是什么？

l 网络拓扑是怎样的？（网络拓扑直接关系到应当如何配置）

l 服务器是什么应用，什么系统？（不同的应用有不同的特点和不同的配置方式）

l 用户访问流程（越详细越好）

2) 服务器的服务是起来的吗？

总有这种情况，你的服务器是加电的，但服务是否起来了,可能没留意，所以第一步从负载均衡设备角度先确定服务是否起来了，检查方法：

l 如果设置了ICMP健康检查，检查设备Ping服务器看是否成功。（ICMP健康检查一般配置在Server下面，其他健康检查一般配置在端口下面，若Server检查为down，该所有应用都为down，所有若服务器禁Ping，则只在端口下面设置健康检查，不要用Ping检查服务器地址）

l 去服务器上查看服务是否在运行

l 在负载均衡设备上查看server状态：show slb server

l 在负载均衡设备上用telnet命令探测服务端口，例如：telnet 1.1.1.1 80,若有响应，则服务端口是起来的。

l 以上其实还不够，对于一些三层架构的平台，web服务器端口可能起来了，但应用服务器或者数据库服务器可能有问题，所以还有个检查的办法是直接访问服务器操作一下，确认服务器操作没问题。

3) 服务组是UP的吗？

设备健康检查看到服务器的服务是up的，但访问仍然不通，这时候需要继续确认服务组是否up，毕竟VIP关联的是服务组，只有服务组up，VIP才会up。

l 检查服务组状态：show slb service-group

l 如果上面显示相应服务组的检查为down，检查服务组中是否单独配置了健康检查，可能跟健康检查有关。

4) 健康检查

一般负载均衡设备都内置了4-7层各种常见协议的健康检查，要单独配置健康检查根据模板自己配置一个即可。有些负载均衡设备（例如A10）对于服务器缺省带四层的健康检查，若不自己对服务组手工另配健康检查，则默认沿用服务器健康检查的结果。而有些设备必须手工配置健康检查。所以健康检查问题可能如下：

l 自己创建的健康检查正确吗？例如http健康检查要get一个url，你填的url根本就不存在，自然检查不成功。再如一些要求比较复杂的健康检查，要求多个条件进行逻辑与和或混合判断的，往往自己创建的健康检查就不正确，需要仔细调试。

l 服务器或者服务组配的是正确的健康检查吗？经常见到有人在服务组里面配了个ping的检查或者把健康检查配错，例如这不是http服务，但配了个http的健康检查。或者某个健康检查配的是对指定端口的检查，但把他用在了其他端口下面等等。

l Port 0 仍然保留了健康检查，0代表所有端口，假设你保留了tcp的健康检查，设备可能去探测端口65535，该端口根本就不存在，健康检查自然不会成功。

l 某些特殊的服务不响应你的健康检查，这种情况确实存在，解决的办法只能根据服务器的要求，自己编写一个健康检查脚本去检查它才能成功（该功能只有少数设备能做）。

l 健康检查不停地报up/down, 这种问题很难判断，一种是情况是服务器压力过大，导致有时不能及时响应，另一种情况就比较复杂了，服务器上不知道配置了什么安全软件或者检查机制，导致健康检查不正常，这种情况需要客户自己去检查服务器，负载均衡设备除了多试几种检查策略之外，基本上没有其他可调试的办法。

5) 是否需要配置snat?

如果负载均衡设备是旁路接入，就必须考虑是否要做源地址转换。这基本上要成为本能反应。还有一种情况，如果服务器直连到负载均衡设备，或者虽然是负载均衡设备旁挂接入，但服务器网段跟客户端网段不同，而服务器指的网关是负载均衡设备地址，这个时候是可以不做snat的。需要配snat而没配基本上会出现在一些经验较少的工程师身上，一旦出现这种情况，访问肯定有问题。

6) 会话保持

负载均衡配置三部曲：分发算法，健康检查，会话保持，再加上一个是否要做源地址转换，这些是基本要素，要时刻在心，在做配置的时候就应该本能想到，这些要不要配，怎么配？而不是出问题的时候，才检查到原来这个没有配。一般来说除了一些仅仅提供浏览业务的服务器，例如各大网站的新闻频道等等，客户服务器涉及到用户登录才能操作的系统，那是必须要配会话保持的。至于配了会话保持后，分发是否均衡，以及如何均衡，我们另找专题讨论。

7) HTTPS证书

如果对外发布的服务是HTTPS，而访问VIP却无法访问，首先检查负载均衡设备上配置的vport协议类型，如果配置的是port 443 tcp，那么负载均衡设备是按照TCP协议来处理，SSL的加解密是由客户端跟服务器之间完成，如果配置的是port 443 https,那么就要检查你在443端口下配置证书模板了吗？不配证书，负载均衡设备无法完成跟客户端之间的SSL交互，你的访问自然不通。如何导入和配置证书模板，可以参看其他文章。

2. 服务器4-7层问题Troubleshooting总结

以上描述多是基本问题的Troubleshooting，更多的疑难问题需要结合自己的经验和用户的应用特点专门分析。不过Troubleshooting的思路是一致的，具体做法总结如下：

l 明确网络拓扑，首先确保二三层工作没问题：网络互连，路由无问题。

l 检查真实服务器状态：show slb server

l 检查服务组状态：show slb service-group

l 检查虚拟服务器状态：show slb virtual-server

l 检查Log，分析Log中的告警信息。

l 万能工具：抓包，无论是二三层，还是四七层的访问，通过抓包可以实时跟踪某个访问的转发处理细节，很多情况下，我们遇到的问题无法从配置以及基本检查中获得原因，这个时候抓包分析是最有用的，例如：用户反映某客户端访问某个Ｗeb服务有异常，那么按照如下方式抓包：

Debug packet l3 ip <客户端IP> l4 tcp 80 count 0

Debug monitor

客户端IP访问目的端口为80的包都会被记录下来。对于抓包来说，不但是要会抓包，更重要的能够对抓包内容进行分析，这考验的是你对TCP/IP协议知识的深刻理解。

审计日志查看配置更改

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

至此，整个事件真相大白。在整个事件的分析过程中，系统日志帮助我们还原了整个事件发生的经过。通过对比前后的配置变化、查询相关的日志记录，我们成功的还原了整件事情的发生过程。