Guest

Desktop Virtualization (On-Premises)

Design Considerations for Increasing VDI Performance and Scalability with Cisco Unified Computing System

  • Viewing Options

  • PDF (1.1 MB)
  • Feedback

Contents

What You Will Learn

Background

Test Objectives

Test Platform

Physical Environment

The Login VSI Testing Tool

Cores vs. Clock Speed and the Impact on Virtual Desktop Density

Effect of Individual Core Speed (Burst) on Virtual Desktop Scalability

Setting Realistic Virtual Desktop Limits for Cisco UCS B200 M3 Servers Using Intel Xeon E5-2643 and E5-2665 Processors

SPEC CPU2006 CINT2006 Rate Required for Virtual Desktop Operations

Scalability of One- and Two-vCPU Virtual Desktop Deployments

Weighing the Merits of Two-vCPU Virtual Desktops

Effect of Memory Speed on VDI Scalability

Effect of Memory Density on VDI Scalability

Effect of Storage IOPS on Virtual Desktop Operations

Your Results May Differ

Conclusion

For More Information

Appendix: Server and Storage Configuration Information


What You Will Learn

• Virtual desktop infrastructure (VDI) performance is closely tied to certain configuration choices made when selecting a server platform for hosting virtual desktops.

• Variables such as the number of CPU cores and virtual CPU (vCPU), memory speed, and storage requirements play crucial roles in system density and scalability and the delivery of an uncompromised user experience.

• Implementers of VDI should carefully assess their user environments, use-case profiles, and business objectives when designing the computing infrastructure for hosting virtual desktop workloads and use these factors to guide their choices when selecting a server to host their virtual desktops.

Background

Much attention has been focused on the use of VDI to address the evolving end-user computing environment. VDI is increasingly being positioned as a means for enabling a bring-your-own-device (BYOD) approach to client computing while offering increased security and resiliency of corporate data and enabling new work styles that transcend the limits and geographical boundaries of the traditional user work environment.
Desktop virtualization solutions encompass myriad components that span a variety of broker technologies, display protocols, user personalization, storage optimization solutions, and management layers. However, the underlying foundation of VDI - the data center server platform - is the critical element that must reliably deliver an uncompromised end-user experience that is secure and manageable and does not degrade as it scales.

Test Objectives

This document explores the impact of the virtualized server foundation on the delivery of scalable, high-performing virtual desktops. This document raises a number of critical questions that should be addressed in designing a computing infrastructure to help ensure that it supports the desired objectives for end-user performance, system scalability, and cost efficiency.
The discussion that follows is the result of an initiative led by a team of consulting systems engineers (CSEs) who specialize in the design of scalable VDI architecture for Cisco's largest customers around the world. Through the group's efforts to document the specific questions and answers most relevant to the delivery of scalable VDI performance, the group found that the VDI marketplace offers very little content that is free from vendor-specific interests. Careful examination of publicly available information pertaining to VDI performance as affected by server configuration reveals that these are, in fact, highly pertinent questions that are missing from much of the documentation provided in the VDI marketplace as of the time of this writing.
This document therefore seeks to provide a clear, unbiased analysis of server-side parameters that affect real-world implementations as witnessed by the CSE team and as verified in the team's efforts to observe these considerations in a carefully crafted test platform and environment.

• To guide readers through the test results, this document describes: The Testing Environment

• VDI Questions and Answers

• Overall Summary

• Appendix: Server and Storage Configuration Information

Test Platform

The test platform used in this study included the following main components:

• Various configurations of the Cisco UCS B200 M3 Blade Server

VMware Horizon View 5.1.1

Login Virtual Session Indexer (Login VSI) 3.6.1 benchmark

• Login VSI Medium with Flash workload (click here for details)

• Microsoft Windows 7 SP1 32-bit virtual desktops

Pure Storage FlashArray with Purity Version 2.0.2.

These test results are not a Cisco Validated Design or reference architecture. This document is not intended to demonstrate maximum scalability, but instead to show scalability differences achieved under different operating conditions. The goal of the tests was simply to show the many choices that affect scalability, including:

• Deployment using one vCPU or two vCPUs

• Use of 1600-MHz or 1066-MHz Intel platform

