The sizing recommendations below are guidelines for small, medium and large Moogsoft AIOps systems based on input data rate and volume.
In the context of this guide, Managed Devices (MDs) are all of the components in the network infrastructure that generate and emit events:
Consider the following restrictions for virtual environments:
- Ideally all Moog servers (guests) should be on the same compute node (host) sharing a hypervisor or virtual machine monitor. This minimizes latency between Moog guests.
- If servers are liable to automated resource balancing (e.g. vMotion) and liable to move compute nodes, then all Moog servers should be moved at the same time. If this is not possible, then Moog servers should be constrained to movements that minimize the resulting network distance.
- If Moog 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.
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.
- Moog 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.
You can calculate 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.
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.