现 象 描 述

某客户为了提高业务性能和高可用，在现生产环境中添加负载均衡设备来分担已在正常运行的应用，在添加之前基于安全考虑，在测试环境中已做过模拟部署测试，效果符合预期。
在正式将负载均衡设备部署到生产后，业务部门反映在做业务时比之前有2秒左右的延时。通过网络部门在网络上抓包分析，进一步验证了业务部门的反映：

现 象 分 析

由于生产环境在引入负载均衡设备之前运行在HP服务器上的应用是正常的，引入负载均衡后业务处理才会发生2秒的延时，所以在查找问题时只是负载均衡厂商在查找问题，在查找一周左右后依然不能定位问题，最后找HP介入查找问题。
从抓包看，每笔交易有2秒延迟，HP服务器上还有其他网络应用以及通用的ssh等应用则没有影响，可以基本判定2秒延时应该和HPUX主机的TCP/IP协议栈本身没有关系，猜测应该和应用有关系。因此建议跟踪程序的执行，查看在何处的系统调用会有两秒左右的返回，由于在测试环境下没有发生2秒延时的情形，只能在生产环境中跟踪，而在生产环境下跟踪应用会对性能带来不利的影响，需要安排合适的能接受的时间窗口来执行。
在和用户沟通过程中，用户反映一个之前发生的情形，之前其他主机和此服务器互联时也曾经有过类似情形，在hosts文件中加入对方信息后，故障就消失了。
此信息给出一个有用的提示:此现象很可能和DNS解析有关联。查看生产环境服务器配置，在resolv.conf文件中，有两个server项，同时设置了timeout 1s，retrans 2的数值，和两秒的延时一致，在测试环境的服务器上则没有配置DNS客户端。
测试验证，在测试环境中，将测试服务器设置为DNS客户端，则通过抓包发现会发生2秒延时。

Root Cause 解释

在该场景中，客户访问服务器并没有采用域名的方式，采用IP地址的方式访问服务器，而服务器则配置成DNS客户端为了从服务器访问其他系统时可以用域名访问。在DNS场景的名称解析有两种，第一种是从主机名解析成IP地址，此为最为常用的一种场景，第二种为从IP地址解析成域名，此场景用的很少，只是在一些应用有安全防主机欺诈等需求的环境中使用。在此场景中，客户端用IP地址直接访问服务器应用，服务器应用已经得知客户端的IP信息，通常情况下，即使服务器配置成DNS客户端，服务器也不会采用gethostbyname的调用，但服务器应用如果采用gethostbyaddr调用从客户IP希望获取对应的域名，则需要做DNS解析，将此推测和开发商沟通，应用开发商在源码中发现确实是调用了DNS反向域名解析。
那么还有一个问题，为什么之前没有发生2秒延时，而在加入负载均衡设备之后发生呢？这和负载均衡的部署方式有关，负载均衡的部署方式有几种，通常采用旁路的方式可以不用改变现网的结构，此方式是比较常见的一种部署方式，但有个缺陷是通常在此方式下，服务器端看不到客户端真实的IP地址，看到的是负载均衡设备的IP地址。
在部署负载均衡设备之前，在服务器的hosts文件或DNS服务器上有客户主机的信息项，所以没有发生2秒延迟现象。
在部署负载均衡设备时，在DNS服务器或hosts文件中没有做相应变更，导致在做DNS反向解析时，由于缺乏负载均衡设备IP的相关条目产生解析失败延迟2秒。

解 决 方 案

针对以上问题，解决方案如下：

1. 在服务器hosts文件中加入负载均衡IP条目。
   2.在DNS服务器上加入负载均衡IP相关记录。