Configuring Clusters
You define a cluster by specifying cluster configuration properties for each of its member brokers. These properties are discussed below under Cluster Configuration Properties and are described in detail in Table 14–10.
Setting the Cluster Configuration
Like all broker properties, the cluster configuration properties can be set individually for each broker in a cluster, either in its instance configuration file (config.properties) or by using the -D option on the command line when you start the broker. For example, to create a conventional cluster consisting of brokers at port 9876 on host1, port 5000 on host2, and the default port (7676) on ctrlhost, you could include the following property in the instance configuration files for all three brokers:
imq.cluster.brokerlist=host1:9876,host2:5000,ctrlhost
Notice, however, that if you need to change the cluster configuration, this method requires you to update the instance configuration file for every broker in the cluster. For consistency and ease of maintenance, it is generally more convenient to collect all of the shared cluster configuration properties into a central cluster configuration file that all of the individual brokers reference. This prevents the settings from getting out of agreement and ensures that all brokers in a cluster share the same, consistent configuration information. In this approach, each broker’s instance configuration file must set the imq.cluster.url property to point to the location of the cluster configuration file: for example,
imq.cluster.url=file:/home/cluster.properties
The cluster configuration file then defines the shared configuration properties for all of the brokers in the cluster, such as the list of brokers to be connected (imq.cluster.brokerlist), the transport protocol to use for the cluster connection service (imq.cluster.transport), and optionally, for conventional clusters, the address of the master broker (imq.cluster.masterbroker). The following code defines the same conventional cluster as in the previous example, with the broker running on ctrlhost serving as the master broker:
imq.cluster.brokerlist=host1:9876,host2:5000,ctrlhost imq.cluster.masterbroker=ctrlhost
Cluster Configuration Properties
As shown above, the most important cluster configuration property in a conventional cluster is imq.cluster.brokerlist, a list of broker addresses defining the membership of the cluster; all brokers in the cluster must have the same value for this property. (By contrast, high-availability clusters are self-configuring: any broker configured to use the cluster’s shared store is automatically registered as part of the cluster, without further action on your part. If imq.cluster.brokerlist is specified for an HA broker, it is ignored and a warning message is logged at broker startup.)
Additional cluster configuration properties include the following:
-
imq.cluster.ha is a boolean flag specifying whether the broker is a high-availability broker.
-
imq.cluster.url specifies the location of the cluster configuration file, if any.
-
imq.cluster.hostname gives the host name or IP address for the cluster connection service, used for internal communication between brokers in the cluster. This setting can be useful if more than one host is available: for example, if there is more than one network interface card installed in a computer.
-
imq.cluster.port gives the port number for the cluster connection service. You might need to set this property, for instance, to specify a static port number for connecting to the broker through a firewall.
-
imq.cluster.transport specifies the transport protocol used by the cluster connection service, such as tcp or ssl.
-
imq.cluster.masterbroker (conventional clusters only) designates which broker (if any) is the master broker that keeps track of state changes.
-
imq.cluster.clusterid (HA clusters only) gives the cluster identifier, which will be appended to the names of all database tables in the cluster’s shared persistent store. The value of this property must be the same for all brokers in a given cluster, but must be unique for each cluster: no two running clusters may have the same cluster identifier.
Caution – While the hostname and port properties can be set independently for each individual broker, all of the other properties listed above must have the same values for all brokers in the cluster. In addition, in an HA cluster, you must specify a unique broker identifier for each broker by setting the broker’s imq.brokerid property (see Table 14–1); this value must be different for each broker in the cluster.
Brokers in a high-availability cluster have additional properties relating to persistent store configuration, failure detection, and takeover, which are discussed in the following sections.
JDBC Configuration Properties for HA Clusters
The persistent data store for an HA cluster is maintained on a high-availability database server, using the Java Database Connectivity (JDBC) API (see JDBC-Based Persistence). All brokers belonging to such a cluster must therefore have their imq.persist.store property (see Table 14–4) set to jdbc. The remaining persistent store properties are discussed under JDBC-Based Persistence and summarized in Table 14–6.
The database server may be Sun’s own High Availability Database (HADB) server, or it may be an open-source or third-party product such as Apache Software Foundation’s Derby (Java DB) or Oracle Corporation’s Real Application Clusters (RAC). As described in JDBC-Based Persistence, the imq.persist.jdbc.dbVendor broker property specifies the name of the database vendor, and all of the remaining JDBC-related properties are qualified with this vendor name: for instance, when using Sun’s HADB for the HA server, the Java class name of the JDBC driver is specified by a property named imq.persist.jdbc.hadb.driver.
Note –
If the integration between Message Queue and Application Server is local (that is, there is a one-to-one relationship between Application Server instances and Message Queue message brokers), the Application Server will automatically propagate these properties to each broker in the HA cluster. However, if the integration is remote (a single Application Server instance using an externally configured broker cluster), then it is your responsibility to configure the needed properties explicitly for each broker.
After setting all of the needed JDBC configuration properties for the brokers in an HA cluster, you must also install your JDBC driver’s .jar file in the appropriate directory location, depending on your operating-system platform (as listed in Appendix A, Platform-Specific Locations of Message Queue Data) and then execute the Database Manager command
imqdbmgr create tbl
to create the database schema for the HA persistent data store.
Failure Detection and Takeover Properties for HA Clusters
The following configuration properties (listed in Table 14–10) specify the parameters for the exchange of heartbeat and status information within an HA cluster:
-
imq.cluster.heartbeat.hostname gives the host name (or IP address) for the heartbeat connection service.
-
imq.cluster.heartbeat.port gives the port number for the heartbeat connection service.
-
imq.cluster.heartbeat.interval defines the interval, in seconds, at which heartbeat packets are transmitted.
-
imq.cluster.heartbeat.threshold specifies the number of missed heartbeat intervals after which a broker is considered suspect of failure.
-
imq.cluster.monitor.interval defines the interval, in seconds, at which to monitor a suspect broker’s state information to determine whether it has failed.
-
imq.cluster.monitor.threshold specifies the number of elapsed monitor intervals after which a suspect broker is considered to have failed.
Smaller values for these heartbeat and monitoring intervals will result in quicker reaction to broker failure, but at the cost of reduced performance and increased likelihood of false suspicions and erroneous failure detection.
Displaying the Cluster Configuration
To display information about a cluster’s configuration, use the Command utility’s list bkr subcommand:
imqcmd list bkr
This lists the current status of all brokers included in the cluster to which a given broker belongs, as shown in Example 8–1 (for a conventional cluster) or Example 8–2 (for an HA cluster).
Example 8–1 Configuration Listing for a Conventional Cluster
|
Example 8–2 Configuration Listing for an HA Cluster
|
- © 2010, Oracle Corporation and/or its affiliates