...

Agents can be clustered for high availability and scalability. Motivations The motivation for clustering includeincludes:

• High availability: Should a server node in the scheduling environment fail then jobs are executed with the Agents on remaining server nodes.
• Performance: A single Agent can execute thousands of jobs in parallel tasks, however, for a number of use cases it might be is preferable to distribute server load. This applies particularly to applications that require horizontal scaling across a number of server nodes instead of vertical scaling on a more powerful single server node.

Agent Clustering clustering is subject to the agreements of the JS7 - License and is available to commercial license holders. Cluster Agents receive license information from a Controller and do not require individual license keys, see JS7 - How to apply a JS7 License Key.

Use of Standalone Agents is available to Open Source License holders and to commercial license holders, for details see JS7 - Management of Standalone Agents.

Architecture

The architecture is explained with JS7 - Agent Cluster.

...

• The Operational Layer covers installation of Cluster Agents that is no different from installation of Standalone Agents. In addition it covers registration of Agents as members of an Agent Cluster.
• The Functional Layer is situated on top of the Operational Layer and defines a number of logical Agent Subagent Clusters.

Operational Layer

The architecture includes the clustering of Agents in the role of Director Agents for restart capabilities and the clustering of Agents acting as Subagents for high availability and scalability purposes.

• The components involved in an Agent Cluster are represented as one Agent to the Controller.
• A Controller can manage any number of Agents either from different Agent Clusters or as a number of Standalone Agents.

...

For Cluster Agents the following excerpt from the above list screenshot is used:

• In a first position the Primary Director Agent is available. Optionally a Secondary Director Agent can be available.
• Below the Director Agent entry the list of Subagents is displayed.
  
  

...

• The first group of input fields specifies the Agent Cluster:
  • Agent ID: A unique identifier of the Agent Cluster. Uniqueness is required for all Standalone Agents and Agent Clusters assigned a the same Controller. This identifier cannot be changed later on.
  • Agent Cluster Name: The name of the Agent Cluster as displayed in the JOC Cockpit GUI. The name can be changed at any later point in time.
  • Title: An individual description that later on can be searched for.
  • Alias Name: The same Agent Cluster can appear with a number of alias names. This allows to map use of different Agent Clusters, for example in a production environment, to use of fewer Agent Cluster using alias names in a test environment.
• The second group of input fields specifies the Primary Directory Director Agent:
  • Subagent ID: A unique identifier of the Subagent. Uniqueness is applied for all Director Agents and Subagents in the same Agent Cluster. This identifier cannot be changed later on.
  • Title: An individual description that later on can be searched for.
  • URL: The protocol HTTP or HTTPS, host name or IP address and port by which the Director Agent is accessible to the Controller.
• The third group of input fields specifies the Secondary Directory Director Agent should Directory Director Agents be clustered.

Note:

• Each Director Agent includes a Subagent that can be used for execution and that is automatically available for use with any Subagent Cluster.

Anchor
add_subagent add_subagent

Add Subagent

With the Agent Cluster being added users can then add further Subagents from the Agent Cluster's action menu:

...

• Subagent ID: A unique identifier of the Subagent. Uniqueness is applied for all Director Agents and Subagents in the same Agent Cluster. This identifier cannot be changed later on.
• Title: An individual description that later on can be searched for.
• URL: The protocol HTTP or HTTPS, host name or IP address and port by which the Subagent is accessible to the Director Agent.

Manage Subagent Cluster

Anchor
enable_disable_subagent enable_disable_subagent

Enable/Disable Subagent 

Subagents can be disabled and enabled. They are enabled by default.

• When a Subagent is disabled then it is no longer considered for job execution.
  • At the point in time of disabling the Subagent will continue to complete any tasks running for jobs.
  • No new tasks are added to a disabled Subagent.
  • The remaining Subagent(s) in the cluster will take on the load.
• When a disabled Subagent is enabled then it is automatically considered for next job executions.
• The assignment of Subagent Clusters that include a disabled Subagent to jobs in a workflow remains unchanged.
  • For clusters that include more than one Subagent the remaining Subagents will execute the jobs.
  • For Subagent Clusters that hold a single disabled Subagent any orders will wait for the Subagent to become available and enabled. When the Subagent is up and running, for example after a restart, and is enabled then orders will automatically continue in the workflow.

