Chat now with support
Chat with Support

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

Disaster Scenarios in joint SPP and SPS deployments

The scenarios are handled the same way in the case of joint deployments and individual SPP and SPS clusters. Additional possible issues include:

SPP-initiated workflows

Losing the SPS configuration primary

Losing the SPP primary appliance: all of the functionality works until no configuration changes are required, SPP nodes reach out to SPS directly.

SPS-initiated workflows

Losing the SPS configuration primary

Losing the SPP primary appliance:

  • SPS stores all the SPP cluster members and for password requests SPS connects to the first available node, starting with the primary node. If the primary node is not available, SPS makes a connection attempt to other nodes.

  • SPS fetches information about the SPP cluster from the IP address that the SPS was joined with originally (the primary node at the time of the join). If an SPP is available at the IP address, which is not necessarily the primary node, the SPS cluster detects changes in the configuration.

  • If a SPP cluster member can be replaced or reconnected on the same address, you do not need to do anything manually and traffic is not interrupted.

  • If a SPP cluster member is permanently lost and cannot be replaced or reconnected, you need to use the new primary node to unjoin and rejoin the clusters.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating