You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »


Introduction

  • Relocating the Agent refers to the scenario when the Agent needs to be moved to either a new server or to a new location on the same server. The relocating of the agent will stop the execution of workflow for a certain time as we need to copy the contents of the ./state folder to the new agent.
  • Before copying the content we need to first stop the services for the Agent otherwise it will continue to update the journals. This is an important step; otherwise, Agent will execute the same workflows should it be started later on. This would result in double job execution that might be harmful depending on the nature of your jobs.
  • As the agent does not have any database connection so relocating the agent only requires copying the contents of the ./state directory and updating the URL of the Agent with the newly installed agent in the JOC.

Relocating an Agent

  • The relocating of Agent requires only moving the ./state directory of Agent and changing the URL from the JOC Cockpit Manage Controller/Agents view.
  • The./config folder for the Agent contains the trust-store and key stores so if the agent is running on HTTPS and if you want the new Agent also to run on HTTPS then the new server should have its own server authentication certificates.

Relocating the Agent's Journal

If Agent1 is facing an outage and Agent2 is running - on the same server or a different server - then follow the below steps to relocate the Agent's journal from Agent1 to Agent2:

  1. Shutdown Agent2.
  2. Copy the files from the ./state folder of Agent1 to the respective folder of Agent2. 
  3. Start Agent2.
  4. Consider that the Agent URL is not the same for Agent1 and Agent2.  Therefore the URL has to be updated in the JOC Cockpit.
  5. To change the Agent URL, login to the JOC Cockpit.
  6. From the main menu select the item "Manage Controllers/Agents".
  7. Make sure you edit the existing Agent1 which is not in service.
  8. Change the Agent1 URL to point to the Agent2 URL.
  9. When workflows are confirmed to work with Agent2 then drop or move the contents of the ./state directory of Agent1. This an important step as otherwise, Agent1 will execute the same workflows should it be started later on. This would result in double job execution that might be harmful depending on the nature of your jobs.



Notes:

  • If you use an HTTPS connection for Agents then consider that Agent2 might need its own server authentication certificate. 
    • If Agent1 is operated for HTTPS, you can modify the protocol to HTTP and point to a different host provided that this is in line with your security requirements.
    • The same applies vice versa if Agent1 is operated for HTTP and Agent2 is operated for HTTPS.
  • If you intend to roll back from Agent2 to Agent1 then consider applying the above steps respectively.


  • No labels