搞IT的都知道,总是不经意间遇到由于网络问题导致系统异常,有时候是网络配置错误,有时候是防火墙阻挡了,有时候是流量过大导致,笔者近期遇到一个网卡BUG问题,导致数据库节点扩容受阻的案例,给大家分享一下。
某客户的Exadata一体机需要扩容4个计算节点和2个存储节点,各种前期准备工作都到位,2个存储节点也顺利扩容完成,但是在扩容第一个计算节点时,拷贝文件非常缓慢,10多G的文件拷贝了1个多小时还没完成,通过ping以及查看网卡信息都是正常的,没有断连过。由于变更时间的关系,暂时停止扩容该节点,先扩容其他节点,后续再处理这个异常问题,而其他节点则很顺利完成扩容,10分钟即可完成10多G的拷贝,整体3个节点的扩容,1个半小时全部完成。
回过头来,分析问题节点拷贝文件缓慢的原因,发现在服务器起来后,在/var/log/messages日志文件中,就不断出现网卡bondeth0自动down和up的日志信息,日志文件如下:
贴一下文字日志:
Jul 14 05:35:24 dmxxdbxx kernel: [178532.687660] bnxt_en 0000:af:00.0 eth3: NIC Link is Down Jul 14 05:35:24 dmxxdbxx kernel: [178532.707675] bondeth0: link status down for active interface eth3, disabling it in 2000 ms Jul 14 05:35:24 dmxxdbxx kernel: [178532.938901] bnxt_en 0000:af:00.0 eth3: NIC Link is Up, 10000 Mbps full duplex, Flow control: ON - receive & transmit Jul 14 05:35:24 dmxxdbxx kernel: [178532.938909] bnxt_en 0000:af:00.0 eth3: FEC autoneg off encodings: None Jul 14 05:35:24 dmxxdbxx kernel: [178533.006940] bondeth0: link status up again after 300 ms for interface eth3 |
把相关日志发给原厂分析,最终得到的结果是一个固件BUG,需要给该固件升级补丁。据了解,在X7刚出来时,很容易遇到网卡BUG,不过后来出来的X7很少遇到了,因为后来交付的X7已经升级了相关补丁。 日志文件显示,bondeth0状态转为down,失效2000ms,然后接着马上300ms又up起来,所以我们通过ping无法发现网络断连的问题,因为ping是有间隔的,而拷贝文件是需要一直持续的,如果中间出现网卡断连,肯定会影响拷贝的速度。
总结,这一次扩容,遇到了以前扩容没有遇到过的坑,在此,以后扩容前,不仅仅是检查网络是否通畅,还需要检查节点间的拷贝速度是否正常,需要手动scp文件到新节点测试拷贝速度。一般来说,如果是大文件,拷贝速度200M/s以上属于正常,如果下小于1M的小文件,每秒20个以上是正常速度。