恢复误删除的vSAN集群

事件发生

笔者单位新部署了PSC（Platform S e r v i c e s Controller）架构 的vCenter，原计划将一组由6台主机构成的vSAN集群，变更到新vCenter，按照过去的经验，只需要确保取消了vDS和存储策略，或先创建好一致的配置，就可以直接在新vCenter下，建 好 vSAN集群，逐个添加主机即可顺利完成。然而，墨菲定律总是如影随形，我竟然还没在新vCenter下创建集群，也没有添加主机，就把旧vCenter上的vSAN集群删除了，这一切的发生是那么的鬼使神差，一点犹豫都没有的 点下了确定。

看到集群就这么从vCenter中消失了，脑子忽然惊醒过来，然而已不可挽回，同时，立即感受到，集群中的虚机失去了响应，表现为不可操作，他们的网络并没断，虚机状态也是开启，但所有服务都不可用，有如石化了一般。

紧急处置

遇到突发情况，大脑的运转也提了速，立马浮现出两个处置办法。第一是在原vCenter上创建同名集群，逐个添加主机进行恢复；第二是在新vCenter上创建同名集群，逐个添加主机进行恢复。两者相比较，后者可以一步到位实现VC变更计划，但不能确定其他的潜在影响。权衡之下，还是在原VC上进行恢复，待稳定后再考虑变更。

立即在原VC创建同名集群，开启vSAN功能，然后直接在集群中添加主机，待6台主机全部添加完毕，观察虚机都保持之前的电源状态，但虚机依然不可操作，检查集群和主机的告警信息，发现6台主机，都共同显示一条警告：主机无法与已启用vSAN的群集中的所有其他节点进行通信。

看到这条告警，情绪上还是保持乐观和淡定的，因为这个告警信息在以前的运维中也遇到过，但心里也隐约有不详的预感。

根据曾经的处理步骤，登录每个主机的命令行，执 行/etc/init.d/vpxa restart对主机的通信管理服务进行重启，该服务是vCenter和ESXi之间通信管理。执行完毕后耐心等待5分钟以上，所有提示都没有消失。试着重启一个状态为已开启的虚机，虚机立马变成inaccessible不可用的状态，和前面虚机不可操作的状态相印证，典型的存储不可用导致的虚机异常。这种情况下，只能登录命令行去查看进一步状态。

在每个主机执行命令esxcli vsan cluster get查看集群状态信息，每个主机都有相同的Sub-Cluster UUID，说明所有主机都在同一个集群里，但是在Sub-Cluster Member Count信息中，却是仅有2个主机显示为2，其余主机均显示为1，说明6个主机看起来在一个集群里，实际内在却是分裂的。对于这种分裂，准确找到原因再处置更为妥当，否则容易带来存储数据的丢失。

图1 检查vSAN网络状态

寻求帮助

联系到原厂工程师寻求帮助，原厂工程师对删除集群的步骤和恢复集群的操作与我反复确认了三遍，我能猜到，当他听到我自己主动删除集群时，内心一定是波澜的。接下来确认ESXi的版本号是7388607，该版本可以称作ESXi6.5u1版，也可以称作vSAN6.6版。

首先排查的是vSAN网络，用vmkping逐个Ping每个vSAN的vmk地址，这些IP都是通的。接着将一个主机置为维护模式，并设置不撤出数据，不要将关闭电源和挂起的虚拟机移动到集群中的其他主机上，然后重启该主机，退出维护模式，观察许久，该主机仍保持相同的警告。

通过对原厂知识库的搜索，工程师发现，vSAN6.6在变更vCenter时，有一个IgnoreClusterMember ListUpdates属性，该属性用于将vSAN集群从一个VC移至另一个VC时使用，主动关闭集群中主机对成员列表的更新，更符合操作时不可能同时对所有集群节点同时加入集群的客观实际，从而避免逐一添加主机到集群时更新节点成员因时间差异导致的影响。当前的情况与知识库文档的描述并不完全一致，文档要求的是迁移之前设置每个主机节点，而此时已类似于迁移后，如果全部设置一次，但不改变当前VC，让节点主机都重新刷新一次更新状态，可能会有积极的影响。

使用命令esxcfg-advcfg-s 1 /VSAN/IgnoreCluster MemberListUpdates在 所有主机命令行执行，忽略成员更新，重新引导启动VC服务器，等待一段时间后，再到每个主机节点执行esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMember ListUpdates命令，意为不忽略集群成员更新，让集群重新识别成员列表，不过遗憾的是并没有什么作用。

工程师通过命令esxcli vsan cluster unicastagent list继续检查vSAN网络，有了新的发现，如图1所示。

第一个异常表现为每个主机显示的列表数量不一，正常情况下应该每个NodeUuid显示两行，一行 IPv4，一行IPv6，每个主机显示其余5个主机共10行列表，此时却多寡不一，每个主机显示的数量都不同；第二个异常表现为Iface名称都未显示，正常情况应该显示vSAN网络的vmk名称。有了这一线索，恢复的希望越来越强烈。

