THE SUN FIRE™ X4600 M2 SERVER AND PROVEN VIRTUALIZATION SCALABILITY White Paper May 2007 , Inc.

Table of Contents

Introduction ...... 1

Scalability and Consolidation ...... 2 Scalability Defined ...... 2 Measuring Scalability ...... 2 Experience Delivering Scalable Systems ...... 3

Virtualization Scalability and the Sun Fire X4600 M2 Server ...... 4 Pairing Server and Storage Scalability ...... 4 Scalable Storage to Match ...... 5 Scalable Platforms, Scalable Performance ...... 5

Objective Scalability Measures ...... 6 VMmark Benchmark Design ...... 6 Derived From Standard Benchmarks...... 8 Tiled Workload Design ...... 8 The VMmark Metric ...... 8

Test Configuration and Detailed Results ...... 10 Detailed Results ...... 11 Memory Locality Measurements...... 12

Conclusion ...... 14 1 Introduction Sun Microsystems, Inc.

Chapter 1 Introduction

Nearly every Information Technology (IT) organization is using consolidation, or is considering using consolidation, as a way to reduce both capital and operating costs. IT organizations with a number of applications running on older, inefficient, and under- utilized servers can consolidate them onto a smaller number of high-performance, energy-efficient servers that can run at higher utilization levels and reduce overall space, power, and cooling requirements. Reducing the total number of servers can help to reduce both administration and hardware maintenance costs. As a side benefit, IT organizations saddled with legacy applications running on obsolete hardware and operating-system platforms can use consolidation to upgrade to new, more powerful servers.

For more information on the role of In most cases, consolidation requires virtualization technology to allow multiple virtualization, please refer to the solution instances and applications to coexist on a single server without brief titled Consolidation through interference. With products supporting virtualization and resource partitioning Virtualization with Sun x64 Servers. reaching back more than a decade, Sun Microsystems offers customers a range of technologies from which to choose. Dynamic System Domains provide electrically isolated partitions of its high-end Sun Fire™ server platforms to support multiple OS and application instances. Logical Domains (LDoms), supported on the latest UltraSPARC® T1 processors, extends hardware virtualization support to servers having as few as a single processor. The Solaris™ Operating System allows multiple, isolated applications to run on a single operating system instance through Solaris Containers technology, and it supports multiple operating system instances through its support for Xen, currently available through the Solaris ExpressSM program. Some of the most powerful virtualization technology that Sun supports is embodied in VMware Virtual Infrastructure 3 software, whose performance on the Sun Fire X4600 M2 server is the topic of this white paper.

Consolidation through virtualization requires a combination of server and virtualization technology that delivers sufficient performance to make the move to a smaller number of servers worthwhile. Without the ability to support multiple applications on a single server at desired performance levels, IT organizations cannot achieve the capital and operating cost reductions they desire.

The bottom line: a four-socket Sun Fire X4600 Fortunately, the combination of the Sun Fire X4600 M2 server and VMware Virtual M2 server can host twice the number of Infrastructure 3 software provides a powerful, scalable consolidation platform whose virtual machines as a two-socket server, and performance is proven by measurements using a beta version of the VMmark an eight -socket version can host 3.5 times as many as the two-socket server. benchmark. This white paper discusses the importance of scalability in consolidation, the performance of the Sun Fire X4600 M2 server, and the details of how the benchmark was executed. 2 Scalability and Consolidation Sun Microsystems, Inc.

Chapter 2 Scalability and Consolidation

For consolidation through virtualization to be an effective business strategy, the virtualization technology and server performance must combine to deliver a platform that allows multiple applications to run on the same server at the desired performance levels. If more than one application can’t run effectively on a single server, there’s no point in making the effort to consolidate.

Until recently, IT organizations have not been particularly concerned about how well their virtualization platforms scale. This is because most organizations have started with the low-hanging fruit: consolidating applications with very low resource demands such as internal DNS servers, mail servers, and Web servers. As the value of consolidation is proven, IT organizations begin to look at consolidating more resource- intensive applications, and scalability becomes a more important topic.

