About Splunk SOAR (On-premises) clusters
Splunk SOAR (On-premises) supports clustering.
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, and at least one load balancer, such as HAProxy.
Splunk SOAR (On-premises) clustering uses additional technologies to support the cluster:
- GlusterFS for file shares. Other file systems, such as NFS can be used instead of GlusterFS.
- Consul to provide action locking as needed.
- RabbitMQ to provide a fast, reliable messaging bus.
- HAProxy as a load balancer. Alternate load balancers can be used instead of HAProxy.
In a cluster, the PostgreSQL database is externalized from the Splunk SOAR (On-premises) instances. This allows you to scale your database separately from the Splunk SOAR (On-premises) nodes.
Before creating a cluster, work with your Splunk SOAR (On-premises) delivery team representative to assess your needs and design your cluster.
Why build a Splunk SOAR (On-premises) Cluster?
Clustering addresses several important needs:
- Clustering adds horizontal scaling for Splunk SOAR (On-premises) workloads, allowing for increased capacity.
- Clustering adds redundancy for the Splunk SOAR (On-premises) platform. One or more cluster nodes can fail and you still have a functioning deployment of Splunk SOAR (On-premises).
- Clustering removes system downtime for upgrades or maintenance. You can upgrade individual Splunk SOAR (On-premises) cluster nodes without taking the entire deployment offline.
Building a Splunk SOAR (On-premises) cluster
Clusters are built from unprivileged installations, where required services are provided by servers external to Splunk SOAR (On-premises). Each Splunk SOAR (On-premises) node is converted from a TAR file installation using the make_cluster_node.pyc
script. See Create a Splunk SOAR (On-premises) cluster using an unprivileged installation.