Skip to main content
Enterprise applications
简体中文版经机器翻译而成,仅供参考。如与英语版出现任何冲突,应以英语版为准。

Microsoft SQL Server和ONTAP调解器

贡献者

要安全地自动执行故障转移、需要使用调解器。理想情况下、它会放置在独立的第三个站点上、但如果与参与复制的集群之一主机代管、它仍可满足大多数需求。

调解器并不是真正的断路器、但它提供的功能实际上就是这样。它不会执行任何操作、而是为集群到集群的通信提供备用通信通道。

带调解器的SnapMirror活动同步图

自动化故障转移的第一大挑战是脑裂问题、如果两个站点彼此断开连接、就会出现该问题。应该发生什么?您不希望让两个不同的站点将自己指定为数据的无故障副本、但单个站点如何区分实际丢失相对站点与无法与相反站点通信之间的区别?

这是调解者进入画面的地方。如果放置在第三个站点上、并且每个站点都与该站点建立了单独的网络连接、则每个站点都有一条额外的路径来验证另一个站点的运行状况。再次查看上图、并考虑以下情形。

  • 如果调解器发生故障或无法从一个或两个站点访问、会发生什么情况?

    • 两个集群仍可通过复制服务所使用的同一链路彼此通信。

    • 数据仍会提供RPO = 0保护

  • 如果站点A发生故障、会发生什么情况?

    • 站点B将看到两个通信通道关闭。

    • 站点B将接管数据服务、但没有RPO = 0镜像

  • 如果站点B发生故障、会发生什么情况?

    • 站点A将看到两个通信通道关闭。

    • 站点A将接管数据服务、但没有RPO = 0镜像

还需要考虑另一种情形:丢失数据复制链路。如果站点之间的复制链路丢失、显然无法执行RPO = 0镜像。那么应该发生什么呢?

这由首选站点状态控制。在SM-AS关系中、其中一个站点是另一个站点的二级站点。这对正常操作没有影响、并且所有数据访问都是对称的、但是如果复制中断、则必须断开连接才能恢复操作。结果是、首选站点将继续操作而不进行镜像、而二级站点将暂停IO处理、直到复制通信恢复为止。