Chat now with support
Chat with Support

One Identity Safeguard for Privileged Sessions 6.7.2 - Scalability and High Availability in Safeguard

Disaster Scenarios in joint SPP and SPS deployments

The same scenarios are handled in the same way as they would be in case of individual SPP and SPS clusters. In addition to those, there are a few additional potential concerns:

SPP-initiated workflows

Losing the SPS config master

Losing the SPP primary appliance: everything works fine as long as configuration changes are not required, SPP nodes reach out to SPS directly.

SPS-initiated workflows

Losing the SPS config master

Losing the SPP primary appliance:

  • SPS stores all the SPP cluster members and for password requests it connects to the first available node, starting with the primary. If that’s not available, it will try other nodes.

  • SPS fetches information about the SPP cluster from the IP address that it was joined with originally (the primary at the time of the join). If an SPP is available at that IP address (does not need to be the primary), the SPS cluster will learn about changes in the configuration.

  • If the SPP cluster member can replaced/reconnected on the same address, no manual action needs to be taken and the traffic will not be interrupted.

  • If a SPP cluster member is permanently lost and cannot be replaced/reconnected, the clusters need to be unjoined and rejoined using the new primary.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating