Planning the Installation
It is critical for the server to have enough resources to accommodate peak concurrent virtual desktop usage, which is not necessarily the same as peak connected usage. Any virtual desktop environment running on the server—whether a user is connected to it or not—counts toward concurrent usage. Even if users are not connected to the server, they might still have a virtual desktop environment consuming resources.
When planning for adequate server capacity in an existing environment, there are two factors to consider:
- the density of the VERDE virtual server desktop
- the components that make up local storage
The total assigned virtual machine RAM plus overhead should never exceed the amount of physical RAM in the server. Doing so will result in extreme performance degradation.
Calculating VERDE Server Virtual Desktop Density
To determine the virtual desktop density possible on particular hardware for a VERDE Server, gather the following information:
- Number of CPU sockets (C)
- Number of CPU cores per socket (c)
- Total system RAM in GB (M)
- Guest virtual machine RAM assignment in GB (m)
Memory Considerations
The number of concurrent sessions that fit in memory on a particular VERDE Server (T1)—that is, sessions that are either connected or disconnected—can be calculated as follows:
T1 = (M - 8 GB)
(m + 0.128 GB)
The actual applications running in guest virtual machines play a major role in determining the virtual desktop density of a given VERDE Server. For example, office/business applications scale better than high-resolution multimedia programs.
Virtual machine RAM assignment must be calculated for capacity, not performance. Unlike with a physical computer, assigning more RAM to a virtual machine does not improve performance. Assigning too much RAM to a virtual machine might degrade performance by reducing the amount of system-wide caching that the host can perform.
The allocation of RAM must be based on the minimum RAM required to run applications. Most application vendors provide a “minimum” and a “recommended” RAM requirement. When planning virtual machine RAM assignment, use the “minimum” requirement. If necessary, assign less than the minimum to increase server density.
Allocate up to 8 GB of RAM for VERDE system software. Add this amount of RAM to the required guest RAM calculation, or subtract it from the total system RAM to accurately determine the number of concurrent sessions possible.
Allocating more memory than the minimum 8 GB will improve performance significantly. Any additional memory is used to cache Gold Images into memory. NComputing Global, Inc. recommends that up to 20% of total system memory is allocated to cache I/O memory. To calculate for this, add to the 8 GB minimum in the formula to reflect up to 20% of total system memory.
For example, with 92 GB of RAM and 1 GB per session, the number of concurrent sessions that can fit in memory is 75:
T1 = 92 GB - 8 GB
(1 GB + 0.128 GB)
CPU Considerations
A common guideline or metric for calculating the number of concurrent sessions that can be executed on a given CPU core is 8. Depending on the application profile, this number might be as high as 15 (or more). For typical application load (office/productivity applications), it is safe to use 8 concurrent sessions per core metric. To calculate the maximum number of concurrent sessions that can be run on a given VERDE Server without degrading session performance (T2):
T2 = 8 x C x c
For example, on a system with two sockets and four cores per socket:
T2 = 8 x 2 x 4
(T2 = 64)
Putting It Together
The actual maximum number of concurrent sessions that will both fit in memory and execute with expected performance on a given VERDE Server (T) is the lesser of the values T1 and T2. In the examples above, this number would be T = 64.
Local Storage Planning
Traditional VDI requires excess amounts of high performance storage, which is costly to purchase and complex to manage.
VERDE Storage Optimizer™ cache I/O technology works by caching the Input/Output Operations per Second (IOPS) from each virtual desktop onto VDI compute nodes for common data reads and transient data writes. VERDE replicates shared virtual desktop data at scheduled intervals, while running virtual desktop workloads from the VERDE Server direct-attached storage (DAS).
The Cache I/O refers to two features:
- Write Cache I/O manages copy on write storage.
- Read Cache I/O manages shared storage.
Example
In an organization with 1000 users all using one shared Windows 7 Gold Image, when all the users try to login to their desktop, 1000 desktops will be connecting to one shared image hosted on the external storage. If each desktop requires at least 50 IOPS (Input/output operations per second) to perform normal operations, then the external storage needs to support at least 50,000 IOPS—and this multiplies with more users in the organization. People also refer to a generic problem known as “boot storm”—when all the users try to boot Windows at the same time when the IOPS are significantly greater than five. To mitigate this problem, more and more drives (spindles) are put in external storage driving up more cost. Some storage vendors also introduce a solid state disk (SSD) based caching blades front-ending the storage. These blades are very expensive.
In addition, there needs to be enough network bandwidth/ports between the VDI servers and external storage server.
The Read Cache I/O storage optimization feature is best used in cluster environments where the Gold Images are stored on shared storage. When enabled, each server keeps a local copy of the Gold Image, avoiding repetitive access to the shared storage when a new desktop starts. The local copy of the Gold Image is automatically updated when changes occur on the shared image.
Transient Storage Space: Standard Deployment Mode
The Write Cache I/O is used by dynamic desktops to minimize the actual per-user persistent storage of a given Gold Image configuration. For example, if a Gold Image installation consumes 16 GB of storage, each deployed user running a dynamic instance of it might need less than 1 GB of persistent storage space, plus some temporary storage (transient storage) because only the delta from the Gold Image will be stored for each user.
Write Cache I/O requires transient storage. Transient storage requirements vary greatly depending on applications, use, and even runtime length of sessions. However, a conservative estimate is 20% of the Gold Image size for each deployed instance.
Example
If a template guest installation consumes 16 GB of storage, the transient storage size for each server should be 3.2 GB per user. For 50 concurrent users, assuming the preceding example, it would be 160 GB.
Cache I/O addresses these problems by leveraging the local attached storage (which is less expensive) that is available on each VDI server. Be sure to consider the space needed to store the copies of the Gold Images when sizing the direct attached storage.
For sessions that need to persist longer, copy on write storage is on the shared storage device. No Write Cache I/O benefits are available. The storage requirements should be 100%.
After creating a Gold Image, the cache I/O requires synchronization time to complete before images can be launched. Create a group of test users to help gauge the progress of a cache I/O directory synchronization from the User Console.