• Balance of CPU to memory capacity

Physical Environment

Figure 1 shows the physical environment used in the test. The environment is a highly overprovisioned system. Only one Cisco UCS B200 M3 Blade Server was tested at a time, but every logical link between elements consists of multiple 10 Gigabit Ethernet links or multiple 8Gbps Fibre Channel links.
The storage array has 24 flash memory disks and is capable of substantially more I/O operations per second (IOPS) than achieved in this test. All the infrastructure elements used for this test (Microsoft Active Directory, VMware vCenter, VMware Horizon View, and Login VSI launchers) are virtual machines on the Cisco UCS B230 M2 Blade Server in the environment ( Figure 2).

Figure 1. Physical Environment for the Test

Figure 2. Logical Server Environment

The tests in this study used two Cisco UCS B200 M3 Blade Servers: one with dual Intel Xeon E5-2665 processors, and the other with dual Intel Xeon E5-2643 processors, as shown in Table 1.

Table 1. CPU Details

Model

Cores

Speed (G Hz)

Watts

1KU Budgetary price

CINT2006Rate

CFP2006Rate

Blended

Blended/Core

Intel E5-2643

4

3.30

130

$885

187.5

167.5

177.3

44.38

Intel E5-2665

8

2.40

115

$1,440

305

233.3

269.25

33.66

The Login VSI Testing Tool

Text Box:
Login Virtual Session Indexer (Login VSI) is an industry-standard benchmarking tool that is used to test the performance and scalability of centralized Microsoft Windows desktop environments such as VDI deployments. Login VSI is a vendor-independent platform and is used to test virtual desktop solutions including VMware Horizon View, Citrix XenDesktop and XenApp, Microsoft VDI and Remote Desktop Services (RDS /Terminal Server), and many other VDI solutions. Because Login VSI is vendor independent and works with standardized user workloads, the results and conclusions that are based on Login VSI test data are considered objective, verifiable, and replicable.
The images provided in this document were created using data from the Login VSI tool. For more information about Login VSI, please visit http://www.loginvsi.com.
As mentioned, tests were conducted using the Login VSI Medium with Flash workload. The VSImax value was defined as 4000 ms and is illustrated by a shaded orange line on each graph. A system reaches a level of unacceptable performance when the latency exceeds the 4000-ms VSImax. Additional test configuration settings are detailed in Table 2.
Text Box:

Table 2. Configuration Settings for the Test

Configuration

Setting(s)

Login VSI Configuration Settings

• Medium with Flash workload generator
• 4,000ms response cut off

Windows 7 Configuration

• 1.5GB memory for all tests
• 32-bit Windows 7 SP-I and Windows updates through September 1, 2012

ESX Host Configuration

• Power management set to High Performance in vSphere
• BIOS settings have C1E disabled in UCSM policy
• ESXi-5.0.0-623860-custom (Cisco specific build of ESXi with drivers)

VM Configuration

• 1vCPU and 2vCPU configurations

View Configuration

• Linked clones
• View Optimization registry changes on all Virtual desktops
• Did not use profile management
• Did not use host Cache for View

Cores vs. Clock Speed and the Impact on Virtual Desktop Density

A virtual desktop can only run as fast as the core on which it is running. This implies that the Intel Xeon E5-2643 processor has an advantage with a clock speed that is roughly 37 percent greater than that of the Intel Xeon E5-2665. Although this may be the case in a nonoversubscribed system, the business and financial requirements of VDI dictate that the cores be oversubscribed.
Figure 3 compares the VDI scalability of one-vCPU virtual machines using eight-core 2.4-GHz Intel Xeon E5-2665 processors to those using four-core 3.3-GHz Intel Xeon E5-2643 processors. The system with the Intel Xeon E5-2643 processors supported 81 virtual desktops before exceeding the VSImax threshold while the system with the Intel Xeon E5-2665 processors supported 130 virtual desktops. The result is a 60 percent improvement, implying that the number of cores matters more than the core speed as virtual-to-physical CPU overcommit increases. Note that at lower virtual machine (VM) counts (below 30 virtual desktops), the latency was slightly better on the higher-speed Intel Xeon E5-2643 CPU.

