NLB无线定位服务器报警,一次异常艰难的Exchange NLB排错经历详细记录

本文详细记录了一次Exchange邮箱从无锡迁移到深圳机房过程中遇到的网络丢包问题及其解决过程。在排除了多个可能的原因后,最终发现是由于ARP表中的MAC地址不一致导致的网络异常。通过修正ARP表,问题得以解决,体现了IT人员在面对复杂问题时的坚韧和协作精神。
摘要由CSDN通过智能技术生成

最近一个月,我们在进行某集团的邮箱升级和迁移的项目,其中一个非常重要的工作任务是把客户的邮箱从无锡迁移深圳机房,由于客户对邮件服务的可用性要求高,所以我们最终决定采取Exchange 邮箱迁移的办法。这一个多月几乎在煎熬中度过,但是经历过痛苦之后,认真思考发现在这个项目中收获很多。Exchange排错的心得和大家分享, 我们定义本次Exchange排错为”Exchange NLB错误“, 排错的心路历程如下:

7bcfcf1564866db75c862a6a52499ead.png

1、 你总会认为:你解决的问题应该是最后一个问题了。

本次Exchange的项目中出现了非常多的奇怪问题, 之前出现过“25000Session限制问题”,后来又出现“32Session限制问题”,就这样我就已经搞了2个通宵了,每次问题解决的时候,我都会和我们的团队成员讲“靠,这个问题应该是最后一个问题了”。

2、 悲催,迁移500个用户后问题继续出现

前天,我们刚解决了9646的错误“用户Outlook 32 Session连接的问题”,监控系统稳定运行两天后,我们决定继续对无锡的用户邮箱进行迁移,计划晚上迁移500个左右用户邮箱,迁移500个左右用户邮箱后,用户Outlook又再次出现无响应的情况,某些区域近一半用户出现该类型故障。

3、 问题出现后的分析和定位

(1) 这次问题出现后,我们快速的定位到是网络的问题。从Exchange 2010的前端到后端,或从后端到前端都出现了大量的网络丢包。如下图所示:

e2b5abff4157d3d615b2d0bf21bc8976.png

(2) 但是我的环境中,有两套Exchange 2010的前端NLB, 有两套Exchange 2010的后端DAG;但是仅仅是NLB02和DAG02节点之间的网络通讯才会出现丢包;

(3) 根据这个怪异的现象,我们分析应该是和NLB、交换机、服务器网卡配置密切相关;

(4) 但是我们两套NLB的网卡是一样的、DAG的网卡也是同一个型号的、服务器连接在同一个交换机上,型号是Juniper;

(5) 因此,当天晚上我们计划对网络进行变更测试:

1) 变更1:更换网线进行测试,问题依旧;

2) 变更2:更换交换机端口测试,问题依旧;

3) 变更3:离线服务器,使用另一个计算机,使用原来的端口和IP地址,ping发现不丢包。

(6) 抓包测试,发现存在大量的数据包重传的测试。这个时候已经到凌晨2点了,网络组同事和Juniper的工程师都说要回去了。

(7) 网络组和Juniper工程师回去后,只剩下我们嘉为的工程师和甲方的工程师,也许搞IT的人注定需要忍受寂寞和孤单。

(8) 我们整了点“康师傅”,继续开始奋斗;

(9) 我们在看了看画在白板上的拓扑图,发现网络交换机没有换过,我们决定需要更换一个H3C的交换机试试。

(10) 下去找到网络组工程师,在进行风险评估后,决定尝试把DAG的节点转移到H3C的交换机上进行测试,在花费两个小时的测试和抓包后,还是失望的结果;

(11) 。。。。。。已经到了早上7点钟了。

4、 问题解决无望的时候,Workaround思路

(12) 甲方工程师说,之前出现过类似的问题,我们是通过更换服务器进行解决的;

(13) 早上9点,我们需要和周总进行该问题解决的汇报。准备申请服务器资源来解决这个问题;

(14) 周总说,你们先整理资源申请的邮件。

5、 王老吉的幸运,问题的解决峰回路转

(15) 王吉是我们的同事,王老吉是他的外号,因为他做项目一向比较顺畅,我们调侃他:王老吉你这个福将,这次不灵了。

(16) 早上8点半,幸运降临,王老吉吃完我买回的早餐,开始对服务器再次进行检查:居然发现一个奇怪的问题,当他运行一个ARP –d的命令后,网络丢包就会减少,但是过一会有再次出现大量丢包。

(17) 9点钟,和周总汇报,王老吉中断测试;

(18) 9点半,我们汇报完成回来,王老吉还在继续测试中,此时网络组同事王艺也回来,王老吉和他讨论了这个奇怪的现象。

(19) 10点,王艺在服务器上执行ARP –a的命令查看,居然发现一个奇怪的现象:前端NLB的MAC地址,居然在后端DAG上显示的不一样,但是我们的NLB是单播配置,应该MAC地址一样才对呀。

161e4cde8d56012b29d167e32be79723.png

(20) 奇怪的现象,也许就是导致该问题的原因:

1) 我们在客户端计算机上进行测试,添加静态MAC到服务器的ARP表格中,测试成功。

2) 我们写好命令,在1台服务器上进行添加:

netsh int ipv4 set neighbors 12 "10.0.15.10" "02-bf-0a-00-0f-0a" store=persistent

netsh int ipv4 set neighbors 12 "10.0.15.13" "02-bf-0a-00-0f-0a" store=persistent

netsh int ipv4 set neighbors 12 "10.0.15.14" "02-bf-0a-00-0f-0a" store=persistent

netsh int ipv4 set neighbors 12 "10.0.15.15" "02-bf-0a-00-0f-0a" store=persistent

netsh int ipv4 set neighbors 12 "10.0.15.16" "02-bf-0a-00-0f-0a" store=persistent

3) 完美!添加完成后,ping该服务器,没有丢包现象出现;

4) 在另一台DAG成员服务器上添加完成。

(21) 我们收集Outlook用户的反馈,客户端Outlook用户使用邮件正常,不会再出现无响应的问题。

6、 我们的总结

问题的解决和网络、操作系统、应用都是密切相关的、三方面的人员的密切配合最后该问题才解决。感谢大家在这个问题解决的过程中不推卸责任、全心全意的解决问题。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值