How to construct a scalable Automation API solution in Control-M? |
There are several issues that need to be considered with regards to AAPI scalability
All the requests whether they originated from an EM client or from AAPI are send to GUI server for processing and are handled in similar manner. The GUI server handles the particular individual requests with the same amount of resources no matter where its coming from. Similarly, CMS requests issued through AAPI are handled with the same resources as they are handled directly through the CCM. If a configuration has multiple GUI servers across distributed EM instances, the EM client user requests are load balanced by the Thrift module but AAPI requests are routed to the local Rest Server or Config Rest Server. The Rest Server is configured to send all its requests to a particular GUI server as specified in the Rest Server configuration properties. Since load balancing AAPI requests across multiple GUI servers is not yet a feature of the product it is advisable to use 3rd party products such as API gateway to distribute requests across multiple Web Servers in an EM distributed configuration. To properly size a GUI server for EM client interactive requests, one needs to calculate how many concurrent users are logged in at peak time. To properly size for AAPI request, one needs to calculate the number of concurrent request that are executed at peak time. Using Control Shell in the CCM one can obtain GUI internal statistics at a peak time to facilitate these calculations. For sizing the GUI server please refer to the Installation guide for minimum sizing requirement and to the PSR whitepapers for larger environments. If the volume of requests are unpredictable, in many cases due to rogue programs the volume of requests will be inherently unpredictable, the best practice is to dedicate separate GUI server to AAPI requests and a separate GUI server for UI requests. Implementing a distributed EM configuration will allow administrator to dedicate a Web Server and associated GUI server in one EM instance to AAPI requests and designate a second EM instance with its own Web Server for interactive user requests. The draw back to this solution is that in a distributed EM environment the second environment cannot be configured for Control-M High Availability. But this dilemma is solved by introducing a thirds distributed instance for AAPI requests with an API gateway to load balance the request across two distributed EM instances. Implementing distributed EM configuration requires a separate OS environment for each instance. Having a separate environment for each EM instance ensure that there is no conflict in resources and all the machine resources are dedicated to each EM instance. In an EM distributed configuration to load balance AAPI requests one needs to utilize a 3rd party API Gateway. There are several API Gateway including Open Source that are available in the market. The benefit of API Gateway is not only load balancing but also managing the flux of traffic. There may be users that overwhelm the system and do not give opportunity for other user or higher priority requests to be processed. The API Gateway provides throttling functionality to manage who get more and who gets less access to Rest Servers. To ensure that AAPI traffic flows into the AAPI Server only from the API Gateway, use the procedure described in Admin guide under the topic "Limiting incoming traffic through an API gateway" and by limiting this port only to the IP of the API Gateway machine using a firewall. A one EM instance with 2 GUI servers in the same environment, one dedicated to users and one dedicated to AAPI is not recommended. |