Gateway Running Script Redundancy

Hello,

I have a long running script that is triggered by a tag change event on a memory tag. I want to see if there is a way of perpetuating the functionality of this script even if our master gateway goes down (e.g. software upgrade).

My first thought is to run the script on the master and the backup in parallel. Is there a way to run a script on both servers?

Any other ideas to make sure this script has running redundancy?

As far as I know, you can not run scripts on a backup server.

If the service that is executing the script fails, I’m pretty sure all bets are off at that point.

SFCs can handle failover to a backup gateway pretty seamlessly:
https://docs.inductiveautomation.com/display/DOC81/Sequential+Function+Charts#SequentialFunctionCharts-SFCRedundancy

Thanks that is good to know but I doubt it would work for what I am doing in my script (listening to an event stream over socket communication), the only way I can see me achieving redundancy is to run the script in parallel on both servers.

You should have a gateway timer event script that performs a heartbeat operation for the long-lived thread. The running script should exit when that heartbeat isn’t happening. The heartbeat script should be smart enough to start the long-lived thread if/when it isn’t running. In a switchover, the event on the newly active backup will begin firing, and can start your long-lived thread. If the newly inactive master is still alive, its heartbeat event will stop, and its thread should notice and kill itself.

1 Like

Thanks Phil, I was thinking about something like this, the only problem is that when you first connect to the socket, the server of the event stream first gives you a download of it’s machine’s state (which can take 10-20 seconds) and so if the script ends unexpectedly and is restarted, it will take that amount of time before it actually becomes useful again and so the switchover will not be seamless. May be the best I can get it within the Ignition platform though.

Ignition’s switchover isn’t seamless anyways.

If the target can support two connections, consider creating a driver. A driver can hold a connection open in a “warm” backup. You would have to manage all of the state in the driver, though, no scripting at all.