Clustering and High-Availability
Discover how Pleasant Password Server will enhance KeePass for business
There are a variety of methods to achieve High-Availability (HA) for Pleasant Password Server and have component Redundancy.
-
Have Questions? Contact Us!
Achieving Maximum Uptime
For mission critical enterprises, Pleasant Password Server supports multiple simultaneous servers (Multi-Server Load Balancing) on a database cluster ("active-active", "active-passive", or "active-failover" configurations). Password Server is compatible with other systems and database configurations which can make High-Availability possible.
- There are also numerous popular products which can be integrated to manage connectivity and resourcing should primary resources fail.
For more information: on each HA component, see the section headings at the bottom.
Active-Active Password Servers
- Hosted with IIS and a Database Cluster
- Notes:
- Replication is managed by the database (see sections below)
- Failover Cluster / Database Scaling can be used
Data Center Failover
Active-Passive Password Servers
- Hosted without IIS - Database/Failover
Related Topics:
- Cloud Hosting with IIS
- Cloud Hosting
- Setting up Failover
- Disaster Recovery
- Data Recovery Options
- Hardware and Software Requirements
Recommendation:
- 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.
Licensing
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.
Test/Backup 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.
Other High Availability Hardware Components
Other hardware components you may wish to use:
- SAN - SAN Replication,
- SQL Listener(s),
- Proxy Servers or Switches
Azure Integration
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.
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.
External User Access
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.
Options:
- 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 - High-Availability Options
Pleasant Password Server can be configured to use enterprise-level databases that themselves incorporate High-Availability:
- Clustering with failover,
- Replication to a mirror database,
- Database Scaling (Cloud provider)
Below are some examples.
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.
Cloud Database Scaling
Modern Cloud Database Providers are now providing Database Scaling, which allow for seamless scaling up of database capabilities with the size of your implementation
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.