Figure 3. Intel Xeon E5-2665 Compared to Intel Xeon E5-2643 with One vCPU

Figure 4 shows the effects on scale when the virtual desktops are allocated two vCPUs. In this test, the system with the Intel Xeon E5-2643 processors exceeded the VSImax at 54 virtual desktops, and the Intel Xeon E5-2665 system exceeded the VSImax at 93 virtual desktops (72 percent more virtual desktops). Similar one- and two-vCPU tests at a memory bus speed of 1066 MHz yielded the same results, with the Intel Xeon E5-2665 system supplying between 60 and 94 percent more virtual desktops than the Intel Xeon E5-2643 system. These results are summarized in Table 3.

Figure 4. Intel Xeon E5-2665 Compared to Intel Xeon E5-2643 at Two vCPUs per Virtual Machine

Table 3. Comparing Intel Xeon E5-2643 and E5-2665 Virtual Desktop Density

 

E5-2643 Virtual Desktops

E5-2665 Virtual Desktops

% improvement with E5-2665

1vCPU, 1600MHz

81

130

60%

2vCPU, 1600MHz

54

93

72%

1vCPU, 1066MHz

66

128

94%

2vCPU, 1066MHz

56

96

71%

Summary

When virtual machine density is the primary goal in a VDI environment, designers should place greater emphasis on the number of cores than on the clock speed.

Effect of Individual Core Speed (Burst) on Virtual Desktop Scalability

Table 4 summarizes the differences between two processors in the Intel Xeon E5-2600 family. The Intel Xeon E5-2643 provides a low core count and high speed, and the Intel Xeon E5-2665 provides a high core count and medium speed.

Table 4. Comparing Intel Xeon E5-2643 and E5-2665 Processor Specifications and SPEC Performance

 

Intel E5-2643

Intel E5-2665

Number of Cores

4

8

Clock Speed

3.3 GHz

2.4 GHz

Max Turbo Frequency

3.5 GHz

3.1 GHz

Max TDP

130W

115W

Recommended Customer Price (Tray)

$885

$1440

SPEC CINT2006 Rate

187.5

305

SPEC CFP2006 Rate

167.5

233.5

SPEC Blend/Core

44.38

33.6

The SPEC Blend rate, as shown in Table 4, is an average of the SPEC CINT2006 and SPEC CFP2006 rates for a processor. SPEC Blend/Core is the SPEC Blend rate divided by the number of cores and represents the per-core performance for a processor.
The Intel Xeon E5-2643 processor's clock speed is 37 percent faster and the SPEC Blend rate per core is 32 percent higher than for the Intel Xeon E5-2665. The Intel Xeon E5-2665 has overall higher SPEC CINT and CFP capacity values simply because of the higher core count.
Figure 5 expands the results from Table 3 to show the number of VMs per core achieved by each processor. In all scenarios, the Intel Xeon E5-2643 obtained a higher ratio of VMs per core than the Intel Xeon E5-2665.

Figure 5. Comparing Intel Xeon E5-2643 and E5-2665 SPEC Blend/Core and Virtual Machines per Core Ratios

Table 5. Comparing Intel Xeon E5-2643 and E5-2665 Core Density

 

E5-2643 Virtual Desktops

E5-2643 VM/core

E5-2665 Virtual Desktops

E5-2665 VM/core

E5-2643 Core Density Advantage

1vCPU, 1600MHz

81

10

130

8.125

23%

2vCPU, 1600MHz

54

6.75

93

5.8125

16%

1vCPU, 1066MHz

66

8.25

128

8

3%

2vCPU, 1066MHz

56

7

96

6

17%

Summary

Although the increase is not linear, the data shows that the additional 32 percent performance of the higher-bursting Intel Xeon E5-2643 can yield up to a 25 percent (two virtual machines per core) greater per-core virtual machine density.
For more information about SPEC performance data, visit http://www.spec.org/.

Setting Realistic Virtual Desktop Limits for Cisco UCS B200 M3 Servers Using Intel Xeon E5-2643 and E5-2665 Processors

