EMC Virtual Infrastructure for Microsoft Exchange 2007 Enabled by EMC CLARiiON CX4-120 and VMware vsphere 4.0 using iscsi

Transcription

1 EMC Virtual Infrastructure for Microsoft Exchange 27 Enabled by EMC CLARiiON CX4-12 and Applied Technology Abstract This white paper details a solution built and tested using EMC CLARiiON CX4-12 and VMware vsphere 4. with iscsi to host a Microsoft Exchange Server messaging system. This solution incorporates the VMware Fault Tolerance feature that provides mailbox server High Availability. April 29

2 Copyright 29 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com All other trademarks used herein are the property of their respective owners. Part Number: H626 Applied Technology 2

3 Table of Contents Executive summary... 4 Introduction... 4 Audience... 4 Terminology... 5 VMware vsphere 4. and VMware FT technology... 5 Environment configuration... 6 Testing Hypothesis Test Hypothesis Test Hypothesis Test Hypothesis Test Hypothesis Test Hypothesis Test Hypothesis Test Hypothesis Test Hypothesis Building Block Testing Conclusion... 4 References Appendix Enabling FT logging (EX2 example) LoadGen PerfMon Data Test LoadGen PerfMon Data Test Comparison of LoadGen PerfMon Data Test 2 and Test LoadGen PerfMon Data Test LoadGen PerfMon Data Test Comparison of LoadGen PerfMon Data Test 5 and Test LoadGen PerfMon Data Test LoadGen PerfMon Data Test Comparison of LoadGen PerfMon Data Test 8 and Test LoadGen PerfMon Data Test LoadGen PerfMon Data Test Comparison of LoadGen PerfMon Data Test 11 and Test Applied Technology 3

4 Executive summary Microsoft Exchange environments present a challenge for building a consolidated solution that is both scalable and resilient. Using a combination of EMC CLARiiON CX4 arrays with proven five 9s ( percent) availability for storage, VMware vsphere 4. for consolidation, VMware Fault Tolerance (FT) for business continuity, and Microsoft Windows 28 with Microsoft Exchange 27 Service Pack 1 (SP1) for , it is possible to achieve the solution that meets these challenges. Introduction The objective of this white paper is to provide a technical overview of the testing required for the scalability of VMware vsphere 4. and FT for virtualized guests. The virtual machine (VM) guest operating system and application used for this solution was Microsoft Windows 28 with a Microsoft Exchange 27 SP1 mailbox role in 1, mailbox building blocks. One thousand mailbox building blocks were selected to allow for scaling testing of VMware vsphere 4. and FT testing. EMC conducted validation testing using Microsoft Load Generator (LoadGen) with a very heavy Outlook profile. LoadGen was used to simulate client connectivity to the Exchange Mailbox Server and to determine the client experience during failover and whether connectivity was lost or no change was detected. The scope of the testing included: VMware vsphere 4. scalability against proven array building blocks VMware FT with Microsoft Exchange 27 SP1 This white paper discusses the virtual configuration, array configuration, testing results, and conclusions of the solution. Audience This white paper is intended for customers, including IT planners, storage architects and administrators and any others involved in evaluating, acquiring, managing, operating, or designing an EMC networked storage environment using VMware vsphere 4.. This document is also aimed at EMC staff and partners for guidance and development of proposals. The audience of this white paper must have a working knowledge of the following technologies: VMware vsphere 4. VMware FT VMware vcenter Server VMware vsphere 4. Client CLARiiON CX4-12 Components of the Microsoft Exchange environment, including: Microsoft Active Directory Server Microsoft Windows 28 Enterprise Edition x64 Microsoft Exchange Server 27 SP1 Mailbox role Hub/CAS dual server role Microsoft LoadGen Applied Technology 4

5 Terminology Client: Latency >2 The client-reported number of successful RPCs with latencies > 2 seconds. Client: Latency >5 The client-reported number of successful RPCs with latencies > 5 seconds. Client: Latency >1 The client-reported number of successful RPCs with latencies > 1 seconds. Database Latencies LoadGen will report latencies, which can be used to determine an Outlook client experience. Fault Tolerance A feature within vsphere 4. to provide business continuity with higher levels of availability than are offered by VMware High Availability (HA). LoadGen Profile This is used when configuring LoadGen to mimic an Outlook user profile. These options include the Outlook version, cached versus online mode, users per server and storage group, and test duration. Outlook Profile This is the impact each Outlook client will have against an Exchange Server. RPC Averaged Latency RPC latency in milliseconds averaged for the past 1,24 packets. RPC Requests The number of client requests that are currently being processed by the information store. VMware vcenter Server The central point for configuring, provisioning, and managing virtualized IT environments. VMware vsphere 4. Client An interface that allows users to connect remotely to vcenter Server or ESX/ESXi from any Windows PC. VMware vsphere 4. and VMware FT technology VMware vsphere 4. is a virtualization layer running on physical servers that abstracts processor, memory, storage, and resources into multiple VMs. With VMware FT, VMware Infrastructure creates a duplicate of an existing VM. Actions performed on the primary VM are recorded and replayed on the secondary virtual machine, ensuring that they stay in an identical state. Because the secondary VM is in virtual lockstep with the primary virtual machine, the secondary can take over execution at any point without interruption, thereby providing FT. The primary and secondary virtual machines monitor the status of the other VM to ensure that FT is maintained. The virtual machines continually communicate through heartbeats and replay information. If a VM fails or the hardware running the VM fails, one VM detects that the other VM has failed. After a failure is detected, new copies of the fault-tolerant VMs are created on another host in the cluster. If the failed VM is the primary, the secondary takes over and a new secondary is established. If the secondary fails, another secondary is created to replace the one that was lost. VMware Infrastructure automatically handles the situation in which each VM in the FT pair believes the other has crashed, typically due to loss of networking between the VMs. Applied Technology 5

6 Environment configuration This section details the environment configuration used for validating VMware vsphere 4. and VMware FT. Figure 1 shows the physical and logical architecture of the CLARiiON CX4-12 and VMware vsphere 4. solution. Figure 1 Physical architecture of the solution The solution tested was designed to have four VMware vsphere 4. servers within a HA cluster with cabling to the CLARiiON CX4-12 array, using iscsi connectivity through a 1 Gb/s Layer 3 Ethernet switch. Within the VMware HA cluster, two nodes having the prerequisite FT processor homed with Exchange Mailbox Servers, were configured with FT. The second two servers of the HA cluster homed the Microsoft Exchange Hub/CAS dual role server and the virtualized second Active Directory (AD) Domain Controller/Global Catalog server (DC/GC). A physical directory DC/GC server also existed within the environment. A Windows 28 Server was set up with the VMware vcenter Server installed for the creation and management of the virtual guests and required for the configuration of the VMware HA clusters and FT. Applied Technology 6

