文章
Jingwei Wang · 七月 4 阅读大约需 11 分钟

IRIS/HealthConnect 高可用机制

高可用性(HA)指的是使系统或应用程序在很高比例的时间内保持运行,最大限度地减少计划内和计划外的停机时间。

维持系统高可用性的主要机制被称为故障转移。在这种方法下,一个故障的主系统被一个备份系统所取代;也就是说,生产系统故障转移到备份系统上。许多HA配置还提供了灾难恢复(DR)的机制,即在HA机制无法保持系统的可用性时,也能及时恢复系统的可用性。

本文简要讨论了可用于基于InterSystems IRIS的应用程序的HA策略机制,提供了HA解决方案的功能比较,并讨论了使用分布式缓存的故障转移策略。

 

操作系统级别的集群HA

在操作系统层面上提供的一个常见的HA解决方案是故障转移集群,其中主要的生产系统由一个(通常是相同的)备用系统补充,共享存储和一个跟随活动成员的集群IP地址。在生产系统发生故障的情况下,备用系统承担生产工作量,接管以前在故障主系统上运行的程序和服务。备用机必须能够处理正常的生产工作负载,只要恢复故障主机所需的时间就可以了。也可以选择让备用机成为主机,一旦主机恢复,故障主机将成为备用机。

InterSystems IRIS的设计可以轻松地与所支持的平台的故障转移集群技术相结合(如InterSystems支持的平台中所述)。InterSystems IRIS实例安装在集群的共享存储设备上,以便两个集群成员都能识别它,然后添加到集群配置中,这样它将作为故障转移的一部分在备用机上自动重新启动。在故障转移后重新启动时,系统自动执行正常的启动恢复,保持结构和逻辑的完整性,就像InterSystems IRIS在故障系统上重新启动一样。如果需要,可以在一个集群上安装多个InterSystems IRIS实例。

 

InterSystems IRIS 镜像

具有自动故障转移功能的 InterSystems IRIS 数据库镜像为计划内和意外停机提供了经济有效的高可用性解决方案。镜像依赖于数据复制而不是共享存储,避免了存储故障导致的重大服务中断。

InterSystems IRIS 镜像由两个物理上独立的 InterSystems IRIS 系统组成,称为故障转移成员。每个故障转移成员在镜像中维护每个镜像数据库的副本;应用程序更新是在主故障转移成员上进行的,而备机故障转移用户的数据库则通过主成员的日志文件保持数据同步。

镜像会自动将主节点的角色分配给两个故障转移成员中的一个,而另一个故障转移成员则自动成为备机系统。当主 InterSystems IRIS 实例失败或变得不可用时,备机将自动快速接管并成为主机。

第三个系统称为仲裁机,它与故障转移成员保持持续的联系,在无法直接通信时安全地做出故障转移决策,为他们提供所需信息。在每个故障转移系统主机上运行的代理(称为 ISCAgents )进程也有助于自动故障转移逻辑。除非备机能够确认主节点确实处于停机状态或不可用状态,并且无法再作为主节点运行,否则备机将无法接管。在仲裁机和 ISCAgents 之间,这可以在几乎每个中断场景下完成。

当镜像配置使用 virtual IP address(虚拟 IP 地址)时,将应用程序连接重定向到新主节点是透明的。如果连接是通过 ECP,它们会自动重置到新的主节点。用于重定向应用程序连接的其他机制也是可用的。

当主机实例恢复正常时,它将自动成为备机实例。操作员启动的故障转移也可在计划的维护或升级停机期间维护可用性。

 

自动故障转移机制

镜像主旨在当主节点失败或变得不可用时,为备机提供安全的自动故障转移。本部分描述了允许这种情况发生的机制,包括:

• 自动故障转移的安全性要求

• 自动故障转移规则

• 对于各种中断情况的镜像响应

• 自动故障转移机制详节

 

自动故障转移的安全性要求

备机的 InterSystems IRIS 实例只有在能够确保满足以下两个条件时才能自动接管主节点:

• 备机实例已从主节点接收到最新的日志数据。

这一要求保证了主节点上镜像数据库的所有持久更新都已经或将要对备机的相同数据库进行,从而确保不会丢失任何数据。

• 主机实例不再作为主机实例运行,并且在没有手动干预的情况下无法这样做。

这个要求消除了两个故障转移成员同时作为主节点的可能性,这可能导致逻辑数据库性能下降和完整性损失。

 

自动故障转移规则

 

备机状态和自动故障转移

在正常镜像操作期间,备机故障转移成员的日志传输状态为活动,这意味着它已从主节点接收到所有日志数据,并与其同步。活跃的备机接收写在主机上的当前日志数据,主机等待备机确认收到日志之后才考虑该数据的持久化。因此,备机为活跃状态满足故障转移的第一个条件。