Data from previous tables in this document can be used to construct Figure 6, which shows that the system based on the Intel Xeon E5-2643 never achieved more than 80 virtual desktops. The system achieved between 60 and 80 virtual desktops under one-vCPU loads, and fewer than 60 virtual desktops under two-vCPU loads.

Figure 6. Practical Scalability Limits

Most VDI deployments typically use one vCPU. Therefore, the Intel Xeon E5-2643 system can comfortably achieve more than 60, but fewer than 80, virtual desktops.
Figures 6 and 7 show that the Intel Xeon E5-2665 system never achieved a usable scale of fewer than 90 virtual desktops and reached as many as 130 virtual desktops. Considering that most VDI deployments consist of one vCPU per virtual desktop, the Intel Xeon E5-2665 system is better suited for deployments ranging between 105 and 125 virtual desktops per system.

Figure 7. CPU Scaling

Summary

The Intel Xeon E5-2643, with its high clock speed and lower core count, is better suited for smaller deployments of fewer than 80 virtual desktops per system. The Intel Xeon E5-2665, with its moderate clock speed and higher core count, is better suited for larger deployments of more than 100 virtual desktops per system.
This assessment leaves two ranges that are not covered by either processor: between 80 and 100 virtual desktops per system, and more than 120 virtual desktops per system. The Intel Xeon E5-2600 family includes many processors that could be evaluated to cover these densities, but those processors are beyond the scope of the testing discussed in this document.

SPEC CPU2006 CINT2006 Rate Required for Virtual Desktop Operations

Figure 8 shows the SPEC CPU2006 CINT2006 rate required for each virtual desktop using the scalability data shown in Table 5 of this document. There are several noteworthy observations from this data:

• In three of the four tests, the Intel Xeon E5-2665 and E5-2643 SPEC CINT rates per VM were close to each other, implying that SPEC CINT is a good indicator for expected VM density.

• The lowest SPEC CINT rate per VMwas achieved by both processors in the one-vCPU 1600-MHz test, implying that this scenario represents the optimal VDI deployment for these two processors, as shown in Figure 8.

• The smallest difference between these two processors was seen in the one-vCPU 1600-MHz test.

Figure 8. SPEC CINT2006 Rate per Virtual Desktop

Summary

With one vCPU per virtual desktop and a 1600-MHz memory speed, a SPEC CINT rate of 4.6 to 4.7 per virtual desktop running a Medium Login VSI workload is a reasonable expectation regardless of processor core count or clock speed. An increase in the vCPU count or a decrease in the memory bus speed will lead to higher SPEC CINT requirements per virtual desktop.

Scalability of One- and Two-vCPU Virtual Desktop Deployments

Figure 9 shows a comparison of one-vCPU and two-vCPU virtual desktops running on the Intel Xeon E5-2643. With one vCPU, the Intel Xeon E5-2643 system scaled to 81 virtual desktops before exceeding the VSImax. The same system scaled to only 54 virtual desktops when configured with two vCPUs (a 33 percent decrease in scalability). The addition of a second vCPU to the user's virtual desktop resulted in little improvement in end-user latency , even with only a small number of virtual desktops.

Figure 9. Intel Xeon E5-2643 vCPU Scalability at 1600 MHz

Figure 10 shows the impact on the Intel Xeon E5-2665 system. With one vCPU, the Intel Xeon E5-2665 system scaled to 130 virtual desktops before exceeding the VSImax. The same system scaled to only 93 virtual desktops when configured with two vCPUs (a 40 percent decrease in scalability).

Figure 10. Intel Xeon E5-2665 vCPU Scalability at 1600 MHz

Unlike the Intel Xeon E5-2643 system, the Intel Xeon E5-2665 system showed a slight improvement in virtual desktop latency with the use of two vCPUs. The slight improvement was achieved when fewer than 45 total virtual desktops were deployed.
Figures 9 and 10 show systems performing at 1600-MHz memory bus speed. The same comparisons between one- and two-vCPU deployments were performed at a memory bus speed of 1066 MHz. At the lower memory bus speed, moving from one vCPU to two vCPUs resulted in a drop in VM density of between 12 and 20 percent, as seen in Figures 12 and 13 later in this document.

Summary

Regardless of core count or processor speed, the number of vCPUs allocated to each virtual desktop has a significant impact on scalability, even with the same workload.

