MS Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
Description
FROM THE SOLUTIONS CENTER Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5 As the opportunity to consolidate servers on to virtualized platforms is now considered commonplace, end users are looking further ahead and considering more resource-intensive applications as candidates for deployment in a virtualized environment. FROM THE SOLUTIONS CENTER TECHNICAL BRIEF CONTENTS Executive Overview.......................................................................................................................................................................................................................... 3 Results Summary...........................................................................................................................................................3 Approach ........................................................................................................................................................................3 Testing............................................................................................................................................................................3 Goals .................................................................................................................................................................................................................................................. ...
Informations
| Publié par | Mothug |
| Nombre de lectures | 33 |
| Langue | Slovak |
Extrait
FROM THE SOLUTIONS CENTER Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5 As the opportunity to consolidate servers on to virtualized platforms is now considered commonplace, end users are looking further ahead and considering more resource-intensive applications as candidates for deployment in a virtualized environment.
TECHNICAL BRIEF
FROM THE SOLUTIONS CENTER C ONTENTS Executive Overview.......................................................................................................................................................................................................................... 3 Results Summary........................................................................................................................................................... 3 Approach ........................................................................................................................................................................ 3 Testing ............................................................................................................................................................................ 3 Goals .................................................................................................................................................................................................................................................. 4 Anticipated Benefits ....................................................................................................................................................................................................................... 4 Methodology ..................................................................................................................................................................................................................................... 5 Results................................................................................................................................................................................................................................................. 6 ESX Server 3.5 Performance Data................................................................................................................................ 6 Guest Performance Data............................................................................................................................................... 8 Exchange Instance Metrics .........................................................................................................................................10 Virtualized versus Non-Virtualized Environments ......................................................................................................14 Lessons Learned............................................................................................................................................................................................................................15 Conclusion........................................................................................................................................................................................................................................15 Why Brocade? ................................................................................................................................................................................................................................16 Appendix A: High-Level Configuration ....................................................................................................................................................................................17 Software .......................................................................................................................................................................17 Loadgen Scripting ........................................................................................................................................................17 Hardware ......................................................................................................................................................................17 Compute Platforms ..............................................................................................................................................17 Storage Network...................................................................................................................................................18 Storage..................................................................................................................................................................18 Messages Weights and Sizes......................................................................................................................................19 Exchange Standard and Enterprise Licensing Differences .......................................................................................20 Results in Tabular Format ...........................................................................................................................................20
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
2 of 22
TECHNICAL BRIEF
FROM THE SOLUTIONS CENTER E XECUTIVE O VERVIEW As the opportunity to consolidate servers on to virtualized platforms is now considered commonplace, end users are looking further ahead and considering more resource-intensive applications as virtualizing candidates. This paper will show that Microsoft Exchange 2007 running in an environment virtualized through VMware ESX Server 3.5 is an entirely viable proposition. Even though previous versions of ESX Server have not been optimized for I/O-intensive applications, Brocade ® decided to test the hypothesis that a Microsoft Exchange 2007 environment running on ESX Server 3.5 could support a production Exchange 2007 infrastructure for the same number of mailboxes that could run on equivalent non-virtualized platforms. The goal was to make the case regardless of the total mailboxes involved so that the solution could apply to organizations of all sizes. A stretch goal was to show that a consolidated virtualized solution could go beyond simple equality and deliver a more robust and flexible solution that scales better and reduces infrastructure costs. Organizations typically regard their e-mail application as mission-critical. Any change to a functioning e-mail architecture must at a minimum maintain existing application performance and availability. Once those criteria are satisfied, organizations next determine if the benefits arising from the change more than offset the effort and cost to move to the new architecture. Performance and availability characteristics depend on the size of the organization. Small to Medium sized Businesses (SMBs) may not require continuous availability. Global enterprises need very high levels of availability to satisfy their user population worldwide. Results Summary Here are some of the results of the benchmark testing, which are discussed in greater detail later: The results show that relatively modest virtualized environments can comfortably support up to 5,000 users and improve operational efficiency and expenditure. Virtualized environments provide availability dividends in backups, clustering, and smaller failure domains and provide a simpler, more scalable architecture. Consolidating Exchange servers save infrastructure costs and means fewer platforms, reduced license costs, and other overhead costs. Approach The approach was simple. A complete Exchange 2007 environment was simulated on a single virtualized platform for 1,000 mailboxes complete with all the servers normally associated with an implementation such as this. The Mailbox Servers were then separated from the support servers and complete environments for 3,000, 4,000 and 5,000 mailboxes were simulated by adding a new Mailbox Server for every 1,000 mailboxes serviced. Finally the performance of a virtualized 3,000-mailbox environment was compared to a non-virtualized environment Extend the concept to include building Exchange infrastructures based on building blocks of 1,000 mailboxes each based on a Mailbox Server running in a separate Virtual Machine (VM), and the result is a simpler and very scalable architecture. Testing The testing was performed in the Brocade Solutions Center lab at Brocade corporate headquarters in San Jose California.
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
3 of 22
TECHNICAL BRIEF
FROM THE SOLUTIONS CENTER G OALS The project was divided into several phases, which together address the overall goal of showing the general viability of a virtualized Exchange 2007 deployment. The goals were as follows: To show that all processes can be run on a single platform for 1,000 mailboxes To show that 1,000 mailbox configurations on two platforms can be scaled up to 5,000 mailboxes to demonstrate that the virtualized environment will support more than 3,000 mailboxes without violating Microsoft best practice guidelines. Note that each VM running the message server is well below the recommended maximum per server. To compare resource utilization and platform headroom between a virtualized and non-virtualized environment supporting 3,000 mailboxes To demonstrate the viability of running virtualized Exchange 2007 on one of the most popular bladed server platforms (since many end users are switching to bladed server environments). A NTICIPATED B ENEFITS Any significant change to an infrastructure that is currently working requires substantial benefits to offset the risks of such a change. Here are some of the architectural and operational advantages of a Microsoft Exchange solution running on VMware ESX Server 3.5 for both the SMB and the enterprise: Simplified Exchange and Windows maintenance. It is much easier to apply and revert changes to both the application and operating system in a virtualized environment. For the guest, one can simply snapshot the guest and apply the patch. If any errors are detected simply restore from the snapshot. Smaller architectural building blocks make the solution more scalable. In this test, Mailbox Servers were deployed 1,000 mailboxes at a time. Limiting the mailboxes to 1,000 Mailbox Server creates a server with a predictable performance profile that reduces deployment risk. Smaller Mailbox Servers reduces failure domains, which means that only 1,000 mailboxes are impacted by the failure of a Mailbox Server or loss of database data. The backup and restore processes are simplified, and a 1,000-mailbox limit allows for parallel backups and shorter restore windows. Virtualizing Exchange on ESX Server 3.5 can also reduce both capital and operational costs (CapEx and OpEx). For example: For organizations with up to 1,000 total mailboxes, it is possible to run the entire Exchange infrastructure on a single platform and an additional platform for standby . Platform requirements can be reduced for larger organizations by consolidating the hardware and workload to a maximum of two platform types plus a standby as follows: One platform for the edge, Client Access Server (CAS), and hub servers One platform server for Mailbox Servers each servicing 1,000 mailboxes. As shown below, more mailboxes can be supported on a single virtualized platform than on the same non-virtualized platform. One or more hot standby servers depending on the overall size of the infrastructure Note that reducing the number of platforms reduces a corresponding need for power, cabling, Keyboard, Video (display), and Mouse (KVM), and rack space. Operational and licensing costs can be reduced by:
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
4 of 22
TECHNICAL BRIEF
FROM THE SOLUTIONS CENTER Moving away from Enterprise Exchange licenses. See Appendix ??? for the feature differences between the Standard and Enterprise licenses. Eliminating the need for an Enterprise license reduces the per-mailbox cost of deployment considerably. Note also that each Mailbox Server can have either a Standard or Enterprise license. No need for a cluster server M ETHODOLOGY The purpose of this proof of concept testing was to simulate real Exchange user workload as closely as possible. Here are some of the highlights: Standard office usage emulation was simulated using the Microsoft standard load Generator (Loadgen). Mobile devices were always active. KPN provided custom scripts used in their own Exchange environments to emulate protocol behavior (ESP) including: Retrieve and read messages of different sizes Four hours of work in four hours where the first two hours are unmeasured because Exchange is filling caches (Microsoft best practice). Two runs of 8 hours in 8 hours (4,000 MB and 5,000 MB) were added to monitor longer usage. Web mail was not simulated because most employees rarely use Web mail at the same time as they are using a regular Outlook client. The proof of concept was divided into three phases 1. 1,000 mailboxes all Exchange processes running on one blade 2. 3, 000 mailboxes running on two blades including a direct comparison to a non-virtualized configuration on a single non-virtualized platform using 3,000 mailboxes. Note that a Microsoft best practice recommendation for a single physical platform at time of test was 2,500 mailboxes. A goal was to show that all processes run without performance degradation. 3. 4,000 and 5,000 mailboxes on 2 blades show that a single platform can support up to 5 VMs each serving 1,000 Mailbox Servers. The mailbox increments were added by adding Mailbox Servers (1,000 MB at a time). Microsoft Exchange performance, VM (guest Windows OS) performance, and VMware ESX Server performance were measured as follows: Microsoft Perfmon for Windows and Exchange with a sampling interval of 15 seconds (Microsoft recommendation) VMware esxtop for ESX Server and guest VMs with a sampling interval of 5 seconds (for details about VMware esxtop, which provides a real-time view of ESX Server worlds, see http://www.vmware.com/pdf/esx2_using_esxtop.pdf)
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
5 of 22
TECHNICAL BRIEF
FROM THE SOLUTIONS CENTER R ESULTS Note that the Mailbox Server platform was the subject of interest in this proof of concept testing. All monitoring and measurements concentrated the blade server running this workload. The following metrics were collected: ESX Server CPU utilization, memory utilization, and I/O data transfers Microsoft Exchange CPU utilization, memory utilization, RPC latencies, IOPS and reads/writes. Unless otherwise noted all the performance information on the graphs in this section use the same y-axis (the number of mailboxes supported). The y-axis is as follows top to bottom: 5,000 mailboxes served (5 Mailbox Servers each serving 1,000 mailboxes). 4,000 mailboxes served (4 Mailbox Servers each serving 1,000 mailboxes) 3,000 mailboxes served (3 Mailbox Servers each serving 1,000 mailboxes) 1,000 mailboxes served (a single Exchange Mailbox Server) The same information is provided in table format in Appendix A. ESX Server 3.5 Performance Data NOTE: All ESX Server data was collected using esxtop . Figure 1 shows the ESX Server CPU utilization levels for each set of mailbox servers virtualized. The x-axis shows the percentage CPU utilization by ESX Server itself. Note that the ESX Server never consumes more than the one core quantum it initially received..
Figure 1. ESX Server CPU utilization
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
6 of 22
FROM THE SOLUTIONS CENTER TECHNICAL BRIEF Figure 2 shows IOPS measured by esxtop based on the number of commands per second. The levels, including peaks, show nothing unexpected. The ESX Server I/O abstraction layer is more than capable of dealing with this level of activity.
Figure 2. ESX Server I/Os Per Second (IOPS) Figure 3 shows ESX Server memory utilization of the four virtualized scenarios on the Message Server blade. As expected, the amount of free memory declines as Exchange Mailbox Severs are added to the workload. Since the amount of memory available to each Mailbox Server was limited to 6 GB (5 GB for the fifth server) the observed behavior is expected. There is no evidence of ESX Server ballooning or swapping.
Figure 3. ESX Server memory free
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
7 of 22
FROM THE SOLUTIONS CENTER TECHNICAL BRIEF Figure 4 shows platform I/O in MB per sec. The averages climb with increased workload as expected. Peaks are more than 6x averages. This could be significant depending on the duration of peak periods because Exchange expects deterministic I/O performance.
Figure 4. ESX Server I/O in MB per second Guest Performance Data Figure 5 presents average guest CPU utilization. Because each VM was allocated 4 cores, utilization is measured on a maximum of 400%. Notice that the performance is linear until 5 concurrent Exchange Mailbox Servers each supporting 1,000 mailboxes is reached. The fifth VM was memory constrained to 1 GB less than the others (5 GB). A possible explanation is that more time was spent managing real memory in the guest and cache memory in Exchange as a result. At no point, however, were there any issues with guest CPU utilization. Also, there was never any Windows swapping, an observation that strongly suggests that memory utilization was never an issue.
Figure 5. Guest CPU utilization
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
8 of 22
TECHNICAL BRIEF
FROM THE SOLUTIONS CENTER Touched memory, shown in Figure 6, refers to memory that is frequently used within a VM and is roughly equivalent to the VM working set of memory pages. Touched memory is determined statistically and depends somewhat on the activity of the application running in the guest and the sampling intervals used. The anomaly in the test with three concurrent Virtual Machines cannot be explained; however other runs for one, two and five concurrent Exchange Message Server instances produced very consistent results.
Figure 6. Touched memory Ready time is defined as the time a Virtual Machine must wait in a ready-to-run state before it can be scheduled on a CPU. Several factors affect the amount of ready time seen including: Overall CPU utilization The number of guests The number of virtual CPUs in a VM Physical CPU Scheduling: Virtual machines that have been scheduled on a particular CPU are given preference to run on the same CPU again, because of performance advantages of finding data in the CPU cache. The recommended value in this proof of concept testing is less than 120% on a maximum of 400% as shown by the light bars. Normal increases are observed as number of VMs increase, while averages remain very good.
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
9 of 22
FROM THE SOLUTIONS CENTER
TECHNICAL BRIEF
Figure 7. Percent ready time Exchange Instance Metrics Exchange IOPS shown in Figure 8 are a key Exchange performance metric. The average levels for all tests are all very close to recommended values (approximately .32 shown in light bars) and are uniform across all the VM instances.
Figure 8. Microsoft Exchange IOPS per mailbox
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
10 of 22
TECHNICAL BRIEF
FROM THE SOLUTIONS CENTER Figure 9 shows that the average and peak megabytes free are well above the recommended value of 100 megabytes on average. It demonstrates clearly that memory, a key constraint in virtualized environments, is not an issue in the testing.
Figure 9. Average and peak free space Figure 10 presents RPC Requests per second, another key Exchange performance measure. The graph shows clearly that RPC latencies are very low across all VM instances.. The Microsoft guideline (less than 70) is almost never exceeded, even at peak usage.
Figure 10. RPC requests per second
Microsoft Exchange 2007 Benchmark Testing in a Virtualized Environment with VMware ESX Server 3.5
11 of 22
© 2010-2024 YouScribe