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.
Below is a configuration for an on-premise Hyper-scalable PAS using VMware vSphere consisting of the following machines:
|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.
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
- 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.
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.
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
- On demand provisioning
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