Here are some possible deployment strategies for Privileged Identity. Included are descriptions of bare minimum deployments through enterprise deployments.
Single Server, No High Availability
A bare-minimum installation uses a single server. The single machine hosts the database, management console, and web site service. The same system can also host the application launcher and session recording software. This system may be a virtual system or a physical system. If this is a production system, it requires at least two CPU cores and 4GB or more of RAM. The addition of Application Launcher to this host greatly increases CPU and RAM requirements.
Although not required, we recommend you install the database in its own instance (rather than a shared database instance) both for security and resource availability.
Backup is achieved by backing up the virtual machine or by backing up the database and encryption key. Virtual machine backup is achieved by using a solution appropriate to your virtual host. Database backup is performed by configuring a backup job using SQL Management Studio.
This deployment solution provides minimum scalability and no high availability. This solution is suitable for testing and for small environments, due to memory, storage, and high availability constraints. The single-server solution also poses the greatest security risk as the encryption key and the encrypted data are hosted on the same server.
Multi-System, No High Availability
This minimum-deployment method includes two systems: one for a database and a second for a web app and management console. We recommend that you install Application Launcher on a separate system, if applicable.
The database system hosts the MS SQL database, preferably in its own instance, not shared with other applications. This machine may be a physical system or a virtual system.
The management console, web app, and web service may be hosted by a single virtual system. This system should have at least two CPU cores and 2 GB of RAM. Hard drive space should provide for multiple gigabytes of free space for log file growth, as required by the management console and web application.
This deployment solution provides scalability to meet most medium to medium-large environments that are generally well connected. Backup is achieved by backing up the virtual machine or by backing up the database. Virtual machine backup is achieved by using a solution appropriate to your virtual host. Database backup is performed by configuring a backup job using SQL Management Studio.
Multi-System, Minimum High Availability
We recommend that medium deployments include no fewer than three systems: at least two servers for database high availability, and one for the management console, web app and web service. We recommend that application launching be deployed on a separate system, if applicable.
The database utilizes database availability groups, mirroring, or database clustering to provide for higher availability.
Availability groups, also known as AlwaysOn, require only two database servers but can leverage more. This deployment method also offers a readable secondary server, which makes it very easy to work with reporting services tied to the non-modifiable copy of the database. Availability groups also allow up to two synchronous replicas and two asynchronous replicas to be simultaneously active. We recommend using availability groups as the high-availability architecture for the Privileged Identity database.
The AlwaysOn availability groups concept was introduced with MS SQL 2012.
Database mirroring requires the use of at least two database servers - one as a primary DB and any additional servers for failover. Database mirroring supports automatic and manual failover scenarios. At least two database systems are required for manual failover and three for automatic failover. In a manual failover, the database settings in the management console must be changed by hand, whereas in an automatic failover, the SQL Native Client and the witness server perform the failover.
Mirroring functionality was deprecated in SQL Server 2012.
Clustering may be used for the database in this type of deployment, but requires the use of shared hard drives and multiple network interfaces for each server.
Multi-System, Full High Availability
Large deployments will contain five or more servers:
- Two or more database servers
- One or two management console servers
- Two or more password retrieval web site servers
BeyondTrustrecommends installing Application Launcher on a separate system, if applicable. Additional transcoder/media servers should also be placed on separate servers.
While the provided image demonstrates one possible database configuration, there are actually multiple options for configuring the database:
- The two database servers can be configured as an availability group, without configuring the database as a failover cluster. If using an availability group, multiple replicas can be made available.
- The two database servers can be configured as a failover cluster. Additionally, you can mirror the clustered database to a single system or to another cluster of systems, which adds one or two more systems, respectively.
The Privileged Identity components are pointed to the active nodes in either scenario.
The two web servers are configured as a network load-balanced cluster, which may be either software-based or hardware-based. A network load-balanced cluster provides high availability to the data source, as well high-availability access to the data (stored passwords). This provides constant access to stored passwords, even if two or more servers should fail.
To deploy more than one management console in a highly available solution, deploy a secondary console on a separate machine. Loss of the management console results in the loss of the following abilities in a GUI:
- Configure data store settings
- Configure email settings and alerts
- Configure Application Launch
- Configure event sinks
- Configure or change encryption key
- Create new password change jobs
- Scheduled jobs: Will not run from the deferred processor, though zone processors that operate independently on secondary systems will continue to function.
In other words, the web app and web service communicate directly to the database, independent of the management console. The converse is also true, so disruption of one does not constitute disruption of the other.
The presence of a high-availability deployment does not negate the need for regular backups.