10.1 配置 高可用性 ActiveMQ

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 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.

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.

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

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.

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

? remoteURI —代理主机监听的URI

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

<services>
<masterConnector
remoteURI="tcp://remotehost:62001"
</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.

Table 10.1 Slave broker properties

Property name Default value Description
shutdownOnMasterFailure  false  The slave will shut down when the master does.

表10.1 备机代理可配置属性

shutdownOnMasterFailure  false  The slave will shut down when the master does.

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.

Table 10.2 Master broker properties

Property name Default value Description
waitForSlave  false  The master won’t allow any client or network connections until a slave has attached itself.
shutdownOnSlaveFailure false If true, the master will shut down if a slave becomes detached. This ensures that a slave is only ever in sync with the master.

Property name Default value Description
waitForSlave  false  如果配置为true,则主机代理在备机连接好之前,步接收任何客户端和网络连接
shutdownOnSlaveFailure false 如果配额为true,则与备机失去连接后,主机代理会自动关闭.这样就保证了备机与主机永远是同步的.

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 共享存储主/备机配置

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.

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.

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.

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.

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.

微信赞赏  支付宝赞赏