The global cache is embedded in the broker. You can also connect to an external WebSphere® eXtreme Scale grid.
The embedded cache has a default single-broker topology and can be used by message flows running in any integration server on the broker, without any configuration. However, you can switch off the default topology by selecting a broker policy of none, and set properties explicitly for each integration server.
The following diagram shows the embedded global cache in a broker that contains six integration servers. Four integration servers host components for the global cache, but message flows in all six integration servers can use the cache.
The following diagram shows a multi-broker embedded cache, which is configured by the broker policy file policy_two_brokers_ha.xml.
The following diagram shows how IBM® Integration Bus can connect to both an embedded cache and an external WebSphere eXtreme Scale grid. A configurable service is used to connect to the external grid.
IBM Integration Bus has a default cache policy that creates a default topology of cache components in a single broker. The default topology puts catalog servers and container servers in integration servers dynamically so that the cache is available for use by all integration servers in the broker. Broker-level properties are available to specify a range of ports, and a listener host for the default topology. The broker sets a range of ports to use, but you can specify a particular range of ports by using the cachePortRange parameter. You can use the listenerHost parameter to specify the listener host that is used by the cache components. If your computer has more than one host name, setting the listener host ensures that the cache components use the correct host name.
If you set the cache policy to none, you must set the integration server properties explicitly. The properties that were set most recently by the broker-level policy are used as a starting point. Therefore, if you set the cache policy to default first, then switch to none, the default topology properties are retained.
You can configure the global cache to span multiple brokers by setting the cache policy to the fully qualified name of an XML policy file. This policy file lists the brokers that share the cache, and for each broker specifies the listener host, port range, and the number of catalog servers hosted. You can use the policy file to set up a single broker that hosts two catalog servers. If one catalog server is stopped, the broker switches to the other catalog server, ensuring that no cache data is lost. You can also use the policy file to configure a multi-instance broker to host more than one container server. If the active instance of the multi-instance broker fails, the global cache switches to the container server in the standby instance.
If you set the cache policy to disabled, all cache components in the broker are disabled. The disabled policy is the default setting.
For more information, see Configuring the embedded global cache and Parameter values for the cachemanager component.
In the default topology, one integration server in the broker hosts a catalog server, and up to three other integration servers in that broker host container servers. All integration servers can communicate with the global cache, regardless of whether they are hosting catalog servers, container servers, or neither. Each integration server contains a cache manager, which manages the cache components that are embedded in that integration server. When you turn off the default topology, configure the integration servers by setting the parameter values for the cachemanager component.
For more information, see Configuring the embedded global cache and Parameter values for the cachemanager component.
You can host more than one container server in a multi-instance broker. If the active instance of the multi-instance broker fails, the global cache switches to the container server in the standby instance.
To avoid losing cache data when a catalog server is lost, use a policy file to specify more than one catalog server for a broker. For example, if you specify two catalog servers for a single broker, if one catalog server fails, the broker switches to the other catalog server. If the cache is shared by two brokers, each of which hosts a catalog server, if one catalog server fails, the brokers switch to the remaining catalog server. Having more than one catalog server can affect startup time until the cache is available. If you have more than one catalog server, you must start at least two of them for the cache to be available. When you configure a cache across multiple brokers with multiple catalog servers, if you need to start one broker before the others then you can configure this broker to host two catalog servers. You cannot host catalog servers in a multi-instance broker.
By default, each server starts with a domain name that is derived by the broker. In previous versions of IBM Integration Bus, the domain name for all WebSphere eXtreme Scale servers in all embedded caches was an empty string. Servers in different domains cannot collaborate in the same grid. Therefore, for a cache that spans more than one broker, migrate those brokers at the same time.
The cache uses WebSphere eXtreme Scale dynamic maps. Any map name is allowed, apart from names that begin with SYSTEM.BROKER, which is reserved for use by the broker. The default map is named SYSTEM.BROKER.DEFAULTMAP; you can use or clear this map.
You can use resource statistics and activity trace to monitor the status of the global cache and external grid, and to diagnose problems. You can also administer the embedded global cache by using the mqsicacheadmin command.