This section explains how the members of the cache cluster can be discovered. In many cases, the default multicast values in the provided engine property files work out of the box, with no configuration. Two methods are available: multicast, and well-known-addresses.Configuration instructions are provided in Configuring a Cache OM Cluster — Cluster Tab in TIBCO BusinessEvents Administration
When discussing cache clusters, BusinessEvents processing units are also referred to as nodes. The term node is used in the TIBCO BusinessEvents Cache Configuration Guide and in this section.With multicast cache cluster configuration, the cluster membership is established using the multicast IP address and port. When a BusinessEvents node subscribes to this multicast IP address it broadcasts information about its presence to the address.Multicast discovery is used by default. The default values provided mean you may not have to configure any discovery-related properties. However, if you deploy multiple BusinessEvents projects in your environment, you must specify different multicast address and port settings for each project.You can use multicast when processing units are deployed to hosts in the same subnet, or across subnets when broadcast is enabled between the subnets.The object management layer uses multicast to discover new nodes and add them to the cache cluster. Similarly when nodes are removed or moved to a different server, the multicast protocol ensures that members are kept current without any additional configuration.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 uses unicast as needed. Peer-to-peer connections are automatically established with other servers listening on the multicast address.When multicast is undesirable or unavailable, for example, if nodes are deployed to different subnets and broadcast between the subnets is not enabled, use "well-known-addresses" (WKA) instead.To use well-known-addresses you provide a list of IP addresses and ports in the CDD file (at the cluster level and, for each WKA machine, in one processing unit deployed to that machine).Any of these machines can be used by the cluster discovery protocol (instead of multicast broadcast). At least one of these machines must be running at any time so that others can join the cluster.It is not required that all the servers are active all the time. At least one of the servers in the well-known address list must be available, however, so that new cluster members can join the cluster when they start.Well-known-address configuration uses unicast communication for all types of messaging including acknowledgements and heartbeats.You must ensure that the WKA information is kept up to date on all deployed engines. If a machine changes name or IP address, cluster discovery continues to work correctly until the next time you restart that machine. (For a reference to the properties, see Well-Known Address Properties in TIBCO BusinessEvents Administration.)If a host machine has multiple network cards, you must specify which IP address and port to bind to. To do this you use localhost and localport properties. This is required for multicast and well-known-address cluster discovery.
Copyright © TIBCO Software Inc. All Rights Reserved.