The correct calculation for VDI (part 2)
This is a continuation of a series of two posts in which I talk about building a VDI solution for a large Russian software company. First post here .
Based on the theory described in the previous post, we will perform the calculations:
At the same time, from 6 to 9 VDI users can use the same physical core of the CPU. For simplicity, take the average number - 7 users.
')
According to customer requirements, it is necessary to ensure the work of 700 users by VDI with an extension up to 1000.
Calculate the number of required processors.
Customer servers on 6-core Intel Xeon processors, 2 pcs per server, i.e. 2 x 6 x 7 = 84 users per 1 ESX server with 2 processors. In addition, the architecture of Nehalem and Westmere very effectively allows you to use Hyper Threading and get 50-80% more clients. Those. in practice, somewhere: 1.52 * 84 = 126-128 users.
If Hyper Threading cannot be used or gives a gain of less than 50%, or if you need to make a miscalculation with a margin, then the recommended rule is: use 75% of users per server from the indicator with hyper threading (i.e. in our case: 128 * 75% = 96 users per server), but in the current calculation all indicators were tested in practice and coincided with the calculated ones.
The number of servers for the first stage (700 users) - 6 servers, taking into account further expansion - 8 servers.
The amount of memory depends on the version of Windows OS you are using, and on which applications will be launched. Requirements for each application can always be viewed on the website of the manufacturer of the OS and software.
For example, with Windows XP (this is our case) , 400-500 MB is required for basic operations , with caching - no more than 700 MB. Under normal conditions, the system begins to use the paging file when less than 25% of free space remains in RAM. OS always tries to save at least 25% of free space in the reserve. But using paging files in a virtual environment will lead to a loss of performance, so instead of creating a paging file with a capacity of 1.5-2 from RAM, we’ll fix it hard: no more than 200-500 MB per paging file, if that is not enough, the client needs to add more random access memory.
In addition, about half of all used memory contains similar blocks on all clients (DLLs, similar blocks of applications, etc.). vSphere Memory Management divides all memory into 4 KB pages, and TPS scans all data blocks every 60 minutes and calculates a hash. The kernel saves the hash to the table and compares it with the previously written values, leaving only one copy of the two identical, thus freeing up free space. If you need to make changes to this page, then a copy of it is created for recording. The percentage of RAM that is released using TPS is a relative indicator that depends on many factors and can reach 35% -50% . On Windows 7, this figure is lower due to the use of ASLR (Address Space Load Randomization), but it can also be disabled .
To run Windows XP on the ESX server, we need:
Fortunately, in our case Transparent Page Sharing functioned, the guest system selected Windows XP, so the calculation was made according to the “worst” scenario possible for this case - point 2, that is, 75 GB RAM per server.
IOPS is very dependent on the OS version and on the applications that will be used. For Windows XP, an approximate figure is 8 IOPS per system, for Windows 7 10 IOPS per system. Based on this, 128 Windows XP virtual machines (8 IOPS) need 1024 IOPS in read / write mode 20/80, i.e. 205 IOPS for reading and 819 IOPS for writing. That is, we get the number of disks in RAID1: 205/160 IOPS + 819/80 IOPS (see previous post , part on RAID) = 14 disks, no matter whether they are on the host or on the shared storage.
In RAID5: 205/160 + 819/45 = 21 disk.
Based on the measurements on the disk subsystem: 20 IOPS disk performance is required for each regular user, thus: 20 IOPS * 1000 users = 20000 IOPS. Of these, 20% for reading (4000 IOPS) and 80% for writing (16000 IOPS). Calculate the number of disks in RAID1: 4000/160 + 16000/80 = 226 disks. If users differ in applications, the calculation is taken for each user group.
If you need to count the number of disks in RAID5: 4000/160 + 16000/45 = 381 disk.
In the requirements of our customer were listed ordinary users (email, Internet, tables, text documents).
Since the current storage (HP EVA) could be expanded to the required 226 disks, there was no need to replace the storage.
To obtain performance indicators for VDI profiles within an array, use the vscsiStats command. C using it counts: IO size, seek distance, Outstanding IOs, Latency .
VmWare has a document that contains indicators and commands for running statistics.
After the calculations, in theory, it is necessary to check with this command whether the test configuration works correctly and, if necessary, make adjustments to the configuration.
Let's summarize in the form of a table by VDI:
Indicators of the number of VDI-clients per 1 physical disk and the number of disks required for the work of 128 users:
So here are a number of steps that can improve VDI performance:
Interesting reading:
A bit of math
Based on the theory described in the previous post, we will perform the calculations:
At the same time, from 6 to 9 VDI users can use the same physical core of the CPU. For simplicity, take the average number - 7 users.
')
According to customer requirements, it is necessary to ensure the work of 700 users by VDI with an extension up to 1000.
Processors
Calculate the number of required processors.
Customer servers on 6-core Intel Xeon processors, 2 pcs per server, i.e. 2 x 6 x 7 = 84 users per 1 ESX server with 2 processors. In addition, the architecture of Nehalem and Westmere very effectively allows you to use Hyper Threading and get 50-80% more clients. Those. in practice, somewhere: 1.52 * 84 = 126-128 users.
If Hyper Threading cannot be used or gives a gain of less than 50%, or if you need to make a miscalculation with a margin, then the recommended rule is: use 75% of users per server from the indicator with hyper threading (i.e. in our case: 128 * 75% = 96 users per server), but in the current calculation all indicators were tested in practice and coincided with the calculated ones.
The number of servers for the first stage (700 users) - 6 servers, taking into account further expansion - 8 servers.
RAM
The amount of memory depends on the version of Windows OS you are using, and on which applications will be launched. Requirements for each application can always be viewed on the website of the manufacturer of the OS and software.
For example, with Windows XP (this is our case) , 400-500 MB is required for basic operations , with caching - no more than 700 MB. Under normal conditions, the system begins to use the paging file when less than 25% of free space remains in RAM. OS always tries to save at least 25% of free space in the reserve. But using paging files in a virtual environment will lead to a loss of performance, so instead of creating a paging file with a capacity of 1.5-2 from RAM, we’ll fix it hard: no more than 200-500 MB per paging file, if that is not enough, the client needs to add more random access memory.
In addition, about half of all used memory contains similar blocks on all clients (DLLs, similar blocks of applications, etc.). vSphere Memory Management divides all memory into 4 KB pages, and TPS scans all data blocks every 60 minutes and calculates a hash. The kernel saves the hash to the table and compares it with the previously written values, leaving only one copy of the two identical, thus freeing up free space. If you need to make changes to this page, then a copy of it is created for recording. The percentage of RAM that is released using TPS is a relative indicator that depends on many factors and can reach 35% -50% . On Windows 7, this figure is lower due to the use of ASLR (Address Space Load Randomization), but it can also be disabled .
To run Windows XP on the ESX server, we need:
- If 60% of the memory is occupied and half of it is shared between other virtual machines (Transparent Page Sharing), then we need 1 GB * 60% * 50% = 300 MB. Plus, each virtual machine requires a little RAM by itself - about 5% of the total server memory, about 50 MB per client. Total 350 MB. The host itself requires 4 GB of RAM. Total: 4 GB (host) + 350 MB * 128 (number of virtual machines per server) = 48 GB RAM per server.
- If 75% of the RAM is occupied and only a third is divided, then each client needs 1 GB * 75% * 67% = 512 MB. Total: 4 GB (host) + (512MB + 50 MB) * 128 = 75 GB RAM per server.
- If the host just does not support page splitting, then we need: 4 GB (host) + (1024 MB + 50 MB) * 128 = 139 GB RAM.
- For Windows 7 clients, the numbers are as follows: (2 GB + 102MB) * 50% * 60% = 645MB per client. Total: 4GB + 660MB * 128 = 81 GB. If the host does not support transparent page sharing, then you need: 4GB + (2GB + 102MB) * 128 = 275 GB.
Fortunately, in our case Transparent Page Sharing functioned, the guest system selected Windows XP, so the calculation was made according to the “worst” scenario possible for this case - point 2, that is, 75 GB RAM per server.
Discs
IOPS is very dependent on the OS version and on the applications that will be used. For Windows XP, an approximate figure is 8 IOPS per system, for Windows 7 10 IOPS per system. Based on this, 128 Windows XP virtual machines (8 IOPS) need 1024 IOPS in read / write mode 20/80, i.e. 205 IOPS for reading and 819 IOPS for writing. That is, we get the number of disks in RAID1: 205/160 IOPS + 819/80 IOPS (see previous post , part on RAID) = 14 disks, no matter whether they are on the host or on the shared storage.
In RAID5: 205/160 + 819/45 = 21 disk.
Based on the measurements on the disk subsystem: 20 IOPS disk performance is required for each regular user, thus: 20 IOPS * 1000 users = 20000 IOPS. Of these, 20% for reading (4000 IOPS) and 80% for writing (16000 IOPS). Calculate the number of disks in RAID1: 4000/160 + 16000/80 = 226 disks. If users differ in applications, the calculation is taken for each user group.
If you need to count the number of disks in RAID5: 4000/160 + 16000/45 = 381 disk.
In the requirements of our customer were listed ordinary users (email, Internet, tables, text documents).
Since the current storage (HP EVA) could be expanded to the required 226 disks, there was no need to replace the storage.
To obtain performance indicators for VDI profiles within an array, use the vscsiStats command. C using it counts: IO size, seek distance, Outstanding IOs, Latency .
VmWare has a document that contains indicators and commands for running statistics.
After the calculations, in theory, it is necessary to check with this command whether the test configuration works correctly and, if necessary, make adjustments to the configuration.
Let's summarize in the form of a table by VDI:
Value | Windows xp | Windows 7 |
|---|---|---|
| Number of VDI clients per CPU core | 6-9 | 6-9 |
| Hyper-threading efficiency | 150-180% | 150-180% |
| ERAM on VDI client | 1 GB | 1 GB |
| Used RAM | minimum: 37.5%
average: 50% without TPS: 100% | minimum: 20%
average: 50% without TPS: 100% |
| IOPS on a VDI client | light user: 4-6
medium user: 8-10 heavy user: 12-16 | light user: 6-8
medium user: 10-12 heavy user: 14-20 |
Indicators of the number of VDI-clients per 1 physical disk and the number of disks required for the work of 128 users:
Scenario with 128 users | 20 IOPS
| 20 IOPS
| 10 IOPS
| 10 IOPS
|
| Vdi clients to disk | RAID5: 3
RAID1: 4 | RAID5: 3
RAID1: 5 | RAID5: 6
RAID1: 8 | RAID5: 7
RAID1: 10 |
| Number of disks per host | RAID5: 50
RAID1: 34 | RAID5: 36
RAID1: 26 | RAID5: 24
RAID1: 16 | RAID5: 18
RAID1: 12 |
So here are a number of steps that can improve VDI performance:
- Disable Memory Ballooning - for VDI, the paging file is useless, try to set hard values, if necessary, increase the RAM, not the paging file.
- Use single vCPU VMs - most user applications are single-threaded, they do not need multi vCPU.
- Timed Boots - divide user groups into groups, start groups by priority.
- Optimize anti-virus scanning . Antivirus software is a “necessary evil” in IT, but if the software is not properly configured, this will lead to a dramatic decrease in performance. It will be useful to set scan by write, scan only local disks and exclude Pagefile.sys and the Print Spool folder.
- Disable 3D Screen Savers in user profiles - these screensavers consume a lot of CPU resources.
- Use physical domain controllers — yes, you can run DC in a virtual environment, but Microsoft still recommends using DC as a physical machine.
- NIC Teaming (Aggregation) - NICs must be combined for greater bandwidth.
- Application Virtualization - Applications must be virtualized as well as the OS. This simplifies support and compresses the size of the “golden images”. Such images are easier to deploy and update.
- Correctly calculate the network bandwidth - earlier the calculation was made based on the indicator of 20 KB / s per user, but this does not correspond to the current state of affairs. The actual value will now be about 100 KB / s per user.
- Properly calculate storage system performance — the choice of disk type and RAID level determines how well your storage system performs in a VDI environment. Experience shows that RAID 10 is a smart choice for VDI due to its high performance. And SSD and Flash-memory seriously reduce load time, but they are more expensive (although the price of such a solution is steadily falling).
Interesting reading:
Source: https://habr.com/ru/post/150736/
All Articles