了解群集和池仲裁

• 项目

• 2024/02/22

• 10 个参与者

适用于：Azure Stack HCI 版本 22H2 和 21H2；Windows Server 2022、Windows Server

windows-server/failover-clustering/failover-clustering-overview" data-linktype="absolute-path" style="box-sizing: inherit;outline-color: inherit;cursor: pointer;overflow-wrap: break-word;background-color: rgba(0, 0, 0, 0);outline-style: initial;outline-width: 0px">Windows Server 故障转移群集为 Azure Stack HCI 和 Windows Server 群集上运行的工作负载提供高可用性。 如果托管资源的节点已启动，则认为这些资源具有高可用性；但是，群集通常需要运行一半以上的节点，才认为它具有仲裁。

仲裁旨在防止在网络中存在分区且节点子集无法相互通信时可能发生的 拆分脑 方案。 这可能会导致两个节点子集尝试拥有工作负载并写入同一磁盘，这可能会导致许多问题。 但是，故障转移群集的仲裁概念会阻止这种情况，该概念仅强制其中一组节点继续运行，因此其中只有一个组保持联机。

仲裁确定群集在仍保持联机的情况下可以承受的故障次数。 仲裁旨在处理群集节点子集之间通信出现问题的情况，以便多个服务器不会尝试同时托管资源组并同时写入同一磁盘。 通过具有仲裁的概念，群集强制群集服务停止在节点子集之一中，以确保特定资源组只有一个真正的所有者。 已停止的节点可以再次与main组节点通信，并自动重新加入群集并启动其群集服务。

Azure Stack HCI 和 Windows Server 2019 中有两个系统组件具有自身的仲裁机制：

• 群集仲裁：此组件在群集级别运行（即，可以在丢失节点的情况下让群集保持运行状态）

• 池仲裁：该组件在池级别运行（即，可以在丢失节点和驱动器的情况下让池保持运行状态）。 存储池既可在群集方案中使用，也可在非群集方案中使用，正因如此，它们采用了不同的仲裁机制。

群集仲裁概述

下表简要介绍了每种方案的群集仲裁结果：

群集仲裁建议

• 如果你有两个节点，则必须使用见证。

• 如果你有三个或四个节点，则我们强烈建议使用见证。

• 如果你有 5 个或更多节点，则不需要见证，并且不提供额外的复原能力。

• 如果你可以访问 Internet，请使用云见证。

• 如果你所处的 IT 环境包含其他计算机和文件共享，请使用文件共享见证。

群集仲裁的工作原理

当节点发生故障或者某些节点子集与另一个子集失去联系时，幸存的节点需要确认它们可以构成群集的多数，这样才能保持联机。 如果无法确认这一点，则它们将会脱机。

但是“多数”的概念仅在群集中的节点总数是奇数（例如，五节点群集中的三个节点）时才起作用。 那么，如果群集的节点数目是偶数呢（例如四节点群集）？

有两种方式可让群集将投票总数变成奇数：

1. 首先，可以通过添加见证来增加一个投票。 这需要用户进行设置。

2. 或者，可以通过将一个不幸运的节点归零来减去投票（在需要时会自动发生）。

每当幸存节点成功验证它们是否为 多数节点时， 多数 数的定义就会更新为仅是幸存节点之一。 这可以让群集失去一个节点，然后再失去一个节点，依此类推。 这种在连续故障后会自动调整的“投票总数”概念称作“动态仲裁”。

动态见证

动态见证切换见证的投票，以确保投票总数为奇数。 如果投票数为奇数，则见证不会获得投票。 如果得票数偶数，则见证人有一票。 动态见证可显著降低群集因见证服务器故障而关闭的风险。 群集根据群集中可用的投票节点数目，确定是否要使用见证投票。

动态仲裁按下面所述的方式与动态见证配合工作。

动态仲裁行为

• 如果节点数目为偶数且没有见证，则某个节点会将其投票归零。 例如，四个节点中只有三个获得投票，因此投票总数为三个，而获得投票的两个幸存节点被视为多数。

• 如果节点数目为奇数且没有见证，则这些节点都获得投票。

• 如果有偶数数目的节点再加上见证（见证投票），则节点总计为奇数。

• 如果有奇数数目的节点再加上见证，则见证不会获得投票。

使用动态仲裁可将投票动态分配给节点，以避免失去多数投票，并且可允许群集使用一个节点（称为“幸存到最后的节点”）运行。 让我们以一个四节点群集为例。 假设仲裁需要 3 个投票。

在此情况下，如果失去两个节点，群集就关闭。

但是，动态仲裁可防止这种情况发生。 仲裁所需的投票总数现在根据可用节点数来确定。 因此，使用动态仲裁时，即使丢失了三个节点，群集也会保持运行状态。

上述方案适用于未启用存储空间直通的普通群集。 但是，启用存储空间直通时，群集只能支持两个节点发生故障。 池仲裁部分对此做了更详细的解释。

示例

两个节点且没有见证

一个节点的投票已归零，因此多数投票由总数 1 票所确定。 如果非投票节点意外关闭，幸存的节点将获得 1 个投票中的 1 票，而群集将会幸存。 如果非投票节点意外关闭，幸存的节点将获得 1 个投票中的 0 票，而群集将会关闭。 如果投票节点正常关闭，则投票将转移到另一个节点，而群集将会幸存。 正因如此，配置见证至关重要。

• 可以承受一次服务器故障：50% 的几率。

• 可以承受一次服务器故障，以后还可以承受一次：不。

• 可以同时承受两次服务器故障：不。

两个节点加一个见证

