IBM WAS系统从Linux迁移至Windows后应用访问异常
客户最初业务系统部署在Linux OS上，经过ADC设备运行很长一段时间没有问题。 App-WAS-Linux-Vmware ESX；App-WAS-Windows-Vmware ESX； 业务迁移前后的IP地址配置不变，ADC负载均衡设备和网络都没有做任何调整。迁移后发现VIP可以ICMP成功，Telnet VIP对外端口正常，但是HTTP请求卡顿错误。 排除Vmware ESX配置后，咨询WAS供应商。这个问题的核心在于Linux 和 Windows 操作系统在处理未知主机名反向解析时的行为差异，并与负载均衡的IP代理模式共同作用，最终导致了业务中断。负载均衡代理模式
为了尽可能少的修改原有网络架构，负载均衡在部署过程中经常会采用代理模式，当 LB 收到客户端请求后，它会以自己的一个IP地址作为源IP，与后端的WAS服务器建立新的TCP连接。因此，从WAS服务器看到所有请求都来自这个PIP地址，而非真实的客户端IP。
WAS 应用的行为
运行在WAS上的业务在处理请求时，会尝试对连接来源的IP地址（即PIP地址）进行反向DNS解析（Reverse DNS Lookup），以获取其主机名。这通常是应用日志记录、安全审计或业务逻辑的一部分。
操作系统行为差异
- Linux WAS: 当Linux系统上的WAS尝试解析PIP地址的主机名时，如果DNS服务器无法提供记录，Linux系统通常会快速失败或返回IP地址本身，这个过程耗时极短，对业务交互的等待时间影响可以忽略不计。
- Windows WAS:Windows系统在DNS解析失败后，会尝试其他名称解析机制，其中最常见的是 NetBIOS over TCP/IP。NetBIOS名称解析会进行广播或查询WINS服务器，这个过程有较长的超时等待时间（通常是数秒）。WAS发起反向解析请求后，由于PIP地址没有对应的DNS记录，Windows系统陷入了这个漫长的等待中，导致业务线程被阻塞，从而出现“业务交互等待”的现象。
- 在每一台部署了WAS的Windows服务器上直接配置HOSTS文件，路径通常是：
C:\Windows\System32\drivers\etc\hosts 将PIP地址添加到HOST文件中，保存文件立即生效。
10个月宝宝每天需要喝多少奶粉？
