Skip to main content

Manual Self-Hosted High Availability IQ Server Deployment

This topic covers the process for manually setting up a self-hosted high availability (HA) IQ Server deployment.

Use Cases

IQ HA is designed to protect against the following scenarios:

  • Failure of an individual IQ Server node

  • Virtual machine or bare-metal host failure

  • Planned or unplanned downtime of a single server

HA also enables horizontal scaling of IQ Server instances to support increased analysis and policy evaluation workloads.

Requirements

A manual HA IQ deployment consists of multiple Nexus IQ Server instances configured identically and connected to shared infrastructure components.

Manual self-hosted IQ HA deployments must meet the following requirements:

  • All nodes in the cluster must run on the same supported Nexus IQ Server version. Mixed-version clusters are not supported.

  • HA deployments require reliable, low-latency network connectivity between all IQ Server nodes to the shared filesystem and the database.

  • An external load balancer is required to distribute client traffic across IQ Server nodes. Load balancer configuration is external to IQ Server and must be managed independently.

  • All nodes require local storage to be used for logs and node-specific runtime data. Local storage is not shared between nodes and must have sufficient capacity for log retention and support artifacts.

  • Shared storage must be accessible by all IQ Server nodes and be mounted at the same filesystem path on each node.

  • All IQ Server nodes must connect to the same external PostgreSQL database.

  • The IQ Server license must be persisted to be available to all nodes.

  • Each IQ Server instance must be configured identically with the following:

    • A local sonatypeWork directory for node-specific data

    • A clusterDirectory that points to the shared network filesystem. This directory must reference the shared filesystem path and be identical on every node.

    • Identical database configuration across all nodes

Network File System Setup

HA Nexus IQ Server deployments require shared storage for cluster coordination data. To set up your NFS, take the following steps:

  1. Prepare an NFS export directory by creating a local mount point for shared storage. Ensure permissions on the NFS export directory allow read/write access and ownership.

  2. Configure NFS exports to define the NFS share. Ensure that the NFS share is accessible with read/write, synchronus, and no_subtree_check options for each IQ Server node's IP address.

  3. Activate NFS exports by reloading the NFS server configuration to make the new exports active.

Shared Storage Mount

HA deployments of Nexus IQ Server require shared storage for cluster coordination data. This must be writable by all IQ Server nodes, mounted at the same filesystem path on every node, and use consistent ownership and permissions.

Create a local mount point on each IQ Server node; mount the NFS share to the local mount point on each node.

Configure and Deploy Nexus IQ Server

Each IQ Server instance must be configured identically. Key configuration requirements include the following:

  • A local sonatypeWork directory for node-specific data

  • A clusterDirectory that points to the shared filesystem

  • Identical database configuration across all nodes

The cluster directory must reference the shared filesystem path and must be the same on every node. Any mismatch in configuration may prevent the cluster from forming correctly.

  1. Download and extract Nexus IQ Server onto each node.

  2. Configure Nexus IQ Server (config.yml) identically on each node to add the persisted license and a clm-cluster directory. See the following example:

      config:
    sonatypeWork: "/sonatype-work/clm-server" #local disk
    clusterDirectory: "/sonatype-work/clm-cluster" #network disk

  3. Prepare the PostgreSQL database on a third machine.

  4. Start Nexus IQ Server on each node.

Test the Configuration

To validate that your HA IQ Server deployment is working as expected, we recommend taking the following steps:

  1. Check clm-server.log on each machine for errors.

  2. Run a scan against each server.

  3. Access each node's user interface.