负载均衡故障排错指南 （5）

故障排查方法论

 

故障排查方法

简单的来说，故障排错的方法很简单：说明问题，分析问题，解决问题。在这三个步骤中，分析问题花费的时间最多，说明问题却最容易被我们忽略，而解决问题则相对简单。

 

• 说明问题

当问题发生后，我们应该做的第一件事是尽快收集信息，确定问题的现象以及造成的影响。有时候，我们还需要利用一些工具做一些对比测试，以进一步对问题进行确认。

通常情况下，我们可以通过回答以下问题来对问题进行进一步的定位：

·   出现问题的是一直在用的应用还是新上线的应用？

·   在问题出现之前一段时间，网络或应用是否进行过调整？

·   什么类型的应用出了问题？对应的VIP地址是什么？可能的话，判断可能出问题的功能模块。

·   确定问题发生的频度，是经常发生，偶尔发生还是总是发生？

·   确定问题的影响范围，是所有用户都遇到同样的问题，还是只有某些固定的用户遇到问题，还是部分用户（不固定）遇到这样的问题？

• 分析问题

通过分析上述问题的答案，我们可能对问题有一个初步的判断。并大致的对问题进行定位。我们假设可能导致问题的种种原因，并通过进一步的信息收集，或采用工具来做一些简单的测试，验证自己的猜想。当测试的结果与自己的猜想一致时，你可能就找到的导致问题的原因。

这个方法很简单，但是却需要工程师对相关的网络知识有比较深入的理解——注意，我这里用得是“理解”二字。因为，只有你真正理解了这些基本的原理，分析问题时才会得心应手。

在这里，我跟大家分享一个“简单”的训练方法，能够帮助我们更加深入的理解网络中的这些基本原理。

想象一下，这个网络中只有三个简单的元素：客户端PC、交换机、Web服务器。如果客户端通过浏览器来访问服务器，你能否充分发挥你的想象能力，想象一下整个数据在终端、交换机、服务器上的处理流程？

 

最简化版：

客户端发送HTTP请求，通过交换机转发至Web服务器，然后Web服务器响应请求。

 

这种描述方式可能是最简单的了，但是，对于网络工程师来说，却是无用了。我们可以对这个描述进行一些细化：

 

简单版：

·  客户端首先与服务器建立TCP连接

·  客户端在该TCP连接中发送HTTP请求

·  服务器收到请求后，将响应内容返回给客户端

 

有点意思了。至少，我们知道HTTP请求是封装在TCP协议里的。还能再细化一点吗？当然可以。

 

TCP交互版：

·  客户端首先向服务器发送TCP SYN数据包，请求建立TCP连接。

·  服务器返回客户端SYN+ACK

·  客户端向服务器发送ACK数据包，TCP三次握手成功。

·  客户端向服务器发送HTTP请求

·  服务器向客户端返回ACK数据包，确认请求收到。

·  服务器向客户端返回响应内容。

·  客户端向服务器返回ACK数据包，确认响应内容收到。

·  服务器响应内容发送完毕，发送FIN1来终结TCP连接

·  客户端收到FIN1后，应答FIN1+ACK，并发送FIN2关闭TCP连接

·  服务器收到FIN2后，应答FIN2+ACK，TCP连接关闭

 

在这个版本中，我们已经比较清晰的分析了TCP协议的交互过程。还能再进一步细化吗？回答是：当然可以。这一次，我们将加入二层的一些交互分析。

 

ARP交互版：

想象一下，你的PC客户端是一台刚刚开机，配置了静态IP地址。当你在浏览器中输入服务器地址时，PC、交换机、服务器之间会怎么交互呢？

·  PC会根据自己的掩码和地址，来判断你要访问的服务器IP地址与自己是否属于同一网段。

·  如果属于同一网段，则查询本地的ARP缓存，查找服务器IP对应的MAC地址。

·  如果找不到，PC会通过网卡发送一个ARP查询广播报文，源MAC为自身，目标MAC为FF:FF:FF:FF:FF:FF。

·  服务器收到了这个ARP的查询广播后，会通过单播的方式，向PC终端发送一个ARP查询应答，告诉PC，自己就是它要找的那台服务器。

·  PC收到ARP应答后，会将该IP与MAC的对应关系放入自己的ARP缓存系统中。

·  然后，PC会将TCP SYN封装成数据帧，目的MAC为服务器MAC地址，并将该数据帧转发给交换机。

·  同样，交换机在收到各种数据帧后，会将源MAC与端口的对应关系，放入自己的MAC-ADDRESS-TABLE中。这样，下次再收到数据帧后，查询自己的MAC与端口对应关系表，就可以进行快速转发了。

·  交换机将TCP SYN数据帧转发至服务器所在的端口。

·  服务器收到TCP SYN之后，后续将按照前面所描述的那样，二者之间进行三次握手、发请求、响应、关闭连接。

 

当然，这里只有简单的三个元素，在复杂的网络环境中，你可以想象网络中的数据从PC生成，在各种设备中的处理过程。你想的越仔细，那么，你就越容易找到可能导致问题的原因。

 

当然，在真正出现问题时，我们需要在最短的时间内找到导致问题的原因。因此，你可以对这些交互过程进行一些简化，重点对你怀疑的环节进行分析，尽量弄清楚设备在这个环节上的处理规则，并通过设计一些小的实验来验证自己的猜想。

 

• 解决问题

找到了导致问题的原因，那么解决问题就相对比较简单了。当然，有时候，受限于当时的环境和条件，我们可能无法彻底解决问题，那么，也可以采用一些临时的解决方案，来临时的解决问题，这个就要针对具体的问题具体分析了。

 

常见的故障排查原则

· 自底向上的排查方法

自底向上的排查方法与网络协议的分层设计有关，从物理层开始，逐层向上进行排查，并逐层排除可能导致问题的原因。比如：用户报告说无法访问服务器了，那么，从服务器与交换机的连接线开始，首先查看物理层的端口的状态指示灯，然后检查交换机、服务器上的链路状态，然后检查ARP表、路由表等等，这样一层层向上进行排查，并最终对问题进行定位。

· 分而治之的排查方法

在某些比较大的网络中，自底向上的排查方法可能会显得比较复杂，因此，可以采用ping的方式，对可能出现问题的层次进行判断。如果能够ping通，至少说明网络层以下是没有问题的，问题可能出现在上层；否则，如果ping不通，则说明问题可能出现在网络层以下。

· 数据流追踪法

对于负载均衡设备来说，大部分的问题可能都是来自于网络层之上的。因此，通过抓包工具来追踪数据流的处理过程，对于故障排查排查和分析来说，也是一个非常有效的方法。

· 配置比较法

有时候，如果怀疑配置可能有变化，那么，与原来备份的配置进行一些比较，也许也能够找到一些线索。

· 模块替换法

模块替换法经常用于可疑的硬件故障。比如：通过替换光模块，我们可以判断是否是光模块的损坏而导致的问题。

 

在接下来的章节中，我将带大家利用这个方法论和常见的故障排查原则，结合一些案例，来介绍常见的负载均衡问题及排查方法。

 

E.S.