Sizing Recommendations

The sizing recommendations below are guidelines for small, medium and large Moogsoft Enterprise 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 Enterprise servers (guests) should be on the same compute node (host) sharing a hypervisor or virtual machine monitor. This minimizes latency between Moogsoft Enterprise guests.
If servers are liable to automated resource balancing (for example vMotion) and liable to move compute nodes, then all Moogsoft Enterprise servers should be moved at the same time. If this is not possible, then Moogsoft Enterprise servers should be constrained to movements that minimize the resulting network distance.
If Moogsoft Enterprise 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 minimized within the available constraints of a SAN.
Moogsoft Enterprise 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.

In this section: