IBM Storwize V ,000 mailbox resiliency Microsoft Exchange 2013 storage solution. IBM Systems and Technology Group ISV Enablement March 2014

Transcription

1 IBM Storwize V ,000 mailbox resiliency Microsoft Exchange 2013 storage solution IBM Systems and Technology Group ISV Enablement March 2014 Copyright IBM Corporation, 2014

2 Table of contents Abstract... 1 Disclaimer... 1 Features... 1 Solution description... 3 IBM Storwize V IBM Flex System... 4 IBM Flex System x240 Compute Node... 5 Solution overview and layout... 6 Targeted customer profile... 7 Test environment... 8 Simulated Exchange configuration... 8 Storage hardware... 8 Storage software... 9 Storage disk configuration (mailbox store and log disks) Best practices Storage mailbox resiliency Backup strategy Additional information Test result summary Reliability Storage performance results Database backup and recovery performance Database read-only performance Transaction log recovery / replay performance Conclusion Appendix - Test results Stress testing Performance testing Streaming backup testing Soft-recovery testing Resources Trademarks and special notices... 40

3 Abstract This paper describes a Microsoft Exchange Server 2013 high availability (HA) solution for 16,000 user mailboxes using the IBM Storwize V5000 as part of the Microsoft Exchange Solution Reviewed Program (ESRP). The ESRP was developed by Microsoft Corporation to provide a common testing framework for vendors to demonstrate their storage products performance characteristics when used with Microsoft Exchange Server. For more details about the storage-centric Microsoft ESRP, refer to the following website location: technet.microsoft.com/en-us/exchange/ff aspx This Microsoft Exchange Server solution primarily focuses on database and log storage performance for the stated mailbox count and profile. It does not take into account all of the unique variables and space requirements present in many production messaging environments. For supplemental Microsoft Exchange solution and sizing guidance, refer to the TechNet content at the following website location: blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange deployments.aspx For additional storage-related questions or comments regarding this solution, visit the following website location: ibm.com/systems/storage/disk Disclaimer This paper has been produced independently of Microsoft Corporation. Microsoft Corporation expressly disclaims responsibility for, and makes no warranty, express or implied, with respect to, the accuracy of the contents of this paper. Refer to IBM disclaimer at the end of the paper. Features The solution achieves Microsoft Exchange 2013 mailbox resiliency by employing a single database availability group (DAG) spread across two sites. Each site maintains different IBM Storwize V5000 controllers and spindles that contain HA database copies hosted by separate servers for redundancy and failover. Notably, the solution includes two IBM Storwize V5000 systems with a total of eight servers. The Microsoft Exchange Jetstress 2013 testing actually simulates the additional workload of the secondary site and thereby requires only half of the total hardware located at the primary site. This is achieved mostly by doubling the server workloads or active databases during the Microsoft Exchange Jetstress testing. Thus, the test bed consists of a single Storwize V5000 system and four servers or compute nodes. Figure 1 illustrates the general design of the Microsoft Exchange DAG architecture. There are three HA database copies with the active and passive databases being evenly distributed across all of the servers in the DAG, with eight active databases and sixteen passive databases per server. The database copies benefit from network-based replication using the native Exchange 2010 DAG log shipping engine. Each server has 2000 active mailboxes, allowing for database or entire server failovers. 1

4 Figure 1: Microsoft Exchange Server 2013 DAG layout 2

