HA Pair and ADOM Design for a Managed Security Provider
An MSSP operates 45 customer ADOMs on a pair of FortiAnalyzer 3000E appliances in HA. The primary receives about 450 GB of logs per day, with peaks near 900 GB during month-end scanning. Each appliance has 18 TB usable after RAID. The contract promises 90-day retention for most customers; one bank requires 365-day retention at up to 200 GB/day. The MSSP currently uses a single Customers ADOM with one admin profile and no per-ADOM quota. The bank has asked for evidence that its logs are isolated from other tenants and that an admin for another customer cannot search them. The MSSP also wants to add a second FortiAnalyzer VM as a DR target, but the budget only covers one more appliance, not a second HA pair.
1. How should the MSSP restructure ADOMs and administrator access to satisfy the bank? Include what not to do.
Read the worked answer
Restructure to one ADOM per customer, with a dedicated ADOM for the bank. A shared ADOM plus search filters is not an isolation boundary: any admin with access to that ADOM can see all tenant logs, and ADOM-level RBAC cannot separate records inside one ADOM. Create restricted admin profiles scoped to the customer ADOM, avoid super_admin for tenant staff, and assign the bank's ADOM only to the bank's analysts and the MSSP escalation team. Set a per-ADOM disk quota so one tenant cannot consume the cluster. Use clear ADOM naming and device assignment so FortiGates register into the correct ADOM. For the bank, enable the longer retention on its ADOM only, and document that isolation is enforced by ADOM membership and admin profile scope. Verify with a test account that the other tenant cannot select the bank ADOM or run reports against it.
2. Is the HA pair sufficient for the stated retention and peak rate? What configuration changes or architecture would you recommend?
Read the worked answer
Start with arithmetic: 450 GB/day x 90 days = 40.5 TB, which already exceeds the 18 TB usable on one node; HA replicates the same data, it does not double capacity. The bank alone needs 200 GB/day x 365 = 73 TB. Therefore the proposed retention cannot be met on these appliances, regardless of compression assumptions. Peak 900 GB/day is about 10.4 MB/s; confirm the model's rated log rate, but storage is the binding constraint. Recommend tiering: keep 30-45 days of analytics logs on the HA pair, enforce ADOM quotas, filter low-value traffic, and forward/archive older logs to an external syslog/SIEM or a larger FortiAnalyzer. Renegotiate the bank's 365-day promise or fund storage that matches 73 TB plus growth. Do not simply lower retention silently; document the gap.
3. The MSSP proposes configuring the DR FortiAnalyzer VM as a secondary node in the same HA cluster over the WAN. What is your assessment?
Read the worked answer
HA over a WAN is a poor fit. FortiAnalyzer HA expects low-latency, stable connectivity for heartbeat and log synchronization; a WAN link adds latency, jitter, and split-brain risk. A DR VM in the same HA cluster also consumes the same log stream and may fail over to a site that cannot serve queries at the required speed. Better: keep the on-site HA pair for analytics, and use the DR VM as a standalone log-forwarding or archive target with a documented restore procedure. Test failover and log continuity separately. If the business requires HA across sites, budget for a proper second HA pair and dedicated low-latency links, not a single VM over the WAN.