14.3. 实施高可用性


您可以通过实施高可用性(HA)来提高可靠性,即使一个或多个代理离线,代理集群也会继续正常工作。

实现 HA 涉及几个步骤:

  1. 为您的 HA 实现配置代理集群,如 第 14.2 节 “创建代理集群” 所述。
  2. 您应该了解什么是主备份组,然后选择最适合您的要求的 HA 策略。请参阅了解 HA 在 AMQ Broker 中的工作方式
  3. 当您选择合适的 HA 策略时,在集群的每个代理上配置 HA 策略。请参阅:

  4. 将您的客户端应用程序配置为使用故障转移
注意

之后,如果您需要对配置为高可用性的代理集群进行故障排除,建议您为在集群中运行代理的每个 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. 仅主高可用性

其他资源

14.3.1.3. 复制策略限制

当您使用复制提供高可用性时,主代理和备份代理可以同时变为活动状态(称为"脑裂"。

如果主代理及其备份丢失连接,则脑裂可能会出现。在这种情况下,主代理及其备份可以同时变为活动状态。由于在这种情况下没有代理间没有消息复制,因此它们各自为客户端和处理消息提供服务,而不会进行其他了解。在这种情况下,每个代理都有完全不同的日志。从这种情况中恢复可能非常困难,在某些情况下无法进行。

  • 消除 脑裂的可能性,请使用 共享存储 HA 策略。
  • 如果使用复制 HA 策略,请执行以下步骤来减少发生脑裂的风险。

    如果您希望代理使用 ZooKeeper Coordination 服务协调代理,请在至少三个节点上部署 ZooKeeper。如果代理丢失到一个 ZooKeeper 节点的连接,使用至少三个节点可确保当主备份代理对复制中断时,大多数节点都可用来协调代理。

    如果要使用嵌入式代理协调,它使用集群中的其他可用代理提供仲裁投票,您可以减少(但不消除)遇到脑裂的可能性( 至少使用三个主备份对 )。至少使用三个主备份对可确保当主备份代理对复制中断发生时,任何仲裁票数都可实现大多数结果。

使用复制 HA 策略时的一些额外注意事项如下所述:

  • 当主代理失败且备份代理处于活跃状态时,在新的备份代理附加到活跃代理前,不会进行进一步的复制,或者恢复到原始主代理发生。
  • 如果 primary-backup 组中的备份代理失败,则主代理将继续提供信息。但是,在将另一个代理添加为备份或原始备份代理重启前,消息不会被复制。在此期间,消息只会保留在主代理中。
  • 如果代理使用嵌入式代理协调,且主备份对中的两个代理都已关闭,为了避免消息丢失,您必须首先重启最近活跃的代理。如果最近活跃的代理是备份代理,则需要手动将此代理重新配置为主代理,以便首先重启它。

14.3.2. 配置共享存储高可用性

您可以使用共享存储高可用性(HA)策略在代理集群中实施 HA。使用共享存储时,主代理和备份代理可以访问共享文件系统上的通用目录;通常是存储区域网络(SAN)或网络文件系统(NFS)服务器。如果您配置了基于 JDBC 的持久性,您还可以将代理数据存储在指定的数据库中。使用共享存储时,如果主代理失败,备份代理会从共享存储中加载消息数据,并接管作为活跃代理。

通常,SAN 提供了更好的性能(例如,速度)与 NFS 服务器,如果可用,则推荐选项。如果您需要使用 NFS 服务器,请参阅 Red Hat AMQ 7 支持的配置 以了解有关 AMQ Broker 支持的网络文件系统的更多信息。

在大多数情况下,您应该使用共享存储 HA 而不是复制。由于共享存储不会通过网络复制数据,因此通常比复制提供更好的性能。共享存储还避免了网络隔离(也称为"脑裂")问题,其中主代理及其备份同时处于活动状态。

注意

使用共享存储时,备份代理的启动时间取决于消息日志的大小。当备份代理接管失败的主代理时,它会从共享存储中加载日志。如果日志包含大量数据,则此过程可能会非常耗时。

14.3.2.1. 配置 NFS 共享存储

使用共享存储高可用性时,您必须将主代理和备份代理配置为使用共享文件系统上的通用目录。通常,您可以使用存储区域网络(SAN)或网络文件系统(NFS)服务器。

以下是在每个代理机器实例上从 NFS 服务器挂载导出的目录时的一些推荐配置选项。

sync
指定所有更改都会立即刷新到磁盘。
intr
如果服务器关闭或无法访问,允许中断 NFS 请求。
noac
禁用属性缓存。需要在多个客户端间实现属性缓存一致性。
soft
指定如果 NFS 服务器不可用,应报告错误,而不是等待服务器恢复在线。
lookupcache=none
禁用查找缓存。
timeo=n
NFS 客户端(即代理)在重试请求前等待来自 NFS 服务器的时间(以秒为单位)。对于 TCP 上的 NFS,默认的 timeo 值为 600 (60 秒)。对于 UDP 上的 NFS,客户端使用自适应算法来估算常用请求类型的适当超时值,如读取和写入请求。
retrans=n
NFS 客户端在尝试进一步恢复操作前重试请求的次数。如果没有指定 retrans 选项,NFS 客户端会尝试每个请求三次。
重要

在配置 timeoretrans 选项时,务必要使用合理的值。一个默认的 timeo 等待时间为 600 deciseconds(60 秒),retrans 值为 5(重试 5 次),可能会导致 AMQ Broker 需要 5 分钟的等待时间来检测到一个 NFS 已断开连接。

其他资源

14.3.2.2. 配置共享存储高可用性

此流程演示了如何为代理集群配置共享存储高可用性。

先决条件

  • 共享存储系统必须可以被主和备份代理访问。

流程

  1. 将集群中的代理分组到主备份组中。

    在大多数情况下,primary-backup 组应该由两个代理组成:一个主代理和一个备份代理。如果您在集群中有六个代理,则需要三个主备份组。

  2. 创建由一个主代理和一个备份代理组成的第一个 primary-backup 组。

    1. 打开主代理的 < broker_instance_dir&gt; /etc/broker.xml 配置文件。
    2. 如果使用:

      1. 用于提供共享存储的网络文件系统,验证主代理的分页、绑定、日志和大型消息目录是否指向备份代理也可以访问的共享位置。

        <configuration>
            <core>
                ...
                <paging-directory>../sharedstore/data/paging</paging-directory>
                <bindings-directory>../sharedstore/data/bindings</bindings-directory>
                <journal-directory>../sharedstore/data/journal</journal-directory>
                <large-messages-directory>../sharedstore/data/large-messages</large-messages-directory>
                ...
            </core>
        </configuration>
        Copy to Clipboard Toggle word wrap
      2. 提供共享存储的数据库,请确保主代理和备份代理可以连接到同一数据库,并在 broker.xml 配置文件的 database-store 元素中指定相同的配置。示例配置如下所示:

        <configuration>
          <core>
            <store>
               <database-store>
                  <jdbc-connection-url>jdbc:oracle:data/oracle/database-store;create=true</jdbc-connection-url>
                  <jdbc-user>ENC(5493dd76567ee5ec269d11823973462f)</jdbc-user>
                  <jdbc-password>ENC(56a0db3b71043054269d11823973462f)</jdbc-password>
                  <bindings-table-name>BIND_TABLE</bindings-table-name>
                  <message-table-name>MSG_TABLE</message-table-name>
                  <large-message-table-name>LGE_TABLE</large-message-table-name>
                  <page-store-table-name>PAGE_TABLE</page-store-table-name>
                  <node-manager-store-table-name>NODE_TABLE<node-manager-store-table-name>
                  <jdbc-driver-class-name>oracle.jdbc.driver.OracleDriver</jdbc-driver-class-name>
                  <jdbc-network-timeout>10000</jdbc-network-timeout>
                  <jdbc-lock-renew-period>2000</jdbc-lock-renew-period>
                  <jdbc-lock-expiration>15000</jdbc-lock-expiration>
                  <jdbc-journal-sync-period>5</jdbc-journal-sync-period>
               </database-store>
            </store>
          </core>
        </configuration>
        Copy to Clipboard Toggle word wrap
    3. 将主代理配置为使用共享存储作为其 HA 策略。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <shared-store>
                      <primary>
                          <failover-on-shutdown>true</failover-on-shutdown>
                      </primary>
                  </shared-store>
              </ha-policy>
              ...
          </core>
      </configuration>
      Copy to Clipboard Toggle word wrap
      failover-on-shutdown
      如果这个代理通常停止,此属性控制备份代理是否应该活跃并接管。
    4. 打开备份代理的 < broker_instance_dir&gt; /etc/broker.xml 配置文件。
    5. 如果使用:

      1. 用于提供共享存储的网络文件系统,验证备份代理的分页、绑定、日志和大型消息目录指向与主代理相同的共享位置。

        <configuration>
            <core>
                ...
                <paging-directory>../sharedstore/data/paging</paging-directory>
                <bindings-directory>../sharedstore/data/bindings</bindings-directory>
                <journal-directory>../sharedstore/data/journal</journal-directory>
                <large-messages-directory>../sharedstore/data/large-messages</large-messages-directory>
                ...
            </core>
        </configuration>
        Copy to Clipboard Toggle word wrap
      2. 提供共享存储的数据库,请确保主代理和备份代理可以连接到同一数据库,并在 broker.xml 配置文件的 database-store 元素中指定相同的配置。
    6. 将备份代理配置为使用共享存储作为其 HA 策略。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <shared-store>
                      <backup>
                          <failover-on-shutdown>true</failover-on-shutdown>
                          <allow-failback>true</allow-failback>
                          <restart-backup>true</restart-backup>
                      </backup>
                  </shared-store>
              </ha-policy>
              ...
          </core>
      </configuration>
      Copy to Clipboard Toggle word wrap
      failover-on-shutdown
      如果此代理处于活动状态,然后停止,此属性控制备份代理(原始主代理)是否应该活跃并接管。
      allow-failback

      如果发生故障转移并且为主代理接管备份代理,此属性控制备份代理是否应该在重启并重新连接到集群时返回到原始主代理。

      注意

      failback 用于主备份对(一个主代理与单个备份代理配对)。如果主代理配置了多个备份,则不会进行故障恢复。相反,如果发生故障转移事件,备份代理将活跃,下一个备份将变为备份。当原始主代理重新上线时,它将无法启动故障恢复,因为现在活跃的代理已有备份。

      restart-backup
      此属性控制备份代理是否在返回到主代理后自动重启。此属性的默认值为 true
  3. 对集群中的每个剩余的 primary-backup 组重复步骤 2。

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 代理对使用嵌入式代理协调来协调复制中断,则可以启动以下两种类型的仲裁投票。

Expand
表 14.1. 仲裁投票
vote 类型描述initiator所需的配置参与者基于投票结果的操作

被动投票

如果被动代理丢失了与活跃代理的复制连接,则被动代理会根据这个投票的结果来决定是否启动。

被动代理

无。当被动代理丢失与其复制合作伙伴的连接时,被动投票会自动发生。

但是,您可以通过为这些参数指定自定义值来控制被动投票的属性:

  • quorum-vote-wait
  • vote-retries
  • vote-retry-wait

集群中的其他活跃代理

如果被动代理从集群中的其他活跃代理接收大多数(即 仲裁)投票,这表示其复制合作伙伴不再可用。

活跃投票

如果活跃代理丢失了与其复制合作伙伴的连接,活跃代理会决定根据此票继续运行。

活跃代理

当一个活跃代理(可能配置为已故障转移的备份)时发生投票,丢失与复制合作伙伴的连接,vote-on-replication-failure 被设置为 true

集群中的其他活跃代理

如果没有 从集群中的其他活跃代理接收大多数投票,则活跃代理会关闭,表示其集群连接仍然活跃。

重要

下面列出了一些重要的事项,以记录您的代理集群的配置如何影响制裁行为。

  • 要使仲裁投票成功,集群的大小必须允许达到大多数结果。因此,您的集群应该 至少有三个 主备份代理对。
  • 您添加到集群中的 primary-backup 代理对越多,您可以提高集群的整体容错能力。例如,假设您有三个主备份对。如果您丢失了完整的主备份对,则其余两个主备份对无法达到任何后续的仲裁投票。这种情况意味着集群中出现进一步的复制中断可能会导致主代理关闭,并防止其备份代理启动。通过使用五个代理对配置集群,集群至少可能会出现两个故障,同时仍然保证任何仲裁票的大部分结果。
  • 如果您有意 减少 集群中的主备份代理对数量,则之前为大多数投票建立的阈值不会自动减少。在此期间,丢失的复制连接触发的任何仲裁票数都无法成功,使集群更易受脑裂的影响。要使集群重新计算仲裁投票的最大阈值,请首先关闭您要从集群中删除的主要备份对。然后,重启集群中剩余的主备份对。当所有剩余的代理都已重启时,集群会重新计算仲裁投票阈值。

您必须在使用 Apache ZooKeeper 协调服务的对中同时指定相同的复制配置。然后,代理会协调以确定哪个代理是活跃代理,这是被动备份代理。

先决条件

  • 至少 3 个 Apache ZooKeeper 节点,确保在代理丢失到一个节点时可以继续运行。
  • 代理机器有类似的硬件规格,即,您不希望运行活跃代理,并在任何时间点上运行被动备份代理。
  • ZooKeeper 必须有足够的资源来确保暂停时间显著低于 ZooKeeper 服务器空循环时间。根据代理的预期负载,请考虑代理和 ZooKeeper 节点是否可以共享同一节点。如需更多信息,请参阅 https://zookeeper.apache.org/

流程

  1. 为对 中的两个代理打开 <broker_instance_dir> /etc/broker.xml 配置文件。
  2. 为对中的两个代理配置相同的复制配置。例如:

    <configuration>
        <core>
            ...
            <ha-policy>
               <replication>
                  <primary>
                    <coordination-id>production-001</coordination-id>
                    <manager>
                       <properties>
                         <property key="connect-string" value="192.168.1.10:6666,192.168.2.10:6667,192.168.3.10:6668"/>
                       </properties>
                    </manager>
                  </primary>
               </replication>
            </ha-policy>
            ...
        </core>
    </configuration>
    Copy to Clipboard Toggle word wrap
    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 命名空间来存储为代理提供协调服务的文件。您必须为这两个代理指定相同的命名空间。

  3. 为代理配置任何其他 HA 属性。

    这些额外的 HA 属性具有适合大多数常见用例的默认值。因此,如果您不希望默认行为,您只需要配置这些属性。更多信息请参阅 附录 F, 其他复制高可用性配置元素

  4. 重复步骤 1 到 3,以配置集群中的每个额外代理对。

其他资源

使用嵌入式代理协调进行复制至少需要三个主备份对,以减少(但不消除)"脑裂"的风险。

以下流程描述了如何为 6-broker 集群配置复制高可用性(HA)。在这个拓扑中,6 个代理被分成三个主备份对:三个主代理都使用专用的备份代理对。

先决条件

  • 您必须有一个至少 6 个代理的代理集群。

    6 个代理配置为三个主备份对。有关在集群中添加代理的详情,请参考 第 14 章 设置代理集群

流程

  1. 将集群中的代理分组到主备份组中。

    在大多数情况下,primary-backup 组应该由两个代理组成:一个主代理和一个备份代理。如果您在集群中有六个代理,则需要三个主备份组。

  2. 创建由一个主代理和一个备份代理组成的第一个 primary-backup 组。

    1. 打开主代理的 < broker_instance_dir&gt; /etc/broker.xml 配置文件。
    2. 配置主代理,以将复制用于其 HA 策略。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <primary>
                          <check-for-active-server>true</check-for-active-server>
                          <group-name>my-group-1</group-name>
                          <vote-on-replication-failure>true</vote-on-replication-failure>
                          ...
                      </primary>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>
      Copy to Clipboard Toggle word wrap
      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 策略时,您的集群应该 至少有三个 主备份代理对。

      在集群中配置更多代理对,您可以提高集群的整体容错能力。例如,假设您有三个主备份代理对。如果您丢失了与完整的主备份对的连接,则剩余的两个主备份对不再达到仲裁投票。这意味着,任何后续复制中断都可能会导致主代理关闭,并阻止备份代理启动。通过使用五个代理对配置集群,集群至少可能会出现两个故障,同时仍然保证任何仲裁票的大部分结果。

    3. 为主代理配置任何其他 HA 属性。

      这些额外的 HA 属性具有适合大多数常见用例的默认值。因此,如果您不希望默认行为,您只需要配置这些属性。更多信息请参阅 附录 F, 其他复制高可用性配置元素

    4. 打开备份代理的 < broker_instance_dir&gt; /etc/broker.xml 配置文件。
    5. 配置备份代理,以将复制用于其 HA 策略。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <backup>
                          <allow-failback>true</allow-failback>
                          <group-name>my-group-1</group-name>
                          <vote-on-replication-failure>true</vote-on-replication-failure>
                          ...
                      </backup>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>
      Copy to Clipboard Toggle word wrap
      allow-failback

      如果发生故障转移并且为主代理接管备份代理,此属性控制备份代理是否应该在重启并重新连接到集群时返回到原始主代理。

      注意

      failback 用于主备份对(一个主代理与单个备份代理配对)。如果主代理配置了多个备份,则不会进行故障恢复。相反,如果发生故障转移事件,备份代理将活跃,下一个备份将变为备份。当主代理恢复在线时,将无法启动故障恢复,因为现在活跃的代理已有备份。

      group-name
      此 primary-backup 组的名称(可选)。要形成 primary-backup 组,必须使用相同的组名称配置主和备份代理。如果没有指定 group-name,备份代理可以使用任何主代理复制。
      vote-on-replication-failure

      此属性控制已激活的备份代理是否可以在中断复制连接时启动称为 主票的仲裁投票

      主要投票是主代理用来确定它还是其合作伙伴是中断复制连接的原因的方法。根据 vote 的结果,主代理可以保持运行或关闭。

    6. (可选)配置备份代理启动的仲裁票的属性。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <backup>
                      ...
                          <vote-retries>12</vote-retries>
                          <vote-retry-wait>5000</vote-retry-wait>
                      ...
                      </backup>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>
      Copy to Clipboard Toggle word wrap
      vote-retries
      此属性控制备份代理重试仲裁投票的次数,以便接收允许备份代理启动最多的结果。
      vote-retry-wait
      此属性控制每次重试仲裁票之间等待的备份代理的时间(以毫秒为单位)。
    7. 为备份代理配置任何其他 HA 属性。

      这些额外的 HA 属性具有适合大多数常见用例的默认值。因此,如果您不希望默认行为,您只需要配置这些属性。更多信息请参阅 附录 F, 其他复制高可用性配置元素

  3. 对集群中的每个额外的 primary-backup 组重复步骤 2。

    如果集群中有六个代理,请多次重复这个过程 ; 为每个剩余的 primary-backup 组重复一次。

其他资源

14.3.4. 使用仅主配置有限高可用性

唯一的 HA 策略允许您在不丢失任何信息的情况下在集群中关闭代理。使用 primary-only 时,当活跃代理安全停止时,它会将消息和事务状态复制到另一个活跃代理中,然后关闭。然后,客户端可以重新连接到其他代理以继续发送和接收信息。

仅主 HA 策略仅在安全停止代理时处理问题单。它不会处理意外的代理失败。

虽然仅主 HA 会阻止消息丢失,但可能无法保留消息顺序。如果停止配置了主 HA 的代理,其消息将附加到另一个代理队列的末尾。

注意

当代理准备缩减时,它会将消息发送到其客户端,然后再断开连接,通知这些新代理已准备好处理其消息。但是,只有在初始代理完成缩减后,客户端才应重新连接到新代理。这样可确保当客户端重新连接时,其他代理上都可以有任何状态(如队列或事务)。在客户端重新连接时,会应用正常重新连接设置,因此您应该设置默认值,以处理缩减所需的时间。

此流程描述了如何配置集群中的每个代理来缩减。完成此步骤后,每当代理安全停止后,它将将其消息和事务状态复制到集群中的另一个代理。

流程

  1. 打开第一个代理的 < broker_instance_dir&gt; /etc/broker.xml 配置文件。
  2. 将代理配置为使用只读 HA 策略。

    <configuration>
        <core>
            ...
            <ha-policy>
                <primary-only>
                </primary-only>
            </ha-policy>
            ...
        </core>
    </configuration>
    Copy to Clipboard Toggle word wrap
  3. 配置缩减代理集群的方法。

    指定此代理应缩减到的代理或代理组。

    Expand
    表 14.3. 缩减代理集群的方法
    要缩减到…​这些以下操作

    集群中的特定代理

    指定要缩减的代理连接器。

    <primary-only>
        <scale-down>
            <connectors>
                <connector-ref>broker1-connector</connector-ref>
            </connectors>
        </scale-down>
    </primary-only>
    Copy to Clipboard Toggle word wrap

    集群中的任何代理

    指定代理的发现组。

    <primary-only>
        <scale-down>
            <discovery-group-ref discovery-group-name="my-discovery-group"/>
        </scale-down>
    </primary-only>
    Copy to Clipboard Toggle word wrap

    特定代理组中的代理

    指定代理组。

    <primary-only>
        <scale-down>
            <group-name>my-group-name</group-name>
        </scale-down>
    </primary-only>
    Copy to Clipboard Toggle word wrap
  4. 对集群中的每个剩余的代理重复此步骤。

其他资源

  • 有关使用 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,并请求创建备份并与集群中的另一个代理在一起。

流程

  1. 打开第一个代理的 < broker_instance_dir&gt; /etc/broker.xml 配置文件。
  2. 将代理配置为使用 HA 策略和 colocation。

    在本例中,代理配置了共享存储 HA 和 colocation。

    <configuration>
        <core>
            ...
            <ha-policy>
                <shared-store>
                    <colocated>
                        <request-backup>true</request-backup>
                        <max-backups>1</max-backups>
                        <backup-request-retries>-1</backup-request-retries>
                        <backup-request-retry-interval>5000</backup-request-retry-interval/>
                        <backup-port-offset>150</backup-port-offset>
                        <excludes>
                            <connector-ref>remote-connector</connector-ref>
                        </excludes>
                        <primary>
                            <failover-on-shutdown>true</failover-on-shutdown>
                        </primary>
                        <backup>
                            <failover-on-shutdown>true</failover-on-shutdown>
                            <allow-failback>true</allow-failback>
                            <restart-backup>true</restart-backup>
                        </backup>
                    </colocated>
                </shared-store>
            </ha-policy>
            ...
        </core>
    </configuration>
    Copy to Clipboard Toggle word wrap
    request-backup
    通过将此属性设置为 true,此代理将请求一个备份代理由集群中的另一个主代理创建。
    max-backups
    此代理可以创建的备份代理数量。如果将此属性设置为 0,则此代理不接受来自集群中其他代理的备份请求。
    backup-request-retries
    此代理应尝试请求创建备份代理的次数。默认值为 -1,即无限尝试。
    backup-request-retry-interval
    代理在重试请求以创建备份代理前应等待的时间(毫秒)。默认值为 5000 或 5 秒。
    backup-port-offset
    用于接受器和新备份代理的端口偏移。如果此代理收到一个请求来为集群中的另一个代理创建备份,它将创建带有这个数量的端口偏移的备份代理。默认值为 100
    excludes (可选)
    从备份端口偏移中排除连接器。如果您已经为应该排除在备份端口偏移中的外部代理配置了任何连接器,请为每个连接器添加一个 &lt ;connector-ref >。
    primary
    此代理的共享存储或复制故障转移配置。
    backup
    此代理的备份的共享存储或复制故障转移配置。
  3. 对集群中的每个剩余的代理重复此步骤。

其他资源

  • 有关使用 colocated 备份的代理集群示例,请参阅 HA 示例

14.3.6. 将客户端配置为故障切换

在代理集群中配置高可用性后,您可以将客户端配置为故障切换。客户端故障转移可确保如果代理失败,连接到它的客户端可以在最少的停机时间的情况下重新连接到集群中的另一个代理。

注意

如果出现临时网络问题,AMQ Broker 会自动重新附加连接到同一代理。这与故障转移类似,但客户端重新连接到同一代理。

您可以配置两种不同类型的客户端故障转移:

自动客户端故障转移
客户端在第一次连接时接收代理集群的信息。如果连接了它的代理失败,客户端会自动重新连接到代理的备份,备份代理会在故障转移前重新创建每个连接上存在的任何会话和用户。
应用程序级别的客户端故障转移
作为自动客户端故障转移的替代选择,您可以在故障处理程序中使用自己的自定义重新连接逻辑来编写客户端应用程序。

流程

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat