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 Phantom.
- You may wish to failover even if the primary instance of Splunk Phantom is healthy in order to perform system maintenance or upgrades without significant downtime.
Do these steps as the root user or a user with sudo permissions.
- If the primary instance of Splunk Phantom is online, you must stop all Splunk Phantom services. The warm standby will not take over if it detects that the primary instance is still operating. /<PHANTOM_HOME>/bin/stop_phantom.sh
- SSH to your warm standby Splunk Phantom instance. SSH <username>@<warm_standby_phantom_hostname>
- Run the setup_warm_standby.pyc script to convert the standby to the primary.
On Splunk Phantom instances version 4.6.19142 or newer:phenv python2.7 /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --convert-to-primary --ignore-package-updatesOn Splunk Phantom instances version 4.6.18265 or earlier:phenv python2.7 /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --convert-to-primary
- Update DNS to resolve the hostname of your Splunk Phantom instance to the IP address of the new primary.
- 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 Phantom. The previous primary should be offline.
Do not reboot or restart Splunk Phantom services on the decommissioned primary. It can lead to two standalone instances of Splunk Phantom polling the same assets, and lead to data loss or other unwanted behavior.
Create a warm standby
Disable warm standby
This documentation applies to the following versions of Splunk® Phantom: 4.8