10.1 Configuring ActiveMQ for high availability

When an application is deployed  into a production environment, it’s  important  to plan  for disaster  scenarios—network failures,  hardware failures, software  failures, or  power outages.  ActiveMQ can  be deployed  defensively, to prevent  such failures from inhibiting your application in production. Typically you need  to run multiple ActiveMQ brokers on  different machines, so that if one  machine  or one  ActiveMQ broker  fails, a  secondary one  can take  over. Using ActiveMQ  terminology, such deployments are known as master/slave, where one broker  takes  the role of the primary or master  and there are one or more slave  brokers that  wait for the master to fail, at which point one will take over to become the new  master. The ActiveMQ Java and C++ clients provide a built-in failover  transfer,  so that they’ll  automatically switch over  from the failed  master to the  new  master without message loss.

10.1 配置 高可用性 ActiveMQ

将应用程序部署到生产环境中时,为诸如网络故障,硬件,软件故障,或者意外断电等  灾难场景制定应对计划十分重要.ActiveMQ可以做预防性部署,以便在上述系统  灾难发生时,阻止应用程序发送故障.通常,你需要在不同的机器上同时运行多个  ActiveMQ代理,以便在一个机器或ActiveMQ代理发生故障时,其他的备用机器  可以接管继续工作.在ActiveMQ的术语中,这种部署方式被称为主/备结构,即,一个  代理作为主机,其他一个或多个备用代理等待主机失效,一旦主机失效,其中之一的  备机将立刻接管变成新的主机继续主机的工作.ActiveMQ的Java和C++客户端提供  内建的失效转移传输,因此它们会自动的从失败的主机转换到新的主机上并且不会  造成消息丢失. 

ActiveMQ currently supports two different types of master/slave  configurations:  shared nothing, where each ActiveMQ  broker has its own unique  message storage,  and shared storage,  where multiple ActiveMQ  brokers can connect  to the shared  message store  (a relational  database or  a shared  file system)  but only  one  broker will be active  at a time. We’ll  discuss these deployment scenarios  in  this section.

目前ActiveMQ支持两种方式配置主/备机:  无共享主/备机配置,这种配置中,每个ActiveMQ代理拥有独立的消息存储;   存储共享主/备机配置,这种配置中,每个ActiveMQ代理可以连接到共享的消息存储  (关系数据库系统或者共享文件系统),但是同一时间只有一个代理是活动的.  本节中我们将讨论这两种配置的应用场景. 

10.1.1 Shared nothing master/slave

A shared nothing master/slave refers to a deployment where both the master and the  slave have their own message storage. This is probably the easiest option to use for  providing high availability of message brokers.

A slave is configured to connect to the master broker. Whereas the slave needs a  special configuration  denoting its  special state,  the master  broker needs no  special  configuration. There  is some  optional configuration  for the  master,  which we’ll cover at the end of this section.

10.1.1 无共享主/备机配置

无共享主/备机配置中,主机和备机各自拥有自己的消息存储.这也许无共享主/备机配置高可用  性消息代理中最简单的配置了.

备机需要连接到主代理,且需要额外的配置用来报告其当前的状态,而主消息代理不需要  这种额外的配置.主机也有一些可选的配置项,我们将在本节的最后部分讨论这些可选配置项.

All message commands  (messages, acknowledgements, subscriptions,  transactions,  and so on)  are replicated from  the master to  the slave as  depicted in figure  10.1. Such replication takes  place before the master  acts upon any command  it  receives.

所有消息指令(消息,确认,订阅,日志等)都会从主机拷贝到备机上,如图10.1所示.这种拷贝  在主机执行任何接收的到命令之前进行.

