About Operations Controllers in a Clustered Installation

Each application server component has an operations controller, which provides local and remote interfaces for controlling a server component and inquiring about its status.

Using JNDI, server components on the same node or different nodes can directly communicate to all operations controllers. Sterling B2B Integrator provides a command line tool for running operations commands for automating the operations.

Role of the Central Operations Controller in a Clustered Installation

The Central Operations Controller provides a single point of contact for all cluster operations, and communicates with the operational controller on each cluster node VM to coordinate operations. The Central Operations Controller runs on a separate JVM. There is one Central Operations Controller for each cluster node instance.

During startup, the Central Operations Controller coordinates the operations of the local cluster node startup and its corresponding components, such as the Service Controller and the Scheduler.

Features of the Central Operations Controller include:
  • A heartbeat mechanism that provides support for central operations failover and node status update.
  • Token nodes, which allow individual nodes to assume the role of being the Central Operations Controller.

Central Operations Controller Heartbeat Mechanism

The heartbeat thread interrogates the cluster nodes to obtain status updates and identify new members. It runs in the same JVM as the Central Operations Controller. It is started inside the Central Operations Controller when it registers itself as part of the startup procedure. It updates its local cache of node status that is used for communicating with cluster nodes.

When the cluster node, along with its Central Operations Controller, is fully up and running, the heartbeat thread detects the presence of other nodes and registers the identity and status of other cluster nodes to the Central Operations Controller. From that point on, each Central Operations Controller connects to all the nodes in the cluster and is ready to service requests.

Central Operations Controller Token Node

Each node running a Central Operations Controller can assume the role of being the Central Operations Controller at any time. This is managed by a token. The ownership and passing of the token are mediated through the database.

One of the Central Operations Controllers in the cluster holds a token that identifies that controller as the master Central Operations Controller. The Central Operations Controller with the token is responsible for coordinating recovery if a node fails. The Central Operations Controller that possesses the token when it detects a node failure does the following:
  1. Releases locks placed by the failed node.
  2. Initiates automatic scheduler jobs failover. That is, it identifies another active node that can take the jobs from a failed node.

If the failed node is the token-possessing Central Operations Controller, the Central Operations Controller on an active node takes over the token and performs the operations of a token node. This operation ensures that only a single node holds the token at one time.

This arrangement provides for automated failover of the Central Operations Controller and enables operations to be distributed across the cluster.