了解仲裁对系统行为的影响
但如果发生更多灾难性故障（例如，所有可能的网络路径均中断），everRun系统将尝试确定整个系统的整体状态。然后，系统会采取必要的行动来保护客人 VM 的完整性。
以下示例说明了在灾难性故障期间系统的过程。
示例 1：无仲裁服务器的系统遇到脑裂情况
在这个 SplitSite示例中，everRun 系统包含 node0 和 node1，但不包含仲裁服务器。操作正常；当前没有检测到任何故障。这两个节点通过 A-Link 连接传达它们的状态和可用性，就像它们在正常（无故障）操作期间那样。下图显示了正常连接。
灾难性故障
一个粗心的叉车操作员将墙撞穿了，切断了所有网络连接（业务和 A-Link），同时供电仍未中断并且系统正在运行。下图显示了故障情况。
故障处理
这两个节点按照以下方式处理故障：
- node0 — node0 上的 AX 检测到 A-Link 以及其他所有网络路径中断。由于 node0 AX 无法再检测到其配对节点的存在，因此 node0 AX 变为活动状态并运行客人 VM。客人 VM 中的应用程序继续运行，其或许由于网络中断而以有限的容量运行。
- node1 — node1 上的 AX 也检测到两个 A-Link 中断，但 ibiz0 仍可用。由于其配对节点未响应 ibiz0 上的消息，因此 node1 AX 现在处于活动状态。客人 VM 中的应用程序继续运行，或许未注意到系统的任何问题。
从应用程序客户端或外部观察者的角度来看，这些客人 VM 均处于活动状态，并且生成具有相同返回地址的网络消息。这两个客人 VM 均生成数据并看到不同数量的通信故障。这些客人 VM 的状态随时间而变得更加不同。
恢复和修复
一段时间后，网络连接恢复：修好了墙壁并更换了网络电缆。
当 AX 对的每个 AX 均意识到其配对节点重新联机时，具有故障处理程序规则的 AX 对选择继续处于活动状态的 AX。该选择是不可预测的，并且对于在脑裂情况下哪个节点的性能更准确没有任何考虑。
活动节点的重新同步覆盖了从（现在）备用节点生成的数据，因此（现在）备用节点上的数据永久丢失。
在脑裂情况下，系统需要几分钟的时间进行重新同步，这取决于需要将多少磁盘活动发送到备用节点。如果多个客人 VM 正在使用不同的活动节点运行，则可能在两个方向上发生同步流量。
示例 2：具有仲裁服务器的
在这个 SplitSite示例中，everRun 系统包含 node0 和 node1，它们的连接与示例 1 中系统的连接相同。此外，示例 2 中的系统还包含仲裁服务器。下图显示了这些连接。
灾难性故障
那个粗心的叉车操作员又将墙撞穿了，切断了所有网络连接，同时供电仍未中断并且系统正在运行。下图显示了故障情况。
故障处理
这两个节点按照以下方式处理故障：
- node0 — node0 上的 AX 检测到 A-Link 以及其他所有网络路径中断。由于 node0 AX 无法再检测到其配对节点的存在，因此 node0 AX 尝试联系仲裁服务器。在这种情况下，仲裁服务器也不可用。因此，node0 AX 决定关闭。此关闭不是正常的 Windows 关闭，而是突然停止，这会导致客人 VM 中的应用程序停止。
- node1 — node1 上的 AX 也检测到两个 A-Link 中断，但 ibiz0 仍可用。node1 AX 尝试联系响应的仲裁服务器，因此 node1 AX 保持活动状态。客人 VM 中的应用程序运行，或许未注意到系统的任何问题。
从应用程序客户端或外部观察者的角度来看，node1 上的客人 VM 保持活动状态，并且在 node0 上的 VM 关闭时生成数据。不存在脑裂情况。
恢复和修复
一段时间后，网络连接恢复：修好了墙壁并更换了网络电缆。
当 node1 AX 意识到其配对节点重新联机时，node0 AX 变为备用节点。由于 node0 先前未运行，因此从 node1 开始将数据同步到 node0。
由于没有发生脑裂情况，因此数据未丢失。
系统需要几分钟进行重新同步，这取决于需要将多少磁盘活动发送到备用节点。
示例 2，已修改：在灾难性故障期间仲裁服务器不可及
在具有仲裁服务器的
故障处理类似于示例 2 的故障处理，对于 node1 而言有一个重要区别：
在这种情况下，客人 VM 在 node0 和 node1 上均关闭，从而防止发生脑裂。折衷方法是在恢复与 node0 或仲裁服务器的连接前，客人 VM 不可用。
在这种情况下，确定您不想运行的节点并将其关闭。然后，强制启动您想要运行的节点，之后强制启动 VM。有关关闭 VM 然后启动它的信息，请参阅管理虚拟机的运行。）
示例 2，已修改：在无灾难性故障时仲裁服务器不可及
在某些情况下，即使没有发生灾难性的物理故障，仲裁服务器也可能不可及。一个示例是当重启仲裁计算机进行例行维护时，例如应用 OS 补丁。在这些情况下，AX 检测到仲裁服务无响应，因此 AX 会暂停同步流量，直至恢复与仲裁服务器的连接为止。当连接中断时，客人 VM 继续在处于活动状态的节点上运行。但由于可能会发生其他故障，此客人 VM 不移到备用节点。恢复仲裁服务后，只要保持与仲裁服务器的连接，AX 就会继续进行同步和正常故障处理。
从电源故障中恢复
如果在断电或系统关闭后重启系统，everRun系统将在启动任何客人 VM 前无限期等待其配对系统启动并在做出响应。如果先前处于活动状态的 AX 能够联系仲裁服务器，则该 AX 会立即启动客人 VM，不等待其配对节点启动。如果先前备用的 AX 首先启动，则它会等待其配对节点。
如果系统收到来自配对节点或仲裁服务器的响应，则系统将继续正常运行，并且 VM 将启动，这需要遵守在其他情况下适用的相同故障处理程序规则。
如果系统未收到来自仲裁服务器的响应，或者系统没有仲裁服务器，则必须强制启动客人 VM，这会覆盖 AX 或故障处理程序做出的任何决定。您必须确保两个人没有在 node0 和 node1 上强制启动同一客人 VM。无意中这样做会导致脑裂情况。
产品支持与下载