After the future removal of the classic playbook editor, your existing classic playbooks will continue to run, However, you will no longer be able to visualize or modify existing classic playbooks.
For details, see:
About clusters
supports clustering.
A cluster consists of a minimum of three instances of and its supporting external services; file shares, a PostgreSQL database or database cluster, Splunk Enterprise, and at least one load balancer, such as HAProxy.
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, both the PostgreSQL database and the deployment of Splunk Enterprise are externalized from the instances. This allows you to scale your database and Splunk Enterprise deployments separately from the nodes.
Splunk SOAR (On-premises) clusters add a level of system redundancy and scaling to your deployment. However, SOAR does not have the ability to automatically scale, or automatically add or remove cluster nodes through external systems such as Kubernetes, AWS, or Azure.
Before creating a cluster, work with your delivery team representative to assess your needs and design your cluster.
Do not use this release to create new clusters of Splunk SOAR (On-premises).
Use this release to upgrade from your current privileged deployment of Splunk Phantom 4.10.7 or Splunk SOAR (On-premises) releases 5.0.1 through 5.3.4.
If you are upgrading a privileged deployment of Splunk Phantom 4.10.7 or Splunk SOAR (On-premises) releases 5.0.1 through 5.3.4, upgrade to release 5.3.6, convert your deployment to unprivileged, then upgrade again directly to Splunk SOAR (On-premises) release 6.1.1 or higher.
If you have a privileged deployment of Splunk SOAR (On-premises) release 5.3.5, convert your deployment to unprivileged, then upgrade directly to Splunk SOAR (On-premises) release 6.1.1 or higher.
To learn how to upgrade see Splunk SOAR (On-premises) upgrade overview and prerequisites.
Why build a Cluster?
Clustering addresses several important needs:
- Clustering adds horizontal scaling for workloads, allowing for increased capacity.
- Clustering adds redundancy for the platform. One or more cluster nodes can fail and you still have a functioning deployment of .
- Clustering removes system downtime for upgrades or maintenance. You can upgrade individual cluster nodes without taking the entire deployment offline.
Building a cluster
Clusters can be built in the following ways.
- From privileged installations, where required services are provided by servers external to . Each node is converted from a TAR file installation using the
make_cluster_node.pyc
script. See Create a cluster from aTAR installation file. - From unprivileged installations, where required services are provided by servers external to . Each node is converted from a TAR file installation using the
make_cluster_node.pyc
script. See Create a cluster using an unprivileged installation.
Log in to the web interface | Create a cluster using a privileged installation |
This documentation applies to the following versions of Splunk® SOAR (On-premises): 5.3.6
Feedback submitted, thanks!