Users Guide

Verifying Clustered Installations | Clustering
OMNM 6.5.3 Installation Guide 131
Mediation Behavior and Polling
When you set up a mediation cluster to do polling, one server in the cluster does the all the polling.
If the active server goes down, another resumes polling. A High Availability mediation setup
duplicates the backlog of collected data that has not been posted to database in this standby server.
In this case, installation requires redundant messages from devices to all servers in the cluster.
If the active mediation server goes down, you may lose one interval to re-establish starting values
for computations about the changes (deltas) from previous polling. As always, data replication may
impact performance.
Database Server Configuration
Custom installation lets you select the database server from a screen in the installer. When the
database resides on its own server, you must remove all enabled startup services from that database
server—this includes application server and mediation agent.
NOTE:
Make backups before altering files.
Configuring the Cluster’s Multicast Address
The installation process sets this application’s multicast address automatically. Multicast must
handle the communication between elements of a cluster—whether application or mediation
servers. You can disable multicast discovery of servers (mediation server to application server) or
clients (client to application server[s]) as described in
Disabling Multicast on page 111.
The range for multicast as defined by the
Host Extensions for IP Multicasting [RFC1112] is from
224.0.0.0 to 239.255.255.255. The following is an excerpt from the article
Internet Multicast
Addresses
that should be considered when assigning addresses:
“The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is reserved for the use of
routing protocols and other low-level topology discovery or maintenance protocols, such as gateway
discovery and group membership reporting. Multicast routers should not forward any multicast
datagram with destination addresses in this range.”
Use an address above 225.0.0.0, like the one cited in the example above.
Application servers in a cluster use multicast to determine when a peer has come up or when one
goes down. This communication usually has to be done in a matter of seconds or even milliseconds
and should probably be exclusive on the multicast channel chosen. In other words, best practice is
to use a multicast address exclusively for a cluster. Do not use the same multicast address for two
clusters and do not use the same multicast for other multicast communication.
If a cluster member asks a running peer to respond but the traffic on the channel prevents a
response within the designated timeout, then the requesting member concludes the running peer is
gone and takes appropriate fail-over action, even if the peer is running without problem. This can
be the source of undesirable behavior from your cluster. For example, it could initiate the rule
resynchronization process on the cluster.