到目前为止，我已经多次被问及这个问题，我曾想过在中进行解答，但考虑到要解释清楚这个问题需要用到图表和不小的篇幅，就写下了这篇文章。如何处理 Virtual SAN 群集中的主机或磁盘故障？我想我们可以从头开始，我尽力把问题说的简单些。

      几周前我在中说明了一些基本信息，但这里还是要重复一下。在讨论这些故障之前，我想很有必要先说明一下 IO 路径。请看下图中由四个主机组成的群集，其中部署了一个虚拟机。该虚拟机是使用默认策略部署的，也就是说，“条带宽度”为 1，“允许的故障数目”也为 1。按照这种方式部署后，会显示以下结果：

      此时，您会看到：2 个 VMDK 镜像和 1 个见证。顺便说一下,这些 VMDK 完全相同，它们都是精确副本。我们还能从这张简单的图表中观察到什么呢？

• 虚拟机与其存储对象不一定要运行在同一台主机上。

• 见证与其相关组件位于不同的主机上，这样就可以在一个网络分区下创建奇数个主机，以此打破平局。

• VSAN     网络用于通信/IO 等

       除了上述信息之外，我们还需要注意，为保持可用性，VSAN 不会将镜像放在相同的主机上。虚拟机执行写入时，VSAN 会镜像 IO，这些 IO 在全部完成之前不会向虚拟机确认。也就是说，在上述示例中，必须先收到“esxi-02”和“esxi-03”的确认，才会向虚拟机确认写入。这里需要注意的是，尽管会全部写入到闪存/ssd，但会在此期间使用写入缓冲区。在某一时刻，VSAN 会将数据从磁盘中取消暂存，但客户机虚拟机并不会意识到发生了这种情况。

       下面我们来探讨一下发生故障的情况，这也是我撰写这篇文章的初衷。我们来深入研究一下，磁盘发生故障时会发生什么情况。下图显示了“esxi-03”磁盘发生故障的情况。

      在这张图上，您可以看到“esxi-03”磁盘发生了故障。VSAN会根据类型对这一故障做出响应，即，将所有受影响组件（此处为 VMDK）标记为“已降级”，然后立即创建一个新的镜像副本。当然，在创建此镜像 VSAN 之前，需要验证是否有足够的资源来存储这一新副本。请注意，虚拟机不会注意到这一点。不过，也不完全如此。如果需要从磁盘读取，则虚拟机性能会受到影响，因为在这一示例中，发生故障前只有 1 个磁盘，而不是 2个磁盘。

      我发现很有意思的是，如果没有足够的资源可以创建该镜像副本，VSAN 就会一直等待，直至添加了资源为止。添加新磁盘或主机后，恢复过程就会开始。此时，虚拟机仍然可以如前文所述执行 IO，因此，虚拟机仍然能够正常运行。

      现在，我们已经知道了 VSAN 是如何处理磁盘故障的，那么，如果主机发生故障，会如何呢？我们再来看看下面这幅图：

      这种情况与“磁盘故障”稍有不同。发生磁盘故障时，VSAN 会注意到所发生的情况，它会注意到磁盘无法恢复。但发生主机故障时，VSAN 不会注意到所发生的情况。这种故障状态称为“不存在”。一旦 VSAN 注意到组件（在上述示例中为 VMDK）不存在，计时器就会开始 60 分钟计时，如中所述。如果组件在 60 分钟内恢复，VSAN就会同步镜像副本。如果组件无法恢复，则 VSAN 就会创建新的镜像副本。请注意，您可以通过更改高级设置“VSAN.ClomRepairDelay”来减少此超时值。（我不清楚目前是否支持这种更改，也不清楚将来是否提供这种支持。如果要更改此值，请参考手册或向技术支持咨询！）

      是不是很简单？我知道一开始要掌握这些新概念可能会有点难，因此在叙述过程中我可能有点啰嗦，但我认为这是有必要的。下一篇文章我将介绍隔离/分区应用场景的工作原理，并介绍其中的一些 HA 逻辑。最后，我想感谢（VSAN 开发团队）对这篇文章进行了审阅。

-----------------------------------------------------------------------------------------------------------------------------------------------

       现任 VMware R&D 的 SDDC 新兴解决方案团队首席架构师。他主要负责挖掘现有产品和功能的新机会，并通过对新解决方案或产品进行原型开发来为 VMware 探索新的业务商机。他主要致力于软件定义的存储和业务连续性/灾难恢复解决方案，目前正申请一项专利。

原文：

注明：本文内容基于 VMware VSAN beta 版本撰写，请访问 获得有关正式版本的更新信息。