Sizing Guidelines for VDI & DaaS
- Print
- DarkLight
- PDF
Sizing Guidelines for VDI & DaaS
- Print
- DarkLight
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
Use the following article to properly size the required ControlUp components that monitor your environment. Whether your organization is small or large, ControlUp offers scalability. To ensure high availability, we recommend that your monitor cluster/sites and the data collectors be redundant with N+1.
Note:
You can use 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. If you require assistance with sizing, contact our Support Team at support@controlup.com.
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 10 or Windows 11 virtual machines with or without third-party software installed, such as Citrix Virtual Apps and Desktops, Omnissa Horizon (formerly VMware Horizon), or Microsoft AVD.
The main factor to consider is the number of VDI machines connected to ControlUp. If you manage more than 500 VDI machines, it is a mandatory requirement to disable the process flat views in the Real-Time Console.
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 | 2,000 | 3,000 - 4,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 here.
(****) 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 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 if you manage more than 2,000 concurrent user sessions, it is a mandatory requirement to disable the process flat views in the Real-Time Console.
| 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, see 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 average number of concurrent processes per host including 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
We always recommend that you configure dedicated data collectors for hypervisors, EUC connections, and NetScalers. In large environments, you should run the data collector on a dedicated VM. For more details about why a data collector is important both for your environment and the performance of the Real-Time Console, see here.
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 use more RAM 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. Adding NetScaler can use more network due to the amount of data that we're getting via the Nitro API.
If linking a data source that is an Omnissa/Hyper-V/XenServer/Nutanix Hypervisor, we query hosts, machines, datastores and virtual disks. If linking a data source that is an EUC environment like Citrix Virtual Apps and Desktops/Omnissa Horizon, we query topology (delivery groups/desktop pools), brokers/connection servers, machines and sessions. If linking a data source that is a NetScaler, we query appliance info and metrics, load balancers, HDX sessions and gateways.
The number of records that the API passes per ControlUp's API query is always 4 vCPU/8 RAM.
Was this article helpful?