A slave broker will connect to the master at startup, so ideally the master should be  running first. The slave broker won’t start any transports (so it can’t accept any client  or network connections) and won’t itself initiate any network connections unless the  master fails. A failure of the master is detected by loss of connectivity from the slave to  the master.        A shared nothing master/slave configuration does impose some extra overhead on  message processing, but this overhead is small considering the benefit that it provides.  When a message producer sends a persistent message to the master, it’ll wait for a  receipt from the master until it can send the next message. The master won’t send the  receipt until it has replicated the message to the slave, and in turn wait for the slave to  finish its processing of the message (which will typically involve the slave persisting it  to storage). The master will then process the message (persist it to storage and dispatch  it to any interested consumers) before sending back a receipt to the message  producer that it has successfully processed the message.

配置主/备机后确实会在消息处理过程中引入一些额外的开销,但是这种额外的开销对于其带来的  好处而言是微不足道的.当一个消息生产者发送持久化消息给主机后,消息生产者需要等待主机的  回执然后才能发送下一条消息.主机在将消息拷贝到备机上并且等待备机依次处理完消息(这种处理  通常是备机将消息存储已进行持久化).备机处理完后,主机便开始处理消息(存储以便持久化消息,然后  分发消息给所有对消息感兴趣的消费者),主机成功消息完处理后才会发送回执给消息生产者. 

When a master broker fails, the slave has two choices:
? Shut itself down—Hence, it’s only acting to preserve the state of the master. In this scenario, an administrator will typically have to manually configure the slave to be the master, and configure a new message broker to take the role of the slave.
? Start up its transports and initiate any network connections—Hence, the slave automatically becomes the new master.

当主机失效后,备机有以下两种选择:
1. 关闭自身 — 这样,备机的作用就是保存主机失效之前的状态. 在这种情况下,系统管理员可以手工配置备机 为新主机,并再配置一个新的消息代理担当备机的角色.
2. 启动其传输连接其并初始化所有网络连接 –这样,备机自动的变成了新主机

If the slave broker takes over the role of the master broker, all clients using the failover  transport will fail over to the new master. For JMS clients to ActiveMQ, the default  transport used by the client’s connection is the failover transport and is typically configured  to be able to connect to both the master and the slave, as shown:  failover://(tcp://masterhost:61616,

tcp://slavehost:61616)?randomize=false 

当备机担当起主机的角色后,所有使用失效转移连接器的客户端会自动切换连接到新主机上.  对于使用ActiveMQ的JMS客户端来说,默认使用的就是失效转移传输连接器,这种连接器通常  会被配置成既可以连接到主机也可以连接到备机,配置如下所示:  failover://(tcp://masterhost:61616,

tcp://slavehost:61616)?randomize=false 

ActiveMQ’s shared nothing master/slave configuration has some limitations. A master  will only replicate its active state from the time the slave connects to it. So if a client is  using the master before the slave is attached, any messages or acknowledgements that  have been processed by the master before the slave has attached itself can potentially  be lost if the master then fails. You can avoid this by setting the waitForSlave property  on the master configuration. This property forces the master to not accept any client  connections until a slave broker has attached to it. Other limitations are that a master  is allowed to have only one slave, and that a slave itself can’t have another slave.

ActiveMQ的无共享主/备机配置存在一些限制.主机只会把备机连接到主机之后的主机状态复制到  备机上.因此,如果客户端在备机连接到主机之前就已经连接到主机了,那么备机连接到主机之前,主机  上任何已存在的消息或者消息确认回执不会被拷贝到备机上,因此如果主机失效,这部分消息和消息  确认回执会永久丢失.你可以为主机设置waitForSlave属性以避免这种丢失的发生.这个属性配置后,会  阻止主机接收任何客户度的消息直到备机代理连接到主机.另外一个限制是,一个主机只能拥有一个备机,  并且备机不能在配置自己的备机.

If you already have a  running broker that you want  to use in a shared  nothing  master/ slave configuration, it’s recommended that you first stop that  broker,  copy  all message  store files  (usually in  the data  directory) to  the slave  machine, and, after configuring, restart the master broker and the slave broker.

如果你已经有一个正在运行的代理,你打算使用这个代理配置一个无共享主/备机系统,那么  推荐的做法是:首先,停止这个代理,宝贝所有的消息存储文件(通常在data目录下面)到备机  所在的机器上,然后配置主/备机结构,配置完成后启动主机代理和备机代理.