如果活跃备机在Quality of Service(QoS)(服务质量超时)内不能确定已从主节点接收新数据,主节点会撤销备机的活动状态,断开备机并暂时进入故障状态。当处于故障状态时,主节点不提交任何新的日志数据(可能导致应用程序暂停),确保充足的时间,使故障转移成员在不发生异步的情况下恢复联系或进行适当的安全故障转移决策

当备机重新连接到主节点时,它首先通过从主节点获取所有最近的日志数据来跟上,然后变为活动状态。当备机通过从主节点同步了最新的日志数据并确认其接收而跟上时,将恢复其活动状态。

 

备机处于活动状态时的自动故障转移

当备机处于活动状态时,如果它能够确认故障转移的第二个条件,主节点不可以再作为主节点,并且在没有人工干预的情况下不能继续成为主节点,那么它就有资格作为主机进行接管。备机可以通过以下三种方式中的任意一种来接管主节点:

• 通过接收来自主机的请求接管的通信

这发生在主机实例正常关闭期间或主机实例检测到主机实例挂起时。一旦主节点发送了这条消息,它就不能再作为主机了,活动备机可以安全地接管它。如果前一个主机被挂起,新的主机就会迫使它关机

• 通过从仲裁机处收到信息,得知其已与主机失去联系。

当一个网络事件同时将主节点与备机和仲裁机隔离时,它将无限期地进入故障状态。因此,如果一个活跃备机与主机失去联系,并且从仲裁机那里得知它也与主机用失去了联系,那么备机可以安全地接管,因为主机用必须要么已经出现故障,要么被隔离并处于故障状态,因此不能再作为主节点运行了。当连接恢复时,如果前一个主节点挂起,新的主节点就会将之前的主节点强制关闭。

• 通过从主机的 ISCAgent 接收主机实例已关闭或挂起的信息。

当仲裁机不可用或未配置仲裁机时,与主机实例失去联系的活动备机可以尝试联系主机实例的 ISCAgent(只有在主机实例主机系统仍在运行时才可能)以确认主机实例已关闭或处于挂起状态。一旦代理确认主节点不能再作为主机,并且故障转移因此是安全的,备机就会接管。

 

备机不处于活动状态时的自动故障转移

不活动的备机可以尝试与主机实例的 ISCAgent 联系,以确认主机实例处于关闭状态,或在挂起时强制关闭主机实例,并从代理获取主机实例最近的日志数据。如果在这两方面都成功,那么备机可以安全地作为主机接管。

不活动且无法与主机的 ISCAgent 联系的备机无法确保主机不再作为主机,并且无法保证此时的备机拥有主机最新的日志更新,因此无法接管主机。

当备机没有活动时,仲裁机在故障转移机制中不起任何作用。

 

对于各种中断情况的镜像响应

 

自动故障转移中主机中断场景的响应

在以下几种主要的主节点中断情况下,活动的备机故障转移成员会自动接管:

  1. 主节点的计划中断(例如出于维护目的)通过关闭其 InterSystems IRIS 实例来启动。

自动故障转移发生是因为主机指示活跃备机接管。

  1. 主 InterSystems IRIS 实例由于意外情况而挂起。

自动故障转移发生是因为主节点检测到它被挂起并指示活跃备机接管。

  1. 主 InterSystems IRIS 实例由于意外情况而被迫关闭或完全失去响应。

在此情况下,主节点不能指示备机接管。然而,活动备机可以在从仲裁机那里得知它也与主节点失去联系后接管,也可以通过与主机的 ISCAgent 联系并获得主机停机的确认后接管。

  1. 主机存储的子系统失败。

存储失败的典型后果是主机实例挂起,原因是 I/O 错误,在这种情况下,主节点检测到它被挂起,并指示活动的备机接管(如场景 2)。然而,在某些情况下,场景 3 或场景 5 描述的行为可能适用。

  1. 主机的主机系统发生故障或失去响应。

如果活动的备机从仲裁机获悉它也与主机失去联系,则发生自动故障转移。

如果没有配置仲裁机,或者仲裁机在主机故障前已经不可用,则不可能进行自动故障转移;在这些情况下,可以选择手动强制备机成为主机。

  1. 一个网络问题隔离了主机。

如果配置了仲裁机,并且在网络故障时两个故障转移成员都不能连接到它,则主节点将无限地进入故障状态。

• 如果活动的备机从仲裁机获悉它也与主机失去联系,则发生自动故障转移。

• 如果备机在与主节点失去联系的同时失去与仲裁机的联系,则不可能进行自动故障转移。如果两个故障转移成员都已启动,则在还原网络时,备机将与主节点联系,主节点恢复操作。或者,可以手动指定主节点。

如果没有配置仲裁机,或者在网络故障发生前,故障转移成员之一已经与仲裁机断开,则无法进行自动故障转移,主节点将继续作为主机运行。

一个未活动的备机(例如备机正在启动或未追上主机最新日志)可以通过与主节点的 ISCAgent 联系并获得最新的日志数据,在上述场景 1 到 4 下接管。未活动的备机不能在场景 5 和 6 中接管,因为它不能与 ISCAgent 联系;在这些情况下,手动强制使备机成为主机可能是一种选择。

 

