Splunk SOAR (On-premises) cluster upgrade process

A checklist and supporting information describing the upgrade process for a Splunk SOAR (On-premises) cluster.

Splunk SOAR (On-premises) cluster upgrade process

This topic gives a general overview of the Splunk SOAR (On-premises) upgrade process for clustered deployments.

General principles for upgrading a cluster

These are some guiding principles to use when upgrading your Splunk SOAR (On-premises) cluster.

  • Always take a backup of the Splunk SOAR's PostgreSQL database before beginning any cluster upgrade.
  • Finish a cluster upgrade quickly. Do not leave a cluster only partially upgraded.
  • Upgrade a cluster one node at a time. Do not attempt to upgrade multiple cluster nodes simultaneously.
  • During any cluster upgrade, or when adding or removing nodes, a cluster must have a minimum of three cluster nodes.
  • All cluster nodes must run the same software version of Splunk SOAR (On-premises) except during an upgrade.
    • During the upgrade some cluster nodes that have been upgraded will have a newer release of the Splunk SOAR (On-premises) software than other nodes in the cluster. This is normal.
    • During a cluster upgrade, upgrade your cluster nodes one Splunk SOAR (On-premises) software release at a time. Once all the nodes in a cluster have been upgraded to a release version, you can proceed to upgrade your cluster to the next software release in your upgrade path.
    • If you must add or replace a cluster node, the new node must run the same version of Splunk SOAR (On-premises) as the existing nodes in your cluster.
  • Whichever Splunk SOAR software version is in the majority will determine the overall software version of the cluster.
  • Whenever possible, upgrade or migrate the host operating system separately from the Splunk SOAR software.
Table 1. Splunk SOAR (On-premises) cluster upgrade checklist
StepTasksDescription
1Identify your upgrade path.Determine which Splunk SOAR (On-premises) releases you will need to upgrade to, in order to arrive at your target release.
  • Deployments running a privileged Splunk SOAR (On-premises) cluster with releases earlier than release 5.3.5 should upgrade their cluster nodes to release 5.3.5, then convert to unprivileged before undertaking any further upgrades or migrations.
  • Deployments running an external PostgreSQL database older than PostgreSQL release 15, should upgrade cluster nodes to Splunk SOAR (On-premises) release 6.2.1 before undertaking any further upgrades or migrations.
    • Once the clustered deployment has been updated and is using PostgreSQL 15.x, deployments can upgrade further as needed.
  • Deployments running on hosts using the CentOS 7 operating system should upgrade to Splunk SOAR (On-premises) release 6.3.0 before any further upgrades or migrations.
    • Once the clustered deployment is successfully upgraded to Splunk SOAR (On-premises) release 6.3.0, migrate from CentOS 7 to a supported operating system.
  • Deployments running Splunk SOAR (On-premises) release 6.3.0, should upgrade cluster nodes to the latest release of Splunk SOAR (On-premises).

See:

2Make a full backup of your Splunk SOAR (On-premises) deploymentMake a full backup of your Splunk SOAR (On-premises) deployment before upgrading. See

Backup or restore your Splunk SOAR (On-premises) instance in Administer Splunk SOAR (On-premises).

Note: For deployments using Amazon Web Services RDS see the section "Create a full backup for deployments with an external PostgreSQL database in RDS" in the linked topic.
3Perform the prerequisitesSee Prerequisites for upgrading Splunk SOAR (On-premises).
  1. Obtain logins
  2. Make sure the Splunk SOAR (On-premises) cluster nodes have enough available space. See Splunk SOAR (On-premises) upgrade overview and prerequisites.
  3. If your Splunk SOAR (On-premises) deployment is using an external PostgreSQL database earlier than 15.x must upgrade PostgreSQL to release 15.x before upgrading the SOAR cluster to a release higher than 6.2.1.
  4. Conditional: Turn off scheduled backups. For example, if you scheduled backups with a cron job, deactivate the cron job to turn them off.
