AWA System Requirements and Sizing

The first step in preparing to install or upgrade your CA Automic Workload Automation system is making sure that you have the necessary infrastructure ready and required components and versions installed.

Automic Compatibility Matrix

In order to install and run your intended system or update an existing one successfully you have to check requirements and prerequisites.

Use the Automic Compatibility Matrix online. You will find the latest details about supported versions and other information regarding the setup or prerequisites there. It is a database we constantly maintain and keep up to date.

Please check all Automic components and prerequisites for vendor, version or setup information.

For details on preparations and prerequisites see New Installation or Upgrade Installation.

Sizing of CA Automic Workload Automation Systems

Sizing an AWA system is no easy task, as a number of aspects have to be considered. To help you make your decisions, below you find a table for different workload options and a second table containing the most important considerations as Q&A.
The first table is meant to help you to make a quick rough estimate for your system setup. It shows conservative results to be on the safe side.

Database systems and database storage have always to be fail safe and redundant. This section does not deal with that question.

Modules

Small Configuration

Medium Configuration

No. of Servers

CPU

Memory

Disk

No. of Servers

CPU

Memory

Disk

Automation Engine

2 x

4 cores

8 GB

512 GB

2 x

8 cores

32 GB

1 TB

Database

 

4 cores

8 GB

512 GB

 

8 cores

32 GB

1 TB

Utilities

1 x

1 core

n/a

20 GB

1 x

1 core

n/a

20 GB

Agent

n x

1 core

n/a

20 GB

n x

2 cores

n/a

20 GB

Service Manager

n x

1 core

n/a

n/a

n x

1 core

n/a

n/a

Service Manager Dialog

1 x

1 core

n/a

n/a

1 x

1 core

n/a

n/a

Automic Web Interface

1 x

2 cores

8 GB

20 GB

1 x

4 cores

16 GB

20 GB
Analytics Backend and Datastore 1x 4 cores 16 GB 512 GB 1 x 16 cores 64-128 GB 1 TB

 

Number of

 

 

Concurrent users

< 10

< 50

Agents

< 20

< 100

Object definitions

< 1 000

< 50 000

Total Executions per day

< 1 000 000

< 2 000 000

 
WP 2 x 4 2 x 8
DWP* 2 x 2 2 x 4
JWP* 2 x 1 2 x 1
CP 2 x 2 2 x 2
JCP 1 x n (n= number of servers) 1 x n (n= number of servers)

 

Modules

Big Configuration

High End Configuration

No. of Servers

CPU

Memory

Disk

No. of Servers

CPU

Memory

Disk

Automation Engine

2 x

16 cores

64 GB

1 TB

4 x

16 cores

 96 GB

1 TB

Database

 

16 cores

64 GB

2 TB

 

16 cores

 96 GB

2 TB

Utilities

1 x

1 core

n/a

20 GB

1 x

1 core

n/a

20 GB

Agent

n x

4 cores

n/a

20 GB

n x

4 cores

n/a

20 GB

Service Manager

n x

1 core

n/a

n/a

n x

1 core

n/a

n/a

Service Manager Dialog

1 x

1 core

n/a

n/a

1 x

1 core

n/a

n/a

Automic Web Interface

1 x

8 cores

32 GB

20 GB

1 x

8 cores

32 GB

20 GB
Analytics Backend and Datastore 1 x 32 cores 256 GB 2 TB 1 x 32 cores 256+ GB 4 TB

 

Number of

Concurrent users

< 200

> 200

Agents

< 1 000

> 1 000

Object definitions

< 100 000

> 100 000

Total Executions per day

< 10 000 000

> 10 000 000

 
WP 2 x 16 4 x 16
DWP* 2 x 8 4 x 8
JWP* 2 x 2 4 x 2
CP 2 x 2 4 x 4
JCP 1 x n (n= number of servers) 1 x n (n= number of servers)

The numbers of JWP and DWP ensure stable response times up to the maximum amount of concurrent users. You can adjust the number of processes according to the expected amount of users.

If you are using a x core AMD CPU, deactivate low-current functions and dynamical cycle adjustments in the BIOS on the Automation Engine computer.

Automic Web Interface

AWI allows you to make Automation Engine accessible to more users. To guarantee quick response times in the web interface, the Automation Engine has to handle lots of requests. Most requests are handled by DWPs, and some by JWPs.
Automic recommends using separate DWPs so that web interface requests do not interfere with job processing. 

Web interface requests also generate a significant amount of database I/O, so make sure your system is not I/O bound when making it available to many concurrent users.

Analytics

For medium configurations and bigger installations, setting up a regular backup and truncate for the Analytics datastore is recommended in order to provide a stable chart performance (e.g. back up and truncate to only keep the last 3-12 months in the Analytics database).

Setup Recommendations

Adjustments - Questions and Answers

After you have got a rough estimation of what to expect, there are some additional aspects to be taken into consideration, which may affect the sizing. Below you find a list of possible questions and the appropriate answers concerning system sizing for different scenarios.

Question

Sizing Adjustment

General

 

Is the expected load distributed over the day evenly or do you expect high peaks?

Normal: -
Even: Reduce resources
High Peaks: Add resources (cores, WPs)

