现网案例【1】：某数据中心计算节点无法访问分布式存储的排查实录

案例背景

组网架构图

案例背景，基于现代云数据中心
SpineLeaf组网架构，并且采用存算分离架构
Str-Server为存储服务器
NFV-Server为计算服务器
组网层面
Spine采用M-Lag组网，Spine承载双活网关做流量转发
Leaf采用主备接入，各服务器网口配置bond模式为mode1

问题经过

事件发生前Spine刚经历完割接，第二天云平台方发现测试业务虚机全量卡死，排查发现存储掉线，于是报障
得到通知后，立即介入排查，并且要求当天凌晨割接人员提供配置脚本，以及割接后采集脚本

排查思路

存储掉线问题排查思路：

云平台方已告知存储掉线
首先尝试登录存储服务器命令行&BMC带外，查看设备运行、及端口状态是否正常
排查Leaf侧，观察Leaf侧上下行端口或聚合是否正常，查看MAC表对应VLAN下是否学到存储服务器的MAC
排查Spine侧，观察至下行Leaf侧端口或聚合是否正常，查看MAC表对应VLAN下是否学到存储服务器MAC

排查过程

【1】Leaf侧排查：

经排查Leaf侧端口正常

经排查Leaf侧端口、VLAN、MAC学习正常

【2】Spine侧排查

经排查Spine侧端口为正常，但流量极低

遂排存储业务VLAN下MAC地址学习情况，发现异常
该VLAN下没有学习到任何MAC地址

【3】查看割接配置文件

通过当天割接人员提供的割接配置脚本文件，发现其配置内容中含有undo vlan 30配置项
并通过配置比对发现，割接前备份文件中，是创建了存储业务VLAN30，但割接后配置备份文件中，该项已被删除
于是登录Spine侧查看是否存有VLAN

回显结果为无，观察到导致存储掉线的问题所在

正常流量路径应该如上所示，走二层与计算节点互通

但由于Spine侧删除了存储业务VLAN，因此导致存储业务中断不通计算节点

【5】创建VLAN

发现问题所在后，立即对两台Spine的VLAN进行创建
并且观察到对应存储交换机聚合口是否放行该VLAN
创建完成后，通知云平台方对虚机和存储做检查，完毕后给出答复，业务已恢复

问题总结

此次事件的根本原因是割接过程中的人为失误
具体表现为割接脚本中包含了删除存储业务VLAN30的操作
而割接人员未能识别到这一变更将带来的影响
在进行网络变更时，必须仔细审查每一步配置变更，尤其是涉及到已有的生产环境配置
并且割接完成后，一定要对其割接前后备份的配置文件，做对比处理，双重检查机制可以有效减少人为失误的风险