You also need  to do the  same when introducing  a new slave  after a master has  failed. The  shared nothing  broker configuration  should only  be used when you  want to ensure that you don’t  lose messages for your application, but  you can  afford to have some down time to attach a new slave after the master has  failed  and the old slave has become the master.

另外,在主机失效后,你还需要配置一个新的备机(译注:原来的备机变成了新主机).无共享主/备机  配置应当在你需要保证主机失效后没有消息丢失,且能接受一些停机时间以便在原来备机成为新  主机后为应用程序配置新备机时使用.

WHEN TO USE SHARED NOTHING MASTER/SLAVE

You should use a shared nothing master/slave configuration in production environments  when some down time on failure is acceptable. Manual intervention by an  administrator will be necessary after a master fails, as it would be advisable to set up  and configure a new slave for the new master after the old master has failed. 

Having covered the theory, let’s look at how to configure a shared nothing master/slave.

何时使用无共享主/备机配置

你应当在可以接收一些停机时间的生产环境中使用无共享主/备机配置.当主机失效后,系统管理员  的手工干预是有必要的,因为原来主机失效后为新主机配置新备机是明智的. 

了解了相关理论后,我们来卡看如何进行无共享主/备机配置 

CONFIGURING SHARED NOTHING MASTER/SLAVE

Designating that a broker is a slave is straightforward. You configure a master-Connector service that accepts the following parameters:
? remoteURI —The URI on which the master broker is listening
? userName—Optional username if the master has authentication configured
? password—Optional password if the master has authentication configured

配置共享主/备机

将一个代理配置为备机很简单.你只需配置收下面参数的masterConnector服务:
? remoteURI —代理主机监听的URI
? userName—可选的用户名,当主机需要认证时使用
? password—可选的密码,当主机需要认证时使用

The following example of slave configuration shows how to configure the slave broker  with a masterConnector:

下面的示例代码展示了如何通过masterConnector配置备机代理:

<services>
<masterConnector 
remoteURI="tcp://remotehost:62001"
userName="Rob" 
password="Davies" />
</services>

You’d normally configure the slave to have duplicate transport and network configurations  as the master broker.

One additional optional property can be  useful for a slave in a  shared nothing  configuration:  the  shutdownOnMasterFailure  property.  When  this  property is  enabled, the slave will safely shut down, ensuring no message loss, allowing  an  administrator to  manual set  up a  new slave.  The slave  broker properties are  shown in  table 10.1.

你需要将备机代理和主机代理的transport和network配置成一样的.

另外一个在配置无共享主/备机时有用的可选属性是:shutdownOnMasterFailure属性.当配置这个  属性为启用时,备机主机在主机失效后会安全的关闭,确保消息不会丢失,这样就允许系统管理员手工  配置一个新的备机代理.备机代理的相关配置属性如表10.1所示.

  Table 10.1 Slave broker properties

  表10.1 备机代理可配置属性

You can designate a broker to be a master without any additional configuration; some  optional properties may be useful. The master broker properties are shown in table 10.2.

你可以指定一个代理为主机代理而不需要进行任何额外配置,但一些可选的属性也许会有用.主机  代理的相关属性如表10.2所示.

Table 10.2 Master broker properties

表10.2 主机代理属性

In addition to the shared nothing master/slave configuration, ActiveMQ also offers a  shared storage master/slave configuration.

 除了无共享主/备机配置,ActiveMQ还提供了共享存储主/备机配置.

10.1.2 Shared storage master/slave

Whereas the shared nothing master/slave offers the ability for brokers to remain independent  of one another, the shared storage master/slave allows many brokers to share the  storage mechanism, but only one broker can be live at any given time. Using a shared  resource storage will ensure that in the event of a master broker failure, no manual  intervention will be required to maintain the integrity of your application in the event  of an additional failure. Another benefit is that there’s no limitation on the number of  slave brokers that can be active at one time with shared storage master/slave.  The ActiveMQ shared storage master/slave configuration comes in two flavors: a  relational database or a file system–based storage.

