培训
认证
Microsoft Certified: Azure Database Administrator Associate - Certifications
使用 Microsoft PaaS 关系数据库产品/服务,管理云、本地和混合关系数据库的 SQL Server 数据库基础结构。
适用于:Azure Stack HCI 版本 22H2 和 21H2;Windows Server 2022、Windows Server
重要
Azure Stack HCI 现在是 Azure 本地的一部分。 产品文档重命名正在进行中。 但是,旧版 Azure Stack HCI(例如 22H2)将继续引用 Azure Stack HCI,不会反映名称更改。 了解详细信息。
Windows Server 故障转移群集为 Azure Stack HCI 和 Windows Server 群集上运行的工作负载提供高可用性。 如果托管资源的节点已启动,则认为这些资源具有高可用性;但是,群集通常需要运行一半以上的节点,才认为它具有仲裁。
仲裁旨在防止“裂脑”的情况。当网络中存在分区,并且节点的子集无法相互通信时,就可能会发生这种情况。 此情况可能会导致两个节点子集尝试拥有工作负载,并写入到同一磁盘,这可能会造成许多问题。 但是,可以通过故障转移群集的仲裁概念来避免此问题,仲裁会强制要求这些节点组中只能有一个组继续运行,以便只有其中一个组能保持在线。
仲裁确定群集在仍保持联机的情况下可以承受的故障次数。 仲裁旨在处理群集节点子集之间发生通信问题时出现的情况,避免多个服务器同时尝试托管某个资源组并写入到同一磁盘。 有了这个仲裁概念,群集会强制群集服务在某个节点子集中停止,以确保特定的资源组只有一个真正的所有者。 已经停止的节点可以再次与主要节点组通信,它们将自动重新加入群集,并启动其群集服务。
Azure Stack HCI 和 Windows Server 2019 中有两个系统组件具有自身的仲裁机制:
下表简要介绍了每种方案的群集仲裁结果:
服务器节点 | 可以承受一次服务器节点故障 | 可以承受一次服务器节点故障,以后还可以承受一次 | 可以承受同时发生两次服务器节点故障 |
---|---|---|---|
2 | 50/50 | 否 | 否 |
2 个 + 见证 | 是 | 否 | 否 |
3 | 是 | 50/50 | 否 |
3 个 + 见证 | 是 | 是 | 否 |
4 | 是 | 是 | 50/50 |
4 个 + 见证 | 是 | 是 | 是 |
5 个或更多 | 是 | 是 | 是 |
当节点发生故障或者某些节点子集与另一个子集失去联系时,幸存的节点需要确认它们可以构成群集的多数,这样才能保持联机。 如果无法确认这一点,则它们将会脱机。
但是“多数”的概念仅在群集中的节点总数是奇数(例如,五节点群集中的三个节点)时才起作用。 那么,如果群集的节点数目是偶数呢(例如四节点群集)?
有两种方式可让群集将投票总数变成奇数:
当幸存的节点成功确认其属于多数时,“多数”的定义将在这些幸存的节点之间更新。 这可以让群集失去一个节点,然后再失去一个节点,依此类推。 这种在连续故障后会自动调整的“投票总数”概念称作“动态仲裁”。
动态见证切换见证的投票,以确保投票总数为奇数。 如果投票数为奇数,则见证不会获得投票。 如果投票数为偶数,则见证有一票。 动态见证大幅降低了群集因见证失败而关闭的风险。 群集根据群集中可用的投票节点数目,确定是否要使用见证投票。
动态仲裁按下面所述的方式与动态见证配合工作。
使用动态仲裁可将投票动态分配给节点,以避免失去多数投票,并且可允许群集使用一个节点(称为“幸存到最后的节点”)运行。 让我们以一个四节点群集为例。 假设仲裁需要 3 个投票。
在此情况下,如果失去两个节点,群集就关闭。
但是,动态仲裁可防止这种情况发生。 仲裁所需的投票总数现在根据可用节点数来确定。 因此,使用动态仲裁时,即使失去三个节点,群集也仍能保持运行。
上述方案适用于未启用存储空间直通的普通群集。 但是,启用存储空间直通时,群集只能支持两个节点发生故障。 池仲裁部分对此做了更详细的解释。
一个节点的投票已归零,因此多数投票由总数 1 票所确定。 如果非投票节点意外关闭,幸存的节点将获得 1 个投票中的 1 票,而群集将会幸存。 如果非投票节点意外关闭,幸存的节点将获得 1 个投票中的 0 票,而群集将会关闭。 如果投票节点正常关闭,则投票将转移到另一个节点,而群集将会幸存。 正因如此,配置见证至关重要。
这两个节点都可投票,再加上见证投票,因此“多数”由总数 3 票来确定。 如果任一节点关闭,则幸存的节点会获得 3 个投票中的 2 票,而群集将会幸存。
所有节点都可投票,因此“多数”由总数 3 票来确定。 如果任一节点关闭,则幸存的节点会获得 3 个投票中的 2 票,而群集将会幸存。 群集包含两个节点但没有见证 – 此时,你将进入方案 1。
所有节点都可投票,因此见证最初不会投票。 “多数”由总数 3 票来确定。 发生一次故障后,群集将包含两个节点和一个见证 – 此时将返回到方案 2。 因此,现在两个节点和见证都可投票。
一个节点的投票已归零,因此“多数”由总数 3 票所确定。 发生一次故障后,群集将包含三个节点,此时,你将进入方案 3。
所有节点和见证都可投票,因此“多数”由总数 5 票来确定。 发生一次故障后,你将进入方案 4。 同时发生两次故障后,你将直接跳到方案 2。
所有节点都可投票,或者只有其中的一个不能投票,无论总数是如何变成奇数的。 存储空间直通无法处理两个以上节点关闭的情况,因此,此时不需要见证,它也发挥不了作用。
了解仲裁的工作原理后,接下来让我们看看仲裁见证的类型。
故障转移群集支持三种类型的仲裁见证:
前面介绍了在群集级别运行的群集仲裁。 接下来,让我们深入了解在池级别运行的池仲裁(即,可以在丢失节点和驱动器的情况下让池保持运行状态)。 存储池既可在群集方案中使用,也可在非群集方案中使用,正因如此,它们采用了不同的仲裁机制。
下表简要介绍了每种方案的池仲裁结果:
服务器节点 | 可以承受一次服务器节点故障 | 可以承受一次服务器节点故障,以后还可以承受一次 | 可以承受同时发生两次服务器节点故障 |
---|---|---|---|
2 | 是 | 否 | 否 |
2 个 + 见证 | 是 | 否 | 否 |
3 | 是 | 否 | 否 |
3 个 + 见证 | 是 | 否 | 否 |
4 | 是 | 否 | 否 |
4 个 + 见证 | 是 | 是 | 是 |
5 个或更多 | 是 | 是 | 是 |
当驱动器发生故障,或者某些驱动器子集与另一个子集失去联系时,幸存的驱动器承载元数据需要确认它们可以构成池的多数,以保持在线。 如果无法确认这一点,则它们将会脱机。 池是根据其磁盘是否足以用于仲裁 (50% + 1) 而确定脱机或保持联机状态的实体。 只要群集本身是合法的,群集数据库就可以是 +1。
但是,池仲裁的工作原理在以下方面不同于群集仲裁:
16 个驱动器各自获得一个投票,节点 2 也获得一个投票(因为它是池资源所有者)。 “多数”由总数 16 票来确定。 如果节点 3 和 4 关闭,则幸存的子集包含 8 个驱动器和池资源所有者,即,获得了 16 个投票中的 9 票。 因此,池将会幸存。
16 个驱动器各自获得一个投票,节点 2 也获得一个投票(因为它是池资源所有者)。 “多数”由总数 16 票来确定。 首先,驱动器 7 会关闭。 如果节点 3 和 4 关闭,则幸存的子集包含 7 个驱动器和池资源所有者,即,获得了 16 个投票中的 8 票。 因此,池不会获得多数投票,从而会关闭。
培训
认证
Microsoft Certified: Azure Database Administrator Associate - Certifications
使用 Microsoft PaaS 关系数据库产品/服务,管理云、本地和混合关系数据库的 SQL Server 数据库基础结构。