7 The solution was configured as a single VMware HA cluster to prove that servers having the prerequisite processors and chipset could be added to a VMware HA cluster with FT enabled. This allows customers to migrate their virtual servers quickly and enable this new feature as compliant hardware is added. The purpose of using a one-processor virtual Exchange Server was to accommodate the requirement for VMware FT, which is a maximum of one processor. For this reason, a building block was outlined and tested. Disk storage was provided by a CLARiiON CX4-12 with two Disk Array Enclosures (DAEs) containing thirty 3 GB 15k rpm Fibre Channel (FC) hard drives, where twenty-seven drives were used for the solution. The storage building blocks that were used are based on several EMC proven designs. These designs have been validated on physical machines and currently can be found on the Microsoft.com website under the ESRP V2.1 submissions. The design uses a RAID 1_ 2+2 build block CLARiiON RAID group, which has a proven capacity of 1, very heavy Outlook 27 users (.5 IOPS). Four Microsoft Exchange 27 SP1 Mailbox Servers were configured with four storage groups, with one Exchange database per storage group and one LUN per storage group for a total of 16 drives. Exchange Log files were placed in a single RAID 1_ 2+2 CLARiiON RAID group. CLARiiON metalun technology was used for both the databases and log files for proven FT and balanced LUN performance. Figure 2 illustrates the disk layout used. Figure 2 Disk layout The following section illustrates the storage design seen within the Navisphere UI. Applied Technology 7

8 metaluns EMC CLARiiON metaluns were used for increased balance and performance within the disks and LUNs. Balanced LUNs within storage groups Each server s LUNs are distributed equally on the array s storage processors (SP). This ensures that both SPs perform at optimal levels. SP A SP B Applied Technology 8

9 RAID groups CLARiiON storage groups The VMware vsphere 4. servers were all entered within a single CLARiiON storage group to allow all servers access to shared data stores. Each Exchange VM is configured within Navisphere, having access to each building block database and log file LUNs. Each server also has two mount point LUNs for additional SP balance. EXCH1 EXCH2 Applied Technology 9

10 EXCH3 EXCH4 Environment profile Each of the four Exchange servers was configured as shown in Table 1. As each server was added into the testing environment, this increased the number of mailboxes by 1, with a final total of 4, mailboxes. Table 1 Environment profile Profile characteristic Value Number of users per building block 1, Exchange 27 SP1 Mailbox Servers 4 Number of Exchange 27 users per server 1, Number of storage groups per server 4 Number of Exchange 27 databases per storage group 1 Number of Exchange 27 mailboxes per mail database 25 Mailbox quota 5 MB Applied Technology 1

11 Hardware and software resources Table 2 and Table 3 list the hardware and software configurations used in this solution. Table 2 Hardware resources Equipment Quantity Configuration Rack 1 42 U EMC CLARiiON CX storage processors GB mirrored cache DAEP GB FC HDD 3 (27 used) 15k FC FT Cluster Server 2 2 quad-core Xeon X545 (3GHz) processors 32 GB RAM 2 quad-port 1 Gb NICs High Availability Cluster Server VMware vcenter Server Physical Active Directory (DC/GC) Server 2 2 dual-core Xeon E722 (2.93GHz) processors 64 GB RAM 2 quad-port 1 Gb NICs 2 (1 VMware vcenter, 1 AD) 2 quad-core Xeon E5345 (2.33GHz) processors 16 GB RAM 2 Intel 1 Gb NICs Ethernet Switch 2 24-port 1 Gigabit Ethernet Layer 3 with 4 comboports Table 3 Software resources Software Version Microsoft Windows Server 28 RTM VMware vsphere (build 14882) Microsoft Exchange Server 27 mailbox role SP1 Microsoft Exchange Server 27 Hub/CAS role SP1 EMC PowerPath 5.2 x64 Microsoft iscsi Initiator Built In EMC Navisphere CLI EMC Navisphere Agent VMware vcenter Server 4. VMware vsphere 4. Client 4. Applied Technology 11

12 Testing Prior to running the tests, all 4,/4 server mailboxes were initialized with LoadGen, with each server having an independent organizational unit (OU) structure within the Active Directory Server. For an example of the OU structure, see the appendix of this white paper. Upon completion, all servers/storage groups were immediately backed up for later testing requirements of this white paper. The following test procedures were used: 1. Check that FT is disabled on all virtual guests. 2. Gracefully shut down servers not being used in the test. For every server that remains online, 1, mailboxes are added to the test. 3. Initiate the LoadGen 2-hour test on Server Save all data logging: a. From LoadGen client machines b. Event logs from all servers c. Navisphere data logging (NAR) 5. Enable FT on the mailbox server. a. Monitor ESX events until the secondary node showed as started. b. For an example of these events, see the appendix of this white paper. 6. Initiate the LoadGen 2-hour test. At the 1-hour mark, power off FT NODE 1 via the remote access console. (Note that the node is not gracefully shut down.) 7. Save all data logging: a. From LoadGen client machines b. Event Logs from all servers (AD, EX, Hub/CAS, ESX) c. Navisphere data logging (NAR) 8. Dismount and delete all database/log files on the server. 9. Restore databases for the servers that participated in the testing. 1. Repeat by adding another building block at a time until all four building block tests are completed or the thresholds for ESX, CLARiiON or Exchange are exceeded. Table 4 lists the tests that were run. Table 4 Test list Test Result Description 1 Init LoadGen initialization of 4, mailboxes. 2 Pass 2-hour LoadGen 1, mailboxes very heavy profile. Server 1, FT not enabled. Servers 2-4 off. 3 Pass FT enabled 2 hour LoadGen. At the 1-hour mark, power down FT NODE 1 via the remote access console. 4 Restore Restore first server databases. 5 Pass 2-hour LoadGen 2, mailboxes very heavy profile. Servers 1 and 2, FT not enabled. Servers 3-4 off. 6 Pass FT enabled 2 hour LoadGen. At the 1-hour mark, power down FT NODE 1 via the remote access console. Applied Technology 12