5 Solution description The primary objective of this paper is to reveal the storage performance behavior for 16,000 Exchange 2013 mailboxes on the IBM Storwize V5000 system. This particular solution uses two Storwize V5000 systems, each with three expansion enclosures for a total of 96 disks. Two separate controllers and corresponding disks are required to provide DAG redundancy and failover capability. Each Storwize V5000 system can scale out considerably by attaching up to six expansion enclosures per storage controller or by using additional external virtualized storage. IBM Storwize V5000 As illustrated in Figure 2, IBM Storwize V5000 is an entry-level, mid-range storage system with an innovative design and advanced features offered at a truly competitive price. Within the IBM storage portfolio, the Storwize V5000 system is positioned between the proven IBM Storwize V7000 and Storwize V3700 systems, offering customers a powerful yet affordable alternative that is very reliable, conveniently scalable, and provides dependable performance. Small- to mid-size businesses can take advantage of this cost-effective, efficient, and simple storage system with built-in virtualization, consolidation, and solid-state drive (SSD) tiering capabilities all through a user-friendly management interface for both new and existing storage arrays. Based on the well-established virtualization technology of the predecessor IBM System Storage SAN Volume Controller (SVC), numerous IBM and third-party external storage systems can be readily virtualized by the Storwize V5000 system, extending the flexibility and longevity of existing data center assets. Remarkably, Storwize V5000 makes integration with a diverse spectrum of storage arrays painless, providing a single, native, Web Based Enterprise Management (WBEM) interface for internal and external storage. Upon examining the system as a whole, individual storage enclosures house up to twelve 3.5-inch drives or twenty-four 2.5-inch drives. Control enclosures contain drives, redundant dual-active intelligent Redundant Array of Independent Disks (RAID) controllers and dual-power supplies, batteries, and cooling components. Expansion enclosures contain drives, power supplies, and cooling components. The modular design allows attachment of up to six expansion enclosures for each control enclosure, enabling the system to scale up to 168 drives. Other components and characteristics of the system include: Disk drives Serial-attached SCSI (SAS) disk drives, nearline SAS disk drives, and solidstate drives (SSDs). Intermix of these drive types within RAID controller and storage expansion enclosures add flexibility. Efficient 2U rack-mountable modular design. Support for standard RAID levels 0, 1, 5, 6, and 10. One-way data migration to simplify implementation. Designed for easy customer setup and support, with flexible warranty and extended support options IBM Subsystem Device Driver Device Specific Module (SDDDSM) path failover driver Storage Management Initiative Specification (SMI-S) provider for industry-standard storage management and monitoring solutions Cache memory 16 GB cache memory (8 GB per internal RAID controller) as a base feature designed to improve performance and availability. 3

6 Host connectivity 8 Gbps Fibre Channel (FC), 6 Gbps SAS, or 1 Gbps iscsi. Advanced features including: thin provisioning, IBM System Storage Easy Tier automated tiering, nondisruptive data migration, replication, and IBM FlashCopy. Virtualize existing external storage arrays, and manage all of it from a single interface. Take advantage of the advanced features of Storwize V5000 with existing storage systems. Figure 2: Front and rear view of the tested IBM Storwize 5000 storage system For further information about the IBM Storwize V5000 system, visit the following website location: ibm.com/systems/storage/disk/storwize_v5000 IBM Flex System As illustrated in Figure 3, IBM Flex System is the latest (at the time of publishing this paper) IBM blade chassis evolution to offer a new high performance, double-dense design that can support the equivalent of up to 28 nodes per enterprise chassis that substantially reduces its data center footprint by lowering power, cooling, and operational costs. Information technology (IT) administrators have the flexibility to choose preferred chassis integrated technology elements (ITEs) from a wide assortment of priceoptimized yet powerful compute, storage, management, and network hardware resources. Consequently, organizations can easily custom-build very scalable, physical, or virtual infrastructures for demanding business-critical applications such as Microsoft Exchange Server 2013 and the infrastructures can be comfortably managed using the optional IBM Flex System Manager ITE. IBM Flex System Manager is designed to optimize the physical and virtual resources of the IBM Flex System infrastructure while simplifying and automating repetitive tasks. It provides easy system setup procedures with wizards and built-in expertise, and consolidated monitoring for compute, storage, networking, virtualization, and energy resources. In essence, IBM Flex System Manager provides core management functionality along with automation that allows organizations to minimize administrative expenses and focus efforts on business innovation. 4

7 IBM Flex System Manager provides a single-user graphical user interface (GUI) that controls the following features: Simplified setup Complete management integration Improved resource utilization Intelligent automation Resource pooling Figure 3: Front and rear view of the IBM Flex System Enterprise Chassis For further information about the IBM Flex System, visit the following website location: ibm.com/systems/pureflex/flex-converged-infrastructure.html IBM Flex System x240 Compute Node As one of the optional elements of the Flex System chassis, the IBM Flex System x240 Compute Node provides outstanding performance for popular business-critical applications. Its highly scalable and energy-efficient design supports up to 16 processor cores and 768 GB of memory capacity in a package that is easy to service and manage. Moreover, with outstanding computing power per watt and the latest Intel Xeon processors, data centers can reduce costs without sacrificing infrastructure speed and availability. Basically, to meet today s complex and ever-changing business demands, the x240 compute node as illustrated in Figure 4, provides the following highlights and comes equipped with numerous notable features that decidedly power a wide variety of workloads, including Microsoft Exchange Server. Optimized for virtualization, performance, and highly scalable networking Embedded IBM Virtual Fabric allows I/O flexibility Designed for simplified deployment and management Intel Xeon processor E v2 product family 24 DDR3 / DDR3L LP, 768 GB maximum with 32 GB LRDIMM Automated power management with onboard sensors 5

