While Pleasant Password Server does not specifically contain any redundancy or failover features, it is compatible with database and infrastructure systems that enable these types of features. 

Server failover

Pleasant Password Server incorporates an in-memory cache, so running more than one simultaneous instance against a database is not advised. Multiple installs can be configured to run against the same database, provided they're not running concurrently. Server backups, reconfiguring DNS, etc. are subject to your local policies and infrastructure.

Database failover

Database Recovery Process

It's recommended that if a redundant database is used during an outage that it be promoted to primary, since re-merging of data is not a supported operation. Note that this affects selection of replication methods. 

Replication Methods
Edit section

Pleasant Password Server can be configured to use enterprise-level databases that themselves incorporate mirroring or replication. We recommend a Transactional replication method, something which PostgreSQL and Microsoft SQL Server support.

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.

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

 

Possible implementations:

Scenario 1: Redundant databases with manual failover

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

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 occurence of data loss is probable due to lack of merge ability.

Tag page
You must login to post a comment.