Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

MID Server cluster configuration

Log in to subscribe to topics and get notified when content changes.

MID Server cluster configuration

MID Server clusters enable multiple MID Servers with the appropriate capabilities to be grouped together for load balancing and fail-over protection.

External data sources

For performance and reliability reasons, these data sources should not be used with MID Server clusters:
  • LDAP
  • Export sets
  • JDBC data sources

These external data sources should only be used with dedicated MID Servers.

Note: If a MID Server in a cluster fails, the fail-over MID Server starts over at the beginning of the ECC queue task even if much of the information from the JDBC data source was already returned. This can result in duplicate data.

How clusters work

MID Servers in clusters must be able to connect to the instance and to all the devices with which they are expected to communicate. If all MID Servers in a cluster are down, the discovery is canceled. Make sure all the MID Servers are added to any Access Control List (ACL) in use. MID Server clusters are managed by a business rule called MID Server Cluster Management, which checks to see if the MID Server assigned to a job in the ECC Queue belongs to a cluster.

Load balancing

If the cluster business rule determines that a MID Server is part of a load balancing cluster, the application using the MID Server automatically balances the work between the MID Servers in that cluster. It is good practice to put MID Servers with the same capabilities in a load balancing cluster.

Fail-over protection

MID Servers in a fail-over cluster each have a configured order that the platform uses to determine which MID Server to use next in case of failure. MID Servers in a fail-over cluster work independently and do not load balance with other MID Servers in that cluster (although they might also be members of load balancing clusters). When a MID Server fails, the MID Server Cluster Management business rule selects the highest available MID Server in the order to take over the work. The selected MID Server checks the ECC Queue and starts with jobs that are either Processing or Ready.

Note: MID Server clustering does not supported the ECC queue topics Command or SystemCommand. If these commands are received, the clustered MID Servers do not redirect the ECC queue to another MID Server. The ECC queue records stay on the ECC queue without being processed.
Configure a fail-over MID Server with at least the same capabilities as the MID Server it is intended to relieve.
Note: If a MID Server fails while the Shazzam probe is running and auto-selection is configured, failover is not available. The Shazzam discovery stops. Discovery does not automatically choose another MID Server.

MID Server cluster event

The following event is triggered when the platform cannot find a MID Server with the appropriate capabilities to replace a MID Server in a fail-over cluster. Use this event to create an email to notify appropriate users that the cluster has failed.

Table 1. MID Server cluster event
Event Table Description Business Rule
mid_server.cluster.down MID Server Cluster [ecc_agent_cluster] A MID Server cluster has failed MID Server Cluster Management

Combining clusters

A MID Server can be added to both types of clusters at the same time. This diagram shows a scenario in which a MID Server from a load balancing cluster (MID Server D) is also present in a fail-over cluster. If MID Server D fails, MID Server E in the failover cluster is available to the load balancing cluster to perform the tasks previously assigned to MID Server D.

MID Server failover example

Specifying a specific MID Server cluster

You can specify a specific MID Server cluster for a Discovery schedule. The discovery process uses that cluster only. You cannot chain clusters or specify a single MID Server that belongs to multiple clusters.