4Prepare your system for upgradeSee Prepare your Splunk SOAR (On-premises) deployment for upgrade.
5Upgrade Splunk SOAR (On-premises) the first cluster node to your next target release.After all the preparation stages are complete, you can upgrade your first Splunk SOAR (On-premises) cluster node. See Upgrade Splunk SOAR (On-premises).
6Validate the Splunk SOAR (On-premises) cluster's status.

Check that the new cluster node's status. See How to view a Splunk SOAR (On-premises) cluster's status. If your cluster nodes are healthy, proceed with the rest of the cluster upgrade process.

7Upgrade Splunk SOAR (On-premises) the other cluster nodes, one at a time.See Upgrade Splunk SOAR (On-premises). Upgrade the Splunk SOAR (On-premises) software to the target release on each of the remaining cluster nodes. Upgrade only one cluster node at a time, pausing to check the cluster health before moving on to the next cluster node.
Note: Do not attempt to upgrade all the cluster nodes at once.
8Conditional: Upgrade Splunk SOAR Automation Brokers. If your clustered Splunk SOAR (On-premises) deployment uses any instances of the Splunk SOAR Automation Broker, make sure to upgrade them to a version supported by your version of Splunk SOAR (On-premises).

See Upgrade or update the Splunk SOAR Automation Broker in Set Up and Manage the Splunk SOAR Automation Broker.

9Conditional: Migrate or upgrade to a supported operating system.See:
10Conditional: If needed, upgrade cluster nodes to the target Splunk SOAR (On-premises) release.Upgrade the Splunk SOAR (On-premises) software to the target release on each of your cluster nodes. Upgrade only one cluster node at a time, pausing to check the cluster health before moving on to the next cluster node.
Note: Do not attempt to upgrade all the cluster nodes at once.
11Conditional: Upgrade Splunk SOAR Automation Brokers. If your clustered Splunk SOAR (On-premises) deployment uses any instances of the Splunk SOAR Automation Broker, make sure to upgrade them to a version supported by your version of Splunk SOAR (On-premises).

See Upgrade or update the Splunk SOAR Automation Broker in Set Up and Manage the Splunk SOAR Automation Broker.

Supported operating systems

A Splunk SOAR (On-premises) cluster can run on a mix of supported operating systems. For example, you may have two of your three nodes running Oracle Linux 8, and one running Red Hat Linux 8.

Note: Different operating systems may require different versions of software dependencies, such as GlusterFS. Because the dependencies can have differences in supported features, using different operating systems for each node may cause compatibility issues for the cluster.
See General system requirements in Install and Upgrade Splunk SOAR (On-premises) for a list of supported operating systems.

A simple example of an in-place cluster upgrade

A simple example of the cluster upgrade process.

  1. A cluster comprised of three cluster nodes is being upgraded from Splunk SOAR (On-premises) release 6.3.1 to release 6.4.1.
  2. After the the first cluster node has its software upgraded, you would have two cluster nodes running release 6.3.1, and one cluster node running 6.4.1. The overall software version of the cluster is release 6.3.1, and the cluster node running release 6.4.1 is temporarily inactive.
  3. Once the a second cluster node has its software upgraded to release 6.4.1, the overall software version for the cluster is now 6.4.1, and the single node still running release 6.3.1 is temporarily inactive. At this point in the upgrade, Splunk SOAR (On-premises) applies important changes such as database migrations, and activating new features.
  4. After the third cluster node is upgraded, the Splunk SOAR (On-premises) cluster's overall software version is 6.4.1 and all cluster nodes are active.
A four-stage diagram showing the process during an upgrade of a three-node Splunk SOAR (On-premises) cluster, from Splunk SOAR (On-premises) release 6.3.1 to release 6.4.1. The first stage shows no cluster nodes have been upgraded. The second stage shows a single cluster node has been upgraded. The third stage shows two of three nodes have been upgraded. The fourth stage shows all nodes have been upgraded.