Chapter 19 Configuring Cache Cluster Discovery : Cache Cluster Discovery Overview

Cache Cluster Discovery Overview
This chapter explains how the members of the cache cluster are defined. In many cases, the default multicast values in the provided engine property files work out of the box.
The chapter provides details about how you can specify members in different ways if the default multicast configuration is not appropriate for your environment.
For AIX only  You must add the following property to all engine property files (be-engine.tra) files:
Cluster Member Discovery Using Multicast Discovery
Multicast discovery is used by default. A set of default values mean you may not have to configure any discovery-related properties other than cluster name. However, if you deploy multiple projects, you must specify different multicast address and port settings for each.
You can use multicast when instances of an application are deployed to hosts in the same subnet, or across subnets when broadcast is enabled between the subnets.
Multicast requires less maintenance than the well-known-address method of cluster configuration. For example, with multicast you don’t have to update the property files after moving a deployed node (engine) to another machine.
As an alternative you can use well-known addresses for discovery. See Discovering Cache Cluster Members Using Well-Known-Addresses.
Also see Discovery When Hosts Have Multiple Network Cards.
Network Traffic
When multicast discovery is used, network traffic is generated by the following activities:
Cluster heartbeat  The most senior member in the cluster issues a periodic heartbeat using multicast. The rate is configurable and defaults to one per second.
Message delivery  Messages intended for multiple cluster members are often sent using multicast, instead of unicasting the message one time to each member.
For peer-to-peer communications and data transfer, the object management layer then uses unicast as needed. Peer-to-peer connections are automatically established with other servers listening on the multicast address.
Cluster Member Discovery Using Well-Known-Addresses
Well-known-address configuration uses direct member-to-member (point-to-point) communication, including messages, asynchronous acknowledgements (ACKs), asynchronous negative acknowledgements (NACKs) and peer-to-peer heartbeats. The addresses are "well known" to the extent that they are known to each server in the cluster.
Use well-known-addresses instead of multicast to define the cluster participants when multicast is undesirable or unavailable, for example, if nodes are deployed to different subnets and broadcast between the subnets is not enabled.
Also see Discovery When Hosts Have Multiple Network Cards.
Overriding and Adding Cluster Configuration Properties
Operational settings for the cache cluster are provided in the operational descriptor, tangosol-coherence.xml, provided in BE_HOME/lib/ext/coherence.jar.
For details on all the settings in this file, see the online reference, TIBCO BusinessEvents Cache Configuration Guide, which is available from the HTML documentation interface.
If you need to use different values than are provided in the operational descriptor, you do not make any changes in the tangosol-coherence.xml file itself. Engine properties and (as needed) override files enable you to override and extend the settings in the operational descriptor file.
See Overriding and Extending the Operational Deployment Descriptor for information about using system-property attributes in the operational descriptor to create new engine properties.
See Specifying Operational Override File Locations for details about using override files.