Skip to main content

Key Manager Performance Considerations

Key Manager performance may differ greatly depending on the host environment that is to be managed. The following performance factors should be taken into account when planning the Key Manager deployment and hardware:

  • Number of Key Manager back ends in the Key Manager system. Deploying more back ends increases system performance.

  • Number of Key Manager front ends in the Key Manager system. In large scale User Portal deployments we recommend to have a dedicated front end for User Portal.

  • How often scan operations (such as host scans and key-activity scans) are performed on the hosts. Performing scan operations more frequently decreases system performance.

  • The number of user accounts in the host environment. Increased number of user accounts increases the duration of scans.

  • The number of SSH keys in the host environment. Increased number of keys increases the duration of scans.

  • Latency between the Key Manager Servers and the managed hosts. Increased latency increases the duration of scans.

The minimum system requirements provided in System Requirements for Key Manager Components are appropriate for evaluation deployments of up to 1000 hosts.

The recommended system requirements provided in System Requirements for Key Manager Components have been selected based on an environment with the following specifications:

  • 20 000 hosts in the managed environment

  • Each host has 100 local user accounts on average, totaling to 2 million user accounts.

  • Each host has about 28 private keys on average, totaling to approximately 550 000 private keys in the managed environment.

  • Each host has about 200 authorized keys on average, totaling to approximately 4 million authorized keys in the managed environment.

  • The Key Manager deployment includes 4 Key Manager back ends with the recommended system requirements.

  • The Key Manager deployment uses an Oracle database with the recommended system requirements for the database server.

In a scenario similar to previously described, a full scipt-based scan of a 25 000-host environment can be completed in under 2 hours.

The performance statistics are derived from sample Key Manager test runs performed in a lab environment with the following specifications:

CPUMemory
Back end 14 × Intel(R) Xeon(R) CPU E3‑1220 V2 @ 3.10GHz16GB
Back end 24 × Intel(R) Xeon(R) CPU E3‑1220 V2 @ 3.10GHz16GB
Back end 34 × Intel(R) Xeon(R) CPU E3‑1220 V2 @ 3.10GHz16GB
Back end 48 × Intel(R) Xeon(R) CPU E3‑1240 V2 @ 3.40GHz16GB
Oracle database16 × Intel(R) Xeon(R) CPU E5620 @ 2.40GHz48GB
note

Note that the employed Key Manager components were equipped with hardware that is below the recommended system requirements. On all the Key Manager back ends, the limit for concurrent processes was raised to 80 (from the default 40). Therefore, the CPU load average on the Key Manager back ends periodically exceeded recommended values during the runtime of the test (particularly on back ends with less cores). The maximum number of processes on the Oracle database was raised to 500 (from the default 150). There was no significant CPU usage on the Oracle database

Due to the high rate at which Key Manager performs database transactions, system performance may be improved by increasing the number and the size of database redo logs. For information about optimizing database performance, please check the documentation provided by your database vendor.

The performance tests focused solely on user-key scanning. Other functionality, such as key- activity scanning, were not included in the performance tests.

For answers to questions regarding Key Manager performance in your environment, please contact the SSH Communications Security Corporation customer support at https://support.ssh.com/