13 7 Restore Restore the first and second server databases. 8 Pass 2-hour LoadGen 3, mailboxes very heavy profile. Servers 1, 2, and 3, FT not enabled. Server 4 off. 9 Pass FT enabled 2-hour LoadGen. At the 1-hour mark, power down FT NODE 1 via the remote access console. 1 Restore Restore the first, second, and third server databases. 11 Pass 2-hour LoadGen 4, mailboxes very heavy profile. Servers 1-4, FT not enabled. All four mailbox servers online. 12 Pass FT enabled 2-hour LoadGen. At the 1-hour mark, power down FT NODE 1 via the remote access console. Initialization and restore phases were entered as tests to ensure that the time projected for each test took these phases into consideration, which are often overlooked and take a great deal of time. These test phases are not listed below. In the following sections, chart performance information graphs illustrate the performance in each area affected by these tests: ESX, CLARiiON array, PerfMon (guest) and LoadGen. On the ESX console, the CPU % Idle Time shows the effects of the test on the ESX server nodes gathered during the tests from esxtop data. This answers the question, how did the ESX server react to these tests? If the ESX server is constantly busy and unable to keep up, this would indicate that the server is overloaded. Navisphere performance charts show the effects of the test on the CLARiiON array gathered during the tests from the array (NAR data). This answers the question, how did the array react to the tests? If the service processors are constantly high, this would indicate that the arrays are overwhelmed and unable to keep up. The iscsi queue full would indicate that the paths have been flooded and more front-end ports are required. Windows Performance Analyzer (PerfMon) charts show the effects of the test on the guest, as seen from inside the virtual machines. This answers the question, how did the virtual guest react during the tests? RPC requests show the number of RPCs being handled on the virtual Exchange Server. This cannot remain above 75 for long periods of time and never above 9-95, otherwise users and server communications are greatly affected. Processor and Idle time work hand in hand; as processor utilization goes up, idle time drops. If the servers are at 1 percent constantly, and RPC requests remain high, the server will not perform well. If the processor is high, but RPCs are being serviced, this is not a problem. Hypothesis Test 2 Testing VMware vsphere 4. connected through iscsi to a CLARiiON CX4-12 array, with one server utilizing Building Block 1, 1, mailboxes, and running a simulated load through Microsoft LoadGen, will not cause guest processor utilization to exceed the recommended thresholds for the Microsoft Exchange Server, ESX Server, CLARiiON array, or LUNs. Test description Microsoft LoadGen was run against one VMware virtualized Exchange Mailbox Server for two hours, configured with a very heavy Outlook Client profile with four storage groups, each with 25 mailboxes and a total of 1, mailboxes. Test data standard for LoadGen was collected and saved, along with VMware esxtop performance data, and Navisphere Analyzer data. Result LoadGen completed all tasks for a period of two hours with no exceptions. ESX performance charts for Node 1 and Node 2 ESX logging showed during the test that the nodes perform at or above expectation with no issues. Applied Technology 13

14 It is important to note in the following ESX charts that the physical CPU % Idle Time, the drop in idle time in these charts, was investigated and no corresponding event within ESX event/alerts or Microsoft Event logs reported a cause for the increase in processor utilization. The drops were not due to the FT feature as the same drops were seen with and without FT enabled. Console Physical CPU % Idle Time 12 \\F4ESX5.f4e2k7.local\Console Physical Cpu\% Idle Time :25:17 PM 1:28:17 PM 1:31:17 PM 1:34:17 PM 1:37:18 PM 1:4:18 PM 1:43:18 PM 1:46:18 PM 1:49:18 PM 1:52:19 PM 1:55:19 PM 1:58:19 PM 2:1:19 PM 2:4:19 PM 2:7:2 PM 2:1:2 PM 2:13:2 PM 2:16:2 PM 2:19:2 PM 2:22:21 PM 2:25:21 PM 2:28:21 PM 2:31:21 PM 2:34:22 PM 2:37:22 PM 2:4:22 PM 2:43:22 PM 2:46:22 PM 2:49:23 PM 2:52:23 PM 2:55:23 PM 2:58:23 PM 3:1:23 PM 3:4:24 PM 3:7:24 PM 3:1:24 PM 3:13:24 PM 3:16:24 PM 3:19:25 PM 3:22:25 PM 3:25:25 PM 3:28:25 PM 3:31:26 PM 3:34:26 PM 3:37:26 PM 3:4:26 PM 3:43:26 PM 3:46:27 PM 3:49:27 PM 3:52:27 PM 3:55:27 PM 3:58:27 PM 4:1:28 PM 4:4:28 PM 4:7:28 PM 4:1:28 PM 4:13:28 PM 4:16:29 PM Navisphere performance The Navisphere performance chart shows that the service processors were balanced in utilization. Applied Technology 14

15 iscsi ports iscsi ports showed no queue full, which could indicate that the network is saturated. PerfMon performance chart The following PerfMon chart shows that on the virtual Exchange servers, processor %Idle Time averaged 67 percent, % Processor Time at 32 percent, with RPC Requests averaging less than five. The following PerfMon chart shows the total for the entire duration of the test. Applied Technology 15

16 Conclusion Test 2 VMware vsphere 4. connected via iscsi to a CLARiiON CX4-12 with one virtualized Exchange Mailbox Server with 1, mailboxes resulted in expected I/O ranges and latencies for the solution outlined. Hypothesis Test 3 VMware FT will fail over the virtual guest with Microsoft Windows 28 Enterprise Edition and the Microsoft Exchange services will remain online, all Exchange databases will remain online, and clients will remain connected during the failover. Test description Microsoft LoadGen was run against one VMware virtualized Exchange Mailbox Server for two hours, configured with a very heavy Outlook Client Profile with four storage groups, each with 25 mailboxes and a total of 1, mailboxes. Approximately one hour into the test, ESX NODE1 was powered down ungracefully via remote access console. Test data standard for LoadGen was collected and saved, along with VMware esxtop performance data, and Navisphere Analyzer data. Result Upon simulated failure, the FT secondary Exchange Server continued running without Exchange services going offline, Exchange databases dismounting, or LoadGen clients disconnecting. LoadGen results show a slight rise in latencies. ESX performance charts Upon enabling of the FT feature on the EXCH1 Mailbox Server, the local ESX Server showed a very slight difference in activity over the configuration without FT. It is important to note in the following ESX charts that the physical CPU % Idle Time, the drop in idle time in these charts, was investigated and no corresponding event within ESX event/alerts or Microsoft Event logs reported a cause for the increase in processor utilization. The drops were not due to the FT feature as the same drops were seen with and without FT enabled. Applied Technology 16

17 \\F4ESX4.f4e2k7.local\Console Physical Cpu\% Idle Time 6:17:3 PM 6:19:31 PM 6:21:31 PM 6:23:31 PM 6:25:31 PM 6:27:31 PM 6:29:31 PM 6:31:32 PM 6:33:32 PM 6:35:32 PM 6:37:32 PM 6:39:32 PM 6:41:32 PM 6:43:32 PM 6:45:33 PM 6:47:33 PM 6:49:33 PM 6:51:33 PM 6:53:33 PM 6:55:33 PM 6:57:33 PM \\F4ESX5.f4e2k7.local\Console Physical Cpu\% Idle Time 6:17:3 PM 6:19:3 PM 6:21:3 PM 6:23:3 PM 6:25:3 PM 6:27:31 PM 6:29:31 PM 6:31:31 PM 6:33:31 PM 6:35:31 PM 6:37:31 PM 6:39:32 PM 6:41:32 PM 6:43:32 PM 6:45:32 PM 6:47:32 PM 6:49:32 PM 6:51:32 PM 6:53:33 PM 6:55:33 PM 6:57:33 PM PerfMon performance chart PerfMon data showed a slight increase in average % Processor Time. The following PerfMon chart shows the total for the entire duration of the test. Applied Technology 17

18 Conclusion Test 3 The FT feature, with Microsoft Exchange 27 SP1 as a virtualized guest, worked as expected. When the ESX node homed the primary guest Exchange VM, the failover went virtually unnoticed by Exchange, Windows, and, most importantly, the clients. Hypothesis Test 5 Testing VMware vsphere 4. connected through iscsi to a CLARiiON CX4-12 array, with two servers utilizing Building Block 2, 2, mailboxes, and running a simulated load through Microsoft LoadGen, will not cause guest processor utilization to exceed the recommended thresholds for the Microsoft Exchange Server, ESX Server, CLARiiON array, or LUNs. Test description Microsoft LoadGen was run against two VMware virtualized Exchange Mailbox Servers for two hours, configured with a very heavy Outlook Client profile with four storage groups, each with 25 mailboxes and a total of 2, mailboxes. Test data standard for LoadGen was collected and saved, along with VMware esxtop performance data, and Navisphere Analyzer data. Result LoadGen completed all tasks for a period of two hours with no exceptions. ESX performance charts ESX performance charts showed that with two virtual machines there was little impact upon the host machine. It is important to note in the following ESX charts that the physical CPU % Idle Time, the drop in idle time in these charts, was investigated and no corresponding event within ESX event/alerts or Microsoft Event logs reported a cause for the increase in processor utilization. The drops were not due to the FT feature as the same drops were seen with and without FT enabled. Applied Technology 18

19 1 \\F4ESX4.f4e2k7.local\Console Physical Cpu\% Idle Time :9:44 PM 1:11:44 PM 1:13:44 PM 1:15:44 PM 1:17:45 PM 1:19:45 PM 1:21:45 PM 1:23:45 PM 1:25:45 PM 1:27:45 PM 1:29:45 PM 1:31:46 PM 1:33:46 PM 1:35:46 PM 1:37:46 PM 1:39:46 PM 1:41:46 PM 1:43:47 PM 1:45:47 PM 1:47:47 PM 1:49:47 PM 1:51:47 PM 1:53:47 PM 1:55:47 PM 1:57:48 PM 1:59:48 PM 11:1:48 PM 11:3:48 PM 11:5:48 PM 11:7:48 PM 11:9:49 PM 11:11:49 PM 11:13:49 PM 11:15:49 PM 11:17:49 PM 11:19:49 PM 11:21:49 PM 11:23:5 PM 11:25:5 PM 11:27:5 PM 11:29:5 PM 11:31:5 PM 11:33:5 PM 11:35:51 PM 11:37:51 PM 11:39:51 PM 11:41:51 PM 11:43:51 PM 11:45:51 PM 11:47:52 PM 11:49:52 PM 11:51:52 PM 11:53:52 PM 11:55:52 PM 11:57:52 PM 11:59:53 PM 12:1:53 AM 1 \\F4ESX5.f4e2k7.local\Console Physical Cpu\% Idle Time :9:41 PM 1:11:41 PM 1:13:42 PM 1:15:42 PM 1:17:42 PM 1:19:42 PM 1:21:42 PM 1:23:42 PM 1:25:42 PM 1:27:43 PM 1:29:43 PM 1:31:43 PM 1:33:43 PM 1:35:43 PM 1:37:43 PM 1:39:43 PM 1:41:44 PM 1:43:44 PM 1:45:44 PM 1:47:44 PM 1:49:44 PM 1:51:44 PM 1:53:44 PM 1:55:45 PM 1:57:45 PM 1:59:45 PM 11:1:45 PM 11:3:45 PM 11:5:45 PM 11:7:45 PM 11:9:46 PM 11:11:46 PM 11:13:46 PM 11:15:46 PM 11:17:46 PM 11:19:46 PM 11:21:46 PM 11:23:47 PM 11:25:47 PM 11:27:47 PM 11:29:47 PM 11:31:47 PM 11:33:47 PM 11:35:47 PM 11:37:48 PM 11:39:48 PM 11:41:48 PM 11:43:48 PM 11:45:48 PM 11:47:48 PM 11:49:48 PM 11:51:48 PM 11:53:49 PM 11:55:49 PM 11:57:49 PM 11:59:49 PM 12:1:49 AM Navisphere Analyzer data shows that the array and LUNs did not exceed EMC s recommended thresholds. Navisphere performance chart SP utilization again showed that SP processors are balanced and performing well at under 1 percent. Applied Technology 19

20 The SP iscsi queue full remained at zero. PerfMon data shows that the virtual Exchange Server did not exceed the recommended thresholds. PerfMon performance chart The following PerfMon chart shows the total for the entire duration of the test. Applied Technology 2

21 Conclusion Test 5 VMware vsphere 4. connected via iscsi to a CLARiiON CX4-12 with one virtualized Exchange Mailbox Server with 2, mailboxes resulted in expected I/O ranges and latencies for the solution outlined. Hypothesis Test 6 Testing VMware vsphere 4. connected through iscsi to a CLARiiON CX4-12 array with two servers utilizing Building Block 2, 2, mailboxes, and running a simulated load via Microsoft LoadGen, will not cause guest processor utilization to exceed the recommended thresholds for the Microsoft Exchange Server, ESX Server, CLARiiON array, or LUNs. Test description Microsoft LoadGen was run against two VMware virtualized Exchange Mailbox Servers for two hours, configured with a very heavy Outlook Client profile with four storage groups, each with 25 mailboxes and a total of 2, mailboxes. Approximately one hour into the test, ESX NODE1 was powered down ungracefully via the remote access console. Test data standard for LoadGen was collected and saved, along with VMware esxtop performance data, and Navisphere Analyzer data. Result Upon simulated failure, the FT secondary Exchange Server continued running without Exchange services going offline, Exchange databases dismounting, or LoadGen clients disconnecting. LoadGen results show a slight rise in latencies. ESX performance charts show Upon enabling of the FT feature on the EXCH1/EXCH3 Mailbox Server, the local ESX Server showed a very slight difference in activity over the configuration without FT. As can be seen in the following charts, the host servers during the enabling of FT and running failover caused a slight processor dip but quickly returned to normal idle levels. It is important to note in the following ESX charts that the physical CPU % Idle Time, the drop in idle time in these charts, was investigated and no corresponding event within ESX event/alerts or Microsoft Applied Technology 21

