Clustering and High-Availability
There are a variety of possibilities for ensuring High-Availability (HA) for Pleasant Password Server by having component Redundancy.
Have Questions? Contact Us!
Achieving Maximum Uptime
For mission critical enterprises, Pleasant Password Server supports Multi-Server Load Balancing: multiple servers running simultaneously against a database cluster ("active-active", "active-passive", or "active-failover" configurations).
- Active-Active Password Servers - Hosted with IIS and a Database Cluster:
- Active-Passive Password Servers - Hosted without IIS - Database/Failover
For more information: on each HA component, see the section headings below.
- Pleasant Password Server can handle multiple simultaneous servers, and is compatible with other systems and database configurations which can High-Availability possible.
- There are also numerous popular products which can be integrated to manage connectivity and resourcing should primary resources fail.
- Cloud Hosting with IIS
- Cloud Hosting
- Setting up Failover
- Disaster Recovery
- Data Recovery Options
- Hardware and Software Requirements
- We recommend 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.
Review the Pleasant Password Server End User License Agreement.
An inactive secondary activation of the same license is permitted for Backup/Testing purposes, as long as the information is archival in nature.
For High-Availability configurations, the same license can be used for 1 or 2 additional servers which are connected to the same database. For a larger configuration with 3 or more servers, please Contact Us for a Quote.
All activations are recorded on our licensing server.
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.
Hosting - Server Load Balancing
Password Server can run multiple servers (active-active) using IIS Hosting, for example, or active-passive servers which would switch upon failure.
Hosting - Server 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 independent secondary service is therefore required to redirect traffic.
To configure access from remote locations or from external users, consider these configuration options.
Domain Controllers - 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.
Password Server synchronizes itself on a schedule with AD/LDAP.
- 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 section: "Using Multiple Domains and Forests" in the AD/LDAP guide.
Database - Clustering/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.
- This replaces the older Transactional replication method for MS SQL
PostgreSQL Warm Standby
PostgreSQL supports what is termed a warm Standby.
Server backups, re-configuring DNS, etc. are subject to your local policies and infrastructure.
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.
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 occurrence of data loss is probable due to lack of merge ability.