10.1.2 共享存储主/备机配置

无共享主/备机是的代理之间可以保持相互独立,而共享存储主/备机允许代理共享存储机制,但是任一时间  仅有一个代理是活动的.使用共享资源存储可以确保在主机代理失效时无需手工干预即可让应用程序从失  败状态中恢复.使用共享存储主/备机的另一个好处是对于统一时间处于激活状态的备机数量没有限制.  ActiveMQ可以配置两种方式的共享存储主/备机:关系数据库和基于文件系统的存储.

SHARED DATABASE MASTER/SLAVE

If you’re already using a relational database for message storage, then providing broker  high availability is extremely straightforward. When an ActiveMQ message broker  uses a relational database, it grabs an exclusive lock on a table to ensure that no other  ActiveMQ broker can access the database at the same time. This is due to the fact that  the state of a broker is held in the storage mechanism and is only designed to be used  by a single broker at a time. The shared database master/slave configuration is  depicted in figure 10.2.

共享数据库的主/备机配置

如果你已经使用了关系数据库作为消息存储,那么配置高可用性代理就变得非常容易了.  当使用关系数据库存储消息时,ActiveMQ消息代理会在相关的表上设置一个排他锁以保证  在同一时间只有一个代理可以操作这个表.这是因为代理的状态是由存储机制来维护的并且  这个存储机制被设计成在同一时间只供一个代理使用.图10.2展示了共享数据库的主/备机配置.

If you’re running more than one broker that’s trying to access the same database,  only the first broker to connect will grab the lock. Any subsequent brokers will  poll until they can get access to the lock. While in this polling state, the ActiveMQ  broker assumes that it’s a slave, so it won’t start any transport connections or network  connections.

如果你同时运行着的多个代理同时操作数据库,那么只有第一个连接到数据库的代理可以获取那个排他锁.  任何其他的代理将等待直到它们获得那个排他锁.等待排他锁的代理被视为备机,因而这种代理不会启动任何  的传输练级和网络连接.

You can run multiple brokers, and only one broker will ever be the master at any  given time. All the brokers in this configuration can use the same configuration file,  which makes setup easy. If a master broker fails, a slave broker will be able to grab the  lock on the database and will then take over as the new master broker. Since all the  ActiveMQ brokers are using the same shared database, no additional manual intervention  is required to introduce new brokers or remove existing ones.

你可以同时运行多个代理,但是在同一时间只有一个代理会成为主机代理.这种配置下的代理可以使用同一个  配置文件,这样使得配置变得简单.如果主机代理失效了,备机代理会获取数据库中的排他锁进而接管主机代理  的功能而变成一个新的主机代理.因为这种配置下所有的代理共享同一个数据库存储,所以在新加入或者移除  一个代理时步需要收手工修改配置.

WHEN TO USE SHARED DATABASE MASTER/SLAVE

Shared database master/slave is an ideal configuration if you’re already using an  enterprise relational database. Although generally slower than a shared nothing configuration,  it requires no additional configuration, and there are no limitations on the  number of slave brokers that can be run or when they can be run.

何时使用共享数据库的主/备机

如果你正在使用一个企业级的关系数据库,那么共享数据库的主备机配置是一个理想的配置.尽管这种配置  被使用无共享备主/机主配置要稍微慢一点,但这种配置无需额外配置,并且对备机的数量没有限制.

If access to an enterprise database isn’t an option, or performance is a consideration,  you can use a shared file system instead, where conceptually ActiveMQ brokers  can be set up in the same way as the shared database.

如果没有企业级的数据库,或者性能是主要的考虑因素,你可以使用共享文件系统主/备机配置.

SHARED FILE SYSTEM MASTER/SLAVE