22 Event logs reported a cause for the increase in processor utilization. The drops were not due to the FT feature as the same drops were seen with and without FT enabled. 1 \\F4ESX4.f4e2k7.local\Console Physical Cpu\% Idle Time \\F4ESX5.f4e2k7.local\Console Physical Cpu\% Idle Time :21:57 AM 2:23:57 AM 2:25:57 AM 2:27:57 AM 2:29:57 AM 2:31:57 AM 2:33:58 AM 2:35:58 AM 2:37:58 AM 2:39:58 AM 2:41:58 AM 2:43:58 AM 2:45:58 AM 2:47:59 AM 2:49:59 AM 2:51:59 AM 2:53:59 AM 2:55:59 AM 2:57:59 AM 3:: AM 3:2: AM 3:4: AM 3:6: AM 3:8: AM 3:1:1 AM 3:12:1 AM 3:14:1 AM 3:16:1 AM 3:18:1 AM 3:2:1 AM 3:22:1 AM 3:24:2 AM 3:26:2 AM 3:28:2 AM 3:3:2 AM 3:32:2 AM 3:34:2 AM 3:36:3 AM 3:38:3 AM 3:4:3 AM 3:42:3 AM 3:44:3 AM 3:46:3 AM 3:48:3 AM 3:5:4 AM 3:52:4 AM 3:54:4 AM 3:56:4 AM 3:58:4 AM 4::4 AM 4:2:5 AM 4:4:5 AM 4:6:5 AM 4:8:5 AM 4:1:5 AM 4:12:5 AM 4:14:6 AM 4:16:6 AM 4:18:6 AM 4:2:6 AM 4:22:6 AM 4:24:6 AM 4:26:6 AM 4:28:7 AM 4:3:7 AM 4:32:7 AM 4:34:7 AM 4:36:7 AM 4:38:7 AM 4:4:8 AM PerfMon data shows that the virtual Exchange Server did not exceed the recommended thresholds. Applied Technology 22

23 PerfMon performance chart The following PerfMon chart shows the total for the entire duration of the test. Conclusion Test 6 The VMware FT feature, with Microsoft Exchange 27 SP1 as a virtualized guest, worked as expected. When the ESX node homed the primary guest Exchange VM, the failover went virtually unnoticed by Exchange, Windows and, most importantly, the clients. Hypothesis Test 8 Testing VMware vsphere 4. connected through iscsi to a CLARiiON CX4-12 array, with three servers utilizing three building blocks, 3, mailboxes, and running a simulated load via Microsoft LoadGen, will not cause guest processor utilization to exceed the recommended thresholds for the Microsoft Exchange Server, ESX Server, CLARiiON array, or LUNs. Test description Microsoft LoadGen was run against three VMware virtualized Exchange Mailbox Servers for two hours, configured with a very heavy Outlook Client profile with four storage groups, each with 25 mailboxes and a total of 3, mailboxes. Test data standard for LoadGen was collected and saved, along with VMware esxtop performance data, and Navisphere Analyzer data. Result LoadGen completed all tasks for a period of two hours with no exceptions. Applied Technology 23

24 ESX performance chart 1 \\F4ESX4.f4e2k7.local\Console Physical Cpu\% Idle Time :35:18 PM 9:37:18 PM 9:39:18 PM 9:41:18 PM 9:43:19 PM 9:45:19 PM 9:47:19 PM 9:49:19 PM 9:51:19 PM 9:53:19 PM 9:55:2 PM 9:57:2 PM 9:59:2 PM 1:1:2 PM 1:3:21 PM 1:5:21 PM 1:7:21 PM 1:9:21 PM 1:11:21 PM 1:13:21 PM 1:15:21 PM 1:17:22 PM 1:19:22 PM 1:21:22 PM 1:23:22 PM 1:25:22 PM 1:27:22 PM 1:29:23 PM 1:31:23 PM 1:33:23 PM 1:35:23 PM 1:37:23 PM 1:39:23 PM 1:41:24 PM 1:43:24 PM 1:45:24 PM 1:47:24 PM 1:49:24 PM 1:51:24 PM 1:53:25 PM 1:55:25 PM 1:57:25 PM 1:59:25 PM 11:1:25 PM 11:3:25 PM 11:5:26 PM 11:7:26 PM 11:9:26 PM 11:11:26 PM 11:13:26 PM 11:15:26 PM 11:17:27 PM 11:19:27 PM 11:21:27 PM 11:23:27 PM 1 \\F4ESX5.f4e2k7.local\Console Physical Cpu\% Idle Time :35:13 PM 9:37:13 PM 9:39:14 PM 9:41:14 PM 9:43:14 PM 9:45:14 PM 9:47:14 PM 9:49:14 PM 9:51:14 PM 9:53:15 PM 9:55:15 PM 9:57:15 PM 9:59:15 PM 1:1:15 PM 1:3:15 PM 1:5:16 PM 1:7:16 PM 1:9:16 PM 1:11:16 PM 1:13:16 PM 1:15:16 PM 1:17:16 PM 1:19:17 PM 1:21:17 PM 1:23:17 PM 1:25:17 PM 1:27:17 PM 1:29:17 PM 1:31:18 PM 1:33:18 PM 1:35:18 PM 1:37:18 PM 1:39:18 PM 1:41:18 PM 1:43:19 PM 1:45:19 PM 1:47:19 PM 1:49:19 PM 1:51:19 PM 1:53:19 PM 1:55:19 PM 1:57:2 PM 1:59:2 PM 11:1:2 PM 11:3:2 PM 11:5:2 PM 11:7:2 PM 11:9:21 PM 11:11:21 PM 11:13:21 PM 11:15:21 PM 11:17:21 PM 11:19:21 PM 11:21:22 PM 11:23:22 PM Applied Technology 24

25 Navisphere performance chart SP utilization remained low and balanced. SP queue full count remained at zero displaying no array iscsi issues. PerfMon data shows that the virtual Exchange Server did not exceed the recommended thresholds. PerfMon performance chart PerfMon data showed in the baseline test of 3, users that the performance metrics from the Exchange servers were outstanding. Applied Technology 25

26 The following PerfMon chart shows the total for the entire duration of the test. Conclusion Test 8 VMware vsphere 4. connected via iscsi to a CLARiiON CX4-12 with one virtualized Exchange Mailbox Server with 3, mailboxes resulted in expected I/O ranges and latencies for the solution outlined. Applied Technology 26

27 Hypothesis Test 9 Testing VMware vsphere 4. connected through iscsi to a CLARiiON CX4-12 array with three servers utilizing Building Block 3, 3, mailboxes, and running a simulated load via Microsoft LoadGen, will not cause guest processor utilization to exceed the recommended thresholds for the Microsoft Exchange Server, ESX Server, CLARiiON array, or LUNs. Test description Microsoft LoadGen was run against three VMware virtualized Exchange Mailbox Servers for two hours, configured with a very heavy Outlook Client profile with four storage groups, each with 25 mailboxes and a total of 3, mailboxes. Approximately one hour into the test, ESX NODE1 was ungracefully powered down via the remote access console. Test data standard for LoadGen was collected and saved, along with VMware esxtop performance data, and Navisphere Analyzer data. Result Upon simulated failure, the FT secondary Exchange Server continued running without Exchange services going offline, Exchange databases dismounting, or LoadGen clients disconnecting. LoadGen results show a slight rise in latencies. ESX performance charts ESX performance charts show upon enabling of the VMware FT feature on the EXCH1 Mailbox Server, the local ESX Server showed a very slight difference in activity over the configuration without FT. It is important to note in the following ESX charts that the physical CPU % Idle Time, the drop in idle time in these charts, was investigated and no corresponding event within ESX event/alerts or Microsoft Event logs reported a cause for the increase in processor utilization. The drops were not due to the FT feature as the same drops were seen with and without FT enabled. 1 \\F4ESX4.f4e2k7.local\Console Physical Cpu\% Idle Time :7:35 AM 5:9:35 AM 5:11:35 AM 5:13:36 AM 5:15:36 AM 5:17:36 AM 5:19:36 AM 5:21:36 AM 5:23:36 AM 5:25:37 AM 5:27:37 AM 5:29:37 AM 5:31:37 AM 5:33:37 AM 5:35:37 AM 5:37:38 AM 5:39:38 AM 5:41:38 AM 5:43:38 AM 5:45:38 AM 5:47:38 AM 5:49:39 AM 5:51:39 AM 5:53:39 AM 5:55:39 AM 5:57:39 AM 5:59:39 AM 6:1:4 AM 6:3:4 AM 6:5:4 AM 6:7:4 AM 6:9:41 AM 6:11:41 AM 6:13:41 AM 6:15:41 AM 6:17:41 AM 6:19:41 AM 6:21:42 AM 6:23:42 AM 6:25:42 AM 6:27:42 AM 6:29:42 AM 6:31:42 AM 6:33:43 AM 6:35:43 AM 6:37:43 AM 6:39:43 AM 6:41:43 AM 6:43:43 AM 6:45:44 AM 6:47:44 AM 6:49:44 AM 6:51:44 AM 6:53:44 AM 6:55:44 AM 6:57:44 AM 6:59:45 AM 7:1:45 AM 7:3:45 AM 7:5:45 AM 7:7:45 AM 7:9:45 AM 7:11:46 AM 7:13:46 AM Applied Technology 27

28 1 \\F4ESX5.f4e2k7.local\Console Physical Cpu\% Idle Time PerfMon data shows the virtual Exchange Server did not exceed the recommended thresholds. PerfMon performance chart The PerfMon data that follows illustrates the RPC latencies seen by the Exchange servers. Exchange Server 27 has an initial startup spike, which the storage group cache builds. This occurs on all Exchange servers. During the failover, a small spike in RPC Averaged Latency was seen but at no time did RPC Requests go into a critical threshold above 75. On the contrary, RPC Requests during the failover period remained constant throughout the test. Additionally, Client: Latency >2 sec RPCs, Client: Latency >5 sec RPCs, and Client: Latency >1 sec RPCs remained at zero. Only the servers that were failing over showed any latency increases. The failover process did not appear to affect the machines already homed on the ESX host. Applied Technology 28

29 The following PerfMon chart shows the total for the entire duration of the test. Conclusion Test 9 The VMware FT feature, with Microsoft Exchange 27 SP1 as a virtualized guest, worked as expected. When the ESX node homed the primary guest Exchange VM, the failover went virtually unnoticed by Exchange, Windows and, most importantly, the clients. Applied Technology 29

30 Hypothesis Test 11 Testing VMware vsphere 4. connected through iscsi to a CLARiiON CX4-12 array with four servers utilizing Building Block 4, 4, mailboxes, and running a simulated load via Microsoft LoadGen, will not cause guest processor utilization to exceed the recommended thresholds for the Microsoft Exchange Server, ESX Server, CLARiiON array, or LUNs. Test description Microsoft LoadGen was run against four VMware virtualized Exchange Mailbox Servers for two hours, configured with a very heavy Outlook Client profile with four storage groups, each with 25 mailboxes and a total of 4, mailboxes. Test data standard for LoadGen was collected and saved, along with VMware esxtop performance data, and Navisphere Analyzer data. Result Esxtop data shows that the virtual guest and host server ran throughout the test without exceeding the recommended thresholds. ESX performance charts for Node 1 and Node 2 The following charts illustrate ESX performance with all four virtual servers running without FT. It is important to note in the following ESX charts that the physical CPU % Idle Time, the drop in idle time in these charts, was investigated and no corresponding event within ESX event/alerts or Microsoft Event logs reported a cause for the increase in processor utilization. The drops were not due to the FT feature as the same drops were seen with and without FT enabled. 1 \\F4ESX4.f4e2k7.local\Console Physical Cpu\% Idle Time :39:46 PM 12:41:46 PM 12:43:46 PM 12:45:46 PM 12:47:46 PM 12:49:46 PM 12:51:47 PM 12:53:47 PM 12:55:47 PM 12:57:47 PM 12:59:47 PM 1:1:47 PM 1:3:48 PM 1:5:48 PM 1:7:48 PM 1:9:48 PM 1:11:48 PM 1:13:48 PM 1:15:49 PM 1:17:49 PM 1:19:49 PM 1:21:49 PM 1:23:49 PM 1:25:49 PM 1:27:5 PM 1:29:5 PM 1:31:5 PM 1:33:5 PM 1:35:5 PM 1:37:5 PM 1:39:51 PM 1:41:51 PM 1:43:51 PM 1:45:51 PM 1:47:51 PM 1:49:51 PM 1:51:52 PM 1:53:52 PM 1:55:52 PM 1:57:52 PM 1:59:52 PM 2:1:52 PM 2:3:53 PM 2:5:53 PM 2:7:53 PM 2:9:53 PM 2:11:53 PM 2:13:53 PM 2:15:54 PM 2:17:54 PM 2:19:54 PM 2:21:54 PM 2:23:54 PM 2:25:54 PM 2:27:55 PM 2:29:55 PM 2:31:55 PM 2:33:55 PM 2:35:55 PM 2:37:55 PM 2:39:55 PM 2:41:56 PM 2:43:56 PM 2:45:56 PM 2:47:56 PM 2:49:56 PM 2:51:56 PM 2:53:57 PM Applied Technology 3

