FortiSIEM
FortiSIEM provides Security Information and Event Management (SIEM) and User and Entity Behavior Analytics (UEBA)
Andy_G
Staff
Staff
Article Id 193041

Description

Summary of Topic

This article will describe What the Sizing Estimates are for AO

 

Additional Information

These are a couple of questions that may be often asked by customers in order to size AO for their environment.

1 - How many workers (in addition to the Super) would we need for xxxxK EPS and xxxxx devices for event logging only?

AO's document system requirements up to 10k EPS in our user's guide, we can only extrapolate what is provided.

 

The numbers are not concrete, but they are estimates:

1 CPU core per 1k EPS

 

EXAMPLE for EPS Receiving/Processing: For 50k EPS we would need 50 cores to receive this EPS and process them (Mix of Workers and Supers)

EXAMPLE for EPS Sending/Passing Through Collectors: For 50k EPS we would need 25 collectors just to pass that amount of EPS (Based on 2 cores/Collector)

This would equate to 100 cores in the environment due to event collection along with event processing.

 

2 - What would specs (# of CPUs and Amount of Memory) be for the Super and Each Worker with an example of 50k EPS?

Super - 8 Cores, 16 GB Memory

Worker - 4 Cores, 8 GB Memory

Collectors - 2 Cores, 4 GB Memory

There will definitely be a need for more resources if reporting and rule processing comes into play.  These values may not be easily given since it depends on load.

 

3 - What is the max EPS a collector can handle?

2 cores per Collector, so 2k EPS

 

4 - What is the max # of concurrent TPC connections that a collector can handle?

cat /proc/sys/net/netfilter/nf_conntrack_max
65536

Note - This limit can be increased. (Please reference External KB: 0000108)

 

Additional NOTE:

With respect to IOPS, the high level answer is that we don't have any high end IOPS requirement other than what is supported on a regular server class machine with a decent hard disk that supports about 50 IOPS at the lower end (For representative numbers of different disk types, see http://en.wikipedia.org/wiki/IOPS)

 

AO Worker nodes – These nodes only perform sequential writes when storing events in event db (usually NFS), and mostly sequential reads during queries.The writes involve writing roughly a 10-15MB compressed file and some small metadata (for every 300k events on average). So, at 5K EPS, this translates to 5-10 sequential IOPS assuming 32k NFS block size. Even the high end model AO-VA-10000 with 32k EPS only requires 30-50 sequential write IOPS per worker node.

 

AO Supervisor node – This node performs random reads and writes to the CMDB database (incident data dominates typically). The size here is in single digit GBs even on a heavily loaded system. IOPS depends on overall aggregate EPS across all worker nodes and the event type mix which trigger incidents. It would be better to provision the CMDB on disks with higher IOPS capacity (local or remote) in general. An SSD is even better for responsiveness. 

 

AO Collector node = Their primary role is of collection and parsing, and upload to workers. No high end requirement of IOPS.

 

Version Application

All+

 

Contributors