通过

了解群集和池仲裁

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

Windows Server 故障转移群集 为 Azure Stack HCI 和 Windows Server 群集上运行的工作负荷提供高可用性。 These resources are considered highly available if the nodes that host resources are up; however, the cluster generally requires more than half the nodes to be running, which is known as having quorum.

Quorum is designed to prevent split-brain scenarios that can happen when there's a partition in the network and subsets of nodes can't communicate with each other. 此情况可能会导致两个节点子集尝试拥有工作负载，并写入到同一磁盘，这可能会造成许多问题。 但是，可以通过故障转移群集的仲裁概念来避免此问题，仲裁会强制要求这些节点组中只能有一个组继续运行，以便只有其中一个组能保持在线。

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

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

  • Cluster Quorum: This operates at the cluster level (i.e. you can lose nodes and have the cluster stay up)
  • Pool Quorum: This operates on the pool level (i.e. you can lose nodes and drives and have the pool stay up). 存储池既可在群集方案中使用，也可在非群集方案中使用，正因如此，它们采用了不同的仲裁机制。

群集仲裁概述

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

Server nodes 可以承受一次服务器节点故障 可以承受一次服务器节点故障，以后还可以承受一次 可以承受同时发生两次服务器节点故障
2 50/50 No No
2 个 + 见证 Yes No No
3 Yes 50/50 No
3 个 + 见证 Yes Yes No
4 Yes Yes 50/50
4 个 + 见证 Yes Yes Yes
5 个或更多 Yes Yes Yes

群集仲裁建议

  • If you have two nodes, a witness is required.
  • If you have three or four nodes, witness is strongly recommended.
  • 如果你有 5 个或更多节点，则不需要见证，并且不提供额外的复原能力。
  • If you have internet access, use a cloud witness.
  • 如果你所处的 IT 环境包含其他计算机和文件共享，请使用文件共享见证。

群集仲裁的工作原理

When nodes fail, or when some subset of nodes loses contact with another subset, surviving nodes need to verify that they constitute the majority of the cluster to remain online. 如果无法确认这一点，则它们将会脱机。

But the concept of majority only works cleanly when the total number of nodes in the cluster is odd (for example, three nodes in a five node cluster). 那么，如果群集的节点数目是偶数呢（例如四节点群集）？

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

  1. First, it can go up one by adding a witness with an extra vote. 这需要用户进行设置。
  2. Or, it can go down one by zeroing one unlucky node's vote (happens automatically as needed).

Whenever surviving nodes successfully verify they're the majority, the definition of majority is updated to be among just the survivors. 这可以让群集失去一个节点，然后再失去一个节点，依此类推。 这种在连续故障后会自动调整的“投票总数”概念称作“动态仲裁”。

Dynamic witness

动态见证切换见证的投票，以确保投票总数为奇数。 如果投票数为奇数，则见证不会获得投票。 如果投票数为偶数，则见证有一票。 动态见证大幅降低了群集因见证失败而关闭的风险。 群集根据群集中可用的投票节点数目，确定是否要使用见证投票。

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

动态仲裁行为

  • If you have an even number of nodes and no witness, one node gets its vote zeroed. 例如，四个节点中只有三个获得投票，因此投票总数为三个，而获得投票的两个幸存节点被视为多数。
  • If you have an odd number of nodes and no witness, they all get votes.
  • If you have an even number of nodes plus witness, the witness votes, so the total is odd.
  • If you have an odd number of nodes plus witness, the witness doesn't vote.

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

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

显示四个群集节点的示意图，每个节点都获得投票。

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

显示四个群集节点的关系图，其中节点一次失败一个，每次失败后所需的投票数都会调整。

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

Examples

两个节点且没有见证

One node's vote is zeroed, so the majority vote is determined out of a total of 1 vote. 如果非投票节点意外关闭，幸存的节点将获得 1 个投票中的 1 票，而群集将会幸存。 如果非投票节点意外关闭，幸存的节点将获得 1 个投票中的 0 票，而群集将会关闭。 如果投票节点正常关闭，则投票将转移到另一个节点，而群集将会幸存。 这就是配置见证至关重要的原因。

在有两个节点但没有见证的情况下解释的仲裁。

  • 可以幸存一个服务器故障： 50% 的几率。
  • Can survive one server failure, then another: No.
  • Can survive two server failures at once: No.

两个节点加一个见证

Both nodes vote, plus the witness votes, so the majority is determined out of a total of 3 votes. 如果任一节点关闭，则幸存的节点会获得 3 个投票中的 2 票，而群集将会幸存。

在有两个节点和一个见证的情况下解释的仲裁。

  • Can survive one server failure: Yes.
  • Can survive one server failure, then another: No.
  • Can survive two server failures at once: No.

三个节点且没有见证

All nodes vote, so the majority is determined out of a total of 3 votes. 如果任一节点关闭，则幸存的节点会获得 3 个投票中的 2 票，而群集将会幸存。 群集包含两个节点但没有见证 – 此时，你将进入方案 1。