31 1 \\F4ESX5.f4e2k7.local\Console Physical Cpu\% Idle Time :39:45 PM 12:41:45 PM 12:43:45 PM 12:45:46 PM 12:47:46 PM 12:49:46 PM 12:51:46 PM 12:53:46 PM 12:55:46 PM 12:57:46 PM 12:59:47 PM 1:1:47 PM 1:3:47 PM 1:5:47 PM 1:7:47 PM 1:9:47 PM 1:11:48 PM 1:13:48 PM 1:15:48 PM 1:17:48 PM 1:19:48 PM 1:21:48 PM 1:23:49 PM 1:25:49 PM 1:27:49 PM 1:29:49 PM 1:31:49 PM 1:33:49 PM 1:35:5 PM 1:37:5 PM 1:39:5 PM 1:41:5 PM 1:43:5 PM 1:45:5 PM 1:47:51 PM 1:49:51 PM 1:51:51 PM 1:53:51 PM 1:55:51 PM 1:57:51 PM 1:59:52 PM 2:1:52 PM 2:3:52 PM 2:5:52 PM 2:7:52 PM 2:9:52 PM 2:11:53 PM 2:13:53 PM 2:15:53 PM 2:17:53 PM 2:19:53 PM 2:21:53 PM 2:23:54 PM 2:25:54 PM 2:27:54 PM 2:29:54 PM 2:31:54 PM 2:33:54 PM 2:35:55 PM 2:37:55 PM 2:39:55 PM 2:41:55 PM 2:43:55 PM 2:45:55 PM 2:47:56 PM 2:49:56 PM 2:51:56 PM 2:53:56 PM Navisphere performance chart In the following test, it can be seen that the increased number of servers and I/O had a direct affect on SP utilization. The SP queue full count remained at zero, displaying no array iscsi issues. Applied Technology 31

32 PerfMon performance chart The baseline performance of the four servers during this test showed the processors were all within the same region of 5 percent idle/used, with RPC Requests remaining at or below five, and RPC Averaged Latency below ten. The following PerfMon charts show the total for the entire duration of the test with factored-out Exchange startup. Applied Technology 32

33 Conclusion Test 11 VMware vsphere 4. connected via iscsi to a CLARiiON CX4-12 with one virtualized Exchange Mailbox Server with 4, mailboxes resulted in expected I/O ranges and latencies for the solution outlined. Applied Technology 33

34 Hypothesis Test 12 VMware FT will fail over to the secondary virtual guest. All Microsoft Exchange services will remain online, all Exchange databases will remain online, and clients will remain connected during the failover. Test description Microsoft LoadGen was run against four VMware virtualized Exchange Mailbox Servers for two hours, configured with a very heavy Outlook Client profile with four storage groups, each with 25 mailboxes and a total of 4, mailboxes. Approximately one hour into the test, ESX NODE1 was powered down ungracefully via the remote access console. Test data standard for LoadGen was collected and saved, along with VMware esxtop performance data. Result Upon simulated failure, the FT secondary Exchange Server continued running without Exchange services going offline, Exchange databases dismounting, or LoadGen clients disconnecting. LoadGen results show a slight rise in latencies. ESX performance charts ESX performance charts show that upon enabling of the VMware FT feature on the EXCH1, EXCH2, EXCH3 and EXCH4 Mailbox Server, the local ESX Server showed a very slight difference in activity over the configuration without FT. It is important to note in the following ESX charts that the physical CPU % Idle Time, the drop in idle time in these charts, was investigated and no corresponding event within ESX event/alerts or Microsoft Event logs reported a cause for the increase in processor utilization. The drops were not due to the FT feature as the same drops were seen with and without FT enabled. 1 \\F4ESX4.f4e2k7.local\Console Physical Cpu\% Idle Time :7:29 PM 7:9:29 PM 7:11:29 PM 7:13:29 PM 7:15:29 PM 7:17:29 PM 7:19:3 PM 7:21:3 PM 7:23:3 PM 7:25:3 PM 7:27:3 PM 7:29:31 PM 7:31:31 PM 7:33:31 PM 7:35:31 PM 7:37:31 PM 7:39:31 PM 7:41:32 PM 7:43:32 PM 7:45:32 PM 7:47:32 PM 7:49:32 PM 7:51:32 PM 7:53:33 PM 7:55:33 PM 7:57:33 PM 7:59:33 PM 8:1:33 PM 8:3:33 PM 8:5:34 PM 8:7:34 PM 8:9:34 PM 8:11:34 PM 8:13:34 PM 8:15:35 PM 8:17:35 PM 8:19:35 PM 8:21:35 PM 8:23:35 PM 8:25:35 PM 8:27:36 PM 8:29:36 PM 8:31:36 PM 8:33:36 PM 8:35:36 PM 8:37:36 PM 8:39:37 PM 8:41:37 PM 8:43:37 PM 8:45:37 PM 8:47:37 PM 8:49:38 PM 8:51:38 PM 8:53:38 PM 8:55:38 PM 8:57:38 PM 8:59:38 PM 9:1:39 PM 9:3:39 PM 9:5:39 PM 9:7:39 PM 9:9:39 PM 9:11:4 PM Applied Technology 34

35 1 \\F4ESX5.f4e2k7.local\Console Physical Cpu\% Idle Time PerfMon data The following PerfMon data illustrates the RPC latencies seen by the Exchange servers. Exchange Server 27 has an initial startup spike, which the storage group cache builds. This occurs on all Exchange servers. During the failover, a small spike in RPC Averaged Latency was seen but at no time did RPC Requests go into a critical threshold above 75. On the contrary, RPC Requests during the failover period remained constant throughout the test. Additionally, Client: Latency >2 sec RPCs, Client: Latency >5 sec RPCs, and Client: Latency >1 sec RPCs remained at zero. Only the servers that were failing over showed any latency increases. The failover process did not appear to affect the machines already homed on the ESX host. Applied Technology 35

36 The following PerfMon chart shows the total for the entire duration of the test. Conclusion Test 12 The VMware FT feature, with Microsoft Exchange 27 SP1 as a virtualized guest, worked as expected. Client latencies increased during the failover period but users were unaffected and remained connected. All Exchange Services remained online and unaffected. Applied Technology 36

37 Hypothesis Building Block Testing Testing for connectivity to the CLARiiON CX4-12 array will perform scale-in performance as the number of virtualized guests increases, thus the number of mailboxes increases without dramatically affecting client latencies. Result As the number of guests increased, the ESX server performance scaled linearly, starting at 2,5 MHz and increasing up to approximately 1, MHz, with each test incrementing at 2,5 MHz showing a very good scaling capability. As load increased linearly, the server scaled linearly in CPU usage in MHz (Average) and CPU usage (Average). When FT was enabled, the CPU usage increased as expected but also increased at almost the same scale without FT. The following graph shows in green the increase in CPU usage and MHz average, starting at little over 2,5 MHz, and incrementing up to 1, MHz. The red line shows the scaling baseline testing, which also shows that as user count, servers, and load increased, the performance increased linearly. Applied Technology 37

