An overview of the Splunk SOAR (On-premises) clustering feature

A cluster consists of a minimum of three instances of Splunk SOAR (On-premises) and its supporting external services; file shares, a PostgreSQL database or database cluster, a Splunk Enterprise or Splunk Cloud deployment, and a load balancer.

Splunk SOAR (On-premises) clusters provide horizontal scaling and redundancy. Larger clusters provide the capacity to handle larger workloads than a single Splunk SOAR (On-premises) instance, and provide benefits in terms of redundancy and reduced downtime for upgrades or other maintenance.

Note: Splunk SOAR (On-premises) does not have the ability to automatically scale, or automatically add or remove cluster nodes through external systems such as Kubernetes, AWS, or Azure.

Elements of a Splunk SOAR (On-premises) cluster

The primary elements of a Splunk SOAR (On-premises) cluster are:

  • a load balancer, such as HAProxy or Elastic Load Balancer
  • three or more Splunk SOAR (On-premises) nodes
  • a PostgreSQL database
  • file shares
  • either a Splunk Enterprise or Splunk Cloud deployment
Note: As of release 7.0.0, a Splunk SOAR (On-premises) clustered deployment can be paired to Splunk Enterprise Security.

See Pair Splunk SOAR (On-premises) with Splunk Enterprise Security in Administer Splunk SOAR (On-premises).

A Splunk SOAR (On-premises) cluster uses RabbitMQ for a messaging bus and queues.

This diagram shows an example of a Splunk SOAR (On-premises) cluster, with the connections marked.

A diagram of a Splunk SOAR (On-premises) cluster showing the connections between components using arrows. The diagram shows from left to right, an icon for the Splunk SOAR (On-premises) web UI, a load balancer, three Splunk SOAR (On-premises) cluster nodes in a column, then another column with PostgreSQL database at the top, a file share, and at the bottom an icon representing either a Splunk Enterprise or Splunk Cloud deployment.

The role of RabbitMQ

Splunk SOAR (On-premises) clusters use a RabbitMQ cluster to send messages between nodes.

Network failures between cluster nodes may result in network partitions (also sometimes called a split-brain), and by default, RabbitMQ requires manual intervention to recover from a network partition. When the RabbitMQ cluster is in a network partitioned state, messages sent between Splunk SOAR cluster nodes may be lost in undefined ways, which can disrupt automation and ingestion.

Splunk SOAR (On-premises) releases 6.1.0 and higher implements RabbitMQ's built-in cluster_partition_handling setting strategy of autoheal by default.

RabbitMQ nodes operate as either RAM nodes or DISC nodes. DISC node persist more state information to disk than RAM nodes. In Splunk SOAR (On-premises) 6.1.0 and later releases, all RabbitMQ nodes are set to DISC.