修复网卡直连vSAN延伸群集故障

■ 石家庄 王春海 马卫华

某2节点万兆网卡直连vSAN延伸群集（网络拓扑如图1所示），在某一天晚上，工作人员发现首选站点节点1服务器（图1中IP地址为192.168.251.2的计算机）的一条64GB内存出现问题导致服务器死机。

故障描述

第二天管理员到单位之后，发现所有的业务虚拟机都无法使用，vCenter Server已经无法连接。

使用vSphere Host Client可以直接登录到192.168.251.2、192.168.251.3及192.168.251.6等每台主机，但虚拟机的信息不正常，已经无法显示虚拟机的名称。另外，vSAN存储容量只有其中一台主机的容量（每台主机配置了1个磁盘组，每个磁盘组有1块400GB的SSD，5块1.2TB的HDD，总容量是10.92TB，现在只有5.46TB）。

故障分析

在关闭这三台服务器，然后打开服务器的电源之后，业务仍然没有恢复。

后来检查发现，将IP地址为192.168.251.2的故障主机关闭，只打开IP地址为192.168.251.3与192.168.251.6的主机（包括见证虚拟机，IP地址为192.168.251.8），此时包括vCenter Server在内的所有虚拟机都自动启动并可以对外提供服务。如果此时再打开192.168.251.2的主机，那么所有的虚拟机都会死机。

为了不影响业务的办理，用户暂时选择关闭了192.168.251.2的主机。此时在vSphere Web Client中显示192.168.251.2无响应，主机已从VC断开连接。

在“监控→vSAN→虚拟对象”选项中，可以看到所有的服务器都提示“可用性降低但未重建”，如图2所示。因为此时首选站点节点主机不在线，系统无法重建冗余数据。

在“配置→vSAN→磁盘管理”选项中，看到192.168.251.2状态为“未响应”，见证主机与192.168.251.3的状态正常。

在关机之后，用户使用备用内存，更换了192.168.251.2这台主机的内存。

故障解决

晚上下班之后，在不影响业务虚拟机使用的情况下，笔者使用下述的方法修复了192.168.251.2的主机，主要方法与步骤如下。

1.首先使用vSphere Web Client登录到vCenter Server，并从清单中移除IP地址为192.168.251.2的主机。

图2 虚拟对象

图3 系统重置

2.由于IP地址为192.168.251.2的主机无法上线，笔者将192.168.251.2的管理端口网线暂时断开，等服务器开机并进入控制台界面之后，按“F2”进入系统配置，在“System Customization”中移动光标到“Reset System Configuration”并回车，在弹出的对话框再次按回车键重置系统配置，如图3所示。在重置后，系统将会重新启动，root密码重置为空（无密码）。

3.再次进入系统后，使用用户名root、密码为空登录系统。进入系统之后，为服务器重新设置管理IP地址，选择管理网卡，仍然使用原来的IP地址192.168.251.2及原来的网卡端口，并设置为原来的密码。然后重新插上服务器管理网卡的网线。

4.在vSphere Web Client中，将192.168.251.2加入清单。参照192.168.251.1的网络设置，为192.168.251.2重新创建虚拟交换机，并为192.168.251.2的主机设置vSAN流量。

5.此时在“群集→配置→磁盘管理”选项中，可以看到192.168.251.2的磁盘组已经添加，但状态不正常。

6.使用SSH登录到节点1的ESXi主机，执行“esxcli vsan network ip add -I vmk0 -T=witness”命令，将192.168.251.2的管理地址设置为见证流量。

（7）在“配置→vSAN→故障域和延伸群集”选项中，重新将IP地址为192.168.251.2的主机添加到“首选”站点。需要注意，两台节点主机中，必须一台主机在“首选”站点，一台在“辅助”站点，其他名称都不行，如图4所示。

8.在“配置→vSAN→磁盘管理”中，可以看到192.168.251.2的磁盘组状态已经正常。

9.在“监控→vSAN→虚拟对象”中，看到大多数的虚拟机状态都恢复正常，只有一台虚拟机数据需要重建。在“监控→vSAN→重新同步组件”中，可以看到正在重新同步的组件，当前只有一个磁盘文件需要同步，如图5所示。

图4 配置故障域

图5 查看重新同步组件

10.在“监控→vSAN→运行状况”中，查看vSAN运行状况，在解决所有问题后，运行状态都是显示“已通过”，此时表示vSAN恢复正常。

总结

这个故障现象比较特殊，因为正常情况下，如果节点主机出现故障，只要修复了节点主机并重新上线，vSAN会重新连接，很少出现vSAN主机都在线而导致虚拟机无法访问的情况。

因为首选站点的主机上线就会导致vSAN群集出错，所以本次修复的关键就是在首选站点不在线的前提下重新配置首选站点。如果重新配置首选站点，可以重新安装ESXi，也可以重置ESXi然后再重新配置，本文就选择了第二种方法。