VSAN集群报错：未知对象类型 不可访问 处理

一、问题描述

某次巡检发下，VSAN集群中，某主机报：主机错误；结果在将其至于维护模式过程中，vm迁移错误；查看集群VSAN磁盘状态，发现部分主机报错：未知对象类型 不可访问，，集群中显示有：不可访问的vsan对象（inaccessible vSAN objects） ；如下：

而且，故障主机上跑着有vm，迁移vm时报错：

相关资源：vsan文档

二、问题分析

1）检查不可访问的虚拟对象，发现这些对象并非在14主机的单一磁盘组里：







2）官方解释：这是因为在解析VMDK路径时，ESXi无法很好地处理某些特殊情况，提取了错误的vSAN UUID，导致重复的VM主文件夹触发了不可访问对象的失败警报。对生产没有影响；

3）解决：升级VSAN到6.7P02或更高版本，实际就是将Sphere 6.7.0U3b 升级到跟高版本；当前版本为：6.7.0 P1版本

可在esxi主机上执行：esxcli software vib get -n vsanhealth

更多参考：KB2150753

更多参考：kb2143838

4）清除不可访问的虚拟机交换对象

在使用vSAN存储的过程中，当出现一些“不可访问”的对象。虽然这些“不可访问”的对象对虚拟机的正常运行不会造成影响，但因为有“不可访问”对象存在，在正常的vSAN维护中或vSAN磁盘模式升级中，这些“不可访问”的对象不能迁移到其他主机会导致进入维护模式或升级vSAN磁盘格式失败。如果要解决这个问题，就需要强制删除这些“不可访问”的对象。

注：我的集群虽然有vm，但暂未使用，如果迁移失败，可趁非生产事假，将vm关机迁移后，至于维护模式后再进行。

查看磁盘格式：现场是10.0版本

xsehll ssh到集群的某台主机上，执行：


上图中这些蓝色的字符串文件夹名就是：vsan对象的UUID；我们将利用objtool命令进行强制删除，objtool在/usr/lib/vmware/osfs/bin/下：

但因本次异常的vm对象较多，手动删除不现实，且因其中vm暂未分配用户使用，故决定对进入维护模式的主机上的磁盘组进行重建，删除其上所有数据。

确认磁盘上没有对象之后，执行重建磁盘组：

重建之后，vm对象数据如下：

如果不是处于维护模式的话，磁盘上的vsan vm对象会在其他主机磁盘位置进行重构

重建磁盘组后退出维护模式，再查看vm对象：

依次类推，将集群中所有不可访问对象涉及主机的磁盘组重建，最后验证。

三、附录1：VSAN对象运行不正常时可能具有的几种状态

1）数据移动：vSAN 将在集群中的 ESXi 主机和存储上构建数据，当将VSAN集群中主机置于维护模式时，因为已请求某种形式的维护模式或撤出，或者因为重新平衡活动。vsan对象这时处于“数据移动”状态，这种状态下的对象完全符合其策略且运行正常，但是 vSAN 正积极地重新构建它们。我们无需担心，对象没有面临任何风险。但是，对象处于这种状态时可能会影响性能。

2）正常：对象处于理想状态，完全符合其策略，目前没有被移动，也没有被处理。

3）不可访问（Inaccessible）：对象遇到的永久或临时故障数已超过配置的允许的故障数，当前不可用且不可访问。如果不是临时故障（例如：ESXi 主机重新引导），必须尽快处理根本原因，如 ESXi 主机故障、网络故障或磁盘被移除，以便恢复可用性，因为**使用这些对象的虚拟机在此不可访问状态下无法正常运行**。

4）与可用性无关的不合规性：这是其他任何状态都不适用时的总称。这种状态的对象不符合其策略，但是满足可用性 (NumberOfFailuresToTolerate) 策略。目前没有适用于此状态的记录案例。

5）与可用性无关的重新配置：当我们请求了与可用性无关的存储策略变更，vSAN 在群集中的 ESXi 主机和存储上重新构建数据。换句话说，此类对象完全符合 NumberOfFailuresToTolerate 策略，数据移动是为了满足其他策略变更，如 NumberOfDiskStripesPerObject。您无需担心这种状态的对象，它没有任何风险。

6）可用性降低 - 主动重建：对象遇到故障，但是其配置能够允许此故障。I/O 继续流动，并且对象可访问。vSAN 积极地重新构建新组件以使对象恢复合规状态，进而重新保护对象。

