网络问题，IT人总会遇到的坑

         搞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个以上是正常速度。