14.3. 实施高可用性
您可以通过实施高可用性(HA)来提高可靠性,即使一个或多个代理离线,代理集群也会继续正常工作。
实现 HA 涉及几个步骤:
- 为您的 HA 实现配置代理集群,如 第 14.2 节 “创建代理集群” 所述。
- 您应该了解什么是主备份组,然后选择最适合您的要求的 HA 策略。请参阅了解 HA 在 AMQ Broker 中的工作方式。
当您选择合适的 HA 策略时,在集群的每个代理上配置 HA 策略。请参阅:
- 将您的客户端应用程序配置为使用故障转移。
之后,如果您需要对配置为高可用性的代理集群进行故障排除,建议您为在集群中运行代理的每个 Java 虚拟机(JVM)实例启用 Garbage Collection (GC)日志记录。要了解如何在 JVM 上启用 GC 日志,请查阅 JVM 使用的 Java Development Kit (JDK)版本的官方文档。有关 AMQ Broker 支持的 JVM 版本的更多信息,请参阅 Red Hat AMQ 7 支持的配置。
14.3.1. 了解高可用性 复制链接链接已复制到粘贴板!
在 AMQ Broker 中,您可以通过将集群中的代理分组到 primary-backup 组 来实现高可用性(HA)。在 primary-backup 组中,主代理链接到备份代理,如果失败,可以接管主代理。AMQ Broker 还为 primary-backup 组中的故障转移(称为 HA 策略)提供多个不同的策略。
14.3.1.1. 主备份组如何提供高可用性 复制链接链接已复制到粘贴板!
在 AMQ Broker 中,您可以通过将集群中的代理链接到 主备份组 来实现高可用性(HA)。主备份组提供 故障转移,这意味着如果一个代理失败,另一个代理可以接管其消息处理。
primary-backup 组由一个连接到一个或多个备份代理的主代理组成。主代理服务客户端请求,而备份代理在被动模式下等待。如果主代理失败,备份代理会替换主代理作为活跃代理,启用客户端重新连接并继续其工作。
14.3.1.2. 高可用性策略 复制链接链接已复制到粘贴板!
高可用性(HA)策略定义了在主备份组中如何发生故障转移。AMQ Broker 提供几个不同的 HA 策略:
- 共享存储(推荐)
主代理将消息传递数据存储在共享文件系统上的通用目录中;通常是存储区域网络(SAN)或网络文件系统(NFS)服务器。如果您配置了基于 JDBC 的持久性,您还可以将代理数据存储在指定的数据库中。使用共享存储时,如果主代理失败,备份代理会从共享存储中加载消息数据,并接管作为活跃代理。
在大多数情况下,您应该使用共享存储而不是复制。由于共享存储不会通过网络复制数据,因此通常比复制提供更好的性能。共享存储还避免了网络隔离(也称为"脑裂")问题,其中主代理及其备份同时处于活动状态。
图 14.4. 共享存储高可用性
- 复制
主代理和备份代理持续通过网络同步其消息传递数据。如果主代理失败,备份代理会加载同步的数据,并作为活跃代理。
主代理和备份代理之间的数据同步可确保主代理失败时不会丢失消息传递数据。当主和备份代理最初加入在一起时,主代理会通过网络将其所有现有数据复制到备份代理中。此初始阶段完成后,主代理会将持久数据复制到备份代理中,因为主代理接收它。这意味着,如果主代理丢弃了网络,备份代理会具有主代理收到的所有持久数据。
因为复制通过网络同步数据,所以网络失败可能会导致主代理及其备份同时处于活跃状态。
图 14.5. 复制高可用性
- 仅主要(有限 HA)
当主代理安全停止时,它会将消息和事务状态复制到另一个活跃代理中,然后关闭。然后,客户端可以重新连接到其他代理以继续发送和接收信息。
图 14.6. 仅主高可用性
其他资源
- 有关主备份组中代理之间共享的持久性消息数据的更多信息,请参阅 第 6.1 节 “在日志中保留消息数据”。
14.3.1.3. 复制策略限制 复制链接链接已复制到粘贴板!
当您使用复制提供高可用性时,主代理和备份代理可以同时变为活动状态(称为"脑裂"。
如果主代理及其备份丢失连接,则脑裂可能会出现。在这种情况下,主代理及其备份可以同时变为活动状态。由于在这种情况下没有代理间没有消息复制,因此它们各自为客户端和处理消息提供服务,而不会进行其他了解。在这种情况下,每个代理都有完全不同的日志。从这种情况中恢复可能非常困难,在某些情况下无法进行。
- 要 消除 脑裂的可能性,请使用 共享存储 HA 策略。
如果使用复制 HA 策略,请执行以下步骤来减少发生脑裂的风险。
如果您希望代理使用 ZooKeeper Coordination 服务协调代理,请在至少三个节点上部署 ZooKeeper。如果代理丢失到一个 ZooKeeper 节点的连接,使用至少三个节点可确保当主备份代理对复制中断时,大多数节点都可用来协调代理。
如果要使用嵌入式代理协调,它使用集群中的其他可用代理提供仲裁投票,您可以减少(但不消除)遇到脑裂的可能性( 至少使用三个主备份对 )。至少使用三个主备份对可确保当主备份代理对复制中断发生时,任何仲裁票数都可实现大多数结果。
使用复制 HA 策略时的一些额外注意事项如下所述:
- 当主代理失败且备份代理处于活跃状态时,在新的备份代理附加到活跃代理前,不会进行进一步的复制,或者恢复到原始主代理发生。
- 如果 primary-backup 组中的备份代理失败,则主代理将继续提供信息。但是,在将另一个代理添加为备份或原始备份代理重启前,消息不会被复制。在此期间,消息只会保留在主代理中。
- 如果代理使用嵌入式代理协调,且主备份对中的两个代理都已关闭,为了避免消息丢失,您必须首先重启最近活跃的代理。如果最近活跃的代理是备份代理,则需要手动将此代理重新配置为主代理,以便首先重启它。
14.3.3. 配置复制高可用性 复制链接链接已复制到粘贴板!
您可以使用复制高可用性(HA)策略在代理集群中实施 HA。通过复制,持久数据会在主代理和备份代理之间同步。如果主代理遇到失败,消息数据会同步到备份代理,它会接管失败的主代理。
如果您没有共享文件系统,您应该使用复制作为共享存储的替代选择。但是,复制可能会导致主代理及其备份同时变为活跃的情况。
由于主和备份代理必须通过网络同步其消息传递数据,因此复制会增加性能开销。此同步进程会阻止日志操作,但它不会阻止客户端。您可以配置日志操作对于数据同步的最大时间。
如果 primary-backup 代理对之间的复制连接中断,代理需要一种协调方法来确定主代理是否仍然活跃,或者是否需要到备份代理的故障转移。为了提供此协调,您可以将代理配置为使用以下一种协调方法。
- Apache ZooKeeper 协调服务。
- 嵌入式代理协调,它使用集群中的其他代理来提供仲裁投票。
14.3.3.1. 选择协调方法 复制链接链接已复制到粘贴板!
红帽建议您使用 Apache ZooKeeper 协调服务协调代理激活。在选择协调方法时,了解基础架构要求和两个协调方法之间数据一致性的差异会很有用。
基础架构要求
- 如果使用 ZooKeeper 协调服务,您可以使用单个主备份代理对操作。但是,您必须将代理连接到至少 3 个 Apache ZooKeeper 节点,以确保代理在连接到一个节点时可以继续正常工作。要为代理提供协调服务,您可以共享其他应用程序使用的现有 ZooKeeper 节点。有关设置 Apache ZooKeeper 的更多信息,请参阅 Apache ZooKeeper 文档。
- 如果要使用嵌入式代理协调,它使用集群中的其他可用代理提供仲裁投票,则必须至少有三个主备份代理对。至少使用三个主备份对,确保在主备份代理对复制中断发生的任何仲裁投票中都可以实现大多数结果。
数据一致性
- 如果您使用 Apache ZooKeeper 协调服务,ZooKeeper 会跟踪每个代理上的数据版本,因此只有具有最新日志数据的代理才可以变为 active,无论代理是否配置为复制目的。版本跟踪消除了代理通过过时的日志和开始服务客户端可以激活的可能性。
- 如果您使用嵌入的代理协调,则不会有机制来跟踪每个代理上的数据版本,以确保只有具有最新日志的代理才会变为活动状态。因此,一个具有没有最新日志的代理可以变为活跃并开始服务客户端,这会导致日志有不同性。
14.3.3.2. 在复制中断后代理如何协调 复制链接链接已复制到粘贴板!
本节介绍在复制连接中断后两个协调方法的工作方式。
使用 ZooKeeper 协调服务
如果使用 ZooKeeper 协调服务来管理复制中断,则两个代理都必须连接到多个 Apache ZooKeeper 节点。
- 如果任何时候,活跃代理会丢失到大多数 ZooKeeper 节点的连接,它会关闭,以避免出现"脑裂"的风险。
- 如果随时,备份代理会丢失到大多数 ZooKeeper 节点的连接,它会停止接收复制数据并等待它连接到大多数 ZooKeeper 节点,然后再重新充当备份代理。当连接恢复到大多数 ZooKeeper 节点时,备份代理使用 ZooKeeper 来确定是否需要丢弃其数据并搜索要从中复制的活动代理,或者它是否可以成为带有其当前数据的活跃代理。
ZooKeeper 使用以下控制机制来管理故障切换过程:
- 可以随时由单个活跃代理拥有的共享租期锁定。
- 跟踪代理数据的最新版本的激活序列计数器。每个代理将其日志数据的版本跟踪在其服务器锁定文件中的本地计数器中,及其 NodeID。活跃代理还在 ZooKeeper 上的协调激活序列中共享其版本。
如果活跃代理和备份代理之间的复制连接丢失,活跃代理会同时增加其本地激活序列计数器值,并在 ZooKeeper 上增加协调激活序列计数器值,以公告它具有最新数据。备份代理的数据现在被视为过时,代理将无法变为活跃代理,直到恢复复制连接并同步最新的数据。
在复制连接丢失后,备份代理会检查 ZooKeeper 锁定是否归活跃代理所有,以及 ZooKeeper 上的协调激活序列是否与其本地计数器值匹配。
- 如果锁定由活跃代理所有,则备份代理检测到 ZooKeeper 上的激活序列计数器会在复制连接丢失时由活跃代理更新。这表示活跃代理正在运行,因此备份代理不会尝试故障转移。
- 如果锁定不归活跃代理所有,则活跃代理将无法激活。如果备份代理上的激活序列的值与 ZooKeeper 上的协调激活序列计数器值相同,这表示备份代理具有最新数据,备份代理会失败。
- 如果锁定不归活跃代理所有,但备份代理上的激活序列计数器的值小于 ZooKeeper 上的计数器值,备份代理中的数据不会处于最新状态,备份代理无法故障转移。
使用嵌入式代理协调
如果 primary-backup 代理对使用嵌入式代理协调来协调复制中断,则可以启动以下两种类型的仲裁投票。
vote 类型 | 描述 | initiator | 所需的配置 | 参与者 | 基于投票结果的操作 |
---|---|---|---|---|---|
被动投票 | 如果被动代理丢失了与活跃代理的复制连接,则被动代理会根据这个投票的结果来决定是否启动。 | 被动代理 | 无。当被动代理丢失与其复制合作伙伴的连接时,被动投票会自动发生。 但是,您可以通过为这些参数指定自定义值来控制被动投票的属性:
| 集群中的其他活跃代理 | 如果被动代理从集群中的其他活跃代理接收大多数(即 仲裁)投票,这表示其复制合作伙伴不再可用。 |
活跃投票 | 如果活跃代理丢失了与其复制合作伙伴的连接,活跃代理会决定根据此票继续运行。 | 活跃代理 |
当一个活跃代理(可能配置为已故障转移的备份)时发生投票,丢失与复制合作伙伴的连接, | 集群中的其他活跃代理 | 如果没有 从集群中的其他活跃代理接收大多数投票,则活跃代理会关闭,表示其集群连接仍然活跃。 |
下面列出了一些重要的事项,以记录您的代理集群的配置如何影响制裁行为。
- 要使仲裁投票成功,集群的大小必须允许达到大多数结果。因此,您的集群应该 至少有三个 主备份代理对。
- 您添加到集群中的 primary-backup 代理对越多,您可以提高集群的整体容错能力。例如,假设您有三个主备份对。如果您丢失了完整的主备份对,则其余两个主备份对无法达到任何后续的仲裁投票。这种情况意味着集群中出现进一步的复制中断可能会导致主代理关闭,并防止其备份代理启动。通过使用五个代理对配置集群,集群至少可能会出现两个故障,同时仍然保证任何仲裁票的大部分结果。
- 如果您有意 减少 集群中的主备份代理对数量,则之前为大多数投票建立的阈值不会自动减少。在此期间,丢失的复制连接触发的任何仲裁票数都无法成功,使集群更易受脑裂的影响。要使集群重新计算仲裁投票的最大阈值,请首先关闭您要从集群中删除的主要备份对。然后,重启集群中剩余的主备份对。当所有剩余的代理都已重启时,集群会重新计算仲裁投票阈值。
14.3.3.3. 使用 ZooKeeper 协调服务为代理集群配置复制 复制链接链接已复制到粘贴板!
您必须在使用 Apache ZooKeeper 协调服务的对中同时指定相同的复制配置。然后,代理会协调以确定哪个代理是活跃代理,这是被动备份代理。
先决条件
- 至少 3 个 Apache ZooKeeper 节点,确保在代理丢失到一个节点时可以继续运行。
- 代理机器有类似的硬件规格,即,您不希望运行活跃代理,并在任何时间点上运行被动备份代理。
- ZooKeeper 必须有足够的资源来确保暂停时间显著低于 ZooKeeper 服务器空循环时间。根据代理的预期负载,请考虑代理和 ZooKeeper 节点是否可以共享同一节点。如需更多信息,请参阅 https://zookeeper.apache.org/。
流程
-
为对
中的两个代理打开 <broker_instance_dir> /etc/broker.xml
配置文件。 为对中的两个代理配置相同的复制配置。例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow primary
- 将复制类型配置为 primary,表示代理可以是主代理,具体取决于代理协调的结果。
coordination-id
-
为两个代理指定一个通用字符串值。具有相同
Coordination-id
字符串的代理将激活协调在一起。在协调过程中,两个代理都使用Coordination-id
字符串作为节点 Id,并尝试在 ZooKeeper 中获取锁定。获取锁定并具有最新数据的第一个代理将作为活跃代理启动,其他代理会成为被动备份。 属性
指定
property
元素,您可以指定一组键值对来提供 ZooKeeper 节点的连接详情:Expand 表 14.2. ZooKeeper 连接详情 键 值 connect-string
指定以逗号分隔的 IP 地址和 ZooKeeper 节点的端口号列表。例如,
value="192.168.1.10:6666,192.168.2.10:6667,192.168.3.10:6668"
。session-ms
代理在丢失到大多数 ZooKeeper 节点的连接后等待的持续时间。默认值为
18000
ms。有效值是 ZooKeeper 服务器空循环时间的 2 次和 20 次。注意垃圾回收值的 ZooKeeper 暂停时间必须小于
session-ms
属性的值 0.33,以便 ZooKeeper heartbeat 能够可靠地正常工作。如果无法确保暂停时间小于这个限制,请增加每个代理的session-ms
属性的值,并接受较慢的故障转移。重要代理复制合作伙伴每 2 秒自动交换"ping"数据包,以确认合作伙伴代理可用。当备份代理没有从活跃代理接收响应时,备份会等待响应,直到代理的连接生存时间(ttl)过期。默认 connection-ttl 为
60000
ms,这意味着备份代理尝试在 60 秒后尝试故障转移。建议您将 connection-ttl 值设置为与session-ms
属性值类似的值,以便更快地进行故障转移。要设置新的 connection-ttl,请配置connection-ttl-override
属性。namespace (可选)
如果代理与其他应用程序共享 ZooKeeper 节点,您可以创建一个 ZooKeeper 命名空间来存储为代理提供协调服务的文件。您必须为这两个代理指定相同的命名空间。
为代理配置任何其他 HA 属性。
这些额外的 HA 属性具有适合大多数常见用例的默认值。因此,如果您不希望默认行为,您只需要配置这些属性。更多信息请参阅 附录 F, 其他复制高可用性配置元素。
- 重复步骤 1 到 3,以配置集群中的每个额外代理对。
其他资源
- 有关将复制用于 HA 的代理集群示例,请参阅 HA 示例。
- 有关节点 ID 的更多信息,请参阅了解节点 ID。
14.3.3.4. 使用嵌入式代理协调配置代理集群以复制高可用性 复制链接链接已复制到粘贴板!
使用嵌入式代理协调进行复制至少需要三个主备份对,以减少(但不消除)"脑裂"的风险。
以下流程描述了如何为 6-broker 集群配置复制高可用性(HA)。在这个拓扑中,6 个代理被分成三个主备份对:三个主代理都使用专用的备份代理对。
先决条件
您必须有一个至少 6 个代理的代理集群。
6 个代理配置为三个主备份对。有关在集群中添加代理的详情,请参考 第 14 章 设置代理集群。
流程
将集群中的代理分组到主备份组中。
在大多数情况下,primary-backup 组应该由两个代理组成:一个主代理和一个备份代理。如果您在集群中有六个代理,则需要三个主备份组。
创建由一个主代理和一个备份代理组成的第一个 primary-backup 组。
-
打开主代理的 <
broker_instance_dir> /etc/broker.xml
配置文件。 配置主代理,以将复制用于其 HA 策略。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow check-for-active-server
如果主代理失败,此属性控制客户端重启时是否应该返回它。
如果将此属性设置为
true
,则当主代理在之前的故障转移后重启时,它会搜索具有相同节点 ID 的集群中的另一个代理。如果主代理找到具有相同节点 ID 的另一个代理,这表示在主代理失败后成功启动了备份代理。在这种情况下,主代理将其数据与备份代理同步。然后,主代理请求备份代理关闭。如果为故障恢复配置了备份代理,它会被关闭。然后,主代理会恢复其活跃角色,客户端会重新连接。警告如果您没有在主代理上将
check-for-active-server
设置为true
,则可能会在之前的故障转移后重启主代理时遇到重复的消息传递处理。具体来说,如果您重启一个主代理,其此属性设置为false
,则主代理不会将数据与其备份代理同步。在这种情况下,主代理可能会处理备份代理已处理的相同消息,从而导致重复。group-name
- 此 primary-backup 组的名称(可选)。要形成 primary-backup 组,必须使用相同的组名称配置主和备份代理。如果没有指定 group-name,备份代理可以使用任何主代理复制。
vote-on-replication-failure
此属性控制主代理是否在中断复制连接时启动一个名为 primary vote 的仲裁投票。
主要投票是主代理用来确定它还是其合作伙伴是中断复制连接的原因的方法。根据 vote 的结果,主代理可以保持运行或关闭。
重要要使仲裁投票成功,集群的大小必须允许达到大多数结果。因此,在使用复制 HA 策略时,您的集群应该 至少有三个 主备份代理对。
在集群中配置更多代理对,您可以提高集群的整体容错能力。例如,假设您有三个主备份代理对。如果您丢失了与完整的主备份对的连接,则剩余的两个主备份对不再达到仲裁投票。这意味着,任何后续复制中断都可能会导致主代理关闭,并阻止备份代理启动。通过使用五个代理对配置集群,集群至少可能会出现两个故障,同时仍然保证任何仲裁票的大部分结果。
为主代理配置任何其他 HA 属性。
这些额外的 HA 属性具有适合大多数常见用例的默认值。因此,如果您不希望默认行为,您只需要配置这些属性。更多信息请参阅 附录 F, 其他复制高可用性配置元素。
-
打开备份代理的 <
broker_instance_dir> /etc/broker.xml
配置文件。 配置备份代理,以将复制用于其 HA 策略。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow allow-failback
如果发生故障转移并且为主代理接管备份代理,此属性控制备份代理是否应该在重启并重新连接到集群时返回到原始主代理。
注意failback 用于主备份对(一个主代理与单个备份代理配对)。如果主代理配置了多个备份,则不会进行故障恢复。相反,如果发生故障转移事件,备份代理将活跃,下一个备份将变为备份。当主代理恢复在线时,将无法启动故障恢复,因为现在活跃的代理已有备份。
group-name
- 此 primary-backup 组的名称(可选)。要形成 primary-backup 组,必须使用相同的组名称配置主和备份代理。如果没有指定 group-name,备份代理可以使用任何主代理复制。
vote-on-replication-failure
此属性控制已激活的备份代理是否可以在中断复制连接时启动称为 主票的仲裁投票。
主要投票是主代理用来确定它还是其合作伙伴是中断复制连接的原因的方法。根据 vote 的结果,主代理可以保持运行或关闭。
(可选)配置备份代理启动的仲裁票的属性。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow vote-retries
- 此属性控制备份代理重试仲裁投票的次数,以便接收允许备份代理启动最多的结果。
vote-retry-wait
- 此属性控制每次重试仲裁票之间等待的备份代理的时间(以毫秒为单位)。
为备份代理配置任何其他 HA 属性。
这些额外的 HA 属性具有适合大多数常见用例的默认值。因此,如果您不希望默认行为,您只需要配置这些属性。更多信息请参阅 附录 F, 其他复制高可用性配置元素。
-
打开主代理的 <
对集群中的每个额外的 primary-backup 组重复步骤 2。
如果集群中有六个代理,请多次重复这个过程 ; 为每个剩余的 primary-backup 组重复一次。
其他资源
- 有关将复制用于 HA 的代理集群示例,请参阅 HA 示例。
- 有关节点 ID 的更多信息,请参阅了解节点 ID。
14.3.4. 使用仅主配置有限高可用性 复制链接链接已复制到粘贴板!
唯一的 HA 策略允许您在不丢失任何信息的情况下在集群中关闭代理。使用 primary-only 时,当活跃代理安全停止时,它会将消息和事务状态复制到另一个活跃代理中,然后关闭。然后,客户端可以重新连接到其他代理以继续发送和接收信息。
仅主 HA 策略仅在安全停止代理时处理问题单。它不会处理意外的代理失败。
虽然仅主 HA 会阻止消息丢失,但可能无法保留消息顺序。如果停止配置了主 HA 的代理,其消息将附加到另一个代理队列的末尾。
当代理准备缩减时,它会将消息发送到其客户端,然后再断开连接,通知这些新代理已准备好处理其消息。但是,只有在初始代理完成缩减后,客户端才应重新连接到新代理。这样可确保当客户端重新连接时,其他代理上都可以有任何状态(如队列或事务)。在客户端重新连接时,会应用正常重新连接设置,因此您应该设置默认值,以处理缩减所需的时间。
此流程描述了如何配置集群中的每个代理来缩减。完成此步骤后,每当代理安全停止后,它将将其消息和事务状态复制到集群中的另一个代理。
流程
-
打开第一个代理的 <
broker_instance_dir> /etc/broker.xml
配置文件。 将代理配置为使用只读 HA 策略。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置缩减代理集群的方法。
指定此代理应缩减到的代理或代理组。
Expand 表 14.3. 缩减代理集群的方法 要缩减到… 这些以下操作 集群中的特定代理
指定要缩减的代理连接器。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 集群中的任何代理
指定代理的发现组。
<primary-only> <scale-down> <discovery-group-ref discovery-group-name="my-discovery-group"/> </scale-down> </primary-only>
<primary-only> <scale-down> <discovery-group-ref discovery-group-name="my-discovery-group"/> </scale-down> </primary-only>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定代理组中的代理
指定代理组。
<primary-only> <scale-down> <group-name>my-group-name</group-name> </scale-down> </primary-only>
<primary-only> <scale-down> <group-name>my-group-name</group-name> </scale-down> </primary-only>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 对集群中的每个剩余的代理重复此步骤。
其他资源
-
有关使用 primary-only 缩减集群的代理集群示例,请参阅
缩减
示例。
14.3.5. 使用并置备份配置高可用性 复制链接链接已复制到粘贴板!
您可以在与另一个主代理相同的 JVM 中并置备份代理,而不是配置 primary-backup 组。在这个配置中,每个主代理配置为请求另一个主代理在 JVM 中创建和启动备份代理。
图 14.7. colocated 主和备份代理
您可以将 colocation 与共享存储一起使用,或复制作为高可用性(HA)策略。新的备份代理从创建它的主代理中继承其配置。备份的名称设置为 colocated_backup_n
,其中 n
是主代理创建的备份数量。
另外,备份代理会继承其连接器的配置,以及创建它的主代理中的 acceptors。默认情况下,为每个应用端口偏移 100。例如,如果主代理具有端口 61616 的接收器,则创建的第一个备份代理将使用端口 61716,第二个备份将使用 61816,以此类推。
根据您选择的 HA 策略设置日志、大消息和分页的目录。如果选择共享存储,请求代理会通知目标代理要使用哪个目录。如果选择了复制,目录将从创建代理继承,并将新备份的名称附加到它们。
此流程将集群中的每个代理配置为使用共享存储 HA,并请求创建备份并与集群中的另一个代理在一起。
流程
-
打开第一个代理的 <
broker_instance_dir> /etc/broker.xml
配置文件。 将代理配置为使用 HA 策略和 colocation。
在本例中,代理配置了共享存储 HA 和 colocation。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow request-backup
-
通过将此属性设置为
true
,此代理将请求一个备份代理由集群中的另一个主代理创建。 max-backups
-
此代理可以创建的备份代理数量。如果将此属性设置为
0
,则此代理不接受来自集群中其他代理的备份请求。 backup-request-retries
-
此代理应尝试请求创建备份代理的次数。默认值为
-1
,即无限尝试。 backup-request-retry-interval
-
代理在重试请求以创建备份代理前应等待的时间(毫秒)。默认值为
5000
或 5 秒。 backup-port-offset
-
用于接受器和新备份代理的端口偏移。如果此代理收到一个请求来为集群中的另一个代理创建备份,它将创建带有这个数量的端口偏移的备份代理。默认值为
100
。 excludes
(可选)-
从备份端口偏移中排除连接器。如果您已经为应该排除在备份端口偏移中的外部代理配置了任何连接器,请为每个连接器添加一个 <
;connector-ref
>。 primary
- 此代理的共享存储或复制故障转移配置。
backup
- 此代理的备份的共享存储或复制故障转移配置。
- 对集群中的每个剩余的代理重复此步骤。
其他资源
- 有关使用 colocated 备份的代理集群示例,请参阅 HA 示例。
14.3.6. 将客户端配置为故障切换 复制链接链接已复制到粘贴板!
在代理集群中配置高可用性后,您可以将客户端配置为故障切换。客户端故障转移可确保如果代理失败,连接到它的客户端可以在最少的停机时间的情况下重新连接到集群中的另一个代理。
如果出现临时网络问题,AMQ Broker 会自动重新附加连接到同一代理。这与故障转移类似,但客户端重新连接到同一代理。
您可以配置两种不同类型的客户端故障转移:
- 自动客户端故障转移
- 客户端在第一次连接时接收代理集群的信息。如果连接了它的代理失败,客户端会自动重新连接到代理的备份,备份代理会在故障转移前重新创建每个连接上存在的任何会话和用户。
- 应用程序级别的客户端故障转移
- 作为自动客户端故障转移的替代选择,您可以在故障处理程序中使用自己的自定义重新连接逻辑来编写客户端应用程序。
流程
使用 AMQ 核心协议 JMS 配置带有自动或应用程序级别的故障转移的客户端应用程序。
如需更多信息,请参阅使用 AMQ 核心协议 JMS 客户端。