Scalability Defined Scalability is the property that adding more resources to a server — such as more CPUs and memory — result in the server handling a commensurate increase in work. Linear scalability describes an ideal situation where every increase in server resources results in the same increase in capacity. Doubling the number of CPUs and memory, for example, result in a doubling of the server’s throughput.

Linear scalability is a goal, but it is rarely achieved beyond more than just a few processors because the greater the workload, the greater the amount of overhead in the operating system (or virtualization software) and the greater amount of interaction between processes detracts from the software’s ability to scale. In servers with large numbers of processors, issues such as memory bus contention and cache coherency come into play, reducing the ability of a server to scale. Sun has been a leader in delivering highly scalable server platforms, from the symmetric multiprocessing supported by the Sun Fire E25K server (with up to 72 processors) to the Sun Fire X4600 M2 server that its the topic of this paper.

Measuring Scalability Scalability is often measured by increasing a server’s workload until one or more of its resources become saturated, then adding more resources and measuring again. The result is a plot of performance (often measured by throughput) versus the resource characteristics of the system. Figure 1 is an example of such a graph. The abscissa represents the number of processors, and the ordinate represents the maximum observed throughput. The set of orange bars illustrate an ideal situation with linear 3 Scalability and Consolidation Sun Microsystems, Inc.

scalability. The set of green bars illustrate a more realistic situation where the server’s throughput begins to level off while the amount of resources continue to increase.

5

4

3 Throughput 2

1

12345 Amount of Dedicated Resources Linear Scalability Typical Scalability

Figure 1. Linear scalability is a goal, but real-world applications typically scale less than linearly.

In the x86-architecture server market, the inability of many operating system-based applications to scale beyond four processors has limited the demand for servers that scale beyond four processors or four processor sockets. Indeed, some processors are architecturally limited to no more than four sockets per server.

Experience Delivering Scalable Systems Sun Microsystems, with its UltraSPARC processor-based server product line offering options with as many as 72 processors in a single server, sees the market differently. Many commercial applications ranging from application servers to enterprise databases easily utilize more than four processors, so Sun has not constrained either its UltraSPARC or its x64 server product line to the four-socket maximum often seen in x86- architecture servers. Indeed, the Sun Fire X4600 M2 server is one of the few eight-socket x64 servers on the market today, and its performance running VMware is one illustration of the benefits of having a more scalable platform. 4 Virtualization Scalability and the Sun Fire X4600 M2 Server Sun Microsystems, Inc.

Chapter 3 Virtualization Scalability and the Sun Fire X4600 M2 Server

Sun built the Sun Fire X4600 M2 server to meet the needs of organizations that need more raw compute power than typical four-socket servers are capable of providing. It is an ideal consolidation platform because of its raw processing capacity and its ability to accommodate additional processors, memory, and I/O resources as workloads demand them. Sun paired the Sun Fire X4600 M2 server with the highly scalable Sun StorageTek™ 6540 Array to create a highly scalable virtualization platform that demonstrates near linear scalability on the VMmark virtualization benchmark.

Pairing Server and Storage Scalability The Sun Fire X4600 M2 server is a modular, scalable system that can pack up to eight CPU sockets and up to 64 GB of memory in a mere four rack units, putting roughly twice the resources in the same space as other 4 RU servers on the market today (Figure 2). The server’s performance per cubic volume helps IT organizations alleviate their space crunch, while the server’s excellent performance per watt helps them to reduce power consumption and cooling requirements.

Figure 2. The Sun Fire X4600 M2 server is an ideal virtualization platform.

