Failover to the warm standby

Failing over to the warm standby is a manual process.

  • You can failover to the warm standby in the event of a systems failure with the primary instance of Splunk SOAR (On-premises).
  • You may wish to failover even if the primary instance of Splunk SOAR (On-premises) is healthy in order to perform system maintenance or upgrades without significant downtime.

Failover procedure

Do these steps as the phantom user.

  1. If the primary instance of Splunk SOAR (On-premises) is online, you must stop all Splunk SOAR (On-premises) services. The warm standby will not take over if it detects that the primary instance is still operating. 
    /<PHANTOM_HOME>/bin/stop_phantom.sh
  2. SSH to your warm standby Splunk SOAR (On-premises) instance. 
     SSH <username>@<warm_standby_phantom_hostname>
  3. Run the setup_warm_standby.pyc script to convert the standby to the primary.
    On Splunk SOAR (On-premises) instances version 4.6.19142 or newer:
    phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --convert-to-primary --ignore-package-updates
    On Splunk SOAR (On-premises) instances version 4.6.18265 or earlier:
    phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --convert-to-primary
  4. Update DNS to resolve the hostname of your Splunk SOAR (On-premises) instance to the IP address of the new primary.
  5. If you are ingesting from external services, you will need to update their configurations to use the new primary. Elasticsearch users will need to manually reindex in Main Menu > Administration > Administration Settings > Search Settings.

After the failover procedure, the warm standby is now the primary instance of Splunk SOAR (On-premises). The previous primary should be offline.

CAUTION: Do not reboot or restart Splunk SOAR (On-premises) services on the decommissioned primary. It can lead to two standalone instances of Splunk SOAR (On-premises) polling the same assets, and lead to data loss or other unwanted behavior.