Hardware Sizing

Sizing is the process of determining the hardware requirements for different slabs of workload. This is an interim document created to provide guidance for immediate 20.0 release deployments. The recommendations here are based on performance test runs (refer factsheet) conducted before product GA release.

These guidelines do not reflect the optimum recommended hardware for running AssistEdge. This document will be refined and updated to reflect the optimum recommendations based on different workloads. Please refer the latest updated document for provisioning production infrastructure for your engagements.

 

General Guidelines

The guidelines mentioned here are based on the validations carried out in a testing environment under specific load conditions.

 

• The server usage in the client environment varies depending on the workload and amount of data in the system.
• It is recommended to periodically analyze the server resource utilization and consider corrective measures.
• Periodic archival of the data is advised. If data storage in a live system is mandatory, the configurations of the servers are to be reviewed based on the resource utilization levels seen at the implementation site.
• The recommended server configurations support number of users/bots as per slabs, the number of automation requests processed, user types, automation complexities, and functionalities implemented. As additional users/bots/workflows are added, requests processing count increased, or if new functionalities are implemented, additional resources may need to be added to the servers.

 

Hardware Configurations

This section explains the AssistEdge RPA capacity plan scenarios for various usage scenarios. Refer the appropriate scenario depending on your implementation plan. An update to this document will provide guidance on different slabs per scenario and recommended hardware sizing.

 

Below suggestions for RPA setup are based on the automation processing load of up to 8 requests per hour per bot based on the automation process execution time.

 

Note: Below guidelines do not indicate the minimum hardware footprint of the platform for meeting a given usage scenario. The H/W guidelines are based on hardware provisioned for actual performance tests; these will be refined further to a more optimum recommended H/W based on follow-on tests.

 

The physical to virtual cores ratio is considered to be 1:2. That is, 1 physical core = 2 logical/virtual cores = 2 vCPUs

 

Reports: The reporting function utilization depends on the data queried and frequency. The system has been tested for RPA reports from a total Open Distro store size of 224 GB and Engage reports from a total Open Distro store size of 150GB. If report requirements are of higher size and frequency, the capacity of the servers should be increased appropriately as per the utilization level observed at the implementation site

 

The hardware recommendations mentioned below are based on the tests carried out. The numbers will be revised with test results from the increased load.

For requirements not mentioned in the document, please get in touch with the product team.

 

Scenarios

This section explains the AssistEdge RPA capacity plan scenarios for various usage scenarios. Refer the appropriate scenario depending on your implementation plan.

 

Below suggestions for RPA setup are based on the automation processing load of up to 8 requests per hour per bot based on the automation process execution time.

 

The physical to virtual cores ratio is considered to 1:2. That is, 1 physical core = 2 logical/virtual cores = 2 vCPUs

 

Reports: The reporting function utilizations will depend on the data queried and frequency. The system has been tested for RPA reports from a total Elastic store size of 327 GB. If report requirements are of higher size and frequency, the capacity of the servers should be increased appropriately as per the utilization level observed at the implementation site.

 

The hardware recommendations below are based on the tests carried out in internal systems engineering Lab.

 

AssistEdge RPA Capacity Plan Scenarios

For AssistEdge RPA, the capacity plan is provided as per below slabs:

 

Non-HA Deployment

• Small scale deployment up to 5 bots, 10 bots and 50 bots
  
  Small scale deployment to cater up to 5 bots, 10 bots, and 50 bots. Web and App components are in single server.
• Medium scale deployment up to 250 bots
  
  Medium scale deployment to cater up to 250 bots. Web and App components are in single server.

  NOTE:

  Non-HA environment depicts the scalability of the application. High Availability setup is recommended in Production environment.

 

HA Deployment

• Medium scale deployment up to 250 bots
  
  Medium scale deployment will cater up to 250 bots in the environment. Web and App components are in a Clustered setup. This also helps in High Availability.

• Large scale deployment up to 500 bots, and 700 bots
  
  Large scale deployment will cater up to 700 bots in the environment. Web and App components are in a Clustered setup. This also helps in High Availability.

AssistEdge RPA With Low Code Orchestrator Capacity Plan Scenarios

