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分钟把群集删了重建,故障就此排除。
posted on 2008-12-01 21:12 软件之美,美在缺陷-Johnson 阅读(1872) 评论(1) 编辑 收藏 举报