The Sun Fire X4600 M2 server is a modular system that supports up to eight internal CPU/memory modules. Each module holds a single dual-core AMD Opteron™ processor and from 1-8 GB of memory. The CPU modules are distributed across the server’s I/O subsystem so that adding modules increases CPU, memory, and I/O capacity at the same time. The server is field upgradeable, so organizations can add resources incrementally using a pay-as-you-grow model. The server’s current capacity of eight dual-core processors yields a maximum of 16 processor cores and 64 GB of memory. The server’s M2 designation indicates that its CPU/memory modules can be replaced with quad-core AMD Opteron processors as they become available, for a total capacity of 32 processor cores. For the purpose of measuring virtualization performance, the Sun Fire X4600 M2 server used in testing utilized 2.8 GHz AMD Opteron model 8220 processors. 5 Virtualization Scalability and the Sun Fire X4600 M2 Server Sun Microsystems, Inc.

The server’s processing capacity is matched with I/O flexibility that contributes to its value as a virtualization platform. The server includes four Gigabit Ethernet ports and up to four hot-pluggable SAS disk drives with on-bard RAID 0 and RAID 1. It has four low- profile 8-lane PCI Express card slots, two low-profile 4-lane PCI Express card slots, and two low-profile PCI-X slots.

The server includes a built-in service processor with a dedicated management network port, and its N+N redundant, hot-swappable power and cooling supplies means no down time in the event of a power supply or cooling fan failure.

Scalable Storage to Match Figure 3. The Sun StorEdge 6540 Array For the purpose of measuring virtualization performance, Sun paired the Sun Fire X4600 matches the scalability of the Sun Fire M2 server with the Sun StorageTek 6540 Array (Figure 3). The StorageTek 6540 Array was X4600 sever to create an ideal chosen because it is a modular, scalable, high-performance storage system that can consolidation platform. scale both storage capacity and performance as workload demands dictate. The Array consists of integrated dual controllers that can support up to 14 Common Storage Module (CSMII) expansion trays, each with from 5-16 15,000 RPM Fibre Channel disk drives for a total capacity of 224 drives and up to 112 TB per system.

As with the Sun Fire X4600 M2 server, the StorageTek 6540 Array can scale its I/O capacity as more disk trays are added to the system. The array can support up to eight 4 GBps Fibre Channel host interfaces.

Scalable Platforms, Scalable Performance The combination of the Sun Fire X4600 M2 server and the Sun StoageTek 6540 Array provides a scalable virtualization platform in three ways:

• Scalable Server. Customers can deploy two-socket Sun Fire X4600 M2 servers and add more CPU and memory resources as their consolidation workloads increase, all without changing the server footprint. The server can scale to up to eight sockets supporting dual-core processors today, with the capacity to handle quad-core processors as they become available. • Scalable Storage. The Sun StorageTek 6540 Array can scale up in capacity as more storage and more storage performance is required. Disk trays themselves can scale from 5-16 disk drives, and customers can add trays up to the maximum of 14 as necessary. I/O scalability can be increased through the addition of more 4 GBps Fibre Channel interfaces • Scalable Capacity. As demonstrated by objective performance measurements on the VMmark benchmark, this potent server and storage combination delivers linear scalability from 2-4 CPU modules, and near linear scalability from 4-8 CPU modules as described in the next chapter. 6 Objective Scalability Measures Sun Microsystems, Inc.

Chapter 4 Objective Scalability Measures

The VMmark benchmark gives IT organizations a way to objectively compare the scalability of different virtualization platforms. A beta version of the VMmark benchmark was used to assess the combination of VMware Infrastructure 3 software, the Sun Fire X4600 M2 server, and the Sun StorageTek 6540 Array configured with varying amounts of CPU, memory, I/O, and storage resources.

VMmark is a product of VMware, Inc., an The benchmark runs a highly resource-intensive workload on the server to measure EMC company. VMmark utilizes the scalability characteristics. The results demonstrate that a four-socket Sun Fire X4600 M2 SPEC®jbb2005 and the SPECweb®2005 server can manage twice the number of active virtual machines as a two-socket system benchmarks, which are available from the Standard Performance Evaluation (Figure 4). An eight-socket server can handle 3.5 times the number of virtual machines Corporation (SPEC®). The beta VMmark as a two-socket system. results reported in this document were 350% obtained using VMmark version v.0.06b.20070115_5GB. SPEC, SPECjbb, and 307% SPECweb are registered trademarks of SPEC, the Standard Performance Evaluation Corporation. 193%200% Scalability 100%100%

