Hyper-scalable PAS Sizing Guidelines

The Centrify Hyper-scalable PAS platform has many features and use-cases. This page provides a baseline guide to use as a starting point.

Note:   Larger or smaller setups can be extrapolated from this guide.

The following key use-cases have been tested and observed.

Note:   Testing is an ongoing process and specifications may need to be adjusted on a case-by-case basis.

Use case Description
Cloud Agent
  • Back-channel traffic impact on TCPRelay, web, and background nodes
  • Password management / reconciliation traffic
  • RDP web and native session traffic
  • SSH web and native session traffic
  • Password management / reconciliation traffic

On-premise example

Below is a configuration for an on-premise Hyper-scalable PAS using VMware vSphere consisting of the following machines:

Name Specifications Server
2x Connector node 4 core 16GB RAM Windows Server 2016
2x TCPRelay nodes 4 core 16GB RAM Windows Server 2016
2x Worker nodes 4 core 16GB RAM Windows Server 2016
3x Web nodes 4 core 16GB RAM Windows Server 2016
Logger node 2 core 16GB RAM Windows Server 2016
Management node 2 core 8GB RAM Windows Server 2016
Postgres DB 8 core 32GB RAM Centos 7, Postgres 10.14 single node
Redis cache 8 core 32GB RAM Centos 7, Redis 6.0.8-1 single node


This configuration is capable of the following concurrent sessions:

  • 50 (medium traffic) RDP web sessions

    Note:   Traffic was simulated by running the task manager which generates RDP traffic via periodic screen updates.

  • 350 (low-medium traffic) SSH sessions

    Note:   Traffic was simulated by running top, which generates SSH traffic via periodical screen updates.

  • 1000 - 1500 Centrify Cloud Agents (depending on activity)

    Note:   Traffic was simulated using an internal tool.

When using this example as a basis, keep in mind:

  • All of these numbers can be serviced via a single connector but we recommend having more than one for redundancy.
  • (Optional) Connectors may be configured to provide only specific services to isolate traffic / load.
  • (Optional)TCPRelays may also be configured to provide a dedicated BackChannel communications for Centrify Cloud Agent.
  • This example does not generate any consequential load on:
    • Postgres database
    • Redis load. Latency was measured to be:
      • Minimum: 0 ms
      • Maximum: 1 ms (spiked up to 2-3 ms during agent enroll)
      • Average: .05 ms
  • Resource impact. See Load impact section below for use-case specifics.

Load impact

The primary load on a Hyper-scalable PAS system is on the web nodes and primarily affects the CPU and RAM resources. This is due to external communications which require the web nodes, such as:

  • Web browser UI
  • REST
  • Agents
  • Data requiring backend (worker node)

The second critical component are the connectors. All web and direct session access without the Portal is directed through the connector machine. This load is primarily seen as total network traffic throughput and the number of concurrently open network sockets.

Note:   The TCPRelay load is seen as total network traffic throughput and the number of concurrently open network sockets. The CPU and RAM utilization will be very low.

There is no significant load on Postgres or Redis.

Comparable Environments

Below is a comparable Amazon EC2 instance: Other machine requirements can be extrapolated from these baselines.

Name AWS EC2 instance vSphere
Management node t2.large 2 core 8 GB RAM
Logger node t3.xlarge 4 core 16 GB RAM
Postgres db.r4.2xlarge 8 core 32 GB RAM
Redis cache.r4.large No direct comparison but you can use the Postgres instance as a baseline.
TCPRelay nodes t3.xlarge 4 core 16 GB RAM
Web nodes t3.xlarge 4 core 16 GB RAM
Worker nodes t3.xlarge 4 core 16 GB RAM
Connector nodes t3.xlarge 4 core 16 GB RAM

Note:   The information in a sample setup only. You may require sizing adjustments based on your specific setup.

Cloud Agent

Centrify Cloud Agent generates a negligible load on Hyper-scalable PAS from login and MFA operations. The Cloud Agent has a back-channel communication path with Hyper-scalable PAS that enables Centrify to provide features such as:

  • Agent-assisted account reconciliation
  • Workflow
  • On demand provisioning
  • HealthCheck

Note:   This back-channel does not require customers to open additional ports. It provides a mechanism for various Platform components to invoke remote functionality on the Centrify Clients.

The Centrify Cloud Agent will register itself via the back-channel by default during the enrollment process or agent start-up.

Note:   The default settings are configurable.

Once the Centrify Cloud agent registration is complete, back-channel traffic may be generated for the following reasons:

  • Periodic HealthCheck (configurable) every hour per agent
  • cinfo -H will perform a HealthCheck
  • Feature management capability
  • Password reconciliation capability

On shutdown, the Centrify Cloud Agent unregisters itself from the back-channel.

These operations do not inherently constitute a large amount of traffic or load. However, when multiplied by a large number of enrolled Centrify Cloud Agents, this can present occasional spikes in the back-channel traffic, which can affect performance.

For example, the following may create a large spike in BackChannel registration traffic:

  • An automated / orchestrated provisioning of a large number of machine instances within a short period of time
  • Auto-enrolling Centrify Cloud Agents.

Note:    TCPRelays can be configured to be dedicated for Centrify Cloud Agent use only.


RDP and SSH access via a web browser is a key feature of Hyper-scalable PAS. This system was able to support:

  • 50 RDP web sessions
  • 350+ SSH web sessions