Clustering and High-Availability

There are a variety of possibilities for establishing High-Availability, Redundancy, or Failover with Pleasant Password Server.

Pleasant Password Server can handle multiple simultaneous servers, and is compatible with the systems and database configurations which make it High-Availability possible.

There are numerous popular products which can manage connectivity and resourcing should primary resources fail.

Related Topics:

Achieving Maximum Uptime

For mission critical enterprises, we suggest using a product in your environment such as a SAN with vMotion and clustering to achieve the best uptime. This way if one of your hosts dies, the traffic will shift to another working host and you should see virtually no downtime.

Sample connectivity diagram:



Review the Pleasant Password Server End User License Agreement. So long as the information within the database is archival, an inactive secondary activation of the license is permitted for backup/testing purposes. All activations are recorded on our licensing server.

For active-active set ups or load balancing, additonal licensing is required. Contact Us for a Quote.

Setup Steps for Alternate Servers

A supported configuration for Enterprise Edition can be setup as follows:

1. Install an instance of Pleasant Password Server on an alternate server and activate with your product key.

2. Use the Database Backup feature to create an archival copy and store on the alternate server.

3. In the case of a system outage, access the alternate server and Restore the Database of your choice.

4. Contact users to update their connection path. 

Settings and configuration are stored within the database so no other set up should be required for users to log in, unless there have been changes to AD/LDAP integration. Always maintain a local admin account for these instances.

Always ensure you back up your database and encryption key.

Multi-Server Load Balancing
Edit section

Pleasant Password Server supports running more than one simultaneous instance against a database: "active-active", "active-passive", or "active-failover" configuration.

Web Service Host failover

To see how to setup a web service host failover, look at this Nginx example.

The service does not have an built-in redirect feature, as the service or host would have to fail for the redirect to occur. An independant secondary service is therefore required to redirect traffic.

Domain Controller Load Balancing

Active Directory/LDAP servers have built-in standard features of load balancing and redundancy. For more information, it is possible to lookup these details for your Directory type.


  • We recommend pointing the Password Server Directory to the domain of the AD/LDAP servers, and allowing their directory services to handle the selection of best available domain controller. 
  • Another option is use a load balancer (hardware or software) in front of replicated LDAP servers on the same DNS.

For setting up Multiple Domains or Forests see this section in the AD/LDAP guide.

Database failover

Pleasant Password Server can be configured to use enterprise-level databases that themselves incorporate mirroring, replication, and automatic failover.

Windows Server Failover Cluster (WSFC)

Always On Availability Groups allows a secondary server (secondary replica) to take over (automatically/manually) if the first server goes down for whatever reason.

PostgreSQL Warm Standby

PostgreSQL supports what is termed a warm Standby.

Server backups, reconfiguring DNS, etc. are subject to your local policies and infrastructure.

Replication Methods
Edit section

If a redundant database is used, it is recommended that it be promoted to primary, since re-merging of data is not a supported operation.

Activating or promoting a backup database is dependent on local policies and infrastructure.


  • Due to the limitations mentioned above, Merge replication is not supported.
  • In the case of Snapshot replication, any changes made to the primary database since the last snapshot would be lost. Even if the database is recovered, merging the changes into the backup is not supported.Edit section
Scenario 1: Redundant databases with manual failover
Edit section

In this case, an IT administrator would be notified of a failure in the database used by Pleasant Password Server. They would disable the primary database and promote the backup database to primary. Then, they would log on to the machine where Pleasant Password Server was installed and use the Service Configuration Utility to select the secondary database as the one being used.

Restoring would involve disabling Pleasant Password Server, backing up the database from the secondary server, restoring it to the primary, and then re-enabling Pleasant Password Server.

Scenario 2: Redundant databases with automatic failover
Edit section

In this scenario, a primary web server with Pleasant Password Server installed and running) points to the primary database, while a redundant web server (with Pleasant Password Server installed, but not running) is configured to point to a backup database. These would be behind a load balancer which can signal a failure, in which case:

  • The primary database is disabled,
  • The primary web server is disabled,
  • The secondary database is promoted,
  • The secondary web server is activated, and
  • The load balancer serves information from the secondary web server instead.


We don't recommend that systems are configured to automatically return to the primary system, as occurrence of data loss is probable due to lack of merge ability.

Tag page
You must login to post a comment.