An alternative to using a shared database is to use a shared file system. The setup is  similar to the shared database master/slave, in that no additional configuration of an  ActiveMQ broker is required. Also, there are no limitations on the number of slaves  that can be run or when they can be introduced into the system. It’s recommended  that you use the KahaDB message store, but use an underlying shared file system for  the message storage. When the KahaDB message store starts, it’ll attempt to grab a file  lock, to prevent any other broker from accessing the file-based message store at the  same time. The shared file system master/slave configuration is shown in figure 10.3.  Just like the shared database master/slave configuration, there’s no restriction on  the number of slaves that can be started. The first broker to get the lock on the file  store automatically becomes the master, and any brokers that try to connect after that  automatically become slaves.

共享文件系统主/备机配置

共享数据主/备机配置的一个替代方案是使用共享文件系统.这种配置和使用共享数据库主/备机类似,  不需要为代理做额外配置.同样,在备机代理被引入系统时,对备机代理的数量也没有限制.推荐使用  KahaDB作为消息存储方案,但底层使用能够共享文件系统作为消息存储.当KahaDB消息存储启动时,  KahaDB尝试获取文件锁,以便阻止任何其他代理同时操作基于文件的消息存储.图10.3展示了共享  文件的主/备机配置.与共享数据库的主/备机类似,共享文件主/备机配置对于可以同时启动的备机  数量也没有限制.第一个获取文件锁的代理自动成为主机代理,之后尝试获取同样文件锁的代理成为备机代理.

There are some technical restrictions regarding where you can run a shared file  system master/slave configuration. The shared file system requires the semantics of a  distributed shared file lock. So if you’re not using a storage area network (SAN), there  are some alternatives such as Network File System (NFS)—available on Mac OS X,  OpenVMS, Microsoft Windows (from third parties), Solaris, and AS/400. If you’re  using Fedora or RedHat Enterprise (5.3 and above), it’s recommended you use the  Global File System (GFS) 2, which requires a cluster locking protocol, such as dlm, the  distributed lock manager, which is a Linux kernel module.

使用共享文件系统主/备机配置有一些技术上的限制.共享文件系统要求使用分布式共享文件锁.因此,  如果你没有使用存储区域网络(SAN),你可以使用一些替代方案,比如网络文件系统(NFS)–可用于  Mac OS X,OpenVMS,Microsoft Windows(来自第三方), Solaris, and AS/400.如果你正在使用  Fedora or RedHat Enterprise (5.3 以及更高版本),那么推荐你使用全局文件系统(GFS),GFS要求  使用集群锁协议,比如dlm(分布式锁管理器),这也是Linux内核的一个模块.

WHEN TO USE SHARED FILE SYSTEM MASTER/SLAVE

Using a shared file system is probably the best solution for providing high availability  for ActiveMQ to date. It combines the high throughput of KahaDB and the simplicity  that you get from using a shared resource. KahaDB is only limited by the performance  of the underlying shared file system. The only caveat is that you’re restricted to environments  that support distributed locking on a shared file system.

何时使用共享文件系统主/备机配置

到目前为止,使用共享文件系统应该是配置高可用性ActiveMQ的最好的解决方案了.该方案将KahaDB的高吞吐量  和使用共享资源的简单易用结合起来.KahaDB仅仅受到底层文件系统性能的限制.唯一的警告是,环境中使用的  共享文件系统必须支持分布式文件锁.

So ActiveMQ provides features to make it resilient to failures in production using  the shared nothing master/slave and the shared storage master/slave configurations.  You should now have a good understanding of the different ActiveMQ high availability  options and be able to choose the best configuration for your application’s needs.

ActiveMQ使用无共享主/备机配置和共享存储主/备机配置是的产品在应对失效的处理方案变得  富有弹性.现在,你应该十分消息配置高可用性ActiveMQ的各种选项了,并且能够根据你自己程序的  需要选择最好的配置.

The next section will examine how to use ActiveMQ to reliably pass messages from  broker to broker to support applications that need to use messaging to communicate  across geographically distributed locations. 

下一节将展示如何使用ActiveMQ可靠的将消息从一个代理传递到另一个代理,以便支持应用程序  进行横跨分布式地理区域的通信.