自动故障转移机制详解

代理控制模式

当镜像启动时,故障转移成员在代理控制模式下开始操作。如果仲裁机不可用或未配置仲裁机,则保持此模式。当处于代理控制模式时,故障转移成员响应彼此之间的联系丢失,如下所述。

主机对失联的反应

如果主节点失去了与活动备机的连接,或者超过了等待它确认数据接收的 QoS timeout QoS 超时),则主程序撤消备机的活动状态并进入故障状态,等待备机确认其不再活动。当主节点收到来自备机的确认或故障超时(是 QoS 超时的两倍)过期时,主程序退出故障状态,恢复为主程序运行。

如果主节点失去了与非活动备机的连接,则它将继续作为主程序运行,不会进入故障状态。

备机对失联的反应

如果备机失去了与主节点的连接,或者超过了等待来自主机的消息的 QoS timeout QoS 超时),那么它将尝试与主客户的 ISCAgent 联系。如果代理报告主机实例仍作为主机实例运行,则备机重新连接。如果代理确认主节点处于关闭状态,或者它已将其强制关闭,则备机行为如下:

• 如果备机处于活动状态,且代理确认主节点在故障超时内处于停机状态,则备机将作为主服务端接管。

• 如果备机未处于活动状态,或者超过了故障超时时间,那么如果代理确认主节点已停机,并且能够从代理获得最新的日志数据,则备机将接管。

无论是否处于活动状态,备机永远无法在代理控制模式下自动接管,除非主节点自身确认它已挂起,或者主服务的代理确认主服务已停机(可能是在强制停机之后),如果主节点已停机或网络隔离,这两种情况备机无法自动接管。

注意: 当其中一个故障转移成员重启时,它会尝试联系另一个成员的 ISCAgent,其行为与不活动备机的描述一样。

 

仲裁机控制模式

当故障转移成员相互连接时,两者都连接到仲裁机,并且备机是活动的,它们进入仲裁机控制模式,在该模式中,故障转移会员根据仲裁机提供的关于另一个故障转移成员的信息对它们之间的联系丢失做出响应。因为每个故障转移成员通过测试其与另一个故障转移成员的连接来响应其仲裁连接的丢失,反之亦然,由单个网络事件引起的多个连接丢失被作为单个事件处理。

在仲裁机控制模式中,如果故障转移成员仅丢失其仲裁机连接,或者备机 丢失其活动状态,则故障转移成员协调切换到代理控制模式。

如果主节点和备机节点之间的连接在仲裁机控制模式下断开,则每个故障转移成员根据仲裁机连接的状态进行响应,如下图所述。

 

所有三个系统连接:

  • 镜像进入仲裁机控制模式(如果尚未进入仲裁机控制模式)

 

备机失去与仲裁机的连接,但仍连接到主节点:

  • 镜像切换到代理控制模式
  • 主节点继续作为主节点运行
  • 备机尝试重新连接仲裁机

 

主节点失去与仲裁机的连接,但仍连接到备机:

  • 镜像切换到代理控制模式
  • 主节点继续作为主节点运行
  • 主节点尝试重新连接仲裁程序

 

故障转移成员彼此失去连接,仍然连接到仲裁机:

  • 镜像切换到代理控制模式
  • 主节点继续作为主节点运行
  • 备机尝试重新连接主节点

 

仲裁机失败或隔离-故障转移成员失去与仲裁机的连接,但仍彼此连接:

  • 镜像切换到代理控制模式
  • 主节点继续作为主节点运行
  • 两个故障转移成员都尝试重新连接仲裁机

 

备机中断或被隔离-主节点和仲裁机失去与备机的连接,但仍相互连接:

  • 主节点切换到代理控制模式并继续作为主节点操作
  • 备机(如果在操作中)切换到代理控制模式并尝试重新连接到主节点

 

主节点中断或被隔离-备机和仲裁机失去与主节点的连接,但仍相互连接:

  • 主节点(如果在运行中)将无限期地保持在仲裁控制模式和故障状态
  • 备机作为主机接管,切换到代理控制模式,并在恢复连接时强制主机关闭

 

三个连接全部丢失:

  • 主节点如果在运行中将无限期地保持在仲裁控制模式和故障状态;如果与备机设备联系,则切换到代理控制模式并恢复主设备的运行
  • 备机如果在操作中切换到代理控制模式并尝试重新连接到主节点

 

注意   由于单个事件或多个同时发生的事件而导致所有连接丢失的情况很少见。在大多数情况下,镜像在所有连接丢失之前切换到代理控制模式,在这种情况下:

 

  • 主节点如果在运行继续作为主节点运行
  • 备机如果正在运行尝试重新连接到主节点

    

 

0
0 16
讨论 (0)1
登录或注册以继续