Use the supported workflow for your exact QRadar release. Before any manual failover, verify primary/secondary synchronization, confirm the current active host, check that the secondary is Standby, and obtain approval for a maintenance window. Never test failover by simply shutting down an IP address or powering off production infrastructure.
1. What QRadar HA provides
IBM QRadar High Availability (HA) pairs a primary HA host with a secondary HA host and a cluster virtual IP address (VIP). If a qualifying hardware, network, operating-system, or storage failure affects the active host, the secondary can take over the protected host's role. Depending on the architecture, access to data is maintained through QRadar data synchronization or supported shared external storage.
HA protects specific QRadar hosts; it does not automatically protect every server, log source, integration, network path, or external dependency in the SOC. Plan the HA pair for each host role that requires protection, and test end-to-end log ingestion after a failover.
IBM supports HA on hardware and virtual appliances and with appliance or software installations when the requirements are met. Do not assume HA is supported for every QRadar deployment model; for example, IBM documents that native QRadar HA is not supported in cloud environments. Verify the supported architecture for your product and hosting model.
2. Understand primary, secondary, and virtual IP addressing
A common source of confusion is the relationship between the primary's original management IP and the HA cluster VIP. When the HA cluster is created, the primary host's existing IP becomes the cluster VIP. The primary host itself must therefore receive a different unused IP address.
| Address / system | Purpose | Planning rule |
|---|---|---|
| Cluster VIP | Stable address clients and deployment components use to reach the protected QRadar host. | Typically uses the primary host's original IP when the HA pair is created; preserve it in network records and DNS as appropriate. |
| Primary host IP | Direct address of the primary appliance when it is not owning the VIP. | Choose a new, unused address in the correct subnet before configuring the cluster. |
| Secondary host IP | Direct address for administration and synchronization with the secondary appliance. | Choose another unique, reachable address according to the deployment plan. |
Do not assign the same address to the primary, secondary, and VIP simultaneously. Validate subnet, gateway, VLAN, routing, DNS, interface/hostname rules, and required connectivity before running the HA wizard.
3. Prerequisites before configuring HA
- Confirm the primary host is healthy and the existing deployment has no unresolved deployment, storage, database, or event-pipeline issues.
- Confirm both hosts use the same supported QRadar software version and fix level.
- Confirm the secondary has a valid HA activation key, is not already in another HA cluster, and has sufficient supported resources.
- Verify that both hosts support the same required DSM, scanner, protocol, and related RPMs.
- If the primary uses supported external storage, configure the secondary to access the same storage according to the IBM storage/HA guide.
- Prepare unique host addresses and a reserved cluster VIP; validate routes, network reachability, DNS, time synchronization, and firewall rules for the required QRadar ports.
- Ensure adequate capacity and storage; confirm the target design's supported disks, RAID, storage performance, and HA replication requirements.
- Back up the QRadar configuration and critical app data, and document how to recover if the HA setup fails.
- Read the release-specific High Availability Guide and review HA notifications/health status before making changes.
IBM notes that the HA wizard checks factors including the secondary activation key, whether the secondary is already clustered, matching software versions, access to external storage, and compatible support packages.
4. HA setup workflow
Use IBM's documented HA wizard/workflow for the installed release. The names of some menu items and install steps vary across QRadar versions and installation types.
- Prepare the secondary appliance/VM using the matching installation guide and select the supported HA role when required by that workflow. For a Console, select the corresponding Console/all-in-one role as instructed; non-Console managed-host roles must match the protected system.
- Assign unique host addressing and reserve the cluster VIP as described above. Do not finalize addressing by guesswork during the wizard.
- From QRadar, open Admin → System and License Management and use the supported High Availability workflow to create the pair.
- Provide the primary/secondary and VIP information and allow QRadar to validate the hosts, software versions, HA entitlement, storage access, and related prerequisites.
- Monitor the setup until the cluster reports the expected Active/Standby state. If a validation fails, capture the exact error and resolve the underlying issue before retrying.
- Verify the protected host's services, data synchronization, VIP reachability, log-source communication, and event/flow processing before treating the cluster as ready.
The installation path differs for a new virtual appliance, a software installation, or adding HA protection to an existing Console/managed host. Follow the exact installation and HA guide for your QRadar release and topology.
5. Notes for virtual-machine deployments
For VM-based HA, confirm the hypervisor, virtual NICs, storage, reserved resources, and network configuration meet IBM’s requirements. Run prepare_ha.sh only when the exact release-specific installation guide calls for it; it is not a generic repair command.
# Only when required by the release-specific VM HA guide
bash /media/cdrom/post/prepare_ha.shFor administration, verify the SSH host key and connect normally. Do not disable host-key checking as a shortcut or place passwords directly in scripts/commands:
ssh root@<secondary-host-ip>6. Identify the active host and current HA state
Check the status in Admin → System and License Management. For CLI diagnostics, IBM documents the HA state command:
/opt/qradar/ha/bin/ha cstateReview the Local and Remote role/state lines to determine which node is Primary/Secondary and Active/Standby/Online. Save this output before a planned role transition and again afterward.
| Observed state | Initial interpretation / next step |
|---|---|
| Primary Active, Secondary Standby | Expected state for a healthy, synchronized pair; confirm both are online and synchronization is healthy. |
| Primary Active, Secondary Failed/Unknown | Check that the secondary is powered on and reachable over SSH; inspect network/hardware and follow IBM's secondary-recovery guide. |
| Primary Failed/Unknown, Secondary Active | Confirm primary hardware/network state and follow IBM's primary-recovery/failback guide; do not force a switch until the actual state is known. |
| Both Unknown | Check basic network, hardware, and SSH reachability; escalate if the HA state cannot be safely established. |
7. Planned failover to the secondary
A planned manual failover can be useful when maintaining the primary host. IBM's prerequisite is that the HA hosts are synchronized and the secondary is in Standby. Follow the supported UI sequence:
- Verify the primary is currently Active, the secondary is Standby/Online, and synchronization has completed.
- Open Admin → System Configuration → System and License Management.
- Select the primary HA host and use High Availability → Set System Offline as specified in IBM's manual-failover procedure. QRadar should transition the secondary to Active.
- Expect that the QRadar UI might be unavailable during the transition. Do not click repeatedly or issue commands concurrently while the role change is in progress.
- Verify the secondary is Active, the VIP is reachable, log sources can reconnect, new events are searchable, and the health status is acceptable before maintenance begins.
First use a controlled maintenance procedure. If you need to test automatic failover, schedule a dedicated test, define the failure being simulated, verify data synchronization, confirm access to the recovery path, notify SOC stakeholders, and agree on stop/rollback criteria.
8. Restore the intended primary/secondary roles
When a primary recovers after a failure, QRadar may return it as Standby. If the intended design requires the primary to become Active again, use the supported role-switch procedure for your release.
IBM documents the following commands for the role transition; they are alternatives to be run from the specified current role, not a pair of commands to execute one after another blindly:
# Run on the currently ACTIVE host:
/opt/qradar/ha/bin/ha giveback
# OR, run on the currently STANDBY host when the documented
# procedure calls for the standby host to take over:
/opt/qradar/ha/bin/ha takeoverBefore running either command, confirm the current active/standby role and follow IBM's procedure for the desired direction of transition. Do not invoke giveback and takeover sequentially without checking state and the procedure.
When the UI is accessible again, select the secondary HA host in System and License Management and use High Availability → Set System Online where the documented procedure requires it. Confirm that the primary is Active and the secondary is Standby, both are Online, and synchronization is healthy.
9. Troubleshooting common HA issues
Secondary host is Failed or Unknown
- Check power/hypervisor state, virtual NIC connectivity, VLAN/subnet, routing, and whether SSH to the secondary works.
- Confirm both appliances have the expected software/fix level and compatible DSM/scanner/protocol components.
- Verify required shared storage access and the HA storage/mount state.
- Review System Notifications and the HA state using the UI and
ha cstate; follow IBM's host-recovery guide before rebuilding or removing the HA pair.
Both hosts report Unknown
Prioritize basic network and hardware checks. Verify the intended management and virtual IPs, the network path between the hosts, time synchronization, and root SSH reachability. Avoid changing IPs or forcing a role switch until the actual active host and data state are known.
Failover occurred but log ingestion appears unhealthy
Check the cluster VIP, routes, log-source connection status, event/flow pipeline state, and managed-host connectivity. Some external sources or downstream integrations may need time to reconnect. Confirm actual new events are arriving rather than relying on a successful ping alone.
UI unavailable during a role transition
IBM warns that the UI may be inaccessible during the manual transition. Check cluster state through SSH and wait for the transition to settle according to the supported procedure; do not launch several conflicting HA commands in parallel.
10. Safe acceptance test
- HA status reports the expected Primary Active / Secondary Standby state before any test.
- Both hosts are Online, synchronized, and free of unresolved critical HA notifications.
- Primary, secondary, and cluster VIP addressing is documented and conflict-free.
- A controlled failover is planned, approved, and performed according to the version-specific IBM procedure.
- After failover, the expected node is Active and the VIP is reachable from required clients.
- New events and flows are confirmed in QRadar, not just basic IP connectivity.
- Critical apps, reports, integrations, and log sources are checked for reconnection.
- If tested, failback completes and the final primary/secondary roles match the intended design.
- Evidence, timings, outages, warnings, and the test outcome are recorded.
Official IBM references
- IBM QRadar 7.5 — HA overview
- IBM QRadar 7.5 — High-availability clusters
- IBM QRadar 7.5 — Manual failovers
- IBM QRadar 7.5 — Troubleshooting HA deployments
- IBM QRadar 7.6 — Switching the primary HA host to Active
- IBM QRadar 7.5 — Deployment overview and HA roles
- IBM QRadar — HA mount and upgrade preparation checklist
- Security Learning Academy course provided in the original notes
HA operations and supported architectures vary by QRadar release and deployment. Use the matching IBM High Availability Guide. If node state or data synchronization is unclear, stop before switching roles and contact IBM Support.
For QRadar HA design or failover-readiness reviews, contact me with the host roles, versions, synchronization status, and recovery objectives.