Sizing Guidelines for ControlUp v8.x
  • Dark
    Light
  • PDF

Sizing Guidelines for ControlUp v8.x

  • Dark
    Light
  • PDF

Use the information below to properly size the required ControlUp components used to monitor your environment. The article is relevant for the ControlUp Hybrid Cloud solution for version 8.x only. 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 7, 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 ComponentControlUp Monitor Node(*)ControlUp Real-Time Console(***)
VDI Workloads 0 - 1,0001,000 - 2,0002,000 - 4,000(****)0 - 1,0001,000 - 2,0002,000 - 4,000
vCPU(**)488222
RAM162432468

(*) 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.

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 ComponentControlUp Monitor NodeControlUp Real-Time Console(**)
RDS Sessions 0 - 5,0005,000 - 10,000(***)0 - 5,0005,000 -  10,000
vCPU(*)4822
RAM163288

(*) 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(*)2416 N+1 configuration
Real-Time ConsoleN/A2 Per console instance 
Data CollectorSee 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 ConsoleN/A 2Per console instance 
Data CollectorSee 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(*)5832 N+1 configuration
Real-Time ConsoleN/A28 Per console instance 
Data CollectorSee 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 + (**)
vCPU444
RAM888

(**) 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?