Hello , Our snaplogic nodes are not load balanced currently. Snaplogic tied all of our production triggered task to one node. even though we have more than one node in production. If that nodes goes down or decommissioned for some reason, could we continue to use the task with cloud url instead of on-premises secure url ? Any faced the issue and what is the recommended solution here. Load balancing the nodes is not our first preferred option for short term solution.
The scheduling is dynamic upon each scheduled trigger. This is done upon every trigger separately. The triggered tasks are tied to a particular plex, but not a particular node within the plex.
The scheduling will only choose nodes that are have the reasonable resources (threads, cpu, memory) to execute the pipeline associated with the triggered task, and ensures the JCC is responsive.
It is definitely possible to have a single node get multiple tasks scheduled on it continuously if it is the better fit to run the pipeline at that time.
However, you should be able to reasonably see why the scheduler chose the node it did, but once again it is dynamic and these values can change after scheduling the job so that is not always the case.
Yes, if your groundplex node is down, then using the cloud will try and find a node on the plex this task is configured for to host the triggered execution if there is one available. If all nodes are down then the job will not be run.
Hope this answers your questions. Let me know if I can clear anything else up.
The triggered tasks are tied to a particular plex, but not a particular node within the plex.–> If you look at the on-premise URl of triggered task it is tied to a node and our caller application uses that onpremise url instead of cloud URL. So we are impacted here,
could we continue to use the cloud URL even after decommission the node(Triggered task on premise url is pointing to this node) , we don’t need to create new task ?
Ahh I see. Well, without a load balancer the On-premise URL is dependent on having an actively connected ground node.
So, If the node the task is configured for is coming down and going back up a lot, or is changing often, then the cloud URL might be more so of what you are looking for. The cloud URL is not tied to a particular node. So, if there are available nodes in the plex that this job is configured to run on then the cloud URL will schedule it there. However, the caveat here is that data in and out of the pipeline will go through our servers, whereas a ground trigger avoids that.
Can you elaborate on the data in and data out ? You mean to say the input parameter value and out put of the triggered pipeline ?
The input data will be sent to the control plane to then be sent to the node for execution, then the output of the triggered pipeline will be sent back to the control plane to be returned to the caller.
when the pipeline execution happens on different node other than the one tied in triggered task on-premise url, the same behavior like mentioned above would occur right ?
Is this scenario a cloud triggered execution?
If the pipe is started by a ground trigger on-premise url and the pipe executes on a separate node, then the nodes will transfer data between themselves without going through the control plane. This keeps all data on premise and will likely perform better.