Weighing the Merits of Two-vCPU Virtual Desktops

A subset of the data in Figure 10 presents some interesting factors to consider. The purpose of allocating multiple vCPUs to a virtual desktop should be to increase a user's productivity by reducing the latency of task execution on the virtual desktop. Figure 11 shows that in the Medium Login VSI workload scenario, the two-vCPU virtual desktops have lower latency and outperform the one-vCPU virtual desktops in scenarios of up to 45 virtual desktops.

Figure 11. One-vCPU Latency Compared to Two-vCPU Latency

After 45 total virtual desktops are deployed, the latency of the two-vCPU virtual desktops begins to exceed that of the one-vCPU virtual desktops, and the increase in the ratio of vCPUs to physical cores (vCPU:core ratio) starts to reflect the platform's true capacity to sustain optimal response times with this workload.

Summary

The purpose of the two-vCPU deployment (lower application latency and better user experience) was lost at 45 virtual desktops. The true scalability limit for a two-vCPU deployment should not be considered the point at which it exceeds the VSImax; the scalability limit should be considered to be the point at which one-vCPU virtual desktops start to outperform two-vCPU virtual desktops.

Effect of Memory Speed on VDI Scalability

Figure 12 compares the one- and two-vCPU tests at both 1600 and 1066 MHz on the Intel Xeon E5-2643 system. The one-vCPU tests vary substantially at the different memory speeds, whereas the two-vCPU tests show a fairly consistent response. Scalability increases by 23 percent when the memory speed is 1600 MHz in a one-vCPU deployment.
Generally the one-vCPU test showed lower latency at 1600 MHz than at 1066 MHz, and that latency difference became exaggerated at approximately 65 virtual desktops (8.13 vCPUs per core). This effect had a large impact on overall density in the one-vCPU tests.

Figure 12. Intel Xeon E5-2643 at Different Memory Speeds

Figure 13 shows the same combinations of tests as Figure 12, but on the Intel Xeon E5-2665 system. Scalability increases by 3 to 4 percent when the memory speed is 1600 MHz.
Generally, the one-vCPU test showed lower latency at 1600 MHz than at 1066 MHz, but there was not a significant impact on overall density.

Figure 13. Intel Xeon E5-2665 at Different Memory Speeds

Summary

The majority of the tests show that an increase in memory speed has a positive impact on scalability. The greater ratio of VMs per core of the Intel Xeon E5-2643 appears to make this processor more sensitive to changes in memory bus speed for one-vCPU loads. The scalability increase resulting from the 1600-MHz memory speed on the Intel Xeon E5-2665 system is not as pronounced as on the Intel Xeon E5-2643 system.
In the Intel Xeon E5-2665 tests, each virtual desktop was allocated 1.5GB. At one vCPU, a scale of 130 virtual desktops was achieved at 1600 MHz, yielding a total memory requirement of 195GB. In deployments that require more memory per virtual desktop (2 to 4GB), it is better to increase the physical memory of the system, even at the cost of running the memory at a lower speed. As Figure 13 shows, the penalty is minor for running memory at the lower, 1066-MHz speed.

Effect of Memory Density on VDI Scalability

Note: Memory overhead for VMware ESXi is estimated at 200 MB. Memory overhead per vCPU is 29MB for a 1.5GB virtual desktop with 1vCPU. Memory overhead information can be found here.

At 1.5GB per virtual desktop, the system equipped with 160GB of memory will not reach memory saturation until approximately 104 virtual desktops:
200MB ESXi overhead + 104 x (1.5GB + 29MB overhead) = 160GB
Figure 14 shows that the Intel Xeon E5-2665 system equipped with 160GB of memory exceeded the VSImax at 106 virtual desktops, slightly beyond the point of memory saturation. The 160GB system ran out of memory and was unable to scale beyond 106 virtual desktops.

Figure 14. Effect of Intel Xeon E5-2665 Memory Density with One vCPU