38 LoadGen scaling results The following shows all baseline LoadGen scaling results for each rollup task in the ninety-fifth percentile latency. There is an increase in latencies as expected, increasing the number of mailbox servers. Baseline Tests TEST2 SG1 TEST5 SG1 TEST5 SG2 TEST8 SG1 TEST8 SG2 TEST8 SG3 TEST11 SG1 TEST11 SG2 TEST11 SG3 TEST11 SG4 Object: Exchange Load Generator User Groups usergroup usergroup usergroup4 UserGroup UserGroup2 UserGroup4 usergroup usergroup2 usergroup3 usergroup4 Loadgen 95th Percentile Latencies 4 Mailboxes Browse Calendar Action Latency (95th Percentile) Browse Contacts Action Latency (95th Percentile) Browse Public Folder Action Latency (95th Percentile) Browse Tasks Action Latency (95th Percentile) Create Contact Action Latency (95th Percentile) Create Folder Action Latency (95th Percentile) Create Task Action Latency (95th Percentile) Delete Mail Action Latency (95th Percentile) Download OAB Action Latency (95th Percentile) Edit Rules Action Latency (95th Percentile) Edit Smart Folders Action Latency (95th Percentile) Export Mail Action Latency (95th Percentile) Initialize Mailbox Action Latency (95th Percentile) Logoff Action Latency (95th Percentile) Logon Action Latency (95th Percentile) Make Appointment Action Latency (95th Percentile) Module Init Action Latency (95th Percentile) Module Term Action Latency (95th Percentile) Move Mail Action Latency (95th Percentile) Not Implemented Action Latency (95th Percentile) Post Free Busy Action Latency (95th Percentile) Public Folder Post Action Latency (95th Percentile) Read And Process Messages Action Latency (95th Percentile) Request Meeting Action Latency (95th Percentile) Search Action Latency (95th Percentile) Send Mail Action Latency (95th Percentile) Synchronize Folders Action Latency (95th Percentile) User Init Action Latency (95th Percentile) Applied Technology 38

39 Loadgen FT results LoadGen results with FT enabled for each building block increased, showing that as the number of FT Exchange Mailbox Servers were increased, the latencies also increased. Fault Tolerance Enabled Tests TEST3 SG1 TEST6 SG1 TEST6 SG2 TEST9 SG1 TEST9 SG2 TEST9 SG3 TEST12 SG1 TEST12 SG2 TEST12 SG3 TEST12 SG4 Object: Exchange Load Generator User Groups usergroup3 usergroup usergroup4 UserGroup UserGroup2 UserGroup4 usergroup usergroup2 usergroup3 usergroup4 Loadgen 95th Percentile Latencies 4 Mailboxes Browse Calendar Action Latency (95th Percentile) Browse Contacts Action Latency (95th Percentile) Browse Public Folder Action Latency (95th Percentile) Browse Tasks Action Latency (95th Percentile) Create Contact Action Latency (95th Percentile) Create Folder Action Latency (95th Percentile) Create Task Action Latency (95th Percentile) Delete Mail Action Latency (95th Percentile) Download OAB Action Latency (95th Percentile) Edit Rules Action Latency (95th Percentile) Edit Smart Folders Action Latency (95th Percentile) Export Mail Action Latency (95th Percentile) Initialize Mailbox Action Latency (95th Percentile) Logoff Action Latency (95th Percentile) Logon Action Latency (95th Percentile) Make Appointment Action Latency (95th Percentile) Module Init Action Latency (95th Percentile) Module Term Action Latency (95th Percentile) Move Mail Action Latency (95th Percentile) Not Implemented Action Latency (95th Percentile) Post Free Busy Action Latency (95th Percentile) Public Folder Post Action Latency (95th Percentile) Read And Process Messages Action Latency (95th Percentile) Request Meeting Action Latency (95th Percentile) Search Action Latency (95th Percentile) Send Mail Action Latency (95th Percentile) Synchronize Folders Action Latency (95th Percentile) User Init Action Latency (95th Percentile) User Term Action Latency (95th Percentile) Applied Technology 39

40 Conclusion VMware vsphere 4. with iscsi connectivity to a CLARiiON CX4-12, utilizing building blocks both with the storage design, virtualization guest design and FT feature, allows for a viable consolidated virtual Exchange and Active Directory deployment while showing the ability of VMware vsphere to quickly set up and configure FT with minimal impact. Additionally, it proves the capability of a VMware High Availability (VMHA) cluster to home both VMotion/VMHA and FT nodes at the same time, with VMware being able to determine which nodes are compliant for FT. It was observed as the number of guests enabled with FT increased, Exchange latencies as seen through LoadGen also increased. To reduce latencies it is recommended to use additional network adapters or iscsi HBAs when considering iscsi for array connectivity. VM processor utilization, host ESX processor utilization, and array utilization remain low, which would indicate a requirement for increasing the iscsi bandwidth. The CPU Average as displayed in the VMware vcenter Server console shows the effects of the tests and the CPU usage (Average) and CPU usage in MHz (Average) over the week of testing. The following graphs show the ESX server as load was added and FT was enabled in each test. What can be seen is that even with FT, the configuration does not exceed more than 5 percent of processor utilization. ESX FT NODE 1 ESX FT NODE2 Note: The chart range is only to 9,, not 2, as in node 1. Spikes appear to be larger when they are actually the same. Applied Technology 4

41 VMware vsphere 4. FT testing proved Microsoft Windows and, most importantly, Microsoft Exchange services remain online during and after a hardware failure. This is a clustered solution where services and service never go offline, which correlates to clients always having access to without dramatically affecting the Outlook user s experience. Typical clustering solutions result in a period of downtime. No matter how short the downtime, not one solution was zero until VMware vsphere 4. was zero. VMware FT has the ability to enable clustered Exchange having zero downtime. The scaling capabilities of VMware vsphere 4. showed that as Exchange servers were added, VMware ESX scaled to match the increase. VMware FT matched the scaling, the capabilities increasing linearly as servers and load increased. References For details on the proven testing of Building Blocks 2+2 design, visit: Applied Technology 41

42 Appendix This section provides details about the following: Enabling FT logging (EX2 example) LoadGen Reports/PerfMon data for LoadGen Master 95th Percentile Latencies Enabling FT logging (EX2 example) The ESX task events for enabling FT on EX2 Mailbox Server are as follows: Turn on FT task total time was under 1 seconds. Start FT secondary task completed in less than one minute. Applied Technology 42