8 Two 2.5-inch hot-swap disk slots Integrated system management Integrated RAID-0, -1 or optional ServeRAID M5115 (RAID-0, -1, -5, -6, -10, -50) Optional hypervisor Two Mezzanine Cards (x16 + x8 PCI Express 3.0) Dual integrated 10 GbE Figure 4: Front view of the IBM Flex System x240 Compute Node For further information about the IBM Flex System x240 Compute Node, visit the following website location: ibm.com/systems/flex/compute-node/x86/bto/x240/ Solution overview and layout While consisting of the latest IBM Flex System technologies, this solution focuses on the performance of the IBM Storwize V5000 internal disks. The system is based on the well-established virtualization technology of IBM SVC and the innovative Storwize V7000 architecture, running the same software and graphical management interface. The system uses RAID arrays called managed disks (MDisks) created from either the Storwize V5000 internal drives or external attached storage systems. The MDisk arrays are then placed in storage pools. The pools are where the virtualization takes place by creating extents to help define the volumes. Furthermore, data and workload isolation can be attained by placing MDisks in separate storage pools so that the individual pool volumes reside on different physical spindles. This allows Microsoft Exchange administrators the flexibility to use separate database and log pools based on workload I/O profiles while still providing different RAID-level protection. In this solution, because it takes advantage of Exchange 2013 DAGs, the database and log files can be placed on the same physical spindles, within the same storage pool. 6

9 The following table outlines the MDisk, storage pool, and volume layout used in this solution. Jetstress test virtualization layout Total internal MDisks 8 Total storage pools Virtual extent size 4 (one for each server) 1 GB (default) Physical disks per pool 16 MDisks per storage pool 2 (eight-disk RAID 5 arrays) Volumes 16 (4 per storage pool) Table 1: Test virtualization layout The Microsoft ESRP focuses on storage solution testing to address performance and reliability issues with storage design. However, storage is not the only factor to take into consideration when designing an Exchange vertical scaling solution. Other factors that affect the server scalability are: server processor utilization, server physical and virtual memory limitations, resource requirements for other applications, directory and network service latencies, network infrastructure limitations, replication and recovery requirements, and client usage profiles. All these factors are beyond the scope of the Microsoft ESRP. Therefore, the number of mailboxes hosted per server as part of the tested configuration might not necessarily be viable for some customer deployments. For more information on identifying and addressing performance issues in an Exchange system, refer to Troubleshooting Microsoft Exchange Server Performance, available at the following Microsoft website: go.microsoft.com/fwlink/?linkid=23454 Targeted customer profile The IBM Storwize V5000 system targets small- to mid-range customers, with the ability to scale out as their business grows. The targeted profile for this solution includes: Eight Microsoft Exchange Server 2013 compute nodes Two identical IBM Storwize V5000 systems 16,000 mailboxes 0.07 input/output operations per second (IOPS) per user mailbox (0.09 tested for growth) 1000 MB mailbox size Background database maintenance, enabled during all Jetstress tests DAG mailbox resiliency providing high availability and primary data protection 7

10 Test environment Table 2 summarizes the Jetstress testing environment: Simulated Exchange configuration Number of Exchange mailboxes simulated 16,000 Number of DAGs 1 Number of servers/dag 8 Number of active mailboxes/server 2000 Number of databases/host 16 Number of copies/database 3 Number of mailboxes/database 250 Simulated profile: I/O per second per mailbox (IOPS, include 20% headroom) Database logical unit number (LUN) size Log LUN size 0.07 (0.09 tested) 1.27 TB (4 DB per LUN) Logs on DB volumes Total database size for performance testing TB (244.1 GB x 64) Percentage of storage capacity used by the 75.7% Exchange database Table 2: Simulated Exchange configuration Storage hardware Storage connectivity (Fiber Channel, SAS, Serial Advanced Technology Attachment (SATA), iscsi) Storage model and OS / firmware revision Storage cache Fibre Channel IBM Storwize V5000 Version Microsoft Windows Server Catalog link: 16 GB (8 GB per controller canister) Number of storage controllers 2 Number of storage ports Maximum bandwidth of storage connectivity to host Switch type/model/firmware revision Eight 8 Gb FC ports, four 6 Gb SAS, four iscsi 16 Gb (two 8 Gb FC) IBM Flex System FC port 16Gb ESB SAN Scalable Switch, FW 7.0.0_pha4 Host bus adapter (HBA) model and IBM Flex System FC Port 16Gb FC Adapter, FW

