Remote Gateway and Local Gateway best practices for Workload Automation on Cloud (SaaS offer)

In this blog, we will explore the best architectural practice for Remote Gateway and Local Gateway, for Workload Automation on Cloud (SaaS offer).
​

Remote Gateway considerations 
A Remote Gateway in comparison to a Local Gateway is generally used when the customer’s Agents are not able to directly connect to the Internet. The Remote Gateway server acts as a gateway to the external Internet. 

For a Remote Gateway in Workload Automation on Cloud (SaaS offer) to operate optimally, the number of jobs passing through a Remote Gateway at any point in time should be known.  Preferably, the peak-time load would be sufficient to know the gateway’s ability to manage the load. 

In a stress test done with 1000 Agents connecting to a Remote Gateway, it was found that Remote Gateway was able to manage a load of 4000 jobs per hour. This is roughly 4 jobs per Agent per hour. 

When employing a Remote Gateway, it is recommended that you use unique GWIDs to each Agent reporting to the Remote Gateway. 

This is because, when GWID is common between two Agents under a Remote Gateway, the routing for Job Status Notifications can follow unconventional paths and might go through other Agents. 
​
Let us look at an example:

In the above scenario , Job Status Notifications from the DA1 can go via DA2 to the Gateway , similarly the Job Status Notifications from DA3 can go via DA2 to the Gateway in some cases or go directly .

JobManagerGW.ini ITA stanza on the Dynamic Agent:

So, in case of unique GWID’s, the Job Status Notifications can route from the Agent to the Remote Gateway separately. In the below scenario, the Job Status Notifications would go from each Agent (DA1, DA2, DA3) to the Remote Gateway uniquely. The Local GWID’s for each Dynamic Agent is unique like GW2 for DA1, GW3 for DA2, and GW4 for DA3 and so on. This prevents Gateway clogging and prevents Jobs from getting hung on WAIT+/INTRO+ State. 
​
In the above scenario, Job Status Notifications from the DA1 on GW2 can go directly to the Remote Gateway on GW1, similarly the Job Status Notifications from DA2 on GW3 can go to the Remote Gateway on GW1 and from DA3 on GW4 to the Remote Gateway on GW1.

JobManagerGW.ini ITA stanza on the Dynamic Agent:

Backup Remote Gateway: 
Setting up a Backup Remote Gateway is important to have a failover in place when the Primary Remote Gateway goes down. It is defined in the ResourceAdvisorAgent stanza of each Agent reporting to the Remote Gateway. The stanza is shown below for reference:

ResourceAdvisorAgent

The Backup Remote Gateway should have the same GWID setup as the Primary Gateway. The ITA stanza within a Remote Gateway and Backup Remote Gateway are shown below for reference: ​

Remote Gateway

Backup Remote Gateway

Local Gateway Considerations 
In case of Local Gateway, the Agents directly connect to the SaaS Master Domain Manager on Cloud, thus the Agents having Local Gateway must connect to the Internet directly. 

​For a Local Gateway to operate optimally, it is important not to load too many busy Agents together on a single Local Gateway, while you can club multiple Agents to a single Local GWID, it is important to consider the number of jobs that run on all the Agents in an hour. 
 
So, for three Agents reporting to the same SaaS MDM, you can separate GWIDs assigned to each of them thus preventing any Gateway clogging issues potentially resulting in Jobs getting hung on WAIT+ and INTRO+ States: 
 
Thus, if the load is high, it is recommended to have unique GWIDs assigned to each Agent under a Remote Gateway as well as a Local Gateway.
​

Sriram V.
​Senior Technical Lead

Sriram has been working on Workload Automation for the last 10 years in various capacities like IWS Administrator, SME, India-SME, and now currently with the HCL product team supporting Workload Automation on SaaS.