第十章 镜像架构和规划 - 仲裁器中断的影响

仲裁器中断的影响

仲裁器的中断对镜像的可用性没有直接影响。但是，如果在恢复仲裁器之前发生了自动故障转移以响应主中断场景中的主中断场景5或6，则备份无法自动接管。

备份中断的影响

在主应用程序可以恢复处理之前，某些应用程序可能会经历短暂的暂停（大约是 QoS 超时）。如果没有配置仲裁器，或者如果仲裁器在备份中断之前变得不可用，则经历的暂停可能会稍微长一些（大约是QoS 超时的三倍）。如果在恢复备份之前发生主要中断，则结果是整个镜像中断。

主要和仲裁联合中断的影响

这种情况的后果在响应主要中断情况的自动故障转移中进行了介绍。简而言之，如果备份可以联系主的 ISCAgent，它就会接管；如果不是，结果是整个镜像中断，手动干预强制备份成为主要可能是一个合适的选择。

联合备份和仲裁中断的影响

如果备份和仲裁器同时（或几乎同时）变得不可用，则主节点将无限期地保持在故障状态，因为它假定它是孤立的，因此备份节点可能已成为主要节点。结果是整个镜像中断。当备份再次可用时，它会联系主服务器，然后主服务器恢复作为主服务器运行。或者，可以通过手动干预强制恢复主节点。如果备份和仲裁程序依次失败，则在备份中断的影响中描述的短暂暂停之后，主要继续作为主要运行，因为它知道备份不可能成为主要。

主要和备份联合中断的影响

这种组合的结果总是镜像完全中断。

定位仲裁器以优化镜像可用性

故障转移成员和仲裁器一起提供镜像高可用性解决方案（仲裁器扮演最不重要的角色）。仲裁器不是仲裁机制，而是支持每个故障转移成员在与其他故障转移成员失去联系时通过提供上下文来仲裁自动故障转移；只要两个故障转移成员在任何类型的主要中断之前立即与仲裁器联系并且备份保持与仲裁器联系，就可以发生自动故障转移。虽然在某些情况下仲裁器的故障确实消除了自动故障转移的可能性，但它不会阻止镜像在配置替换时运行，或者在许多主要中断情况下提供自动故障转移，例如自动故障转移中的场景 1 到 4在响应主要中断场景。

由于这些原因，仲裁器不需要比任何一个故障转移成员都独立地具有更高的可用性，而只是定位和配置以使仲裁器和单个故障转移成员意外同时中断的风险最小化。 （如果两个故障转移成员都失败，则镜像失败并且仲裁器的状态无关紧要，因此不考虑所有三个同时中断的风险。）

基于此要求，一般来说，仲裁器与故障转移成员的分离程度与它们彼此分离的程度相同。具体来说，

• 如果故障转移成员位于一个数据中心，仲裁器可以放在同一个数据中心。在该数据中心内，仲裁器与故障转移成员之间的物理隔离应该与它们彼此之间的物理隔离相同；例如，如果您将故障转移成员放置在不同的服务器机架中以避免一个机架中的电源或网络问题影响两个成员，应该将仲裁器与这两个机架分开放置。

  如果数据中心使用内部网络在镜像内进行通信，则仲裁器应放置在网络的公共端，以便内部网络故障不会将故障转移成员与仲裁器隔离开来。

• 如果故障转移成员位于不同的数据中心，则仲裁器应放置在第三个位置。这可能是另一个数据中心、另一方托管的位置、公共或私有云服务，甚至是系统管理员的家（假设她有可靠的网络）。将仲裁器放置在代表用户社区的位置支持对网络中断的最佳镜像响应。

单个系统可以配置为多个镜像的仲裁器，前提是它的位置适合每个；在创建或编辑它将作为仲裁服务器的每个镜像时，只需指定其主机和端口号，如创建镜像中所述。

仲裁器不需要托管在新部署的或专用系统上；事实上，现有的具有公认可靠性的主机可能更可取。报告异步镜像成员（请参阅报告异步）可以充当合适的主机。但是，应避免在 DR 异步上托管，因为在维护或故障情况下提升 DR 异步（请参阅将 DR 异步成员提升为故障转移成员）可能导致仲裁器托管在故障转移镜像成员上，一个不正确的配置。

注意：如安装仲裁器中所述，任何运行 ISCAgent 的系统都可以配置为仲裁器，包括托管一个或多个 IRIS 实例的系统。但是，托管镜像的一个或多个故障转移或 DR 异步成员的系统不应配置为该镜像的仲裁器。