• Article

Planning for Jetstress 2010

 

Applies to: Exchange Server 2010 SP1, Exchange Server 2010

Topic Last Modified: 2012-07-23

You can use Jetstress to measure the performance capabilities of a disk subsystem for Microsoft Exchange database and log files. When you design a performance test, you should consider the following factors

  • Multiple databases   To adequately measure disk performance, you must run Jetstress simultaneously on logical drives used for Exchange databases or Exchange database logs. For example, if the production Exchange server will have four database logical drives and four log logical drives, Jetstress should be configured with four databases (where database files and log files are placed on the corresponding logical drives).

  • Multiple servers and SAN   Storage area network (SAN) technology enables multiple servers to use the same storage hardware. To obtain an accurate measurement of the storage performance, you must run Jetstress on all servers attached to the same physical storage devices. For example, if four Exchange servers are attached to the same SAN, you should run Jetstress on each server in tandem to measure the performance. Each server can be configured to run Jetstress differently depending on proposed load and user profile.

  • Importance of database size   It's important to create Jetstress databases that are matched appropriately to the expected database sizes in the production environment. Generally, the larger the Exchange database, the slower that the disks respond to read/write requests. In the disk subsystem throughput test scenario, Jetstress reserves 25 percent of the initial database file size for its future growth during a test run. For example, if you decide to size a database at 100 percent of the storage capacity of 100 gigabytes (GB), Jetstress creates initial databases of 80 GBs and reserves 25 percent of the 80 GBs for the database file growth.

    In the Exchange mailbox profile scenario, consider reserving some free disk drive space for database file growth. For example, if you choose 500 mailboxes with a mailbox size limit of 1,024 megabytes (MB), Jetstress creates an initial database of 500 GBs. You may have to reserve some free disk space for database file growth, depending on the length and intensity of the database transactions during a test run.

  • Users and profiles   The Exchange client usage profile is a primary factor in determining an appropriate disk subsystem for Exchange. If many client actions are performed every day, this can have a significant effect on the load generated for the disk subsystem. Larger average message sizes can also significantly affect the load.

    We recommend that you determine the mailbox profile before measuring the disk subsystem performance. If the mailbox profile is unknown, some general rules can be used to help size disk performance for the Exchange server deployment. For example, extensive mailbox profile analysis has shown trends about the number of random Exchange database I/O per second (IOPS) per mailbox during peak load. For more information about Exchange profile documentation, see Mailbox Server Storage Design.

    Note

    Average peak load is used in the examples to show the average database I/O during the peak hours of the day (for example, 8:00 A.M. to 10:00 A.M.). This is the random disk I/O load the database drives must be able to handle over a matter of hours. Don't confuse average peak load with disk I/O spikes. Also, the IOPS value used for Jetstress testing must be increased by 20 percent to allow for spikes. For example, if measured IOPS per user is 1, use 1.2 in the Jetstress test configuration.

  • Exchange and data replication   Jetstress can be configured to simulate Microsoft Exchange Server 2010 mailbox resiliency features by changing the number of copies and databases. Jetstress can also be used to validate storage-based replication solutions. For storage-based replication solution Jetstress tests, be sure to configure the storage replication (including simulated latency based on replication distance) prior to running the Jetstress performance tests. For more information, see Microsoft Knowledge Base article 895847, Multi-site data replication support for Exchange Server.

Jetstress Test Work Flow

The purpose of the Jetstress test process is to find the maximum workload that Exchange can support while still passing the test. Fundamentally, you need to increase workload until the test fails. The last value before failure is the highest workload that the system can support. If this value is below the design target, you can adjust the value of the SluggishSessions parameter to fine-tune the test.

Jetstress test work flow

Jetstress Test Flowchart

Prerequisites to Running Jetstress

