Skip to content

Using Application Clustering

Assure1 provides clustering capabilities within most metric applications to utilize redundancy and/or the distributed processing of data. Clustering can be setup for multiple instances of an application on a single server, or distributed clustering of applications across multiple servers. This article shows how to enable clustering for Broker Services.

Dependencies

  • The application must be available on all servers that will be running the clustered service.

  • The Cluster ID value must be the same in all Service configurations that will be used by the applications in the cluster.

  • Only applications that poll data can be clustered (for example, the Generic SNMP Poller). Applications that receive data (for example, event list aggregators) can not be clustered.

Best Practices

  • During initial deployment, make sure the application configuration has the LogLevel set to DEBUG. After functionality has been verified, this can be changed to reduce log data.

  • The health status of each application can be viewed under the Assure1 metric tab. If the application was configured to be run on different servers, each application has separate health status metrics saved on each server used in the cluster. Via the Devices navigation pane, click on the Assure1 server. In the Metrics section, select the Assure1 Health tab.

Starting a Clustered Service

The following process is followed when starting a clustered service.

  1. Applications are assigned an internal identifier.

  2. Devices to be polled are divided evenly among and assigned to the available applications.

  3. Before starting a poll cycle, the application will check for a broker message and perform any reconfiguration, if necessary (e.g. if a broker is down).

  4. Periodically the broker will trigger a configuration check and if there are changes, the cluster will reconfigure:

    • Devices that are no longer being polled are removed from the applications they were assigned.

    • New devices to be polled are distributed among the applications and assigned to them, taking into account the current device count of each of the applications to load balance.

    • Notes:

      • Unchanged devices will continue to be polled by the same instance.

      • If an individual service in a cluster is restarted, the entire cluster will completely re-balance the device pool regardless if any devices have been changed. When this occurs, individual applications may begin polling different devices.

Creating a Ping Poller Cluster

The following steps can be used to create a Ping Poller Cluster.

  1. Determine how many application instances will be in the cluster, and which Servers will be running each instance.

  2. Create a Service entry for each of the applications that will be added to the cluster on the Services UI. A separate entry is required for each instance of the application in the cluster. Additional configuration considerations:

    • Make sure to set the correct application configuration for each application.

    • Set Failover Type to Cluster.

    • Set Cluster ID to be the same value for all of the individual Service configurations.

    • Be sure to enter the correct DeviceZoneID.

    • Make sure to set the correct amount of Threads. Do not exceed 8 * total number of cores for total threads. The number of DB threads created will be 1/3 this number unless manually set to a different value.

  3. Start each instance of the application across the cluster.

  4. Verify application functionality and review the application logs to see if any errors occur. The log files can be viewed in the CLI in the $A1BASEDIR/logs/ directory, or from the Logs UI.