Disabling of Subagents can be used for example to manage maintenance windows on server nodes.

Anchor
deploy_agent_cluster deploy_agent_cluster

Deploy Agent Cluster

With the configuration of an Agent Cluster being completed the cluster can be deployed to its Controller.

• An Agent Cluster and its Subagent Clusters can be used only after deployment to a Controller.
• Changes to an Agent Cluster, for example if the Director Agent's URL is changed or if a Subagent is added or dropped, require to be deployed.
• Deployment of an Agent Cluster includes to deploy any Subagent Clusters configured for the Agent Cluster. However, Subagent Clusters can be deployed individually, see chapter: Deploy Subagent Cluster.

Anchor
manage_subagent_cluster manage_subagent_cluster

Manage Subagent Cluster

Subagent Clusters are The Subagent Cluster is situated in the Functional Layer and includes include specification of logical clusters that make use of Subagents.

...

• The view displays the list of available Subagent Clusters.
• The indicated status signals that the Subagent Cluster has been deployed or has not not been deployed.
• The indicated synchronization status signals that the definition of the Subagent Cluster in the JS7 inventory and the version deployed to the Controller are in sync.
  
  

...

The  buttons in the right upper corner allow to toggle between the list view and the card view of Subagent Clusters:

Anchor
bulk_subagent_clusters bulk_subagent_clusters

Bulk Operations on Subagent Cluster

For the list view and card view of Subagent Clusters when When the checkboxes available with each Subagent Cluster are checked then buttons for the following bulk operations become available:

• Revoke: The Subagent Cluster is revoked from the Controller, i.e. the deployment is undone. The definition of the cluster remains in place and can later on be deployed once again.
• Delete: The Subagent Cluster is deleted from the Controller and from the JS7 inventory. This operation cannot be undone.
• Deploy: The Subagent Cluster is forwarded to the Controller and can be used for assignments to jobs.
  
  

Anchor
add_subagent_cluster add_subagent_cluster

Add Subagent Cluster

To add a Subagent Cluster the Create Subagent Cluster button can be used.

...

If the next Subagent is dropped to the area right to the existing Subagent then a cluster with round-robin scheduling mode is created:

Anchor
deploy_subagent_cluster deploy_subagent_cluster

Deploy Subagent Cluster

With the configuration of a Subagent Cluster being completed the cluster can be deployed to its Controller.

• A Subagent Cluster can be used only after deployment to a Controller.
• Changes to an Subagent Cluster, for example if a Subagent is added or removed from a cluster, require to be deployed.
• Deployment of Subagent Clusters can be performed individually and from bulk operations, see chapter: Bulk Operations on Subagent Clusters.
• When deploying an Agent Cluster then this includes to deploy any available Subagent Clusters, see chapter: Deploy Agent Cluster.

The operation to deploy a Subagent Cluster is available from the Deploy button in the right upper corner:

Image Added

Anchor
organize_subagent_cluster organize_subagent_cluster

Organize Subagent Clusters

Users have a number of options to organize their Subagent Clusters:

• For each Subagent JOC Cockpit automatically adds a cluster that holds the single Subagent.
  • This allows to assign an individual Subagent to a job should the job be executed with this Subagent only.
  • This Subagent Cluster is not visible and cannot be modified by users.
  • The name of the Subagent Cluster corresponds to the Subagent ID.
• Any number of Subagents can be added to a cluster.
  • Adding more Subagents to a round-robin cluster allows unlimited horizonal scaling.
  • Some might consider it paranoid to add a larger number of Subagents to a fixed-priority cluster, however, users are free to create a chain of Subagents that can replace each other.
• Subagents can be added for both fixed-priority and round-robin scheduling modes within the same cluster.

Users can add the Director Agent to their Subagent Clusters:

• The Primary and Secondary Director Agents each include a Subagent that can be used to execute jobs.
• The Director Subagent can be added to any Subagent Clusters.
• Users can decide not to use the Director Agent for job execution but for orchestration of Subagents only in order to guarantee the highest level of robustness.

Users can apply different strategies to manage operational Agent Clusters and functional Subagent Clusters.

...