网卡绑定失误导致的业务中断案例

环境介绍：

宿主机四台，每台配置两块双口万兆网卡；接入交换机两台。

网络分管理网段和业务网段，每一个网卡上的双口分别上联两个不同交换机，交换机对端口设置Trunk模式，允许任何网段通过，不需要做绑定。网卡侧需要按照交叉方式绑定四个端口为两组，分别走业务和管理，交换机不需要绑定。

问题描述：

所有虚拟化环境部署完毕，在结合业务做切换测试的过程中，开发人员报告部分业务系统不可访问。

解决过程：

第一反应，先做客户端到应用系统的Ping测试。DNS解析没有问题，但是网络不可达。

第二反应，网络可能有问题，检查客户端到目标网段的网关可达性。网关全部可达。

第三反应，问题出在接入交换机和宿主机链接上，难道发生了双点故障？于是询问运维人员设备监控情况如何？运维人员说一切正常，没有发现异常。

第四反应，什么情况？监控一点直觉没有么？再问，

问：某某机柜某某交换机有没有问题？某某机柜某某服务器有没有报警？

答：回答说，没有报警，不过....。不过什么？有一个交换机在升级firmware，属于正常停机，不在异常范围之内。

问：就一个？

答：对，就一个。

第五反应，不对啊，任何单点都不可能影响到架构的高可用啊。VC登录上去查具体的机器状态，结果所有机器处于运行状态。再次确认问题出在接入交换机和宿主机之间的链接上。于是让运维人员进入机房再查网卡以及交换机状态。报告说有一台机器的其中一个网卡的两个口全部没有上联信号。

第六反应，网卡帮错了。再查，网卡绑定顺序与其他同类型的机器顺序一样啊。查MAC对应关系，结果发现这台机器的Vmware显示的网卡顺序确实与其他机器识别达到的网卡设备名顺序不一样。当初实施工程师仅仅靠着一个样本机的网卡设备文件名与物理网口的对应关系就按照一个标准实施了。

问题总结：

对于这个案例来讲，其实高可用的设计也好，网卡绑定技术也好都不是问题。问题的关键是工程师想当然认为一种型号的机器对于IO设备文件名的识别顺序是完全一致的。其实不然，不同场合下可能设备文件名的顺序会产生不一致。幸亏这个问题是在测试阶段发生。两个教训：第一、不要想当然，用事实说话。第二、实施后的检验过程非常重要，可以救你一条命。