Active/Active Deployment Model

The Active/Active deployment model can be implemented using Physical, Virtual or cloud U-Series Appliances. It requires the use of an external Microsoft SQL Server database with Always On availability groups for data consistency and high availability.

As many U-Series Appliances as required can be configured to connect to the database. In this case, all U-Series Appliances can be used at once, and are fully redundant; if one goes down, you switch to an alternative. Always On availability groups may be configured with a mix of synchronous commit and asynchronous commit replicas to provide real-time database redundancy.

In an Active/Active deployment, the active nodes don’t need to be the same U-Series Appliance version. For example, they may be a mix of 2012 and 2016 nodes.

For supported version information, please see the BeyondTrust Password Safe Supported Platforms Guide.

Database Configuration

The deployment and configuration are the responsibility of the customer but the following guidelines should be noted in the creation and configuration of the replicas:

The database must be created by our software during the installation process. It cannot be created beforehand. After the database has been created, apply the following settings:

  • Place SQL data and log files on separate volumes and isolate from other applications using the same volume, if possible.
  • Default collation.

Data file size should be initialized at 300GB. This value varies according to scoping.

  • Log file size should be initialized at 30GB (vary according to scoping).
  • Auto growth should be on and set to a fixed amount (we recommend 3GB) instead of a percentage (vary according to scoping)
  • Instant file initialization should be enabled.
  • Tempdb should be moved to a non-system drive, if possible.
  • Shrink should not be enabled, can be done manually in certain scenarios if necessary.

A maintenance plan should be in place to regularly backup the transaction log, this should keep the file growing infinitely.

The number of nodes in the availability group will depend on customer requirements, as will the name of the nodes and listener. When creating the database during the installation process you will point to the address of the group listener. Once the database has been created you can make it available in Always On.

For steps on adding to Always On, please see Add a Database to an Always On availability group.

Single Site Deployment

A single site can contain a number of U-Series Appliances for redundancy.

In this scenario, a pair of replicas is configured for synchronous commit within an external Always On availability group. This provides database redundancy. Three U-Series Appliances are connected to the external address of the availability group. One is configured with a management console role; the other two are worker nodes. Access to U-Series Appliances can be made directly or with a load balancer. Both U-Series Appliances can be used simultaneously. Session recordings are stored on the U-Series Appliance in use. Recordings may optionally be sent to a separate archive server based on disk utilization or retention.

Diagram of single site deployment model in an active/active deployment.

Multi-Site Deployment

In this example, multiple data centers are connected to an Always On availability group. You can see that many more U-Series Appliances can be added, each with varying roles, such as: Scanners, Event Servers, Password Portals, Session Managers, and Password Management.

Behind load balancers, U-Series Appliances can be added for redundancy and scalability. For example, session managers configured to send recordings to archive servers can be brought down with no loss of data or functionality. In this example, an additional async commit replica has been added to provide a disaster recovery (DR) capability. An additional U-Series Appliance in the DR site is pointed to the DR replica for retrieval of passwords if access to the main infrastructure is lost. As many U-Series Appliances may be added as required, and pointed at the availability group.

SQL Server has a single master model; therefore, only one replica has write access at any one time. However, replicas may be located in multiple locations for the event of database failover.

Diagram of multiple site deployment model in an active/active deployment.

On-Premise with Cloud DR Deployment

In this example, we are using Azure to store a replica of Password Safe so that in the event that all on premise components fail, operation may continue by releasing passwords from the Cloud. Microsoft SQL Always On availability groups may consist of a primary replica, and up to 8 secondary replicas in either synchronous - commit or asynchronous-commit (SQL Server 2014 and later).

Replicas are supported in both Azure and AWS environments; a typical deployment model comprising an asynchronous replica in the cloud provides access to password data in the event that all on-prem components become unavailable.

On-Premise with Cloud DR Deployment