幽默 VMWare:vSAN 重启后所有VMs均不可访问
Sat May 18 2024
# 幽默 VMWare:vSAN 重启后所有VMs均不可访问
在 2024 年 5 月,西安发布高温预警的第一天,我们的机房,空调坏了,坏了!!!吹的是 36.4 摄氏度的服务器尾气,直接给我们的交换机吹到风扇满转,给我们的 R630 吹到过热、因内存错误而下线。为了保住交换机和 R630(这是我们活动室上网的基础设施),我决定关闭一部分服务器,以减少发热,在等待空调维修工的期间内,不要再次出现过热的问题。于是,我做出了今天最后悔的一个决定:我关闭了一个 vSAN 集群。先不说关这个集群有多费劲,也不提关闭集群是否有显著的控制温度的效果,光是重启集群,就让我修到了晚上 12 点半。
## 症状:vSAN重启后所有VMs均不可访问
如题,我们的集群出现了所有虚拟机不可访问的问题,所有虚拟机都被标记为 inaccessible,并且在 vSphere 的 datastores 里面查看 vsan 的文件,里面什么文件都没有。考虑到关机走的是正常流程(关闭所有的虚拟机 -> 将所有集群节点设置为维护模式 -> 通过 IPMI 逐个给节点的 Host OS 发送关机指令),所以我们暂且排除了是硬件故障(CPU、内存等)导致的,基础网络设施(交换机等)也并未重启(vSAN 和 vMotion 直接走交换机进行数据传输,与网关无关),所以我首先考虑的是是否是硬盘损坏,但是通过 SSH 连上 ESXi 节点后,发现所有硬盘都识别到了,并且信息都显示正确,如果是过热导致硬盘损坏的话,现在应该是不可读状态,所以硬盘的问题基本排除。
此外,还通过 VMWare Skyline Health 发现,此时 vSAN 上的所有 Virtual Objects 都是 Missing 的状态,通过 SSH 查看文件系统挂载,也确实挂载上了 vSAN datastore,用esxcli
进行检查也均未发现问题。重启主机后,问题也未解决。
此时基本怀疑是 vSAN 在重启的过程中,节点的某些状态与 vCenter 不一致导致的问题。
## 解决方案
通过 SSH 连接上 vSAN 集群内所有的主机,并执行:
## 原因分析
从 vSAN 7.0 Update 3 开始,用户现在可以在 vSphere Client 的 GUI 里正常关闭和重新启动整个 vSAN 群集,而不必使用 SSH。虽然仍然可以手动关闭和重新启动 vSAN 群集,但很显然,如果有更简单的方法可以执行此操作,没有人会舍近求远。
其中 vSAN 的 shutdown 脚本会将节点的 DOMPauseAllCCPs 属性值设置为 1(用于暂停所有函数),将 IgnoreClusterMemberListUpdates 属性值设置为 1。当重新启动节点时,这些属性理论上将设置回 0。但很显然,在我们的集群上,DOMPauseAllCCPs 和 IgnoreClusterMemberListUpdates 两个属性在重启后,仍然是 1,使节点的电源状态处于不一致。因此在所有受影响的主机上手动将 DOMPauseAllCCPs 和 IgnoreClusterMemberListUpdates 置为 0 后,即可访问 VM,问题解决。
可通过以下脚本验证问题:
## 插曲
其中一个节点在重启时出现故障,导致 root 密码失效(非常神奇,想不明白.jpg),无法进入 ESXi 的设置界面。
好在 vCenter 还能连上这个节点,用 vCenter 的 Host Profile 功能重置 root 密码
- 先从该节点提取 Host Profile (可以直接右键节点,找到 Host Profiles > Extract Host Profile)
- 进入 Policies and Profiles视图(vSphere Client 最左上角那个菜单,VMWare 的文档里甚至这个名称写的不对,可能是其他版本的名称)
- 找到 Host Profiles
- 右键刚刚创建的配置文件,选择 Edit Host Profile
- 搜索 root 找到 root 密码设置,设置为 Fixed password configuration,并填入你的密码
- 保存后,找到节点,分配刚刚创建的配置文件(可以直接右键节点,找到 Host Profiles > Attach Host Profile)
- 应用配置文件(可以直接右键节点,找到 Host Profiles > Remediate)