For AssistEdge RPA with low code process orchestrator, the capacity plan is provided as per below slabs:

 

Non-HA Deployment

• Small scale deployment up to 5 bots, 10 bots and 50 bots
  
  Small scale deployment to cater up to 5 bots, 10 bots, and 50 bots. Web and App components are in single server.
• Medium scale deployment up to 200 bots
  
  Medium scale deployment to cater up to 200 bots. Web and App components are in single server.
   

  NOTE:

  Non-HA environment depicts the scalability of the application. High Availability setup is recommended in Production environment.

HA Deployment

• Medium scale deployment up to 200 bots
  
  Medium scale deployment will cater up to 200 bots in the environment. Web and App components are in a Clustered setup. This also helps in High Availability.

• Large scale deployment up to 500 bots, and 600 bots
  
  Large scale deployment will cater up to 600 bots in the environment. Web and App components are in a Clustered setup. This also helps in High Availability.

Hardware Recommendations

RPA Capacity Plan: Non-HA Deployment

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

NOTE:

Storage in app server should be determined based on number of automation requests processed in a day and associated complexity of the automation process. rpa-trans-<date>  and rpa-txn-steps-<date> index in elastic search can be used to monitor and determine the data storage needs. In App server, for up to 50 bots, set the elastic heap size at 1 GB and with more than 50 bots, set the elastic heap size at 2 GB. Non-HA environment depicts the scalability of the application. High Availability setup is recommended in Production environment.

RPA Capacity Plan: HA Deployment

 

 

 

 

 

 

 

 

 

 

 

 

 

 

NOTE:

Storage in app server should be determined based on number of automation requests processed in a day and associated complexity of the automation process. rpa-trans-<date>  and rpa-txn-steps-<date> index in elastic search can be used to monitor and determine the data storage needs. In App server, set the elastic heap size at 2 GB and increase depending on the number of bots run and the resources available.

 

RPA with Low Code Process Orchestrator: Non-HA Deployment

NOTE:

Storage in app server should be determined based on number of automation requests processed in a day and associated complexity of the automation process. rpa-trans-<date>  and rpa-txn-steps-<date> index in elastic search can be used to monitor and determine the data storage needs  In App server, for up to 50 bots, set the elastic heap size at 1 GB and with more than 50 bots, set the elastic heap size at 2 GB. DB size needs to be monitored as it depends on the usage of the Low Code Process Orchestrator. Accordingly, the DB storage and archival policy can be determined. Non-HA environment depicts the scalability of the application. High Availability setup is recommended in Production environment.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

RPA with Low Code Process Orchestrator: HA Deployment

NOTE:

Storage in app server should be determined based on number of automation requests processed in a day and associated complexity of the automation process. rpa-trans-<date>  and rpa-txn-steps-<date> index in elastic search can be used to monitor and determine the data storage needs  In App server, set the elastic heap size as 2 GB and increase depending on the number of bots run and the resources available. DB size needs to be monitored as it depends on the usage of the Low Code Process Orchestrator. Accordingly, the DB storage and archival policy can be determined.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Suggestions

Following are the guidelines on server types in Azure and AWS:

 

Azure: Corresponding configuration in General Purpose D series can be looked at for production implementations.

 

AWS: Corresponding configuration in General Purpose M series can be looked at for production implementations.

 

See AssistEdge Hardware Sizing recommendations for the different supported scenarios for automation deployment. In addition, following are a few generic recommendations:

• Adjust/ increase heap size of ElasticSearch based on the total number of robots and concurrent requests being processed.
• Sizing for machines running robots should factor resource utilization by 3^rd party client applications and number of bots planned in the machine.
• Ensure appropriate Load Balancer settings in HA deployment to ensure that load is distributed evenly amongst the different nodes of the configured cluster.

NOTE:

Staging environment is not included in any of the scenarios.

RPA-Automation Studio Client/ Development Components

Below requirements are applicable for Engage Client, Automation Studio and Robot Farm.

 

NOTE:

The configuration of Robot Farm and Automation Studio is dependent on the applications being used in the system. The overall planning is to be done considering the resource utilization by all the applications running parallelly in the system.

 

 

‎