The system equipped with 256GB of memory will not reach memory saturation until approximately 168 virtual desktops:
200MB ESXi overhead + 168 x (1.5GB + 29MB overhead) = 256GB
Figure 14 also shows that the system equipped with 256GB of memory exceeded the VSImax at 130 virtual desktops, which is well short of the point at which saturation should occur (168 virtual desktops). This result occurs because of insufficient CPU.
Increasing memory from 160GB to 256GB (60 percent more memory) yielded 24 additional virtual desktops (23 percent more). The response to additional memory was significant but not linear, simply because the system did not have enough CPU for the additional virtual desktops.
In addition, the system with ample physical memory (256GB) achieved lower virtual desktop latency throughout the test. The nature of this test did not give the Hypervisor enough time to reclaim memory. Over time it may be possible to boot up some additional desktops, but it is not a recommended due to boot and login storms.
On the Intel Xeon E5-2643, CPU became a limiting factor before memory, with the result that the VSImax was reached well before the theoretical 98 virtual desktop count. Therefore, the Intel Xeon E5-2643 data was not used in this portion of the study.

Summary

Memory is often considered important in planning VDI capacity. Overcommit can help stretch limited memory resources, but tests show better performance, improvements in overall usability, and lower response times when the hypervisor has sufficient physical memory to scale as workloads increase.

Effect of Storage IOPS on Virtual Desktop Operations

To determine the number of IOPS required for a boot storm, a VMware Horizon View pool of 150 virtual desktops was enabled. These 150 virtual desktops booted within an approximately 4-minute period as can be seen in the Pure Storage dashboards shown in Figures 15 and 16.

Figure 15. Pure Storage Dashboard (1)

Figure 16. Pure Storage Dashboard (2)

This all-flash memory storage array is capable of a much greater number of IOPS than that seen in this test, and the SAN connecting the blades to the storage target is capable of substantially greater throughput than that seen in this test. With no other activity or contention occurring in the system, it is reasonable to believe that there are no bottlenecks.
Both the Pure Storage dashboard and the VMware vCenter performance graphs showed a peak of 39,000 read IOPS and 2200 write IOPS during this boot storm of 150 virtual desktops, which translates to 260 read IOPS and 15 write IOPS per virtual desktop for bootup.
To determine the number of IOPS required during sustained virtual desktop use, the Login VSI Medium workload generator exercised this pool of 150 virtual desktops. After the initial boot and login storm, system use settled down to approximately 1700 read IOPS and 1000 write IOPS, as confirmed by both the Pure Storage dashboard and VMware vCenter. These results are equivalent to approximately 11 read IOPS and 7 write IOPS per virtual desktop, as shown in Figure 17.

Figure 17. Virtual Desktop IOPS with 150 Simultaneous Virtual Desktops

Summary

A typical Microsoft Windows 7 machine can require 260 read IOPS and 15 write IOPS during bootup. Use of a storage subsystem that accommodates fewer operations will result in slower boot times. The impact of boot storms can be reduced by having some of the virtual desktops powered on at all times. Boot storms will still occur if a VDI host fails and the virtual desktops from that host must be booted from other hosts.
After bootup and login, a typical Microsoft Windows 7 virtual desktop uses a small number of IOPS (11 read and 7 write), but storage must be sized to accommodate concurrent users (with additional capacity to handle boot and login storms).

Your Results May Differ

As with many studies of this nature, the results achieved here are tightly coupled to the specific test environment (hardware and software) used, user workload profile employed, and methodology followed. Although VDI implementers can derive useful guidance from these findings, each specific VDI environment may yield different results. This study therefore provides no guarantees, expressly written or implied, regarding results achieved.

Conclusion

This study was initiated with the objective of revealing the critical choices that implementers of desktop virtualization must make when sizing and designing a computing platform to host virtual desktop workloads. In documenting the findings, the study revealed critical considerations and questions that often are missing from commonly available literature that discusses VDI. The findings in response to these questions are summarized here:

• If the server-to-desktop density ratio is the main consideration, the number of CPU cores is more important than the clock speed.

• The virtual machine density per CPU core can be increased (by up to 25 percent as shown in the study) with a higher CPU burst clock speed.

• For deployments of fewer than 80 desktops, a high clock speed and lower core count yield better results. For deployments with more than 100 desktops, a moderate clock speed and higher core count are beneficial.