11 firmware Number of HBAs/host Host server type Total number of disks tested in solution Maximum number of spindles that can be hosted in the storage 1 dual-port mezzanine card IBM Flex System x240, dual Intel Xeon E Ghz processors, 128 GB RAM (seven 24 disk enclosures) Table 3: Storage hardware Storage software HBA driver Brocade x64 FC driver for Windows Server 2012 HBA QueueTarget setting N/A HBA QueueDepth setting 100 Multipathing IBM SDDDSM v Load balanced, fault tolerant, multipath I/O (MPIO) Host OS Microsoft Windows Server 2012 standard ESE.dll file version Replication solution name/version N/A Table 4: Storage software 9

12 Storage disk configuration (mailbox store and log disks) Disk type, speed, and firmware revision Raw capacity per disk (GB) Number of physical disks in test 96 Total raw storage capacity (GB) Disk slice size (GB) Number of disks per LUN Raid level Total formatted capacity SAS, 10 k, firmware level J2E9 558 GB (600 GB) TB (before RAID) N/A Four virtual average (eight disks per MDisk) RAID 5, storage level TB Storage capacity utilization 38.82% Database capacity utilization 29.2% Table 5: Storage disk configuration Best practices Microsoft Exchange Server is a disk-intensive application. Based on the tests run using the ESRP framework, the test team recommends the following reference to improve the storage performance. For Exchange 2013 best practices on storage design, visit: technet.microsoft.com/en-us/library/ee832792%28v=exchg.150%29.aspx Storage mailbox resiliency Use the following guidelines to optimize the Exchange 2013 environment for IBM Storwize V Format the volumes at 64 KB allocation unit size, as recommended by Microsoft. 2. Even though Microsoft storage guidance for Exchange 2013 suggests a maximum of seven disks per array group, the IBM Storwize is performance optimized for eight disk array groups, as used in this solution. 3. Isolate the Exchange Server database and the log files from other disk-intensive application workloads to avoid performance conflicts. During testing, the storage subsystems were dedicated to Exchange Server. Sharing the storage with other applications might negatively impact Exchange I/O performance. 4. It is now optional with DAGs to isolate the Exchange database and log disk I/O on separate, physical disk arrays. Isolation allows separate log and database array tuning, such as RAID or disk types. With Storwize V5000, LUNs can be separated physically by using separate storage pools. This solution kept the database and logs on the same physical spindles in the same storage pool. 5. The Storwize V5000 system can use external virtualized storage, which are external storage systems connected to Storwize V5000, similar to SAN Volume Controller. This is an optional premium feature. In this configuration, do not assign different external storage controllers to the same storage pool. Each external controller must have its own storage pools. 10

13 6. For most Exchange 2013 environments, it is now recommended to use hardware level RAID 5 for databases and RAID 5 or 10 for the logs. RAID 5 for databases also provides better space utilization when using larger mailboxes (1 GB plus), provided there is an adequate number of spindles to meet the I/O requirements. 7. Enable caching on Storwize V5000 when creating the volumes. Note that the cache option is either read/write combined or none, and is enabled by default. 8. The recommended disk stripe size for Exchange 2013 is 256 KB (or larger). The default stripe size on Storwize V5000 is 256 KB, which was used for this testing. 9. Use single-initiator zoning when configuring the FC switch zones. Each server HBA port is zoned to two Storwize V5000 ports one port per controller. 10. Troubleshooting performance on Storwize V5000 can be performed using its native monitoring features, storage area networking (SAN) switch or HBA monitoring features, and popular tools such as Microsoft Windows Performance Monitor. These tools can help determine the location where the heaviest disk I/O reads and writes are occurring, and the data transfer rates. Assuming all storage components are functioning and configured correctly, most Exchange Server 2013 storage latency issues are caused by an insufficient number of disks for the I/O load. 11. The number of IOPS hitting a given drive can be measured using the Performance Monitor Logical Disk object and Disk Transfers/sec counter. Add the data from all database volumes to find the total IOPS being generated. 12. The average disk latency should be less than 20 milliseconds (ms), with the maximum value no higher than 100 ms. Disk latency can be measured using the Performance Monitor Logical Disk object, Avg Disk sec/read. Backup strategy The solution does not include a backup strategy. Additional information It is recommended to visit the following URL for additional information and support resources: ibm.com/systems/storage/disk Test result summary This section provides a high-level summary of the test data from ESRP and links to the detailed HTML reports that are generated by the ESRP testing framework. The cross reference links can be clicked in the following section to view the HTML report for each test category. Reliability To get a better picture of reliability and to tax the storage system, a number of tests in the framework are required to run for 24 hours. This verifies the storage can handle high I/O load for a longer period of time. Both log and database files are analyzed for integrity after the shorter performance or longer stress tests to ensure no database or log corruption. 11