这两个节点都可投票，再加上见证投票，因此“多数”由总数 3 票来确定。 如果任一节点关闭，则幸存的节点会获得 3 个投票中的 2 票，而群集将会幸存。

• 可以承受一次服务器故障：是。

• 可以承受一次服务器故障，以后还可以承受一次：不。

• 可以同时承受两次服务器故障：不。

三个节点且没有见证

所有节点都可投票，因此“多数”由总数 3 票来确定。 如果任一节点关闭，则幸存的节点会获得 3 个投票中的 2 票，而群集将会幸存。 群集包含两个节点但没有见证 – 此时，你将进入方案 1。

• 可以承受一次服务器故障：是。

• 可以承受一次服务器故障，以后还可以承受一次：50% 的几率。

• 可以同时承受两次服务器故障：不。

三个节点加一个见证

所有节点都可投票，因此见证最初不会投票。 “多数”由总数 3 票来确定。 发生一次故障后，群集将包含两个节点和一个见证 – 此时将返回到方案 2。 因此，现在两个节点和见证都可投票。

• 可以承受一次服务器故障：是。

• 可以承受一次服务器故障，以后还可以承受一次：是。

• 可以同时承受两次服务器故障：不。

四个节点且没有见证。

一个节点的投票已归零，因此“多数”由总数 3 票所确定。 发生一次故障后，群集将包含三个节点，此时，你将进入方案 3。

• 可以承受一次服务器故障：是。

• 可以承受一次服务器故障，以后还可以承受一次：是。

• 可以同时承受两次服务器故障：50% 的几率。

四个节点加一个见证

所有节点和见证都可投票，因此“多数”由总数 5 票来确定。 发生一次故障后，你将进入方案 4。 同时发生两次故障后，你将直接跳到方案 2。

• 可以承受一次服务器故障：是。

• 可以承受一次服务器故障，以后还可以承受一次：是。

• 可以同时承受两次服务器故障：是。

五个或更多节点

所有节点都可投票，或者只有其中的一个不能投票，无论总数是如何变成奇数的。 存储空间直通无论如何都不能处理超过两个节点，因此此时不需要见证或有用。

• 可以承受一次服务器故障：是。

• 可以承受一次服务器故障，以后还可以承受一次：是。

• 可以同时承受两次服务器故障：是。

了解仲裁的工作原理后，接下来让我们看看仲裁见证的类型。

仲裁见证的类型

故障转移群集支持三种类型的仲裁见证：

• 云见证 - Azure 中可供群集所有节点访问的 Blob 存储。 它在 witness.log 文件中维护群集信息，但不存储群集数据库的副本。

• 文件共享见证 - 在运行 Windows Server 的文件服务器上配置的 SMB 文件共享。 它在 witness.log 文件中维护群集信息，但不存储群集数据库的副本。

• 磁盘见证 - 群集可用存储组中的小型群集磁盘。 此磁盘具有高可用性，可以在节点之间故障转移。 它包含群集数据库的副本。 存储空间直通不支持磁盘见证。

池仲裁概述

前面介绍了在群集级别运行的群集仲裁。 接下来，让我们深入了解在池级别运行的池仲裁（即，可以在丢失节点和驱动器的情况下让池保持运行状态）。 存储池既可在群集方案中使用，也可在非群集方案中使用，正因如此，它们采用了不同的仲裁机制。

下表简要介绍了每种方案的池仲裁结果：

池仲裁的工作原理

当驱动器发生故障，或者当某些驱动器子集与另一个子集失去联系时，托管元数据的剩余驱动器需要验证它们是否构成 池的大部分以 保持联机状态。 如果无法确认这一点，则它们将会脱机。 池是根据其磁盘是否足以用于仲裁 (50% + 1) 而确定脱机或保持联机状态的实体。 只要群集本身为报价，群集数据库就可以为 +1。

但是，池仲裁的工作原理在以下方面不同于群集仲裁：

• 池为每个节点选择一部分驱动器来托管元数据

• 池使用群集数据库断开关联

• 池没有动态仲裁

• 池不实现自己的删除投票版本

示例

采用对称布局的四个节点

16 个驱动器各自获得一个投票，节点 2 也获得一个投票（因为它是池资源所有者）。 “多数”由总数 16 票来确定。 如果节点 3 和 4 关闭，则幸存的子集包含 8 个驱动器和池资源所有者，即，获得了 16 个投票中的 9 票。 因此，池将会幸存。

• 可以承受一次服务器故障：是。

• 可以承受一次服务器故障，以后还可以承受一次：是。

• 可以同时承受两次服务器故障：是。

采用对称布局的四个节点，且发生驱动器故障

16 个驱动器各自获得一个投票，节点 2 也获得一个投票（因为它是池资源所有者）。 “多数”由总数 16 票来确定。 首先，驱动器 7 会关闭。 如果节点 3 和 4 关闭，则幸存的子集包含 7 个驱动器和池资源所有者，即，获得了 16 个投票中的 8 票。 因此，池不会获得多数投票，从而会关闭。

• 可以承受一次服务器故障：是。

• 可以承受一次服务器故障，以后还可以承受一次：不。

• 可以同时承受两次服务器故障：不。

池仲裁建议

• 确保群集中的每个节点采用对称布局（每个节点的驱动器数目相同）

• 启用三向镜像或双奇偶校验，以便可以容忍两个节点故障并使虚拟磁盘保持联机状态。

• 如果两个以上的节点关闭，或者两个节点以及另一个节点上的磁盘关闭，则卷可能无法访问这些节点的数据的所有三个副本，因而造成脱机且不可用的情况。 建议快速恢复服务器或更换磁盘，以确保卷中所有数据的最大复原能力。

后续步骤

• 配置和管理仲裁

• 设置群集见证