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 Elements (MEs) are all of the parts of the network infrastructure which generate 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.
** Retention Policy
You can calculate the amount of disk space required for the database using the following:
(Aggregate event rate / the number of seconds per day x desired retention x average event size) / 1,000,000
- Where the aggregate event rate is across all LAMs
- Desired retention is in days
- Average event size is in Kb
- Result is in Gb.
- Some event sources have larger than average events (e.g SCOM) but generally a 2kb event size is a reasonable assumption. This 2kb base takes account of the other event/alert based storage (e.g an alerts situation membership, typical custom_info, situation room thread sizes etc.)
- So for an event rate of 10/s per LAM with 5 lams and a 400 day (13 month) retention we would have
50 x 60 x 60 x 24 x 400 x 2 / 1,000,000 = 3,456GN (3.5TB)