Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Introduction

  • Consider the wording: a Controller can be operated as a Standalone Controller instance or as a Controller Cluster. The term Controller instance refers to the standalone instance or to a Controller Cluster member instance.
  • The outage of a Controller instance will not stop the execution of workflows with an AgentAgents.
  • But However, if a workflow includes jobs that are executed on with different Agents then the workflow will not be executed completed and will be put on hold as the switching of Agents during workflow execution is done performed by the Controller.
  • Testing by SOS includes performing to perform tests for the scenario when the a Controller is not available for 24 hours and the Agent executes all any scheduled orders. When Once the Controller instance is started again then job execution results are updated to the JOC Cockpit History and become visible with the GUI.
  • For information about the behaviour behavior in case of outages see JS7 - FAQ - What happens to workflows in case of outage of a Controller?

Controller Cluster

If you operate a Controller Cluster then an automated fail-over takes place should the active Controller instance fail. A fail-over typically occurs within 3-5s. Should the standby Controller instance fail then this does not affect the active Controller instance. Running a JS7 high availability cluster gives you the relaxed option not to have to take immediate action if one of the instances fails. However, should you intend to immediately make available the failed Controller Cluster member instance then the steps explained below similarly apply to the failed instance.

The below troubleshooting hints are intended for users operating a Standalone Controller , the steps explained are not required for users operating a Controller Cluster.

Troubleshooting

The Controller is the component in JS7 that holds the job-related configurations and orchestrates the Agent. The outage of a Controller instance does not prevent the execution of workflows having the jobs running on a single agentAgent. However, it affects the execution of workflows which includes the that include jobs that are running on multiple agents as the a number of Agents as switching of Agents during the workflow execution is done performed by the Controller. 

The A Controller instance outage can be handled either by resolving the issue with the current Controller instance, e.g. by restarting, or by relocating the ./state directory to a different Controller provided that access to the same scripts and programs is available that should be executednew Controller instance. The journal of the a Controller instance is stored in the ./state directory. To relocate the a Controller instance to a different new Controller instance location copy the journal files to the target Controller instance.

Relocating the Controller Instance's Journal

If Controller1 ControllerInstance1 is facing an outage and Controller2 is running (on the same server or on a different server) then follow the below steps to relocate the Controller instance's journal from Controller1  ControllerInstance1 to Controller2a new ControllerInstance2:

  1. Shutdown Controller2Install ControllerInstance2
  2. Copy the files from the ./state folder of Controller1 ControllerInstance1 to the respective folder of Controller2 ControllerInstance2
  3. Start Controller2ControllerInstance2.
  4. Consider that the Controller URL is not the same for Controller1 ControllerInstance1 and Controller2 ControllerInstance2.   Therefore the URL has to be updated in the JOC Cockpit.
  5. To change the Controller URL, log in to the JOC Cockpit.
  6. From the main menu select the item "Manage Controllers/Agents".
  7. Make sure you edit the existing Controller  ControllerInstance which is not in service.
  8. Change Modify the "URL for JOC Cockpit Cockpit" from the "Register Controller" dialogue box for the Controller which instance that is not in service to point to the Controller2 ControllerInstance2 URL.
  9. When workflows are confirmed to work with Controller2 ControllerInstance2 then drop the contents of the ./state directory of Controller1 ControllerInstance1. This an important step as otherwise, when Controller1ControllerInstance1 is started it will not be able to find the events that were done by Controller2forward past orders from its journal to available Agents. This would result in double job execution that might be harmful depending on the nature of your jobs.


...


Notes:

  • If you use HTTPS connection for Controller instances then consider that ControlerInstance2 might need its own server authentication certificate. 
    • If ControllerInstance1 is operated for HTTPS then you can modify the protocol to HTTP and to point to a different host provided that this is in line with your security requirements.
    • The same applies vice versa if ControllerInstance1 is operated for HTTP and ControllerInstance2 is operated for HTTPS.
  • If you intend to roll back from

...

  • ControllerInstance2 to

...

  • ControllerInstance1 then consider

...

  • to apply the above steps respectively.