• A SPEC CINT requirement of 4.6 to 4.7 per virtual desktop running a Medium Login VSI workload is a reasonable expectation regardless of the processor core count or clock speed.

• The use of more vCPUs per desktop may not increase desktop performance or enhance the user experience, but it will significantly affect virtual desktop density.

• The performance benefits of two-vCPU configurations are achieved for a certain range of deployment size (45 desktops in this study), after which one vCPU starts to outperform two vCPUs and yield lower latency.

• A lower memory bus speed may not affect virtual desktop density.

• Having sufficient physical memory to accommodate virtual machine requirements and overhead yields better latency and better virtual desktop density.

• The number of IOPS during bootup can be 20 times higher than sustained the number of IOPS for a Login VSI Medium workload. The IOPS during bootup are almost entirely read operations, whereas sustained IOPS are more balanced between read and write operations.

For More Information

Please also visit http://www.cisco.com/go/vdi.

Appendix: Server and Storage Configuration Information

Table 6 presents Cisco UCS blade server configurations, and Table 7 presents the Pure Storage configuration.

Table 6. Cisco UCS Blade Server Configurations

System

Cisco UCS B200 M3 - 2643

Cisco UCS B200 M3 - 2665

General

Number of processor packages

2

2

Number of cores per processor

4

8

System power management policy

High Performance - C1E disabled

High Performance - C1E disabled

CPUs

Vendor

Intel

Intel

Name

Xeon

Xeon

Model Number

E5-2643

E5-2665

Stepping

7

7

Socket Type

FCLGA2011

FCLGA2011

Core frequency (GHz)

3.3GHz

2.4GHz

Bus frequency

8 GT/s

8 GT/s

Max TDP

130 Watts

115 Watts

Recommended Customer Price

TRAY: $885

TRAY: $1440

Cache

10M

20M

Platform

Vendor and model number

Cisco UCS B200 M3

Cisco UCS B200 M3

Partnumber

73-13217-06

73-13217-06

BIOS name and version

B200M3.2.0.4a.0.080920121557

B200M3.2.0.4a.0.080920121557

BIOS settings

High Performance - C1E disabled

High Performance - C1E disabled

Memory module(s)

Total RAM in system (GB)

160GB-384GB

256-384GB

Vendor

Samsung

Samsung

Type

PC3L-12800R

PC3L-12800R

Speed (MHz)

1,600MHz

1,600MHz

Speed running in the system (MHz)

1,600MHz-1,066MHz

1,600MHz-1,066MHz

Size (GB)

8-16GB

8-16GB

Number of RAM module(s)

16-24

16-24

Chip organization

Double-sided

Double-sided

Rank

Dual

Dual

Hard Disk

Vendor and model number

NA

NA

Number of disks in system

NA

NA

Size (GB)

NA

NA

RPM

NA

NA

Type

NA

NA

Raid controller

Vendor and model

LSI MegaRAID SAS 2004

LSI Mega RAID SAS 2004

Controller firmware

   

Operating System

Name

VMware ESXi

VMware ESXi

Build number

ESXi-5.0.0-623860-custom (Cisco build of ESXi with Drivers)

ESXi-5.0.0-623860-custom (Cisco build of ESXi with Drivers)

Operating system power profile

Maximum Performance

Maximum Performance

I/O Adapters

Vendor and model number

UCSB-MLOM-40G-01

UCSB-MLOM-40G-01

Type

M-LOM

M-LOM

Table 7. Pure Storage Configuration

System

Pure Storage Flash Array

Storage

Number of disk enclosures

1

Power supplies

Total number

4

Disks

Number

24

Operating system

Name

Purity V 2.0.2

Network

Type

8GB Fiber Channel

Note: At the time of testing, Cisco UCS certification testing for Pure Storage was not complete.

Authors and Credits (in Alphabetical Order)

Keith Brant - Solutions Architect, Cisco Advanced Services.

Doron Chosnek - Consulting Systems Engineer, Virtualization SME

Shawn Kaiser - Consulting Systems Engineer, Virtualization SME

Jason Marchesano - Consulting Systems Engineer, Service Provider

Hardware and software partners - the authors thanks the following vendors for their resources and support provided to this initiative: Login VSI, Pure Storage, and VMware.