7）可用性降低但不进行重新构建：对象遇到故障，但是 VSAN 能够允许此故障。例如：I/O 正在流动，并且对象可访问。但是，VSAN 并未尝试重新保护对象。这不是因为延迟计时器（可用性降低 - 不重新构建 - 延迟计时器）导致的，而是因为其他原因。这可能是因为群集中资源不足，或者是因为过去资源不足，或者是过去重新保护失败而 VSAN 尚未重新尝试。请参考限制运行状况检查，首先评估是否存在资源可能用尽的情况。必须尽快解决故障或添加资源，以便恢复完全受保护的状态，从而防止后续出现故障。

8）可用性降低但不进行重新构建 - 延迟计时器：对象遇到故障，但是 vSAN 能够允许此故障。I/O 正在流动，并且对象可访问。但是，vSAN 尚未尝试重新保护对象，正在等待 60 分钟（默认）延迟计时器过期后发布重新保护请求。如果确定故障实体无法在延迟期限内重新恢复，则可以选择发布明确请求以跳过延迟计时器并立即启动重新保护。

但是，如果确定故障主机正积极重新引导，或者确定错误的驱动器被错误地拔出或正在重新插入，则最好等待这些任务完成，这是完全重新保护对象的最快速的方法。

9）可用性降低且重新构建已暂停：对象遇到故障或其策略最近更改为具有更高的可用性要求。但是，由于缺少可用资源，对象重建已暂停。

10）可用性降低且策略挂起：对象策略最近已更改，但尚未应用于对象。对象当前可用性小于新策略的预期。请注意，这是一种暂时状态，该状态最终将过渡到“正常”或“可用性降低且策略挂起失败”，具体取决于可以接受新策略还是因为资源限制无法接受。根据群集中正在使用的临时容量，对象的状态将持续数分钟到数小时。用户无需对此状态执行任何操作。

11）可用性降低且策略挂起失败：对象策略已更改，但由于缺少可用资源而无法应用到对象。用户需要向群集中添加更多资源，以便 vSAN 可以自动将新的可用性策略重新应用到对象，使其完全合规。

12）与可用性无关的不合规性且策略挂起：对象策略最近已更改，但尚未应用。该对象仍完全符合新的可用性策略，但不符合与可用性无关的新策略。请注意，这是一种暂时状态，该状态最终将过渡到“正常”或“与可用性无关的不合规性且策略挂起失败”，具体取决于可以接受新策略还是因为资源限制无法接受。根据群集中正在使用的临时容量，对象的状态将持续数分钟到数小时。用户无需对此状态执行任何操作。

13）与可用性无关的不合规性且策略挂起失败：对象策略最近已更改，但由于缺少资源而无法应用到对象。该对象仍完全符合新的可用性策略。用户需要向群集中添加更多资源，以便 vSAN 可以自动将与可用性无关的新策略重新应用到对象，使其完全符合该策略。

14）与可用性无关的不合规性且重新构建挂起：该对象不符合其当前策略，但正在满足可用性 (NumberOfFailuresToTolerate) 策略。但是，由于缺少可用资源，对象重新构建已暂停。

15）未知：

四、附录2：其它回顾

4.1、VSAN对象和组件

4.2、VSAN的对象种类

RVC(ruby vSphere 控制台)：可提供用于管理和故障排除vSAN群集的命令行界面，它可提供集群范围的试图，而不是esxcli提供的以主机为中心的试图，与vcsa捆绑不需要单独安装。

VSAN对象的组件的分布主要采用两种技术：条带化（RAID 0）和镜像（RAID 1），创建多少组件副本基于对象策略定义决定；一个过多个对象不能满足分配的存储策略要求时，虚拟机被视为不合规。对于组件状态，如果检查到永久故障，并确定无法恢复到原始工作状态，则该组件将处于已降级状态；对于vSAN检查到临时组件故障，且其中组件及其宿主数据可以恢复且vSAN能够恢复其原始状态，则该组件处于不存在状态，重启主机或从vSAN主机拔出设备时可能出现，等待60分钟后，vSAN将重新构建处于不存在的状态组件。对于对象，当至少满足给RAID1镜像可用或者最低所需数据段数可用时，则认为对象处于正常状态。如果没有可用的完整镜像，或者RAID5或RAID6对象不满足数据段最低数量要求，则该对象将被视为不正常。如果对象的投票数少于50%，则该对象不正常，如果群集中出现多个故障，则也可能导致对象不正常，并影响虚拟机的可用性。