248 Number of Sockets

VMmark Scalability Virtual Machine Scalability

Figure 4. Scalability as demonstrated by VMmark benchmark results.

The benchmark’s VMmark performance metric shows that performance scales with server capacity as well: a four-socket server scaled to 1.93 times that of the two-socket server, and the eight-socket server scaled to 3.07 times the two-socket server.

This chapter discusses the design of the VMmark benchmark, and the following chapter discusses the test configuration and the results in detail.

VMmark Benchmark Design The VMmark benchmark is designed to measure virtualization platform performance by executing a heterogeneous set of workloads that are representative of the kinds of 7 Objective Scalability Measures Sun Microsystems, Inc.

applications that an IT organization might consolidate onto a single server. The benchmark incorporates six workloads, each of which is contained in its own virtual machine. Where necessary, the workloads are imposed by an external load generator, or simply monitored by an external system. The six workload components are as follows:

The number of virtual CPUs and amounts of • Mail Server. This component runs an instance of Microsoft Exchange Server 2003 on main memory reflect how the benchmark Microsoft Windows Server 2003, Enterprise Edition. The mail server is configured to was actually run to produce the results support 1000 Microsoft Exchange users, and is hosted in a virtual machine with two reported in this white paper. virtual CPUs and 1 GB of main memory. The LoadSim load-generation facility is used More details on the VMmark benchmark can to drive this component. be found in the VMware white paper titled • Application Server. The application server component runs the BEA j-Rockit 5.0 Java™ VMmark: A Scalable Benchmark for Virtualized Systems. technology application server on Microsoft Windows Server 2003 software using a derivative of the SPECjbb2005 benchmark. This transactional workload is generated internally on the virtual machine. The workload represents an order-processing application for a wholesale supplier. The application server is hosted in a virtual machine with two virtual CPUs and 1 GB of main memory. • Standby Server. Recognizing that many IT organizations maintain servers that are ready at any time to take on a workload in order to meet peak demands, the benchmark includes a virtual machine that is idle except for a periodic heartbeat to determine that the server is operational. This workload runs on Microsoft Windows Server 2003. The virtual machine is configured with one virtual CPU and 256 MB of main memory. • Web Server. Virtually every IT organization maintains one or more Web servers, and this workload component is a modified version of the SPECweb2005 benchmark. It runs an e-commerce workload placing requests on an Apache 2.0.54 Web server. This workload component runs on Red Hat Enterprise Linux 4 Update 1 software using two virtual CPUs and 512 MB of main memory. • Database Server. The database workload component executes an online transaction processing workload using Swingbench, Oracle’s freely-available online transaction processing application and an Oracle 10g (10.1.0.3) database. This component runs on Red Hat Enterprise Linux 4 Update 1 software using two virtual CPUs and 2 GB of main memory. • File Server. The file server workload component runs on Red Hat Enterprise Linux Update 1 software, and it executes a workload representative of PC users accessing a file server. The workload is imposed by a modified version of dbench, which uses access pattern traces from the NetBench benchmark. The virtual machine was configured with one virtual CPU and 256 MB of main memory. 8 Objective Scalability Measures Sun Microsystems, Inc.

Derived From Standard Benchmarks Rather than designing six new benchmarks to represent each workload, existing benchmarks were modified and utilized where possible. The benchmarks were modified in two significant ways:

• Some benchmarks were modified to have longer run times so that they could support the long run time of the VMmark benchmark. • Some benchmarks had think times adjusted in order to achieve the goal of fully saturating the system.

