Sizing Guidelines for VDI & DaaS
    • Dark
      Light
    • PDF

    Sizing Guidelines for VDI & DaaS

    • Dark
      Light
    • PDF

    Article summary

    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 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. 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 / InstancesvCPU (per instance)RAM(per instance)Notes
    Monitor Nodes(*)2416N+1 configuration
    Real-Time ConsoleN/A28Per console instance
    Data CollectorSee Data Collectors.
    Example configuration for 5,000 VDI machines
    ControlUp Component# of VM's / Instances vCPU (per instance)RAM (per instance)Notes
    Monitor Nodes(*)5832N+1 configuration
    Real-Time ConsoleN/A28Per console instance
    Data CollectorSee Data Collectors.
    Example configuration for 20,000 VDI machines
    ControlUp Component# of InstancesvCPU (per instance)RAM (per instance)Notes
    Monitor Nodes(*)16832N+1 configuration, additional 2 Management Monitors will be required with : 4 vCPU & 8 GB RAM
    Real-Time ConsoleN/A28Per console instance
    Data CollectorSee Data Collectors.
    Example configuration for 50,000 VDI machines
    ControlUp Component# of InstancesvCPU (per instance)RAM (per instance)Notes
    Monitor Nodes(*)35832N+1 configuration, additional 2 Management Monitors will be required with : 4 vCPU & 16 GB RAM
    Real-Time ConsoleN/A28Per console instance
    Data CollectorSee 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?