Is excellent performance important even in periods of peak load?

No: -
Yes: Add resources (cores, WPs)

Is the expected load constant or do you expect growth?

Constant: -
Growth: Consider next sizing level 

How long do you need to hold data (statistics, job reports, revision reports) in the database?

> 12 month: Add more database storage
< 3 month: Reduce database storage 

Do you expect many huge job reports to be stored in the database (e.g. more then 100.000 lines)?

No: -
Yes: Add more database storage

Do you plan to use ILM?

Yes: Plan how to deal with switched out data
No: Run the AE DB Reorg utility as near as possible to the database and add storage for output data (if generated)

Do you plan to use Oracle as database system?

Yes: Add resources on the database node(s) (faster CPUs, faster network, etc. )

What hardware to you plan to use for the AE system?

Linux/Windows on Intel x64: -
Others:  Add resources

Do you plan to run the AE/database on virtual nodes?

Yes: Make sure that computing power is guaranteed for your systems and other Virtual Machines do not detract from the computing power/bandwidth.

Is logging and traceability over a longer period important for you?

Y: -
N: Reduce local disk storage on AE 

Fail safe

 

Is a fail safe system important for you?

No: -
Yes: Make sure your systems are equipped with redundant components (power supply, network, etc.) and that you have an "always-on" database environment.

Performance during a failure situation (e.g. one node fails): Are the remaining node(s) able to handle the load?

Example:
A two-node system has to be oversized by 100% to be able to handle the load on the remaining node!
Consider not only cores and memory, but also the amount of CPs, WPs, DWPs, JWPs, DB-Service agents, etc.

If fail safe is crucial for you, consider to run on more than two nodes!

Agents

 

Do you expect high usage of some agents?

No: -
Yes: Add resources to those nodes. Take care that resources used by your jobs are available.

Do you plan to run many agents on a single node (e.g. SAP, WebService,...)

No: -
Yes: Add approximately 1 GB per Java-based agent to those nodes. (An average used java agent will need between 512-1024 MB, but in some cases this may be more.)

Users

 

Do you have many users, who are constantly monitoring activities and workflows?

No: -
Yes: Add more resources to dialog work processes and AWI (run more DWPs and take care that cores and memory are available for this additional load).

Do you expect huge workflows (> 1000 tasks per workflow)?

No: -
Yes: Add memory to AE/AWI (expect 1-2 GB per DWP)

Do you expect huge xml imports/exports?

No: -
Yes: Add memory to AE/AWI (expect 1-2 GB per DWP)
Automic Web Interface

 

Do you expect to have users in different locations (long distance)?

No: -
Yes: Run multiple AWI instances at every location (e.g. on every continent, where users are located).
Do you expect a high load at a particular location?

No: -
Yes: Run one strong server with plenty of RAM (see high end configuration)
Does load balancing make sense? In general, the AWI needs liitle CPU, just plenty of RAM. Load balancing for performance does not make sense. Most load balancers do not support websockets, which the AWI uses and which reduce our resource usage per session and improves UI responsiveness. If you want to use a load balancer for high availability, see Configuring Automic Web Interface
You are experiencing slow response times If the CPU on the servlet container running AWI is low and you are sure that your database can handle the increased I/O, try increasing the amount of DWPs and JWPs.
Job processing slowed down via database I/O by heavy web interface usage In times of heavy web interface usage, you can temporarily reduce the number of DWPs in order to take load off the backend while working on improving database I/O.
Analytics

 
What is the required disk space? To estimate the disk space required in the datastore you can calculate with about 1GB for 1.000.000 executions in the Automation Engine
Do I need to back up the datastore?

The Analytics datastore was created to store large amounts of data. If you have a medium or bigger installation it might still be useful to remove data older than approx. 1 year from the Analytics datastore. It is recommended to setup the provided backup actions (ANALYTICS ACTION PACK)
General Database Rules

This is valid for all DB vendors - the log files must/should be placed on the fastest available disks (=SSDs).

ORACLE: REDO LOG FILE DESTINATION
SQL SERVER: TRANSACTION LOG and TEMPDB files
DB2: LOG files
LOG and DATA files must always be on separate DISKS /LUNS

Average Transaction Time Rating
> 0.2 sec Critical
> 0.05 sec To be improved
> 0.02 sec OK
< 0.02 sec Perfect

Troubleshooting

#
Issue
Suggestion
1 Local system is too slow  
  CPU is too slow
  • Increase CPU speed
  • Increase CPU count
  Other apps consume too much CPU power on your node Run the Automation Engine exclusively on your nodes.
  The system is under memory pressure
  • Add memory
  • Reduce memory consumption
  The virus scanner slows down I/Os Avoid running the virus scanner on your production node.
2 Database is too slow  
  Connection to the database is too slow
  • Increase network speed/capacity
  • Reduce the distance to the database
  Database transactions are too slow
  • Mirror or similar issues: Reduce the distance to mirror or use other (faster) fail safe features.
  • Check CPU speed/usage/count
  • Check memory size/usage
  • Check storage speed/capacity/usage of other apps
  • Check database maintenance (index reorganization, etc.)
  • Check query optimizer (settings, statistics, etc.)
  • Consult your database vendor for improvements