FortiSIEM ClickHouse Deployment Architecture

[AEH]

Hello everyone,

I’m currently working on the design of a FortiSIEM deployment expected to handle 10,000 EPS, and I’d like to get some insights or recommendations from the community.

Planned architecture

• 1 Supervisor

• 1 Worker

• Collectors at each site (multiple sites)

• ClickHouse for event storage

Before finalizing the architecture, I have a few questions about the design choices and database placement.

1. Architecture benefits

What are the main advantages of separating the Supervisor and Worker compared to using an all-in-one Supervisor setup (for a 10K EPS environment)?
Does it provide noticeable performance or scalability improvements in real-world deployments? or would be an all in one supervisor good enough (to optimize resources usage).

2. ClickHouse placement

Where should ClickHouse ideally be installed — on the Supervisor or on the Worker?
My initial preference is to host ClickHouse on the Worker to reduce load on the Supervisor, but I’d like to confirm if that’s a recommended or supported approach.

3. Installing ClickHouse on the Worker

If ClickHouse can (or should) reside on the Worker, how can I install and configure it there instead of the Supervisor?

If anyone has an official Fortinet KB or deployment guide covering this scenario, please share the reference.

I’d really appreciate feedback from anyone who has implemented or benchmarked a similar setup — especially around event storage design, deployment best practices, and operational lessons learned.

Thanks in advance for your help!

[AEH]

@Secusaurus Waiting for your kind support.

[Secusaurus]

Hi @AEH,

Have a look at these documents:

• https://docs.fortinet.com/document/fortisiem/7.3.5/sizing-guide-clickhouse/965243/fortisiem-sizing-g...
• https://docs.fortinet.com/document/fortisiem/7.3.5/fortisiem-reference-architecture-using-clickhouse...

I think, the NSE training (https://training.fortinet.com) also mentions the basics of ClickHouse deployment.

In general, my recommendation:

• Always use distinct Supervisor(s) and Workers
  • An all-in-one-deployment does not scale. If you ever run into performance issues, you are limited to SSD-speeds, max CPUs/RAM of your server. If you use Workers right from the start and you run into performance issues, you can spin up another worker on another hardware
  • In an all-in-one-deployment, you don't get a good redundancy/backup concept. In case this machine goes down, you loose everything
• Use ClickHouse
  • This is recommended, fully integrated and enables some features you don't have with the other db-structures
  • ClickHouse has a noticeable better performance (hard drive speed & consumption, CPU, RAM) than eventDB which you would usually get on an all-in-one-deployment
• Use (at least) two identically configured Workers as Replicas within the same Shard
  • This is a perfect backup-concept. If one Worker goes down (or just does an upgrade), you have all the data on the other one and don't loose anything

ClickHouse automatically comes with the default installation, you don't need to install anything additionally. You only need to configure it, depending on your needs (for needs: see sizing guide above). This is done in the admin config menu and you simply configure, test and deploy it on the GUI. In a simple setup (10k still is a low number), I would recommend one Supervisor as Keeper and two Workers as Replicas of one Shard can absolutely handle that. You might need to deploy more Keepers, in case you like HA things on the Supervisor.

Hope this helps.

Best,

Christian