Sizing Guidelines

In this section, we cover sizing for a variety of elements in Privileged Identity, including databases, host systems, hard disks, and more.

Database Host Sizing

The database is the most critical part of the Privileged Identity infrastructure. It contains the data for the entire program and is the only piece of the software which would truly cause a production issue if it were to become unavailable. Database sizing covers not only the physical sizing of the database files but also the physical requirements of the server itself.

Database CPU and RAM Resources

Unless the proper RAM and CPU requirements are met, the database platform will not even turn on. The minimum specifications for a production Privileged Identity database are 2 GB of RAM and two CPU cores, though we recommend at least 4 GB of RAM and 4 CPU cores. This is sufficient for hundreds of managed systems, thousands of stored passwords, and an otherwise basic installation which does not include any zone processors.

Proper sizing involves base lining to determine the usage profile of the database. The database involves large amounts of read and comparatively small amounts of write transactions following the initial population of the database. The amount of data (number of systems, jobs, etc.) as well as the number of zone processors affects the requirements of the database.

The amount of system data there is to read and write has an obvious effect on the need for database resources. However, the frequency at which these items are read and written, and the amount of transactional data the server must service, will affect the threading and queuing resources required during any given transaction. To offset this transactional requirement, an increase in the available thread and queue capability is required. This is in large part achieved by adding more CPU and RAM.

An implementation with zone processors requires more database resources than those without. A zone processor, just like a default deferred processor, queries the database every N seconds to check for work to do (N is equal to the sleep time value defined for the zone processor and has a default value of 6 seconds).

In other words, a zone processor will check the scheduling status of every job in the database to determine which jobs are past due and will then run the most out-of-date job. This information is calculated by running a query in the database every N seconds per zone processor. For example, an implementation with 10 zone processors and 200 jobs will require the database to evaluate all 200 jobs, 10 times every 6 seconds. Then, if any zone processor must run a job, it will read and write to the database, while the other zone processors continue to perform queries every 6 seconds, looking for work.

Each zone processor requires a minimum of an additional 512 MB RAM on the baseline database server. Each zone processor requires 1/5th of a CPU core.

Example 1

Server Infrastructure Requirements without Zone Processors Environment Description:

  • System count: 1,000
  • Stored managed passwords: 2,000
  • Propagation enabled: yes
  • Number of base jobs: 20
  • Base job frequency: monthly
  • Number of re-randomization jobs per month: 200 (password recoveries)
  • Total number of password changes per year: (20 base x 12 months) + (200 re-randomizations x 12 months) = 2,640
  • History enabled: yes
  • Number of zones: 1 (default zone)

Recommended DB: 4 CPU cores, 4 GB RAM

Factors:

  • Small number of base jobs = low CPU, low RAM
  • Large number of recoveries resulting in re-randomization including propagation = add RAM
  • Large number of recoveries, year over year = add CPU cores in time
  • Single zone (no zone processors) = low CPU, low RAM.

In example 1, although there are a large number of monthly password recoveries that result in subsequent re-randomizations of the target account, overall CPU and RAM utilization remains low. The need for more CPU and RAM will be affected by the total number of systems, total number of jobs, and additional zone processors.

Example 2

Server Infrastructure Requirements with Zone Processors Environment Description:

  • System count: 1,000
  • Stored managed passwords: 2,000
  • Propagation enabled: yes
  • Number of base jobs: 20
  • Base job frequency: monthly
  • Number of re-randomization jobs per month: 200 (password recoveries)
  • Total number of password changes per year: (20 base x 12 months) + (200 re-randomizations x 12 months) = 2,640
  • History enabled: yes
  • Number of zones: 10 (default zones)

Recommended DB: 4-8 CPU cores, 9-10 GB RAM

Factors:

  • Small number of base jobs = low CPU, low RAM
  • Large number of recoveries resulting in re-randomization including propagation = add RAM
  • Large number of recoveries, year over year = add CPU cores in time
  • Multiple zone processors = add CPU, add RAM.
  • Baseline = 4 CPUs
  • Zone processor requirement = 10 zone processors x 1/5th CPU = +2 cores
  • Baseline = 4 GB RAM
  • Zone processor requirement = 10 zone processors x 512 MB = +5 GB

Database Storage Sizing

The following variables are used to calculate the size of the database:

  • Number of systems
  • Number of accounts
  • Number of passwords
  • Number of groups (system lists)
  • Amount of recoveries and other web operations
  • Number of delegations
  • Number of password jobs
  • Stored password history
  • Propagation turned on or off
  • Job failures
  • Job logging

With the exception of the secure file store, Privileged Identity stores only text in the DB fields, as opposed to storing binary data. Following are observed numbers from a Privileged Identity database running SQL 2008 x64 Enterprise Edition.

Initial Sizing

  • 4 MB (.92 MB Free) default formatted DB, with one dynamic group and one active directory query

Managed Items

  • System added to group (no information) = .0006 MB per system
  • System information and account usage = .005 MB per system
  • System added to a job = .0006 MB per system
  • Stored Password with job settings and first-time discovery information = .045 MB per new password
  • Job re-runs, stored passwords = .0017 MB per password history

Example: 

Given a system list with 1,000 systems, that change one account on each of those systems via one job, and in which the accounts are changed successfully on the first attempt, the initial database would be roughly:

    Initial size: 4 MB
+ (.0006 MB x 1,000 Windows systems)
+ (.005 MB x 1,000 optional initial discovery)
+ (.0006 MB x 1,000 systems in the job)
+ (.045 MB x 1,000 password change jobs)
Total: 55.2 MB

Note: If the optional discovery (which has no effect on jobs with propagation settings) is not performed, the size of the initial database is set to 55.2MB.