14 The following list provides an overview. (Click the underlined words to view the HTML report after the reliability tests run). There were no errors reported in the saved event log file. There were no errors reported during the database and log checksum process. Storage performance results The primary storage performance testing is designed to exercise the storage with maximum sustainable Exchange type of I/O for 2 hours. The test is to show how long it takes for the storage to respond to an I/O under load. The following data is the sum of all of the logical disk I/O and average of all the logical disks I/O latency in the two-hour test. Each server is listed separately and the aggregate numbers across all servers are listed. Individual server metrics: This section includes the sum of I/O and the average latency across all the databases on a per server basis. Server 1 (cn02) Database I/O Database disks transfers/sec 606 Database disks reads/sec 433 Database disks writes/sec 173 Average database disk read latency (ms) 6.54 Average database disk write latency (ms) 1.26 Transaction log I/O Log disks writes/sec Average log disk write latency (ms) 0.42 Server 2 (cn03) Database I/O Database disks transfers/sec 606 Database disks reads/sec 433 Database disks writes/sec 173 Average database disk read latency (ms) 6.53 Average database disk write latency (ms) 1.26 Transaction log I/O Log disks writes/sec Average log disk write latency (ms)

15 Server 3 (cn04) Database I/O Database disks transfers/sec 606 Database disks reads/sec 433 Database disks writes/sec 173 Average database disk read latency (ms) 6.54 Average database disk write latency (ms) 1.23 Transaction log I/O Log disks writes/sec Average log disk write latency (ms) 0.42 Server 4 (cn05) Database I/O Database disks transfers/sec 604 Database disks reads/sec 432 Database disks writes/sec 172 Average database disk read latency (ms) 6.55 Average database disk write latency (ms) 1.23 Transaction log I/O Log disks writes/sec Average log disk write latency (ms) 0.42 Aggregate performance across all servers: This section includes the sum of I/O and the average latency across all servers in the solution. Database I/O Database disks transfers/sec 2422 Database disks reads/sec 1731 Database disks writes/sec 691 Average database disk read latency (ms) 6.54 Average database disk write latency (ms) 1.25 Transaction log I/O Log disks writes/sec Average log disk write latency (ms)

16 Database backup and recovery performance There are two test reports in this section. The first one is to measure the sequential read rate of the database files and the second is to measure the recovery or replay performance (playing transaction logs into the database). Database read-only performance This test is to measure the maximum rate at which databases can be backed up using Volume Shadow Copy Service (VSS). The following table shows the average rate for a single database file. MB read/sec per database MB read/sec total per server Transaction log recovery / replay performance This test is to measure the maximum rate at which the log files can be played against the databases. The following table shows the average rate for 507 log files played in a single database. Each log file is 1 MB in size. Average time to play one log file (sec) 2.65 Conclusion The IBM Storwize V5000 storage system easily meets business-critical requirements for 16,000 Microsoft Exchange Server 2013 mailbox users. The Microsoft Exchange Jetstress 2013 performance and stress test results plainly exceed the target IOPS and keep well within the Microsoft Exchange latency requirements. With further IBM Storwize V5000 storage scalability and flexibility, there is ample headroom for more demanding and rapidly growing Microsoft Exchange organizations. Also part of the IBM SVC code family, many advanced storage features are available and easily managed all within one of the industry s most user-friendly web-based interfaces. This paper is developed by storage solution providers, and reviewed by the Microsoft Exchange Product team. The test results and data presented in this paper are based on the tests introduced in the ESRP test framework version 4.0. Customers cannot quote the data directly for their predeployment verification. It is still necessary to go through the exercises to validate the storage design for any specific customer environment. The ESRP program is not designed to be a benchmarking program; tests are not designed for getting the maximum throughput from a given solution. Rather, it is focused on producing recommendations from vendors for the Exchange application. So the data presented in this paper must not be used for direct comparisons among the solutions. 14