Before you run Jetstress 2010, your environment must meet the following prerequisites. In addition, you must configure the disk or storage subsystem to be used with Exchange in a production environment.

  • If you're running the Windows Server 2008 R2 or Windows Server 2008 operating system, verify that all devices on the storage system must be listed on the Windows Hardware Compatibility List (HCL). For more information, see the Storage page of the Windows Server Catalog.

  • If multiple clusters will be sharing any aspect of the disk subsystem, verify that the server and storage configuration are Cluster/Multi-Cluster Certified. For more information, see the Storage page of the Windows Server Catalog.

  • Verify with vendors that drivers and firmware are current. Drivers and firmware include, but aren't limited to, the following items:

    • Server BIOS or firmware

    • SCSI array controller firmware and driver

    • Fibre Channel host bus adapter firmware and driver

    • Fibre Channel switch and hub firmware

    • SAN enclosure operating system, microcode, and firmware

    • Hard disk firmware

  • Verify that the host bus adapter or SAN-specific configuration is set correctly. Many host bus adapters use registry keys to customize the configuration to a specific SAN platform (for example, queue depth).

  • Configure the storage LUNs. (Consider Exchange log devices and database devices.)

  • Format the LUNs within Windows with the NTFS file system. A best practice is a 64 kilobyte (KB) allocation unit size.

Common Planning Questions

This section provides answers to common Jetstress planning questions that you may have while designing your test.

When Should I Run Jetstress in My Project?

Jetstress testing can take place at multiple phases within the project plan. Depending on the design approach taken, Jetstress testing may be performed during both the planning (design) and build phases of a project.

Where Should I Run Jetstress in My Infrastructure?

To ensure that the Jetstress test is representative of production, we recommend that you run Jetstress on every set of disks that will hold mailbox database copy data (active, passive, or lagged). The test should be run on all servers and disks simultaneously.

Warning

Don't run Jetstress on production servers that have Exchange installed. This may lead to problems with Exchange performance counters. We recommend that you run Jetstress before installing Exchange into production. If you've already installed and configured Jetstress on your production Exchange 2010 servers, see How to unload/reload performance counters on Exchange 2010 for more information about resolving Exchange performance counter problems.

Each database copy requires about 60 percent of the active copy I/O to remain up to date. Additionally, the storage hosting the passive copy must be designed to provide sufficient I/O to support the copy if it's to become active. By testing each database logical unit number (LUN) in parallel, you're validating that the storage solution can meet the design requirements. You're also validating that any of your shared infrastructure can meet the demand of the entire scenario, rather than simply testing each server individually.

How Much Time Should I Allocate for Jetstress Testing?

Jetstress testing can take a long time to complete, and it's vital that this time is accurately accounted for in your Exchange project plan. Generally, the test process occurs in the following phases:

  • Initialization   This phase includes installation, prerequisites, and initial database creation. Of these tasks, the initial database creation takes the longest amount of time. Database creation time varies depending upon hardware deployments. You should expect approximately 24 hours for 10 terabytes of data.

  • Testing   The actual testing phase varies depending on the complexity of your design. If your design is based on complex, cutting-edge storage technology, you need to allocate more time for testing. If your design is based on common direct attached components, the testing phase will be shorter. For simple direct attached solutions, allow from two to five working days. For complex SAN solutions, try to allocate up to ten working days. Troubleshooting storage performance issues can often be time-consuming.

  • Cleanup   Before the server can be put into production, it's necessary to remove the Jetstress application and the test databases that were created. Depending on complexity, allow from 1 to 2 hours for each Exchange server that needs to have Jetstress uninstalled. The recommended process is as follows:

    1. Uninstall Jetstress and restart your server.

    2. Copy the Jetstress data to a safe location.

    3. Delete the Jetstress installation folder.

    4. Remove all test databases.

What Happens If My Test Fails?

It's important to determine the pass and fail criteria for the test. The test will find the peak work load that the solution is able to provide at the I/O latency targets recommended by the Exchange team. For more information about these latency targets, see Reading Jetstress 2010 Test Reports.

If the recorded IOPS target from the Jetstress test is above the targets documented within the Exchange design, the storage solution has passed the test. If it doesn't meet the design targets, the storage solution has failed the test.

If the test shows that the solution has failed to meet its design targets, it's necessary to perform remediation. This task usually involves a combination of resources from the design and project, build, hardware, and storage vendor teams. The aim of remediation is to determine why the IOPS target was below the design target and to provide a remediation plan before submitting the solution for another test.