The latter modification has a significant impact on how the VMmark benchmark results should be interpreted. Unlike most real-world servers, the workloads on these virtual machines have been modified to be even more demanding than the original benchmarks from which they have been derived. This means that results that indicate a number of virtual machines that can be executed on a server is a low number compared to what many IT organizations would expect. Of course when interpreting any benchmark results, organizations should take into account the fact that benchmark workloads are typically higher in intensity than real workloads, and “your mileage may vary” is an appropriate watchword.

Tiled Workload Design One set of the six workloads executing in a virtualized environment is known as a tile. The benchmark methodology has the performance analyst increasing the number of workload tiles running on a server until one or more resources (such as CPU, memory, or I/O capacity) has saturated. Resource consumption is measured by the VMware esxtop command. One benchmark result is the number of tiles that can be executed on a server before resource saturation is observed. The Sun Fire X4600 M2 server, for example, was able to execute two tiles within a two-socket system, four tiles on a four- socket system, and seven tiles on an eight-socket system. This capacity was measured with 91-97 percent CPU utilization across all of the server’s CPUs.

The VMmark Metric The VMmark benchmark is designed to run for at least three hours, with metrics collected at frequent intervals while the benchmark runs. Once an initial startup time has passed, the steady-state time is divided into three 20-minute periods. For each period, measurements from each workload are computed, and the median score for each of the three sections is selected as the score for the tile. For multi-tile runs, the sum of the median results is used.

The VMmark score is computed by first normalizing the varying metrics (for example transactions per second, Web accesses per second, orders placed per second) according to a reference. The geometric mean of the normalized values is used to generate the 9 Objective Scalability Measures Sun Microsystems, Inc.

final VMmark result. This process allows performance for the overall benchmark to be represented as a single number.

The comparative results illustrated in Figure 4 show that a four-socket Sun Fire X4600 M2 sever delivered 1.93 times the VMmark performance of a two-socket server, and an eight-socket server delivered 3.07 times the performance of the two-socket server. 10 Test Configuration and Detailed Results Sun Microsystems, Inc.

Chapter 5 Test Configuration and Detailed Results

The execution of the VMmark benchmark The VMmark benchmark was executed on a Sun Fire X4600 M2 server configured with was audited by VeriTest, the testing service of 2, 4, and 8 CPU/memory modules, with each module populated with 8 GB of memory Lionbridge. The detailed results are available for a total of 16, 32, and 64 GB of main memory, respectively. The benchmark in the February 2007 report titled Scalability Test of the Sun FIre X4600 M2 Server with configuration is illustrated in Figure 5 VMware Infrastructure 3

One Sun Fire V20z Load Generation Server Per Tile

4 1 Gbps Ethernet Connections

Sun Fire x4600 Server

4 4 Gbps Fiber Channel

2 LUNS, 2 Tiles 4 LUNS, 4 Tiles 8 LUNS, 8 Tiles

Figure 5. The VMmark benchmark was executed on a Sun Fire X4600 M2 server driven by up to eight Sun FIre V20z servers and using up to four trays on a Sun StorageTek 6540 Array.

The workload for each tile was driven and monitored by a separate Sun Fire V20z server. Each server connected to a switch over a Gigabit Ethernet connection, with all four of the Sun Fire X4600 M2 server’s Gigabit Ethernet ports connected to the switch. A total of eight Sun Fire V20z servers was used because the benchmark was run to a total of eight tiles to verify resource saturation. 11 Test Configuration and Detailed Results Sun Microsystems, Inc.

As the number of CPU/memory modules was increased, the number of Fibre Channel interfaces connecting to the Sun StorageTek 6540 Array was increased. The two-socket configuration used a single PCI Express 4 Gbps Fibre Channel interface to connect to the array. The four-socket configuration used two interfaces, and the eight-socket configuration used four interfaces. Although each interface is capable of handling 4 Gbps of bandwidth, limitations in VMware ESX Server limited the bandwidth of each Fibre Channel connection to 2 Gbps.