17 Appendix - Test results This section includes Microsoft Exchange Jetstress 2013 summary reports for stress, performance, streaming backup and soft recovery tests. All of the server test results were reviewed by Microsoft, and experienced similar performance. Since the test results for all hosts were similar, only one is provided below. Stress testing Microsoft Exchange Jetstress 2013 Stress test result report Test summary Overall Test Result Pass Machine Name CN02 Test Description 4000 user mbx, 1000 MB mbx size,.09 IOPS mbx, 6 threads Test Start Time 2/17/2014 1:21:01 PM Test End Time 2/18/2014 1:43:28 PM Collection Start Time 2/17/2014 1:34:00 PM Collection End Time 2/18/2014 1:34:00 PM Jetstress Version ESE Version Operating System Windows Server 2012 Standard Evaluation ( ) Performance Log C:\Program Files\Exchange Jetstress\Stress_2014_2_17_13_22_14.blg Database sizing and throughput Achieved Transactional I/O per Second Target Transactional I/O per Second 360 Initial Database Size (bytes) Final Database Size (bytes) Database Files (Count) 16 Jetstress system parameters Thread Count 6 Minimum Database Cache MB Maximum Database Cache MB Insert Operations 40% Delete Operations 20% Replace Operations 5% Read Operations 35% Lazy Commits 70% Run Background Database Maintenance True Number of Copies per Database 3 15

18 Database configuration Log path: W:\1 Database: W:\1\Jetstress edb Log path: W:\2 Database: W:\2\Jetstress edb Log path: W:\3 Database: W:\3\Jetstress edb Log path: W:\4 Database: W:\4\Jetstress edb Log path: X:\5 Database: X:\5\Jetstress edb Log path: X:\6 Database: X:\6\Jetstress edb Log path: X:\7 Database: X:\7\Jetstress edb Log path: X:\8 Database: X:\8\Jetstress edb Log path: Y:\9 Database: Y:\9\Jetstress edb Log path: Y:\10 Database: Y:\10\Jetstress edb Log path: Y:\11 Database: Y:\11\Jetstress edb Log path: Y:\12 Database: Y:\12\Jetstress edb Log path: Z:\13 Database: Z:\13\Jetstress edb Log path: Z:\14 Database: Z:\14\Jetstress edb Log path: Z:\15 Database: Z:\15\Jetstress edb Log path: Z:\16 Database: Z:\16\Jetstress edb 16

19 MSExchange Database ==> s I/O Database Reads Average Latency (msec) I/O Database Writes Average Latency (msec) I/O Database Reads/sec I/O Database Writes/sec I/O Database Reads Average Bytes I/O Database Writes Average Bytes I/O Log Reads Average Latency (msec) I/O Log Writes Average Latency (msec) I/O Log Reads/sec I/O Log Writes/sec I/O Log Reads Average Bytes I/O Log Writes Average Bytes Transactional I/O performance

20 Background database maintenance I/O performance MSExchange Database ==> s Database Maintenance IO Reads/sec Database Maintenance IO Reads Average Bytes Log replication I/O performance MSExchange Database ==> s I/O Log Reads/sec I/O Log Reads Average Bytes

21 MSExchange Database ==> s I/O Database Reads Average Latency (msec) I/O Database Writes Average Latency (msec) I/O Database Reads/sec I/O Database Writes/sec I/O Database Reads Average Bytes I/O Database Writes Average Bytes I/O Log Reads Average Latency (msec) I/O Log Writes Average Latency (msec) I/O Log Reads/sec I/O Log Writes/sec I/O Log Reads Average Bytes I/O Log Writes Average Bytes Total I/O performance

