IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Configuring the global cache for multi-instance brokers

You can configure the global cache to withstand software or hardware failures so that it is available for as much time as possible. Configure a multi-instance broker to host container servers by using an XML policy file.

Before you start:

For more information about the default global cache topology, see Data caching overview.

You can configure the global cache so that a multi-instance integration node hosts up to 4 container servers. If the active integration node instance fails, the standby integration node instance starts, and the container servers start up successfully within that integration node. As long as there is an active catalog server running elsewhere, the container servers rejoin the global cache. This mechanism does not allow a single-integration node cache to retain cached data on failover to a standby integration node instance

Consider the following example. Your global cache consists of 2 brokers that host catalog servers and container servers, and a multi-instance broker. The active instance of the multi-instance broker hosts up to 4 container servers. If the active instance of the multi-instance broker fails, the cache will remain operational as long as at least one of the catalog servers is still available. Data is temporarily rebalanced across the remaining container servers in the brokers that host the catalog servers. When the standby instance of the multi-instance broker starts, the container servers rejoin the global cache, and cached data is rebalanced automatically.

A multi-instance broker cannot host a catalog server. Therefore, you cannot configure an integration server to host a catalog server if that integration server is defined with multiple listener hosts.

A sample XML policy file is provided as a starting point for your configuration. The policy_multi_instance.xml file configures three brokers in a high availability scenario. Two brokers each host a catalog server, and a multi-instance broker hosts two container servers.

To configure a multi-instance broker, a listenerHost element has been introduced as an alternative to the listenerHost attribute of the broker element. You can use the listenerHost element to specify a list of listener hosts. Alternatively, you can set the listenerHost property on the integration server to a comma-separated list of listener hosts.

The following steps describe how to configure the global cache for a multi-instance broker.

  1. Copy the sample policy file, policy_multi_instance.xml, from install_dir/sample/globalcache to another location on your file system.

    Do not edit the sample policy file in its original location; copy it to your own file system first. The original sample policy file might be replaced when you apply maintenance to IBM Integration Bus. You can place a copy of the same policy file on each computer where a broker is running, or you can provide a single copy of the policy file in a shared file system for all brokers to access. No matter how the file is shared between two computers, the policy file must be placed on the same file path on each computer or shared system.

  2. Modify the policy file for your system, specifying the appropriate broker names and listener hosts, the port range that the broker is to use, and how many catalog servers the broker hosts. Optionally, you can also specify a domain name for all catalog servers in the embedded cache. If you do not set a domain name, the broker creates one.
    Ensure that the policy meets the following criteria:
    • You can define 0, 1, or 2 catalog servers for an individual broker, but at least one catalog server must be defined in the policy.
    • A multi-instance broker cannot host a catalog server.
    • You cannot specify the listenerHost element more than once for a broker that is configured to host one or more catalog servers.
    • If two brokers share a host name, you must set a distinct port range for each broker.
    • Ensure that the port range for each broker includes at least 20 ports.
    • The broker names and listener hosts specified in the policy must match the values defined for the brokers.
    • You must specify either the listenerHost element or the listenerHost attribute for each broker.
    • You can define only one domain name in the policy file.
    • If specified, the domain name must precede the broker elements in the policy file.
    • The policy file must be encoded in UTF-8.
    • The policy file must contain valid XML. The policy file is validated against an XML schema when you set the broker-level property. You can also validate the policy file against the copy of the schema (policy.xsd) that is provided in install_dir/cachesupport/schema.
    When you use an XML policy file, the broker-level portRange property is ignored. The port range specified in the XML file overrides the property specified for the broker.
  3. Save the policy file.
  4. Set the cache policy to the fully qualified name of the policy file.

    The path that you specify must be absolute, not relative. If you use a shared drive on Windows, you must use the \\hostname\directory path syntax to the shared drive, instead of a mapped drive letter. The IBM Integration Bus user ID that is used to access the \\hostname\directory path must have read access to the file system and must use the same password.

    You can set the cache policy by using commands (see Configuring the embedded global cache by using commands) or IBM Integration Explorer (see Configuring the embedded global cache by using IBM Integration Explorer).

  5. Restart each broker.
When each broker restarts, it uses the values in the policy file to determine its cache properties. If multiple listener hosts are specified, the global cache tries to bind to each one in turn until it finds one that is available on the system. If the global cache does not find a listener host that is available on the system, it uses the first listener host in the list.
Each broker contains up to 4 container servers. To find out where container servers are placed, use the mqsicacheadmin command to run the showPlacement command, as shown in the following example:
mqsicacheadmin brokerName -c showPlacement
You can also use the mqsicacheadmin command to show cache components in a multi-broker cache. For example, the listHosts command shows the host names, number of hosts, and number of catalogs in the cache:
mqsicacheadmin brokerName -c listHosts

be23815_.htm | Last updated Friday, 21 July 2017