Storage for the benchmark was laid out onto the array with the data for a single tile stored on a single logical unit (LUN). The two-socket server was connected to two LUNs stored on a single expansion tray; the four-socket server used four LUNs on two trays, and the eight-socket server used eight LUNs on four trays. Storage requirements per tile are relatively light: 5 GB per tile.

Detailed Results The benchmark results are summarized in Figure 6, where the overall VMmark score and the score for each of the components have been normalized so that the two-socket server running two benchmark tiles is fixed at 100 percent.

393% 400%

350% 350% 323% 307% 300% 277%

250% 222% 205% 199% 193% 198% 200% 182% 181%

Relative Performance Relative 150%

100% 100% 100% 100% 100% 100% 100%

50%

VMmark FileServer Database Webserver JavaServer MailServer score Two sockets, four cores, two benchmark tiles Four sockets, eight cores, four tiles Eight sockets, 16 cores, seven tiles

Figure 6. Result summary for the Sun Fire X4600 M2 server. 12 Test Configuration and Detailed Results Sun Microsystems, Inc.

Overall, the four-socket Sun Fire X4600 M2 server produced almost double the VMmark score as the two-socket server, and the eight-socket server produced a score just over three times that of the two-socket server. Performance on the individual workload components provides some further insight:

• Mail Server. The mail server component demonstrated the best scalability of all of the benchmark components, with nearly linear scalability to eight sockets. This suggests that workloads of multiple Microsoft Exchange servers should consolidate extremely well onto the Sun Fire X4600 M2 server. • Application Server. The application server component also scaled extremely well, with the eight-socket server running seven application server instances producing a VMmark score 3.5 times that of the two-socket server. Scalability from 2-4 sockets is virtually linear. • Web Server. Web server performance was almost linear from 2-4 sockets, and at eight sockets it produces a VMmark score 3.23 times the two-socket server. • Database Server. The database server workload is a resources-intensive one that consumes CPU, memory, and I/O bandwidth. It scaled somewhat less than the mail, application, and Web server workloads, possibly due to I/O contention with the file server component. • File Server. The file server benchmark scaled almost exactly the same as the database server between the two and four-socket servers, and it scaled less well between four and eight sockets, suggesting that resource contention might be an issue. Indeed, with only one virtual CPU allocated to the file server, and thus fewer CPU resources than the two-CPU virtual machines, it may simply not have enough processing resources allocated to it.

I/O bandwidth is also a possible source of contention. In the past, file servers were configured with large amounts of main memory to increase the likelihood that the requested blocks would be cached in the server. Today, file servers are typically configured with less memory, which forces more I/O activity. This is the case with this benchmark component configuration, where only 256 MB of main memory is allocated to the file server. Alleviating the resource contention caused by this component might also result in even greater scalability in other components.

Memory Locality Measurements The Sun Fire X4600 M2 server is built using a Non-Uniform Memory Architecture (NUMA). The server’s memory address space is uniform, so that all CPUs access memory using a consistent set of real memory addresses. Memory access, however is non-uniform because memory located on a CPU’s own module is accessed with lower latency than memory located on another CPU/memory module. In the latter case, the 13 Test Configuration and Detailed Results Sun Microsystems, Inc.

Hypertransport mechanism speeds the memory access, but with higher latency than local access.

One might argue that a NUMA architecture would perform poorly as a virtualization platform because when different physical CPUs are dispatched to virtual machines whose memory is located on different CPU/memory modules, performance would suffer. Actual measurements show that the opposite is true.

VMware ESX Server, the virtualization component of VMware Infrastructure 3 software, takes care to maintain an affinity between virtual machines and the CPUs that are dispatched to process instructions within them. This is a good strategy for any memory architecture, because every CPU has a cache that is invalidated each time a different CPU is dispatched to handle its workload. When a virtual machine must be dispatched to run on a different CPU, VMware classifies the event as a migration.

