IBM QRadar Deployment & Components — Console, Processors, Data Nodes & Sizing

① Two topologies — all-in-one vs distributed

QRadar supports two core deployment models. In the all-in-one model, every component — Console, Event Processor, Flow Processor, and the correlation engine — runs on a single host. This suits labs, proof-of-concepts, and small environments where a single appliance can handle the expected EPS and FPM load without dedicated hardware for each role.

The distributed model separates roles across multiple appliances. The Console manages configuration and offenses while Event Processors, Flow Processors, Data Nodes and the App Host each run on dedicated hardware. This lets you scale each layer independently: add another Event Processor when EPS grows, add Data Nodes when storage fills, and keep the Console responsive because it is not also grinding through correlation.

IBM recommends the distributed model for any production deployment that expects significant log volumes, multiple data sources, or high availability requirements. The transition from all-in-one to distributed is supported but requires planning, so it is worth designing distributed from day one if growth is expected.

② Core components — what each one owns

Every QRadar deployment is built from a fixed set of roles. The Console is the web UI and management brain: it holds the global configuration, the offense queue, reporting, user management and the license pool. There is exactly one Console per QRadar deployment. The Event Processor (EP) receives normalised events from Event Collectors, runs correlation rules (the Rules Engine and Magistrate), and stores events in its local Ariel data store. You add EPs to scale EPS throughput.

The supporting cast

The Event Collector (EC) sits closest to log sources — it collects raw events from DSMs (device support modules), normalises them and forwards to an EP. An EC inherits the EPS allocation of its parent EP. The Flow Processor (FP) does the same for network flow data (NetFlow, sFlow, J-Flow), producing QRadar flows and counting FPM. The Data Node extends storage and search capacity for an EP — it does not process events itself but lets one EP manage a much larger Ariel data store, useful when retention windows grow. Finally the App Host runs QRadar applications (QRadar Advisor with Watson, User Behavior Analytics, etc.) in Docker containers, isolated from the Console so that an expensive app does not steal Console CPU.

③ EPS & FPM — measuring and licensing throughput

EPS (Events Per Second) and FPM (Flows Per Minute) are the two currency units of QRadar licensing and capacity. IBM licenses QRadar by these rates: the base licence starts at 100 EPS and 15,000 FPM; additional EPS must be purchased in multiples of 100 and additional FPM in multiples of 5,000.

The Console holds the total licensed EPS and FPM as a license pool. You then allocate slices of that pool to individual Event Processors and Flow Processors through the Admin > License Pool Management screen. An Event Collector inherits the allocation of its parent EP — it does not have its own separate slice. If any processor's allocated EPS is exceeded, QRadar throttles incoming events on that processor to protect stability.

There are two licence models: the Usage Model (pay for EPS + FPM rates) and the Enterprise Model which licenses by Managed Virtual Servers (MVS) instead of raw rates. Most on-premises deployments use the Usage Model. For QRadar on Cloud, IBM manages the pool automatically. Always monitor the License Pool Management console for over-allocation warnings before they become dropped-event problems.

④ Sizing & the end-to-end event path

A raw syslog from a firewall travels like this: the log source sends UDP/TCP syslog to an Event Collector. The EC loads the matching DSM, parses and normalises the event into QRadar's Common Event Format, then forwards it to its parent Event Processor. The EP stores the event in its local Ariel database, passes it through the Rules Engine for real-time correlation, and if a rule fires, the Magistrate creates or updates an offense and sends it to the Console for analyst review.

Sizing rules of thumb

Size Event Processors for peak EPS with at least 20% headroom — bursts (authentication storms, vulnerability scans) can spike 3–5× the average. A single EP appliance can handle tens of thousands of EPS at high spec; check the IBM Hardware Guide for the exact model capacities. Add Data Nodes when 90-day retention on raw events exceeds the EP's internal disk. Add an App Host before installing more than one or two QRadar applications to keep Console performance stable. For the Flow side, size Flow Processors for peak FPM at the network boundary — NetFlow can generate far more FPM than logs generate EPS in a traffic-heavy environment.