Follow me @TonySanchez_CTX
-Only physical or virtual architectures must be flexible enough to adapt to different workloads, which enables them to support changing business needs. Although the implementation of a new IT architecture takes time and careful planning, the process of testing and validating the architecture should be easy. In the case of a virtual desktop architecture, test engineers should be able to follow a replicable model, step by step, simply by changing the workload to validate architecture under different expected densities of users, charges working application, and configuration assumptions. The procedure should be as easy as learning a new set of dance (think PSY Gangnam Style, the most watched video on YouTube dance). The point to me as a test engineer to ask the question: in the case of VDI, why not a hypervisor simply learn a new workload as I could learn a new sequence of dance steps
Fortunately for? test engineers, Citrix FlexCast ® offers the opportunity to learn and provide any workload by leveraging the power of Citrix Provisioning Services ® (PVS) . Recently I was working with Citrix and Dell engineers work together to build a FlexCast reference architecture for deploying XenApp ® and XenDesktop ® Hyper-V on Dell infrastructure . Test of this reference architecture discussed how XenApp and XenDesktop performed under different workloads, changing the hypervisor configuration settings, and examining the user experience and overall user densities. At the dime drop, FlexCast PVS and activated with a simple switch of the architecture of a new workload.
Based on this effort to reference architecture, we recently began a test Single Server Scalability (SSS) using the latest hardware and software versions available. This blog focuses on this effort - what I call the "no XenApp dance for FlexCast style" and how XenApp workloads perform on Hyper-V (A follow-up blog post will focus on. another "dance" sequence for XenDesktop.) the purpose of this blog is how to configure the McAfee virus scanner can affect the performance and scaling.
in previous blogs, I describe the testing process and methodology that exploits the test harness Login VSI, as well as key tips for success. Since these same methods and recommendations are applicable here, let's review the configurations we used to this test scalability and workloads and actual test results. If you are not familiar with VSI Login please take some time to consider how their products can help you test applications and scalability of the hardware by visiting www.loginvsi.com.
For background reading, I highly recommend that you consider the position of Frank Anderson on XenApp physical compared to the results of virtual testing with Hyper-V. Frank is my friend and a great resource for ideas on the tests, including implementation tips and best general practices. In addition, Dell and Citrix related white paper describing the FlexCast reference architecture for deploying XenApp and XenDesktop on Hyper-V is available here.
With these resources in mind, let's get right down to the business of learning the "dance" and the presentation of our test results.
McAfee exclusions for XenApp
for XenApp to deliver optimal performance, scalability, and a responsive user experience, exclusions defining the McAfee virus scan is a necessity. The configuration settings specify whether the virus check should take place when reading or writing to disk, as shown in the screenshot below configuration.
Some highly secure environments require that files are scanned both when reading and writing on disk, while others only require scanning on the scriptures. This blog describes the results of tests that compare the performance and scalability configurations when scanning is performed on reads and writes compared when it is performed on the paperwork only.
Compute host material
For the host compute building block, we chose a Dell R720 server configured as follows:
below is a diagram showing the building block compute host XenApp. The Hyper-V host was built with a single RAID 1 for the OS and a RAID 10 for Machine cache write and virtual storage BIN files. Windows Server 08R2 SP1 with Hyper-V requires a BIN file for each virtual machine. The BIN file is used to save the operating system state of the virtual machine running the client side.
To estimate the total amount of storage required on the host computing, then we must take into account the local PVS cache and write the file BIN for each virtual machine. The BIN file is equal in size to the swap file attached to the master image to the level of the operating system. An example:
Example: Suppose we want to build XenApp VMs on a host running Windows Server 08R2 with Hyper-V. The equation for calculating the amount of storage required for all virtual machines on the host is
The total size of all the VHD files Write Cache + Total size of all files BIN = space total storage required
if the XenApp desktops are created with a cache write 10GB partition, the storage BIN files would need an additional 10GB for storage total local disk of 20GB per VM. In this case, if we want to build 10 XenApp VMs on a host with Windows Server 08R2 SP1 with Hyper-V, a local storage 0GB of total need. It is important to note that the BIN file is created in its size when a virtual machine is powered on and removed when off. The BIN file can potentially increase IOPS on the host too, so good planning is important when planning BIN file locations
Note :. Windows Server 2012 Hyper-V introduces a new feature as part of the action automatic shutdown does not require that every Windows client machine keep its operating condition which reduces architecture storage needs. With this latest version, the BIN file is a hard requirement while preserving storage space and improve performance as fewer IOPS are required. An example of this new feature for Windows Server 2012 is presented below. Ben Armstrong Microsoft has a great blog you can read about here to learn more about this feature .
Management Host Hardware
For the construction of block management host, a Dell R720 server was configured as follows:
for the management feature, we used a host of calculation to perform the infrastructure roles basic. Virtual machines for infrastructure roles were stored on a Dell PS4100XV Equalogic SAN in a dedicated Microsoft Cluster Shared Volume (CSV) so they can be migrated to a new host if necessary. Infrastructure virtual machines are as follows:
- DC
- SCVMM 2012
- SCOM 2012
- Desktop Controller
- Web interface
- Data Collector Zone
- SQL
- PVS
- Citrix Licensing
- file server
Provisioning Server (PVS)
Provisioning Server 6.1 was used with the appropriate patches. We also applied the best practices guide for PVS with the appropriate network settings. The PVS VM was awarded 4 vCPUs and 24GB of RAM. The PVS write cache for XenApp master image has been set at a fixed VHD 20GB and has also made client side. The assistant PVS was used to create all 10 pictures XenApp VMs. McAfee Antivirus 8.7 has been installed and configured the VM PVS and best practice guideline was applied to ensure that the appropriate exclusions for vDisk and other critical parts PVS were in place. The best practices guide for McAfee on PVS can be found here.
System Center Virtual Machine Manager 2012
System Center Virtual Machine Manager 2012 has been mobilized to manage VM in Hyper-V host compute. No service pack has been applied from System Center 2012 Virtual Machine Manager. Write caching PVS was also stored in the VMM library and attached to control XenApp VMM model. McAfee Antivirus 8.7 has been installed and configured on the host computing and best practice guideline was applied to ensure that the appropriate exclusions for virtual machines were in place. The best practices guide on McAfee Virtual Machine Manager can be found here.
Hyper-V Host Compute
For the host compute building block, Windows Server 08R2 Enterprise default installation with SP1 was applied and the role of Hyper-V has been enabled. We have created two virtual networks in Hyper-V: a network for management and one for the public traffic flow PVS. All Windows Server patches and appropriate Hyper-V were applied through Windows Update. Two logical drives were created for the Hyper-V host: volume 0 was for the operating system volume and one for storing the write cache. McAfee Antivirus 8.7 has been installed and configured on the host computing and best practice guideline was applied to ensure that the appropriate exclusions for virtual machines were in place. The best practices guide for McAfee Hyper-V can be found here.
XenApp 6.5
XenApp Platinum 6.5 has been installed and configured for the main image. All public XenApp Hotfix Rollup Packs have been applied. PVS client was installed as part of the fault by XenApp installation. Note that by default, the image ISO XenApp 6.5 SP1 installs only the client PVS 5.6. While the client 5.6 SP1 can connect to a 5.6 or 6.1 PVS farm, it is recommended to keep the client and the PVS PVS server to the same version. If you choose not to use client PVS 5.6 SP1 comes with the ISO XenApp 6.5, clear the PVS target device box when installing and mounting the ISO PVS 6.1 to XenApp VM after installation to install XenApp PVS client that matches the server version.
McAfee Antivirus 8.7 has also been installed and configured on the master image XenApp. The best practice guide was applied to ensure that the appropriate exclusions for virtual machines were in place. The best practices guide for McAfee Hyper-V can be found here. As the test results in this article show blog, antivirus analysis parameters applied to McAfee XenApp (write versus read / write) greatly affect the performance and scalability .
Workloads Application
during test design process, we wanted to create a realistic workload application. With this in mind, we tried to take advantage of the most used applications on XenApp that would normally be found in production. The following applications were among those included in the test workload:
- Microsoft Office 2010
- Adobe Reader
- Adobe Flash
- McAfee Antivirus 8.7
Login VSI 3.6 is the workload generator. Test configurations focused on two specific workloads: a basic user (VSI Light) of the workload and a standard user (average VSI) of the workload. Both sets of flash technology leveraged tests HDX, but the flash setting was made available to the server side, which can be changed at any time.
independent settings workload
The table below summarizes the configuration of the host computing environment to support the XenApp task and knowledge workers scenarios.
Although 128GB memory was configured when analyzing XenApp performance, it is possible to configure the server with 96GB and provide minimal resources to each VM
Group workers (Basic workload) -. McAfee Written only
based on workload runs a small number of applications that are representative of applications used by the tasks of workers (such as employees of call centers). Applications are closed immediately after use, resulting in relatively little memory and CPU consumption compared to the standard workload. Applications of the basic workload include Internet Explorer, Microsoft Word 2010 and Microsoft Outlook 2010, with only two of these applications running simultaneously. User downtime is about 17% of total time. In this test, the McAfee when writing to disk one box has been selected for the master image XenApp.
Configuration Summary -. worker job
The table below shows the settings for virtual virtual machine desktop configured for task worker
CPU usage analysis of resources performance Results
CPU graphs below show logical and virtual CPU usage for the host computing in the basic workload. Hyper-V provides hypervisor performance objects to monitor the performance of both logical and virtual processors. A logical processor is directly correlated to the number of processor cores that are installed on the physical computer. (For example, two quad-core processors installed on the physical computer is correlated with 8 logical processors.) Virtual processors are what actually use virtual machines, and any execution in root and child partitions occurs in virtual processors.
The results below show held logical processor runtime%, peaking at about 0%. % CPU runtime logic is the key parameter for analyzing the performance of guest operating systems. A peak of 80% is recommended to optimize the density while providing a sufficient margin to ensure that the experience of the end user does not decrease. A% of high performance logic processor combined with low CPU runtime virtual% is typical of an environment where there are more processors allocated to virtual machines than are physically available on the host computing, which is the for this case VDI.
resources using the Performance Memory Analysis Results
the graph of memory indicates the amount of memory on the host to the host operating systems Hyper-V with 8 active XenApp machines for the test period under the basic workload. Although 128GB memory was configured when analyzing XenApp performance, it is possible to configure the server with 96GB and provide minimal resources. The diagram shows that additional memory is available in memory to use the maximum environment is 92%.
disk I / O utilization of resources Performance Analysis Results
The Disk I / O and graphics below the latency IOPS on average during the test period when all user sessions were connected and active was 1,021, with an average of 4.6 IOPS per user XenApp. It should be noted that the disk I / O numbers are host to calculate D: drive where virtual desktops reside disk activity on C :. Player is minimal
Knowledge Worker (standard workload) - McAfee Written Only
The standard workload executes applications representative of those used by knowledge workers (such as accountants). The applications of this workload are Internet Explorer, a number of Microsoft Office 2010 applications (Excel, Outlook, PowerPoint and Word), Adobe Acrobat Reader, Bullzip PDF printer, and compression software 7-zip files. Compared to the workload task worker (basic user) discussed above, the idle time is slightly lower percentage of the overall performance and up to 5 applications open simultaneously (compared to 2 opened applications for worker of the task).
Configuration Summary -. Knowledge Worker
The table below gives the XenApp configuration settings for virtual desktop VMs shared used for a knowledge worker
CPU Resource Utilization performance results of the analysis
CPU graphs below illustrate the use of the logical processor as standard workload. The results show% Processor runtime logic maintained a peak at about 98%. The peak sustained logical processor runtime% to 80% is ideal for an environment that maximizes density while providing a sufficient margin to ensure that the experience of the end user does not decrease. A high% runtime logic processor combined with low virtual processor runtime% is typical of an environment where there are more processors allocated to virtual machines than are physically available on the host computing, which is the case for this VDI environment. workloads of knowledge workers tend to be more intense on logical processors that applications of the group of workers, causing a decrease in the density of the user.
resources Performance Memory Using the analysis results
the graph of memory below shows the amount of memory used on host for the host operating system with Hyper-V 8 XenApp machinery assets for the duration of the standard workload test. Although 128GB memory was configured when analyzing XenApp performance, it is possible to configure the server with 96GB and provide minimal resources to each VM. The diagram shows that the availability of memory exists in the respectful use of the maximum memory environment is 91%.
I / O performance of resource usage disk analysis results
The graphics Disk / O and latency I below illustrate that the Hyper-V host environment operates on the levels for a knowledge worker. The IOPS on average during the test period when all user sessions were connected and active was in 1165 with an average of 4.4 IOPS per user XenApp. It should be noted that the I / O numbers are record for XenApp VMs. This disk I / S figures are to calculate host D: drive where virtual desktops reside disk activity on C :. Player is minimal
Workers Group (basic workload) - McAfee Reading and writing only
The basic workload runs a small number applications that are representative of applications used by the tasks of workers (such as employees of call centers). Applications are closed immediately after use, resulting in relatively little memory and CPU consumption compared to the standard workload. Applications of the basic workload include Internet Explorer, Microsoft Word 2010 and Microsoft Outlook 2010, with only two of these applications running simultaneously. User downtime is about 17% of total time. In this test, the McAfee when reading and writing to disk one box has been selected for the master image XenApp
Configuration Summary -. Task worker
The table below shows the settings for virtual desktop virtual machines configured for the task worker.
CPU usage analysis of performance resources Results
CPU graphs below show logical and virtual CPU usage for the host in the calculation basic workload. Hyper-V provides hypervisor performance objects to monitor the performance of both logical and virtual processors. A logical processor is directly correlated to the number of processor cores that are installed on the physical computer. (For example, two quad-core processors installed on the physical computer is correlated with 8 logical processors.) Virtual processors are what actually use virtual machines, and any execution in root and child partitions occurs in virtual processors.
The results below show held logical processor runtime%, peaking at about 87%. % CPU runtime logic is the key parameter for analyzing the performance of guest operating systems. A peak of 80% is recommended to optimize the density while providing a sufficient margin to ensure that the experience of the end user does not decrease. A% of high performance logic processor combined with low CPU runtime virtual% is typical of an environment where there are more processors allocated to virtual machines than are physically available on the host computing, which is the for this case VDI.
resources using the Performance Memory Analysis Results
the graph of memory indicates the amount of memory on the host to the host operating system with Hyper-V 7 active XenApp machines for the test period under the basic workload. Although 128GB memory was configured when analyzing XenApp performance, it is possible to configure the server with 96GB and provide minimal resources. The diagram shows that additional memory is available in memory to use the maximum environment is 84%.
disk I / O utilization of resources Performance Analysis Results
The Disk I / O and graphics below illustrate the latency that the Hyper-V host environment operates on the levels for a job worker. The IOPS on average during the test period when all user sessions were connected and active was 839 with an average of 4.2 IOPS per user XenApp. It should be noted that the disk I / O numbers are host to calculate D: drive where virtual desktops reside disk activity on C :. Player is minimal
Knowledge Worker (standard Workload) - McAfee Reading and writing only
The standard workload executes applications representative of those used by knowledge workers (such as accountants). The applications of this workload are Internet Explorer, a number of Microsoft Office 2010 applications (Excel, Outlook, PowerPoint and Word), Adobe Acrobat Reader, Bullzip PDF printer, and compression software 7-zip files. Compared to the workload task worker (basic user) discussed above, the idle time is slightly lower percentage of the overall performance and up to 5 applications open simultaneously (compared to 2 opened applications for worker of the task).
Configuration Summary -. Knowledge Worker
The table below gives the XenApp configuration settings for virtual desktop VMs shared used for a knowledge worker
CPU Resource Utilization performance results of the analysis
CPU graphs below illustrate the use of the logical processor as standard workload. The results show% Processor runtime logic maintained a peak at about 95%. The peak sustained logical processor runtime% to 80% is ideal for an environment that maximizes density while providing a sufficient margin to ensure that the experience of the end user does not decrease. A high% runtime logic processor combined with low virtual processor runtime% is typical of an environment where there are more processors allocated to virtual machines than are physically available on the host computing, which is the case for this VDI environment. workloads of knowledge workers tend to be more intense on logical processors that applications of the group of workers, causing a decrease in the density of the user.
resources Performance Memory Using the analysis results
the graph of memory below shows the amount of memory used on
0 Komentar