Sizing Guidelines for ControlUp v8.x
- Print
- DarkLight
- PDF
Sizing Guidelines for ControlUp v8.x
- Print
- DarkLight
- PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
Use the information below to properly size the required ControlUp components used to monitor your environment. Whether your organization is small or large, ControlUp offers scalability. To ensure high availability, we recommend that the monitor cluster and the data collectors be redundant with N+1.
Note:
You can find our interactive online sizing calculator here. This allows you to input the exact details of your environment and calculate the recommended number of monitor nodes for version 8x.
The scalability limit of a single monitor node is 320,000 concurrent processes. The actual limit of VDI machines per monitor node depends on the average number of concurrent processes per VDI machine.
For a customer with an avg. of 200 concurrent processes per machine, a single monitor node supports 2,000 VDI machines.
VDI-based workloads
Sizing amounts below are based on end-user environments running on VDI machines. These can include Windows 8, Windows 10 or Windows 11 virtual machines with or without third-party software installed, such as Citrix Virtual Apps and Desktops, VMware Horizon, or Microsoft AVD.
The main factor to consider is the number of VDI machines connected to ControlUp. When managing more than 500 VDI machines, disabling the process flat views in the Real-Time Console is a mandatory requirement.
ControlUp Monitor and Real-Time Console hardware sizing
ControlUp Monitor and Real-Time Console hardware sizing is shown in the table below. A higher number of vCPUs and RAM means better performance.
| ControlUp Component | ControlUp Monitor Node(*) | ControlUp Real-Time Console(***) | ||||
| VDI Workloads | 0 - 1,000 | 1,000 - 2,000 | 2,000 - 4,000(****) | 0 - 1,000 | 1,000 - 2,000 | 2,000 - 4,000 |
| vCPU(**) | 4 | 8 | 8 | 2 | 2 | 2 |
| RAM | 16 | 24 | 32 | 4 | 6 | 8 |
(*) Additional monitor nodes should be deployed in environments with more than 2,000 VDI machines. You can find examples for configurations consisting of 500, 5 000, 20 000, and 50 000 VDI machines below.
(**) 2.8Ghz clock speed or higher.
(***) Per console instance, based on a fully optimized console, see this article.
(****) A monitor node can support up to 320,000 concurrent processes, so the maximum number of VDI machines per monitor node is determined by the average number of concurrent processes per VDI machine.
One monitor node supports 2,000 VDI machines for a customer with an average of 200 concurrent processes per machine. A properly sized monitor node can handle dozens of incident triggers per minute.
VDI sizing examples
These examples are based on an average of 200 concurrent processes per VDI machine and on an N+1 redundancy configuration.
| Example configuration for 500 VDI machines | ||||
| ControlUp Component | # of VM's / Instances | vCPU (per instance) | RAM(per instance) | Notes |
| Monitor Nodes(*) | 2 | 4 | 16 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example configuration for 5,000 VDI machines | ||||
| ControlUp Component | # of VM's / Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 5 | 8 | 32 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example configuration for 20,000 VDI machines | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 16 | 8 | 32 | N+1 configuration, additional 2 Management Monitors will be required with : 4 vCPU & 8 GB RAM |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example configuration for 50,000 VDI machines | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 35 | 8 | 32 | N+1 configuration, additional 2 Management Monitors will be required with : 4 vCPU & 16 GB RAM |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
RDSH-based workloads The sizing numbers below are based on environments where the end-users are running on RDSH-based servers. The main factor is the number of concurrent sessions being managed using ControlUp. Note that when managing more than 2,000 concurrent user sessions, disabling the process flat views in the Real-Time Console is a mandatory requirement.
| ControlUp Component | ControlUp Monitor Node | ControlUp Real-Time Console(**) | ||
| RDS Sessions | 0 - 5,000 | 5,000 - 10,000(***) | 0 - 5,000 | 5,000 - 10,000 |
| vCPU(*) | 4 | 8 | 2 | 2 |
| RAM | 16 | 32 | 8 | 8 |
(*) 2.8Ghz clock speed or higher.
(**) Per console instance, based on a fully optimized console, see this article.
(***) Based on approximately. 20 processes per RDS session.
For further information regarding Data Collectors click here.
RDSH-sizing examples
The scalability limit of a single monitor node is 320,000 concurrent processes, so the actual limit of RDS hosts per Monitor node depends on the avg. number of concurrent processes per host incl. the host. On average, a single Monitor node supports 10,000 concurrent sessions.
**The numbers below vary between organizations due to the number of sessions running on each host.
These examples are based on an average of 200 concurrent processes per an RDSH and 20 processes per session on an N+1 configuration.
| Example Configuration for 5,000 RDS Sessions Running on 250 RDSHs | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 2 | 4 | 16 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example Configuration for 20,000 RDS Sessions Running on 1,000 RDSHs | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 3 | 8 | 32 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
| Example Configuration for 50,000 RDS Sessions Running on 2,500 RDSHs | ||||
| ControlUp Component | # of Instances | vCPU (per instance) | RAM (per instance) | Notes |
| Monitor Nodes(*) | 5 | 8 | 32 | N+1 configuration |
| Real-Time Console | N/A | 2 | 8 | Per console instance |
| Data Collector | See Data Collectors. | |||
Data Collectors
Configuring dedicated data collectors for Hypervisors, EUC connections and NetScalers is always recommended. In large environments, the data collector should run on a dedicated VM.
You can get more information here and see why a data collector is important both for the environment and the performance of the Real-Time Console.
Properly sizing how many data collectors to connect depends on which type of data source you're assigning to the data collector. For example, adding vCenter can cause more RAM to be utilized based on the number of machine records that we'll get via the vSphere API. Adding Citrix sites uses more CPU due to the queries that are being performed by the PowerShell API. NetScaler can use more network due to the amount of data that we're getting via the Nitro API.
The numbers in the sizing chart below represent the number of records that the API passes.
- When linking a data source which is a VMware/Hyper-V/XenServer/Nutanix hypervisor, we query hosts, machines, datastores & virtual disks.
- EUC environments like Citrix Virtual Apps and Desktops / VMware Horizon, we query topology (delivery groups/desktop pools), brokers/connection servers, machines & sessions.
- For NetScaler we query appliance info & metrics, load balancers, HDX sessions & gateways.
| ControlUp Data Collector | |||
| 0 - 2,000 (**) | 2,000 - 5,000 (**) | 5,000 + (**) | |
| vCPU | 4 | 4 | 4 |
| RAM | 8 | 8 | 8 |
(**) The numbers represent the number of records that the API passes per ControlUp's API query.
Assistance needed?
Contact our support at support@controlup.com
Was this article helpful?