在有三个节点但没有见证的情况下解释的仲裁。

  • Can survive one server failure: Yes.
  • 能在一个服务器故障中幸存，并且在另一个服务器故障中也幸存：50%的几率。
  • Can survive two server failures at once: No.

三个节点加一个见证

所有节点都可投票，因此见证最初不会投票。 The majority is determined out of a total of 3 votes. 发生一次故障后，群集将包含两个节点和一个见证 – 此时将返回到方案 2。 因此，现在两个节点和见证都可投票。

在有三个节点和一个见证的情况下解释的仲裁。

  • Can survive one server failure: Yes.
  • Can survive one server failure, then another: Yes.
  • Can survive two server failures at once: No.

四个节点且没有见证。

One node's vote is zeroed, so the majority is determined out of a total of 3 votes. 发生一次故障后，群集将包含三个节点，此时，你将进入方案 3。

在有四个节点但没有见证的情况下解释的仲裁。

  • Can survive one server failure: Yes.
  • Can survive one server failure, then another: Yes.
  • 一次可以幸存两次服务器故障： 50% 的几率。

四个节点加一个见证

All nodes votes and the witness votes, so the majority is determined out of a total of 5 votes. 发生一次故障后，你将进入方案 4。 同时发生两次故障后，你将直接跳到方案 2。

在有四个节点和一个见证的情况下解释的仲裁。

  • Can survive one server failure: Yes.
  • Can survive one server failure, then another: Yes.
  • Can survive two server failures at once: Yes.

五个或更多节点

所有节点都可投票，或者只有其中的一个不能投票，无论总数是如何变成奇数的。 存储空间直通无法处理两个以上节点关闭的情况，因此，此时不需要见证，它也发挥不了作用。

在有五个节点及更多节点的情况下解释的仲裁。

  • Can survive one server failure: Yes.
  • Can survive one server failure, then another: Yes.
  • Can survive two server failures at once: Yes.

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

仲裁见证的类型

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

  • Cloud Witness - Blob storage in Azure accessible by all nodes of the cluster. 它在 witness.log 文件中维护群集信息，但不存储群集数据库的副本。
  • 文件共享见证 - 在运行 Windows Server 的文件服务器上配置的 SMB 文件共享。 它在 witness.log 文件中维护群集信息，但不存储群集数据库的副本。
  • Disk Witness - A small clustered disk that is in the Cluster Available Storage group. 此磁盘具有高可用性，可在节点之间故障转移。 它包含群集数据库的副本。 存储空间直通不支持磁盘见证。

池仲裁概述

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

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

Server nodes 可以承受一次服务器节点故障 可以承受一次服务器节点故障，以后还可以承受一次 可以承受同时发生两次服务器节点故障
2 Yes No No
2 个 + 见证 Yes No No
3 Yes No No
3 个 + 见证 Yes No No
4 Yes No No
4 个 + 见证 Yes Yes Yes
5 个或更多 Yes Yes Yes

池仲裁的工作原理

When drives fail, or when some subset of drives loses contact with another subset, surviving drives hosting metadata need to verify that they constitute the majority of the pool to remain online. 如果无法确认这一点，则它们将会脱机。 池是根据其磁盘是否足以用于仲裁 (50% + 1) 而确定脱机或保持联机状态的实体。 只要群集本身是合法的，群集数据库就可以是 +1。

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

  • 池为每个节点选择一部分驱动器来承载元数据
  • 池使用群集数据库中断关系
  • 池没有动态仲裁
  • 池不会实现自身的删除投票机制

Examples

采用对称布局的四个节点

16 个驱动器各自获得一个投票，节点 2 也获得一个投票（因为它是池资源所有者）。 The majority is determined out of a total of 16 votes. 如果节点 3 和 4 关闭，则幸存的子集包含 8 个驱动器和池资源所有者，即，获得了 16 个投票中的 9 票。 因此，池将会幸存。

池仲裁 1。

  • Can survive one server failure: Yes.
  • Can survive one server failure, then another: Yes.
  • Can survive two server failures at once: Yes.

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

16 个驱动器各自获得一个投票，节点 2 也获得一个投票（因为它是池资源所有者）。 The majority is determined out of a total of 16 votes. 首先，驱动器 7 会关闭。 如果节点 3 和 4 关闭，则幸存的子集包含 7 个驱动器和池资源所有者，即，获得了 16 个投票中的 8 票。 因此，池不会获得多数投票，从而会关闭。

池仲裁 2。

  • Can survive one server failure: Yes.
  • Can survive one server failure, then another: No.
  • Can survive two server failures at once: No.

池仲裁建议

  • 确保群集中的每个节点采用对称布局（每个节点的驱动器数目相同）
  • 启用三向镜像或双重奇偶校验，以便可以承受两个节点故障，并使虚拟磁盘保持在线。
  • 如果两个以上的节点关闭，或者两个节点以及另一个节点上的磁盘关闭，则卷可能无法访问这些节点的数据的所有三个副本，因而造成脱机且不可用的情况。 建议尽快将服务器恢复正常或更换磁盘，确保卷中所有数据拥有最大的复原能力。

Next steps