22 Host system performance Counter Average Minimum Maximum % Processor Time Available MBytes Free System Page Table Entries Transition Pages RePurposed/sec Pool Nonpaged Bytes Pool Paged Bytes Database Page Fault Stalls/sec Test Log 2/17/2014 1:21:01 PM -- Preparing for testing... 2/17/2014 1:21:56 PM -- Attaching databases... 2/17/2014 1:21:56 PM -- Preparations for testing are complete. 2/17/2014 1:21:56 PM -- Starting transaction dispatch.. 2/17/2014 1:21:56 PM -- Database cache settings: (minimum: MB, maximum: 4.0 GB) 2/17/2014 1:21:56 PM -- Database flush thresholds: (start: 40.9 MB, stop: 81.9 MB) 2/17/2014 1:22:14 PM -- Database read latency thresholds: (average: 20 msec/read, maximum: 200 msec/read). 2/17/2014 1:22:14 PM -- Log write latency thresholds: (average: 10 msec/write, maximum: 200 msec/write). 2/17/2014 1:22:16 PM -- Operation mix: Sessions 6, Inserts 40%, Deletes 20%, Replaces 5%, Reads 35%, Lazy Commits 70%. 2/17/2014 1:22:16 PM -- Performance logging started (interval: ms). 2/17/2014 1:22:16 PM -- Attaining prerequisites: 2/17/2014 1:34:00 PM -- \MSExchange Database(JetstressWin)\Database Cache Size, Last: (lower bound: , upper bound: none) 2/18/2014 1:34:00 PM -- Performance logging has ended. 2/18/2014 1:43:00 PM -- JetInterop batch transaction stats: 74557, 74557, 74557, 74557, 74557, 74557, 74557, 74557, 74557, 74557, 74557, 74557, 74556, 74556, and /18/2014 1:43:00 PM -- Dispatching transactions ends. 2/18/2014 1:43:00 PM -- Shutting down databases... 2/18/2014 1:43:28 PM (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete) and (complete) 2/18/2014 1:43:28 PM -- C:\Program Files\Exchange Jetstress\Stress_2014_2_17_13_22_14.blg has 5775 samples. 2/18/2014 1:43:29 PM -- Creating test report... 2/18/2014 1:44:51 PM has 7.1 for I/O Database Reads Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:51 PM has 6.8 for I/O Database Reads Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:51 PM has 6.6 for I/O Database Reads Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:51 PM has 6.5 for I/O Database Reads Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:51 PM has 6.4 for I/O Database Reads Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:51 PM has 6.3 for I/O Database Reads Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Reads Average Latency. 20

23 2/18/2014 1:44:51 PM has 6.2 for I/O Database Reads Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:51 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM has 6.2 for I/O Database Reads Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM has 6.3 for I/O Database Reads Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM has 6.3 for I/O Database Reads Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM has 6.3 for I/O Database Reads Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM has 6.3 for I/O Database Reads Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM has 6.6 for I/O Database Reads Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM has 6.7 for I/O Database Reads Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM has 6.9 for I/O Database Reads Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM has 7.1 for I/O Database Reads Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 1:44:52 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 1:44:52 PM -- Test has 0 Maximum Database Page Fault Stalls/sec. 2/18/2014 1:44:52 PM -- The test has 0 Database Page Fault Stalls/sec samples higher than 0. 2/18/2014 1:44:52 PM -- C:\Program Files\Exchange Jetstress\Stress_2014_2_17_13_22_14.xml has 5728 samples queried. Performance testing Microsoft Exchange Jetstress 2013 Performance test result report Test summary Overall Test Result Pass Machine Name CN02 Test Description 4000 user mbx, 1000 MB mbx size,.09 IOPS mbx, 6 threads Test Start Time 2/18/2014 3:16:32 PM Test End Time 2/18/2014 6:14:50 PM Collection Start Time 2/18/2014 3:28:47 PM Collection End Time 2/18/2014 5:28:37 PM Jetstress Version ESE Version Operating System Windows Server 2012 Standard Evaluation ( ) Performance Log C:\Program Files\Exchange Jetstress\Performance_2014_2_18_15_17_6.blg 21

24 Database sizing and throughput Achieved Transactional I/O per Second Target Transactional I/O per Second 360 Initial Database Size (bytes) Final Database Size (bytes) Database Files (Count) 16 Jetstress system parameters Thread Count 6 Minimum Database Cache MB Maximum Database Cache MB Insert Operations 40% Delete Operations 20% Replace Operations 5% Read Operations 35% Lazy Commits 70% Run Background Database Maintenance True Number of Copies per Database 3 22

25 Database configuration Log path: W:\1 Database: W:\1\Jetstress edb Log path: W:\2 Database: W:\2\Jetstress edb Log path: W:\3 Database: W:\3\Jetstress edb Log path: W:\4 Database: W:\4\Jetstress edb Log path: X:\5 Database: X:\5\Jetstress edb Log path: X:\6 Database: X:\6\Jetstress edb Log path: X:\7 Database: X:\7\Jetstress edb Log path: X:\8 Database: X:\8\Jetstress edb Log path: Y:\9 Database: Y:\9\Jetstress edb Log path: Y:\10 Database: Y:\10\Jetstress edb Log path: Y:\11 Database: Y:\11\Jetstress edb Log path: Y:\12 Database: Y:\12\Jetstress edb Log path: Z:\13 Database: Z:\13\Jetstress edb Log path: Z:\14 Database: Z:\14\Jetstress edb Log path: Z:\15 Database: Z:\15\Jetstress edb Log path: Z:\16 Database: Z:\16\Jetstress edb 23

