某2节点万兆网卡直连vSAN延伸群集故障修复


某2节点万兆网卡直连vSAN延伸群集(网络拓扑如图1所示),在某一天晚上,首选站点节点1服务器(图1中IP地址为192.168.251.2的计算机)的一条64GB内存出问题致使服务器死机。次日管理员到单位以后,发现全部的业务虚拟机都没法使用。此时vCenter Server已经没法链接。使用vSphere Host Client能够直接登陆到192.168.251.二、192.168.251.三、192.168.251.6等每台主机,但虚拟机的信息不正常,已经没法显示虚拟机的名称,另外vSAN存储容量只有其中一台主机的容量(每台主机配置了1个磁盘组,每一个磁盘组有1块400GB的SSD、5块1.2TB的HDD,总容量是10.92T,如今只有5.46TB)。服务器

image

图1 拓扑图网络

在关闭这三台服务器,而后打开服务器的电源以后,业务仍然没有恢复。后来检查发现,将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断开链接,如图2所示。ssh

image

图2 IP地址为192.168.251.2的主机已断开链接ide

在“监控→vSAN→虚拟对象”中,能够看到全部的服务器都提示“可用性下降但未重建”,如图3所示。由于此时首选站点节点主机不在线,系统没法重建冗余数据。3d

image

图3 虚拟对象对象

在“配置→vSAN→磁盘管理”中,看到192.168.251.2状态为“未响应”,见证主机与192.168.251.3的状态正常,如图4所示。blog

image

图4 磁盘管理ip

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

晚上下班以后,在不影响业务虚拟机使用的状况下,使用下述的方法修复了192.168.251.2的主机。主要方法与步骤以下。get

(1)使用vSphere Web Client登陆到vCenter Server,从清单中移除IP地址为192.168.251.2的主机。移除以后如图5所示。

image

图5 移除节点1的主机

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

image

图6 系统重置

(3)再次进入系统后,使用用户名root、密码为空登陆。进入系统以后,为服务器从新设置管理IP地址、选择管理网卡,仍然使用原来的IP地址192.168.251.二、使用原来的网卡端口,并设置为原来的密码。而后从新插上服务器管理网卡的网线。

(4)在vSphere Web Client中,将192.168.251.2加入清单。参照192.168.251.1的网络设置,为192.168.251.2从新建立虚拟交换机,并为192.168.251.2的主机设置vSAN流量。如图7所示。

image

图7 从新配置vSAN流量

(5)此时在“群集→配置→磁盘管理”中,能够看到192.168.251.2的磁盘组已经添加,但状态不正常。如图8所示。

image

图8 从新加入的节点主机磁盘状态不正常

(6)使用ssh登陆到节点1的ESXi主机,执行esxcli vsan network ip add -I vmk0 -T=witness命令将192.168.251.2的管理地址设置为见证流量。如图9所示。

image

图9 设置见证流量

(7)在“配置→vSAN→故障域和延伸群集”中,从新将IP地址为192.168.251.2的主机添加到“首选”站点,注意,两台节点主机,必须一台主机在“首选”站点,一台在“辅助”站点,其余名称都不行。如图10所示。

image

图10 配置故障域

(8)在“配置→vSAN→磁盘管理”中,能够看到192.168.251.2的磁盘组状态已经正常,如图11所示。

image

图11 磁盘组状态正常

(9)在“监控→vSAN→虚拟对象”中,看到大多数的虚拟机状态都恢复正常,只有一台虚拟机数据须要重建,如图12所示。

image

图12 查看虚拟对象

(10)在“监控→vSAN→从新同步组件”中,能够看到正在从新同步的组件,当前只有一个磁盘文件须要同步,如图13所示。

image

图13 查看从新同步组件

(11)在导航器中选中每台主机,在“监控→问题”中,检查确认当前主机的问题。

(12)在“监控→vSAN→运行情况”中,查看vSAN运行情况,在解决全部问题后,运行状态都是显示“已经过”,如图14所示。此时表示vSAN恢复正常。

image

图14 运行情况正常

【总结】这个故障现象比较特殊。正常状况下,若是节点主机出现故障,只要修复了节点主机并从新上线,vSAN会从新链接。不多出现vSAN主机都在线而致使虚拟机没法访问的状况。由于首选站点的主机上线就会致使vSAN群集出错,因此本次修复的关键就是在首选站点不在线的前提下从新配置首选站点。若是从新配置首选站点,能够从新安装ESXi,也能够重置ESXi而后再从新配置。本节就选择了第二种方法。