During the execution of the VMmark benchmark, both the number of migrations and the percentage of local versus non-local memory accesses were measured. The number of migrations during the eight-socket benchmark run was 2.81 times the number of migrations during the two-socket benchmark run, which indicates that the number of migrations did not increase as fast as the number of CPUs (a factor of four), a result indicating excellent locality that contributes to the server’s scalability. Local memory references accounted for 93, 89, and 83 percent of all memory accesses during the two, four, and eight-socket server benchmark runs, again pointing to high locality that leads to excellent scalability. 14 Conclusion Sun Microsystems, Inc.

Chapter 6 Conclusion

The Sun Fire X4600 M2 server combined with the Sun StorageTek 6540 Array help to deliver the scalability that IT organizations need to handle the most demanding workloads in a virtualized environment. Proven scalability that is a result of teamwork between Sun, AMD, and VMware:

• Sun built the Sun Fire X4600 sever to be scaled from 2-8 processor sockets, and from 2-64 GB of main memory, allowing organizations to increase the virtualization platform’s capacity without increasing its footprint. In addition to the server’s raw processing capability, the ability to hot swap redundant power supplies and fans in the event of failure, and to monitor and manage the server remotely, all contribute to the high availability that enterprise applications require. • AMD Opteron processors power the Sun FIre X4600 M2 server with dual-core processors today, and the option to upgrade to quad-core processors in the future. With processors designed from the beginning to produce the most performance per watt, AMD Opteron processor-powered servers are an excellent choice for IT organizations needing to reduce their space, power, and cooling requirements. AMD’s Hypertransport mechanism ties the server’s CPU modules together in a NUMA memory architecture that helps to deliver scalability through optimizing memory latency. • With nearly linear scalability from 2-8 processor sockets, and from 4-16 processor cores, VMware Infrastructure 3 software handles some of the most demanding consolidation workloads with ease. The software’s ability to manage the benchmark’s resource-intensive workload while minimizing the number of migrations between CPU/memory modules is further testimony to the value offered by Sun, AMD, and VMware.

The key finding presented in this white paper is the scalability that is demonstrated by the VMmark benchmark. This paper has not stressed the maximum number of virtual machines executed by the benchmark — six components times seven tiles, or 42 virtual machines — because such a number most often does not translate directly into the capacity that an IT organization will observe with a real workload.

Most real workloads are bursty, with periods of low resource utilization punctuated by spikes created by momentary workload fluctuations. In contrast, the workloads used in the VMmark benchmark are continuous and resource intensive, designed so that the benchmark would stress the server’s capabilities. The maximum number of virtual machines that an IT organization will configure on a single Sun Fire X4600 M2 server running VMware Infrastructure 3 software is likely to be higher than the number used 15 Conclusion Sun Microsystems, Inc.

in the VMmark benchmark, but of course even that conclusion depends on the specific real workload characteristics and the quality-of-service levels that must be supported.

As with all benchmark results, its important to remember that “your mileage may vary.” One result, however is not likely to vary: the efforts of three leading-edge technology companies — Sun, AMD, and VMware — have combined to make the Sun Fire X4600 M2 server one of the most scalable virtualization platforms available anywhere. The Sun Fire X4600 M2 Server and Proven Virtualization Scalability On the Web sun.com/x64

Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 USA Phone 1-650-960-1300 or 1-800-555-9SUN (9786) Web sun.com © 2007 Sun Microsystems, Inc. All rights reserved. © 2006-2007 Sun Microsystems, Inc. Sun, Sun Microsystems, the Sun logo, Sun Fire, Java, Solaris, and StorageTek are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon architecture developed by Sun Microsystems, Inc. AMD, Opteron, and the AMD Opteron logo are a trademarks or registered trademarks of Advanced Micro Devices, Inc. SPEC, SPECjbb, and SPECweb are registered trademarks of SPEC, the Standard Performance Evaluation Corporation. Information subject to change without notice. SunWin 499277 Printed in USA 05/07