26 MSExchange Database ==> s I/O Database Reads Average Latency (msec) I/O Database Writes Average Latency (msec) I/O Database Reads/sec I/O Database Writes/sec I/O Database Reads Average Bytes I/O Database Writes Average Bytes I/O Log Reads Average Latency (msec) I/O Log Writes Average Latency (msec) I/O Log Reads/sec I/O Log Writes/sec I/O Log Reads Average Bytes I/O Log Writes Average Bytes Transactional I/O performance

27 Background database maintenance I/O performance MSExchange Database ==> s Database Maintenance IO Reads/sec Database Maintenance IO Reads Average Bytes Log replication I/O performance MSExchange Database ==> I/O Log Reads Average I/O Log Reads/sec s Bytes

28 MSExchange Database ==> s I/O Database Reads Average Latency (msec) I/O Database Writes Average Latency (msec) I/O Database Reads/sec I/O Database Writes/sec I/O Database Reads Average Bytes I/O Database Writes Average Bytes I/O Log Reads Average Latency (msec) I/O Log Writes Average Latency (msec) I/O Log Reads/sec I/O Log Writes/sec I/O Log Reads Average Bytes I/O Log Writes Average Bytes Total I/O performance

29 Host system performance Counter Average Minimum Maximum % Processor Time Available MBytes Free System Page Table Entries Transition Pages RePurposed/sec Pool Nonpaged Bytes Pool Paged Bytes Database Page Fault Stalls/sec Test Log 2/18/2014 3:16:32 PM -- Preparing for testing... 2/18/2014 3:16:49 PM -- Attaching databases... 2/18/2014 3:16:49 PM -- Preparations for testing are complete. 2/18/2014 3:16:49 PM -- Starting transaction dispatch.. 2/18/2014 3:16:49 PM -- Database cache settings: (minimum: MB, maximum: 4.0 GB) 2/18/2014 3:16:49 PM -- Database flush thresholds: (start: 40.9 MB, stop: 81.9 MB) 2/18/2014 3:17:06 PM -- Database read latency thresholds: (average: 20 msec/read, maximum: 100 msec/read). 2/18/2014 3:17:06 PM -- Log write latency thresholds: (average: 10 msec/write, maximum: 100 msec/write). 2/18/2014 3:17:08 PM -- Operation mix: Sessions 6, Inserts 40%, Deletes 20%, Replaces 5%, Reads 35%, Lazy Commits 70%. 2/18/2014 3:17:08 PM -- Performance logging started (interval: ms). 2/18/2014 3:17:08 PM -- Attaining prerequisites: 2/18/2014 3:28:47 PM -- \MSExchange Database(JetstressWin)\Database Cache Size, Last: (lower bound: , upper bound: none) 2/18/2014 5:28:48 PM -- Performance logging has ended. 2/18/2014 6:14:21 PM -- JetInterop batch transaction stats: 8961, 8960, 8960, 8960, 8960, 8960, 8960, 8960, 8960, 8960, 8960, 8960, 8960, 8960, 8960 and /18/2014 6:14:21 PM -- Dispatching transactions ends. 2/18/2014 6:14:21 PM -- Shutting down databases... 2/18/2014 6:14:50 PM (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete), (complete) and (complete) 2/18/2014 6:14:50 PM -- C:\Program Files\Exchange Jetstress\Performance_2014_2_18_15_17_6.blg has 523 samples. 2/18/2014 6:14:50 PM -- Creating test report... 2/18/2014 6:14:59 PM has 7.0 for I/O Database Reads Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 6:14:59 PM has 6.8 for I/O Database Reads Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 6:14:59 PM has 6.6 for I/O Database Reads Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 6:14:59 PM has 6.5 for I/O Database Reads Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 6:14:59 PM has 6.3 for I/O Database Reads Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Writes Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Reads Average Latency. 2/18/2014 6:14:59 PM has 6.3 for I/O Database Reads Average Latency. 2/18/2014 6:14:59 PM has 0.4 for I/O Log Writes Average Latency. 27