VMware Aria Automation 8.16 - Chinese - China

8.18 8.17 8.16 8.14 8.13 all
Português (Brasil) 简体中文 Deutsch Español Français Italiano 日本語 한국어 Nederlands Русский 繁體中文 English

Automation Config
 system requirements

Use these
Automation Config
 system requirements to determine what your system can support.

Supported operating systems for Salt

Automation Config
 runs on Salt, an open-source automation and configuration management engine. In order to begin using
Automation Config
 for configuration management, you also need to install and run the Salt minion service on any nodes that you intend to manage using
Automation Config
.
Salt itself is designed to be operating system agnostic and can manage the nodes of most standard operating systems. For a list of supported Salt operating systems, see Salt Platform Support.

Supported operating systems for
Automation Config

The architecture for
Automation Config
 is best designed to operate on either:
  • RHEL 7.4–7.9
  • RHEL 8
  • RHEL 9
Alternate operating systems are supported only to the extent that they are compatible with RHEL.
If your version of RHEL 7 is lower than 7.4, you must update your OpenSSL version to 1.0.2k before running the installation script. If this version is not available to you through a yum update or your server does not have direct Internet access, retrieve the following packages from RedHat or from your preferred public mirror:
  • openssl-1.0.2k-26.rpm
  • openssl-libs-1.0.2k-26.rpm

Determining minion architecture

In the context of
Automation Config
, a minion generally refers to a node in your production environment that connects with and is managed by
Automation Config
 through one or more Salt masters.
Salt is designed to work with any operating system that might be running on a minion. In addition to the standard operating systems (Linux, Windows, MacOS), Salt provides specialized minion software (generally referred to as "native minions") for operating systems that are unique to various network devices such as Arista, Juniper, AIX, and Solaris.
This table lists the minimum memory requirements for the Salt minion service by operating systems:
Operating system
Minimum memory requirements
AIX minion
512 MB RAM
MacOS minion
4 GB RAM
Linux minion
512 MB RAM
Windows minion
4 GB RAM
Other network devices, including proxy minions
40 MB RAM per controlled device

Estimate the number of Salt master and minions

Although the throughput of your system is difficult to measure prior to installation, you can estimate your needs based on the number of minions (nodes) in your system that will be managed by
Automation Config
. The last section of this guide provides additional measurements for determining your system throughput.
As you bring more Salt minions under management by
Automation Config
, you might need to increase your system architecture to match.
This table lists the recommended number of Salt masters you might need based on the number of managed Salt minions (nodes) in your system:
Minions
Salt masters (16 CPU/16 GB)
5,000
1
10,000
2
15,000
3
20,000
4
25,000
5
30,000
6
35,000
7
40,000
8
45,000
9
50,000
10
55,000
11
60,000
12
65,000
13
70,000
14
75,000
15
80,000
16
85,000
17
90,000
18
95,000
19
100,000
20

Estimate the number of RaaS nodes you need

This table lists the recommended number of RaaS nodes you might need based on the number of managed Salt minions (nodes) in your system:
Minions
RaaS nodes with 16 CPU/16 GB
RaaS nodes with 32 CPU/32 GB
5,000
1
10,000
1
15,000
1
20,000
1
25,000
2
30,000
2
35,000
2
40,000
2
45,000
1
1
50,000
1
1
55,000
1
1
60,000
1
1
65,000
2
70,000
2
75,000
2
80,000
2
85,000
1
2
90,000
1
2
95,000
1
2
100,000
1
2

Estimate the number of PostgreSQL nodes you need

The next two tables list the recommended number of PostgreSQL database nodes you might need based on the number of managed Salt minions (nodes) in your system:
Minions
PostgreSQL nodes with 8 CPU/8 GB
PostgreSQL nodes with 16 CPU/16 GB
PostgreSQL nodes with 24 CPU/24 GB
PostgreSQL nodes with 32 CPU/32 GB
5,000
1
10,000
1
15,000
1
20,000
1
25,000
1
30,000
1
35,000
1
40,000
1
45,000
1
50,000
1
55,000
1
60,000
1
Minions
PostgreSQL nodes with 48 CPU/48 GB
PostgreSQL nodes with 56 CPU/56 GB
PostgreSQL nodes with 64 CPU/64 GB
65,000
1
70,000
1
75,000
1
80,000
1
85,000
1
90,000
1
95,000
1
100,000
1

Estimate the number of Redis nodes you need

The next two tables list the recommended number of Redis database nodes you might need based on the number of managed Salt minions (nodes) in your system:
Minions
Redis nodes with 4 CPU/4 GB
Redis nodes with 8 CPU/8 GB
Redis nodes with 12 CPU/12 GB
5,000
1
10,000
1
15,000
1
20,000
1
25,000
1
30,000
1
35,000
1
40,000
1
45,000
1
50,000
1
55,000
1
60,000
1
Minions
Redis nodes with 16 CPU/16 GB
Redis nodes with 20 CPU/20 GB
65,000
1
70,000
1
75,000
1
80,000
1
85,000
1
90,000
1
95,000
1
100,000
1

Optimize your architecture after installation based on throughput

After you've completed your
Automation Config
 installation, you can use system monitoring metrics to better determine your system's throughput and architectural needs.
When determining what to monitor, consider these factors:
  • Amount of traffic on the event system
     - The event system (also sometimes referred to as the "event bus") is used for inter-process communication by both Salt master and Salt minions. If your event bus is very busy, consider increasing your memory allocations.
  • Job returns per hour
     -
    Automation Config
     uses the term "jobs" to refer to each of the commands, tasks, and operations performed by
    Automation Config
    . Each job sends its output to
    Automation Config
     for reporting and data collection purposes. The number of job returns your system produces in a given hour can impact your architecture needs.
  • Amount of pillar data
     - Pillar data is data that must be stored on the Salt master. Pillar is primarily used to store secrets or other highly sensitive data, such as account credentials, cryptographic keys, or passwords.The amount of data being stored on your Salt master (and later accessed by minions as needed) can impact your memory and data storage needs.
  • Cofiguration Data - Map Files
     - These files are useful for storing non-sensitive data that you don't want to place directly in your state files. Unlike Pillar data, these map files do not put additional resource strain on the salt masters.
  • Amount of custom grains
     - Grains are used in Salt to target the minions for a particular job or command. Grains refer to the basic data and characteristics of each minion. Salt comes with many pre-built grains. For example, you can target minions by their operating system, domain name, IP address, kernel, memory, and many other system properties. You can also create custom grain data to distinguish one group of minions from another based on a characteristic you uniquely target for in your system. The number of custom grains you create can impact your architecture needs.
  • Number of beacons and reactors
     - The beacon system is a monitoring tool that can listen for a variety of system processes on Salt minions. Beacons can trigger reactors, which can then help implement a change or troubleshoot an issue. For example, if a service’s response times out, the reactor system can restart the service. When coupled with reactors, beacons can create automated, pre-written responses to infrastructure and application issues. Reactors expand Salt with automated responses using pre-written remediation states. If your system has beacons and reactors that are activated regularly, that could increase your system architecture needs.
  • Disk size needs
     - You might need to increase your disk size based on the number of minions being managed and for each year's worth of data you need to keep in storage. For example, if you have a high-throughput system and your system is in a highly-regulated industry that requires 7-8 years of data retention, that might require higher disk size and storage capacity.
  • Business-critical operations
     - You might experience issues if there is high latency (>200ms) between the Salt master and the server that is running
    Automation Config
     (RaaS)."
Based on these factors, consider incrementally increasing your resources and monitor the impact to your system's performance. For example, increasing your memory allocations by 4GB RAM with 4 CPUs.
The following image shows an example of a high availability
Automation Config
 architecture design:
As this image illustrates, many high availability systems connect to multiple Salt masters. High availability systems also often build redundancy into the PostgreSQL database and Redis databases so that one can fail over to another. Keep in mind that the current high availability solutions for PostgreSQL and Redis only support manual failovers.

Content feedback and comments