记一次出差排除客户问题的经过和方法总结,客户是金融客户,比较强势,一旦有问题甲方爸爸就直接会要求研发出差到现场定位,在本次网卡问题之前已经到现场排查过另外一个挂载镜像装系统会中断的问题了,排查下来是因为客户的堡垒机资源堪忧,且会有多个会话远程一起使用,明显是资源不足。因此本次网卡问题也是有点怀疑是客户弄错导致的。
本次出差前现场的博通网卡出现过一个批量的问题,网口无法up且指示灯不亮。最后定位出来是因为在BIOS下恢复默认配置时会把网卡的所有选项置为0和disable,所以media auto detect也变成了disable,网口速率不会自动协商,导致网口灯不亮,OS下网口也一直是down的状态。过了没几天,客户再次反馈有两张网卡的各一个网口做了bond,已经排除了上次的选项导致的问题,并且网口灯是亮的,但是OS下网口还是无法up,要求我们去现场尽快定位。其实正常情况下,我们听到这种问题现象,最基础应该怀疑的就是客户会不会弄错网口了,因为只要网卡灯亮了,那么OS下是肯定能up的,但是因为客户的专业性是OK的,还告知我们交叉更换过正常网口的对端网线,并且前期网卡问题出现过作为背景,就想当然的忽略了这点。于是决定到现场后按照下面步骤排查问题
- BIOS下看下网卡的配置选项,先确认上次的问题不存在,网口确实应该是属于正常状态
- 在OS下查看网口的配置文件,和客户的bond配置文件,进行一些up和重启bond的动作,查看网口能否up
到现场后完成以上两个动作后,发现客户说的那两个口确实是一直down的,且之前的选项问题确实不存在。接下来对我们来说最直观的一个判断步骤,就是用笔记本直连这两个网口,看能否up起来。于是和客户经过非常高大上的走廊和流程,进到他们的机房。客户指出了两个口说这是他们的业务口,另外两个口是存储口,于是对着这两个所谓的业务口进行直连,发现确实up不起来,一直是down的。灰溜溜回到客户办公室工位,接下来得求助下网卡厂商了,网卡厂商要求收集ethtool –w <device> data debug.core,这个文件是网卡的dump故障文件,有异常可以在里面看打印,金融客户收集信息也非常麻烦,需要走流程审批,紧急审批之后终于给我们取了出来,厂商看完之后觉得没有什么异常,没有故障相关信息,与此同时,我决定采用一个直观的方法,我开始查看这两张网卡做bond的两个业务口和另外两个客户所谓的存储口的配置差异,通过ethtool工具观察,用到了-i –S 参数,查看的结果都一致,当看到-m参数的时候,发现了异常,如下图
可以看到起不来的口有两个参数是on的,而另外两个正常口这里是off的,咨询网卡厂商这个参数是光模块的,不属于网卡,也无法修改。于是再次提出进入机房的要求,希望交换光模块看看是不是光模块的问题,之前只做了光缆的交叉测试,确实没动过光模块。再次进入到机房后,交换光模块,发现问题仍存在,此时注意到一点,就是OS下这两个起不来的bond口在网卡的物理位置上理论上是右侧的,而客户最开始指示给我们的所谓业务口是指向左侧的,网口的命名和物理位置如果需要互调是需要更改网卡配置文件的,个人觉得客户不可能更改过这个,于是觉得很有可能客户配置bond的口和指给我们的物理口其实对应错了。内心抱着不可能吧的感慨查看了另外两个储存口的网口配置文件,是关闭的,怪不得怎么都up不起来,客户实际上指给我们看的两个口是没做bond配置也没开启网口的存储口,而另外两个所谓的存储口,一直灯亮着的,就是正常配置了网口和bond配置的业务口,怪不得客户会反馈灯亮但是OS下网口无法UP!!当然了,问题其实也不仅仅这么简单,最主要的原因是客户的基础设施部门跳线接线错误了,导致客户的系统部门没想到这一层,认为是服务器的问题。最终陪着客户找他们内部的跳线接线部门以及网络部门进行沟通,才最终解决了问题。
以上是流水账,在现场压力确实很大,需要抗住压力细心思考和判断,总结一下网卡网口问题的定位思路
- OS下网口相关配置文件查看是否异常,可以对比正常和异常的网口的配置文件及bond配置文件
- 物理层面交叉光模块和对端线缆排查,确认是口本身的问题
- 使用ethtool工具对比正常网口和异常网口的配置信息,寻找突破口,来确认是配置还是网卡本体的问题
- Bios层面的选项是否对网卡有做限制
网友评论