HQY 一个和谐有爱的空间

了解 Azure Stack HCI 和 Windows Server 群集上的群集和池仲裁 - Azure Stack HCI | Microsoft Learn| Microsoft Learn| Microsoft Learn

适用于：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; text-decoration-line: none; background-color: rgba(0, 0, 0, 0); outline-style: initial; outline-width: 0px;">Windows Server 故障转移群集为 Azure Stack HCI 和 Windows Server 群集上运行的工作负载提供高可用性。 如果托管资源的节点已启动，则认为这些资源具有高可用性；但是，群集通常需要运行一半以上的节点，才认为它具有仲裁。

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

仲裁确定群集在仍保持联机的情况下可以承受的故障次数。 仲裁旨在处理群集节点子集之间通信出现问题时的方案，以便多个服务器不会同时托管资源组并同时写入同一磁盘。 通过具有此仲裁概念，群集强制群集服务在节点的子集之一中停止，以确保特定资源组只有一个真正的所有者。 已停止的节点可以再次与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 票。 因此，池不会获得多数投票，从而会关闭。

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

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

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

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

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

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

• 配置和管理仲裁

• 设置群集见证

推荐本站淘宝优惠价购买喜欢的宝贝:

本文链接：https://hqyman.cn/post/5158.html 非本站原创文章欢迎转载，原创文章需保留本站地址！

休息一下~~