Windows Network Load Balancing群集故障排除手记。

     在为一个客户做基于Windows Network Load Balance（NLB）的群集时遇到了前无古人的问题，请教了公司的顾问服务部资深顾问并在微软开了Case仍一无所获，最后通过Microsoft Monitor结合网络环境分析终于解决了此问题，特此Mark下。

     建立单播模式（Unicast）的一个群集，主机名称要用现在的电脑名称（因为应用程序中很多地方记录了主机名称），建立过程极其简单和顺利，这里不做表述。在建好群集后，用原来的名称一访问竟然弹出一个对话框要求验证（Windows Authentication），无论输入什么都通不过，问题很象另一位仁兄遇到的（网址忘了）。一开始我们都在群集这里找问题，一直都没有结果。后来客户主动建议从网络方面找找问题，于是尝试用一个新的名称和IP进行了测试，进行访问时一切正常，但回到原来的存在的电脑名称就故障依旧。通过Microsoft Monitor监控显示，在使用旧的电脑名称时，客户端使用的验证协议是Kerberos 5.1，而在登录到新的主机名称时，客户端通过NLMP（还是NTMP？忘了）与主机验证，因此我们怀疑问题发生在网络和域这两方面。由于客户的IT服务已全部外包，对交换机、域控制器等访问要通过外包公司走到新加坡，管理员的身份那是想都不能想的。最后走了个捷径，请客户的IT Manager直接和外包公司的管理员进行处理，将原来的机器名称从域控（Active Directory Controller）、DNS、WINS上删除，在重新建立群集后，访问一切正常！

    客户的网络确实复杂，全球部署、服务器要么在香港要么在新加坡或者美国。本地的IT被绝对弱化，对域没有任何权限，就算改个名字也需要走个流程先到北京再到新加坡。上次RMS的部署就是因为没有域管理员权限而中止，这次又撞在了域的枪口上，还好有一个较高级的IT Manager协调才解决了此事。万幸万幸！

 

    后记：某天一不小心把原来的那台服务器打开并连接了一下网络，“哐铛”一声群集当了。检查来检查去找不出原因，索性花了3分钟把群集删了重建，故障就此排除。