Running two instances of FFAStrans (local and remote cluster)

[veks]

Hi,
is it possible to run two instances of FFAStrans as a service where:
1st FFAStrans.exe is being run from local C:/ folder - (not a cluster) only one machine
2nd FFAStrans.exe is being run from remote VM server with it's own workflows - cluster, several machines

Or it's only possible to run them one at a time?
Is it possible to have two FFAStrans services for both FFAStrans installations?

And if there's no way to have two of FFAStrans separate Windows services, what would be the easiest way to switch from local when needed and back to remote?

Thanks!

[emcodem]

Hey veks,

it's currently not possible to run 2 different ffastrans on the same OS in paralell.
The easiest way depends on what you define to be easy You'd have to disable all watchfolders and such and wait for all jobs to finish before you stop the service of ffastrans #1 and manually start up #2. The option "Enable local workflow processing as application" should be stored with the unique configuration file of both ffastranses and i don't think there are other problems to expect.

I'd not do this on a productive instance. Might i ask what's your reason to do this instead of just firing up another VM for ffastrans #2?

[veks]

Hey veks,

it's currently not possible to run 2 different ffastrans on the same OS in paralell.
The easiest way depends on what you define to be easy You'd have to disable all watchfolders and such and wait for all jobs to finish before you stop the service of ffastrans #1 and manually start up #2. The option "Enable local workflow processing as application" should be stored with the unique configuration file of both ffastranses and i don't think there are other problems to expect.

I'd not do this on a productive instance. Might i ask what's your reason to do this instead of just firing up another VM for ffastrans #2?

It's kinda complicated to explain.
But I'll try.

Our main server room will be without the internet connection for few days, in the meantime we would like to colocate the main transcoder PC (not an VM) to another location.
And running an VM is not an option. As we need fully functional Nvidia transcoding that's being used right now on that PC/server.

Thanks!

[emcodem]

Ah okay but that means it is only about short time so you can "manually" ensure that everything is working as expected after the change.
Well then let us know if we can help in any way!

[veks]

Thanks, I will

[Spectragr]

Hello,

Has anyone tried having two servers with ffa, one active and one standby, when something happens one continues the other? failover?

[emcodem]

Hey @Spectragr

up in front, ffastrans farm works in active-active pattern (no standby), in this case you would just let 2 or more hosts do the work and no need to care about outages of a single host. This is the only inbuilt way for farm envrionments.

The first thing that comes to my mind for turning that into active/standby would be a setup like:
1) create a normal ffastrans farm with your 2 hosts as described in "complex deployment-farm": https://ffastrans.com/wiki/doku.php?id=gui:architecture
2) create a new host group in one workflows farming option, call it "MAIN" and add the main host to the "include hosts" list
3) edit all workflows to run only on the MAIN group

From here all we need is to schedule a mini script on both hosts (run every minute or similar). The script should check the file processors/db/configs/host_groups.json - and if the main host is currently online. If main is offline, ensure that only the secondary host is in the hosts list of your group, otherwise ensure that only the main host is in the host lists of your group.

If you don't like scripting, you can ask me or chatgpt to create such a script for you To run the script every minute, you can use webint scheduler or windows scheduler or a number of other ways, depends on your preference and experience.

This could be one possible way to do what you like. However there are of course many pitfalls with this approach, normally such a setup requires a dedicated "heartbeat" network cable between the 2 hosts to guarantee that no switch happens just because of a little network slurp. There are of course other pitfalls with such an approach and in addition it is kind of impossible to "test" everything that can and will happen on a long run. This is one reason why ffastrans avoids the usual active-standby "clustering" - in 99.99% of errors on a cluster it is only and alone the clustering itself that didnt work correctly or some admin made a mistake or similar.