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

The sections in this chapter describe how High Availability works in the Safeguard product line.

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 a password change, 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. You can request passwords and sessions from any appliance in a Safeguard cluster.

Figure 3: High Availability in SPP

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 is online and can communicate. If a cluster loses consensus, it goes into a read-only mode to prevent data inconsistencies and password check and it disables configuration changes. Offline Workflow Mode allows you to configure to either maintain or suspend access request workflows when consensus is lost.

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

In case of physical appliances, add a hot-spare pair to every appliance to ensure high availability (HA). Place the two appliances ideally adjacent to each other and connect them with a direct cross cable. The secondary node in the pair replicates the entire disk contents of the primary node, including all configuration and audit recordings. The secondary node keeps all of its outside network connections in a disconnected state and serves no traffic until it takes over the role of the primary. You can initiate takeovers manually, or they are performed automatically if the primary node does not reply to the periodic heartbeat checks.

Figure 4: High Availability in SPS

High availability is not available and not required for virtual appliances. All enterprise virtualization environments support high availability on the hypervisor level, which is more optimal compared to a host-based approach.

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

To provide high availability (HA) in joint deployments, have at least 3 SPP nodes and add HA pairs to all SPS nodes. An SPP cluster of at least 3 nodes provides data redundancy and HA for the SPP functionality. In case a hot-spare SPS appliance needs to take over the primary role in a SPS HA pair, the SPP cluster automatically directs new connections to the new primary. This also solves the availability of all audit information in case of a hardware failure.

Figure 5: Joint SPP-SPS deployment