Chat now with support
Chat with Support

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

High Availability

The following describes how High Availability works in the Safeguard product line.

High Availability in One Identity Safeguard for Privileged Passwords (SPP)

In an SPP cluster, all vital data that is stored on the primary appliance is also stored on the replicas. The replicas provide a read-only view of the security policy configuration. You cannot add, delete, or modify the objects or security policy configuration on a replica appliance, but you can perform password change and check operations and make password release and session access requests. Users can log in to replicas to request access, generate reports, or audit the data. Also, passwords and sessions can be requested from any appliance in a Safeguard cluster.

In the event of a disaster, where the primary appliance is no longer functioning, you can promote a replica to be the new primary appliance.

The full operation requires that the cluster has consensus (quorum). Consensus means that a majority of the clustered appliances are online and able to communicate. If a cluster loses consensus, it goes into a read-only mode to prevent data inconsistencies and password check and change is disabled. You can configure whether you want to maintain or suspend access request workflows when consensus is lost via the Offline Workflow Mode setting.

For more information, see Disaster recovery and clusters in the One Identity Safeguard for Privileged Passwords Administration Guide.

High Availability in One Identity Safeguard for Privileged Sessions (SPS)

In case of physical appliances, high availability can be ensured by adding a hot-spare pair to every appliance. The two appliances are ideally placed adjacent to each other and are connected by a direct cross cable. The “minion” node in the pair replicates the entire disk contents of the “master” node, including all configuration and audit recordings. It keeps all of its outside network connections in a disconnected state and serves no traffic until it needs to take over the role of the master. Takeovers can be initiated manually, or they are performed automatically if the master node does not reply to the periodic heartbeat checks.

High availability is not available and not required for virtual appliances. The reason for that is that all enterprise virtualization environments support high availability on the hypervisor level, which will always be more optimal than what a host-based approach could provide.

For more information, see "Managing a High Availability One Identity Safeguard for Privileged Sessions (SPS) cluster" in the Administration Guide.

High Availability in joint SPP and SPS deployments

To provide high availability in joint deployments, have at least 3 SPP nodes and add high availability pairs to all SPS nodes. As described above, an SPP cluster of at least 3 nodes provides data redundancy and high availability for the SPP functionality. In case a hot-spare SPS appliance needs to take over the master role in an SPS HA pair, the SPP cluster will automatically direct new connections against the new master. This solves the availability of all audit information in case of a hardware failure, too.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating