# Sizing Recommendations

The sizing recommendations below are guidelines for small, medium and large Moogsoft AIOps systems based on input data rate and volume. Event calculations depend on the number of events sent to the Alert Builder.

In the context of this guide, Managed Devices (MDs) are all of the components in the network infrastructure that generate and emit events:

## Small

Environment

CPU

File System

• 1000 to 5000 Managed Devices (MDs)

• Less than 20 users

• Up to 5 integrations

• Less than 20 events per second to Alert Builder

• 8 Cores

• 32GB RAM

• 2 x 1GB Ethernet

• Physical or Virtual Server

• 1 TB Local or SAN

See Retention policy below.

## Medium

Environment

CPU

File System

• 5000 to 20,000 MDs

• Between 20 and 40 users

• Between 6 and 10 integrations

• Between 20 and 100 events per second to Alert Builder

• 16 Cores

• 64GB RAM

• 2 x 1GB Ethernet

• Physical or Virtual Server

• 1 TB Local or SAN

See Retention policy below.

## Large

Environment

CPU

File System

• More than 20,000 MDs

• More than 40 users

• More than 10 integrations

• More than 100 events per second to Alert Builder

• 24+ Cores

• 128GB RAM

• 2 x 1GB Ethernet

• Physical or Virtual Server

• 1 TB Local or SAN

See Retention policy below.

###### Virtualization restrictions

Consider the following restrictions for virtual environments:

• Ideally all Moogsoft AIOps servers (guests) should be on the same compute node (host) sharing a hypervisor or virtual machine monitor. This minimizes latency between Moogsoft AIOps guests.

• If servers are liable to automated resource balancing (for example vMotion) and liable to move compute nodes, then all Moogsoft AIOps servers should be moved at the same time. If this is not possible, then Moogsoft AIOps servers should be constrained to movements that minimize the resulting network distance.

• If Moogsoft AIOps servers are distributed amongst compute nodes then the network “distance” (logical hops) between the nodes should be minimized.

• Network latency between components may affect event processing throughput. This is especially true of the core to db servers.

###### Shared storage

On any shared compute platform Moogsoft makes the following recommendations:

• The minimum resource requirements are multiplied by at least 33% to account for shared resource usage and allocation.

• Storage latency will reduce effective throughput at the core processing layer and should be minimised within the available constraints of a SAN.

• Moogsoft AIOps should be treated as a highly transactional system and not placed on the same compute node as other highly transactional applications that may cause SAN resource contention.

• SAN port and array port contention should be minimized.

• Storage medium should be as fast as possible to minimize the transaction times to the database.

###### Retention policy

You can determine the amount of disk space in GB required for the database server using the following calculation:

(es x eps x d x 86,400) x 1.2 / 1,000,000

For this calculation: es = average event size in KB, eps = average events per second, d = number of days of retention and 86,400 represents the number of seconds per day.

For the majority of event sources, you can reasonably estimate a 2KB event size. However, some sources have larger than average events. For example, Microsoft SCOM. A 2KB base takes account of the other event and alert based storage such as an alert's Situation membership and Situation room thread sizes.

The average event rate is across all LAMs and integrations.

### Note

If you do not enable the Archiver tool, the historic database will grow indefinitely. See Archive Situations and Alerts for more information.

For example, the following calculation represents a 400 day retention period with an average event size of 2KB at 300 events per second:

(2 x 300 x 400 x 86,400) x 1.2 / 1,000,000 = 24,883.2 GB.