Password History

Password histories require approximately .0017 MB.

Example:

1,000 historical passwords, at 15 characters each, require an additional 1.7 MB. After the initial password change job, there are an additional 11 password change jobs which are added to the password history.

1.7 MB x 11 password changes = 18.7 MB

Note: No job info is stored with historic passwords.

Logging

Logging requirements vary, based on operations performed versus success versus failure rates. Logging consumes approximately 20 MB of space over the course of a year, assuming no failures are logged. The space consumed by logging grows linearly.

First Year

After one year for 1,000 Windows systems whose passwords change 12 times per year without propagation, the estimated size of the database is:

55.2 MB + 18.7 MB + 20 MB = 93.9MB

Annual Growth

Assuming no other changes, the database is expected to grow at the following rate:

1,000 systems x .0017 password history x 12 months + 1,000 systems x .0017 new password change jobs + 20 MB logs = 42.1MB per year

Actual Planned Size

The size of the database will likely be much larger due to the factors mentioned at the beginning of this section. In particular, job logging, web audit information, and account usage information will impact the physical size of the database the most. Once the base measurement is determined using the above math, for actual capacity planning, triple the minimum size of the database:

93.9 MB x 3 = 281.7MB for the first year

42.1 MB growth x 3 = 126.3MB projected actual growth per year

Management Console and Zone Processor Sizing

CPU and RAM

The management console and zone processors consume a small amount of RAM and CPU cycles when idle. At startup, the management console and scheduling service consume approximately 15-20 MB of RAM, with CPU utilization near 0%, and resources allocated as they work.

Both components are multi-threaded and can take advantage of as many CPU cores as are available when performing work (e.g. password rotation, discovery, etc.).

Note: Because Privileged Identity is a 32-bit application, no more than 2 GB of RAM will ever be available to each application.

During an operation, CPU utilization for either process is capped at 95% of available CPU resources, to ensure the system does not become unresponsive. Similarly, threading is throttled when total CPU resources reach 95%. No additional threads are launched until CPU utilization falls below 95%. When threads cannot be launched, total job performance will suffer. This condition may be avoided by the addition of additional CPU cores.

To help maintain RAM resources, plan your server's RAM capacity to include:

  • 2 GB RAM for the host OS
  • Additional RAM for other applications like anti-virus
  • 2 GB RAM for each Privileged Identity component installed on the host

To help maintain CPU resources, plan your server's RAM capacity to include:

  • 2 CPU cores for the host OS
  • CPU requirements for other applications like anti-virus
  • 2 CPU cores for each Privileged Identity application component installed on the host

The minimum recommendation for a host server is 4 CPU cores and 4 GB of RAM. During operations, additional CPU cores will improve overall job processing performance during multi-threaded operations.

The system also has a number of single-threaded operations that occur, where adding more CPU cores will not improve performance. Specifically:

  • Console operations, such as changing management sets or opening the stored jobs dialog, where the data for a dialog is read from the database and rendered on-screen. Improving the database and console performance, however, will improve the initial load and ensure a fast CPU, whereas sufficient RAM on the host will improve dialog load time.
  • Individual system operations. A job with 500 systems will dispatch 100 threads by default, to manage 100 systems. The remaining 400 will remain pending until there is at least a single available thread. During these operations, there may be 50 operations to perform against the host, such as getting system information, reading service target propagation info, and performing the propagation. These operations will be performed in a single-threaded, linear fashion against any particular host.

Logging

A number of logs are enabled by default for the following items:

  • Management Console Operations - Logs every operation performed in the management console.
  • Deferred Processor Service Log - Logs scheduling service activity such as when jobs are launched or finished.
  • Job Logs - Scheduled jobs create job log files named after each job ID. Each successive job run appends to the job log.

Job log archiving is also enabled by default with a default setting of 1 MB. When a component starts, the size of the file is checked. If it exceeds the archive threshold, the log is moved to the log archival location and compressed, and a new log file is created. With this in mind, an active log can still exceed the 1 MB threshold.

An exact size recommendation for log storage is not possible, though most customers rarely exceed 4 GB in total logging that spans years of activity.

Web App and Service Host Sizing

CPU and RAM

The web application runs via IIS and leverages a COM application for database access and related functionality. These COM applications (represented by dllhost.exe) consume a small amount of RAM and CPU cycles when idle, and shut down automatically when not in use (per COM default settings). At startup, the COM application consumes approximately 15-20 MB of RAM, with CPU utilization near 0%, and resources allocated as they work.

Note: Because Privileged Identity is a 32-bit application, no more than 2 GB of RAM will ever be available to each application.

To help maintain RAM resources, plan your server's RAM capacity to include:

  • 2 GB RAM for the host OS
  • RAM for other applications like anti-virus
  • 2 GB RAM for each Privileged Identity application component installed on the host

To help maintain CPU resources, plan your server's RAM capacity to include:

  • 2 CPU cores for the host OS
  • CPU requirements for other applications like anti-virus
  • 2 CPU cores for each Privileged Identity application component installed on the host

Our minimum recommendation for a host server is 4 CPU cores and 4 GB of RAM.

Logging

One log is enabled by default for the web application or web service:

  • RouletteAppServiceSupport - Logs web service basic activity and errors.
  • RouletteWebApplication - Logs web application basic activity and errors.

Job log archiving is also enabled by default with a default setting of 1 MB. When a component starts, the size of the file is checked. If it exceeds the archive threshold, the log is moved to the log archival location and compressed, and a new log file is created. With this in mind, an active log can still exceed the 1 MB threshold.

An exact size recommendation for log storage is not possible, though most customers rarely exceed 4 GB in total logging that spans years of activity.