通过命令，复制每个主机查到的双栈IP信息，做成一张对照表，如图2所示。

根据这张表，编辑制作成脚本，如图3所示。

准备好上述脚本后，将要进行的操作是用命令esxcli vsan cluster unicastagent clear清除现有vSAN网络配置，用命令esxcfg-vmknic-l查看清除后结果，相应配置均已消失，再用上述脚本批量添加，注意添加时不添加本机自己的IP。添加完毕，用命令esxcli vsan cluster unicastagent list查看，前面的异常点已不存在，如图4所示。

图2 vSAN单播列表

图3 命令行添加vSAN单播网络配置脚本

图4 vSAN集群网络状态

如此重复对6个主机都进行配置，完毕后用命令esxcli vsan cluster get查看集群状态，Sub-Cluster Member Count终于都显示6，顿时感觉悬在头上的巨石落地。接着去VC上查看虚机状态，inaccessible的状态都已消失，主机无法与已启用vSAN的群集中的所有其他节点进行通信的警告也消失了。重新启动虚机，都恢复了可操作的正常状态。

回顾分析

回顾整个过程，在尚未迁移新vCenter时主动删除vSAN集群，同时又很快创建到集群中，vSAN内部其实发生了很多措不及防的变化，有些变化甚至没有执行完就被新变化影响了，从而出现了vSAN网络物理连接上虽然通，但逻辑上已不完整的情况。表面上，这些主机节点好像相互隔离了，看起来像网络分区，实际情况却是vSAN的interface name接口都没有关联到vmk，vSAN主机相互之间无法进行存储上的通信，继而导致存储不可用，存储之上的虚机是瞬间失去了存储I/O，既不可读也不可写，并不属于存储连接丢失，从而出现虚机“石化”的情况，这种情况和FC存储连接丢失后，还可继续只读的情况并不相同。当vSAN通信网络配置恢复正常后，虚拟机状态从不可用恢复正常，之前保持已开机状态虚机并不能自动恢复，需要人工逐一重置。

正确的迁移方法

待上述恢复的环境稳定1至2天，观察虚机运行和业务都正常和稳定，还得继续完成变更VC的动作。首先在新的VC上创建好vSAN集群，名称最好和之前的一样，并对集群开启vSAN功能，接着SSH登录每个主机节点，执行命令esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMember ListUpdates将每个主机忽略成员更新，然后在新VC的集群中逐一添加主机。

全部添加完毕后，逐个查看主机摘要，在第一个添加的主机上，竟然还有警告信息：“已找到另一台参与vSAN服务的主机，但这台主机不是该主机的vCenter集群的成员”。立即回到旧VC查看，发现有4个节点处于not responding状态，还有2个节点活着，并且活着的2个主机节点承载的虚机，也没有出现在新VC中。整个人感觉顿时又不好了。

图5 更新ESXi配置确认对话框

正在考虑如何搜索和处理眼下的状况，旧VC自动进行了刷新，6个节点已经全都显示not responding状态了，再去新VC中查看，之前的警告也随之消失，6个主机节点除了开启SSH的警告外，都表现正常。原来只是一场虚惊，没有给vSAN足够的时间完成后台同步，待集群内部协商同步好了所有状态，也就恢复了正常。最后，回到每个主机的SSH会话，执行命令esxcfgadvcfg -s 0 /VSAN/IgnoreClusterMember ListUpdate不再忽略成员更新。

继续等待一段时间，vSAN自动进行了运行状况检查，显示“vCenter状态具有权威性”测试失败，给的建议是：“如果已替换vCenter Server/已从备份恢复 vCenter Server，并且vCenter Server中的当前主机列表正确，那么请执行‘更新ESXi配置‘操作”。看来这也是新版vSAN的特性，对于迁移变更VC有了更全面的保障。

根据提示点击“更新ESXi配置”按钮，弹出确认对话框，如图5所示。

确认后，后台自动更新vSAN配置，随后该警告消失。关闭每个主机SSH服务，主机和集群所有警告信息都消失，迁移动作顺利完成。

经验总结

相信很多读者能够通过此文，解答了直接删除vSAN集群后果会发生什么这个好奇心理。本人也久久无法忘记原厂工程师听到我说自己就这么把生产环境的vSAN集群删除后，那种不可思议的惊诧语气。对于这一次误删除事故，某种程度上似乎是是祸躲不过的，一方面是只有亲自错过，才会印象更深刻；另一方面也正是因为这些“失误”，才千锤百炼了技术上的淡定。

在vSAN 6.6的变化上，vSAN网络不再使用多播multicast，而是开始使用单播unicast来简化vSAN群集的网络要求，升级或安装vSAN 6.6并完成通过磁盘升级之后，群集会自动切换到单播，这些细节上的变化，也使得vSAN管理和运行中越来越可控。