Many organizations are moving forward with their Microsoft Exchange 2000 Server deployments and have begun designing their Exchange 2000 servers. A big part of this planning involves disk I/O design, so this week, I share my rules of thumb for Exchange storage and I/O design from a hardware perspective.
Selecting which RAID level to use for storage is often a big concern. I don't consider RAID 0 an option, so the choices are RAID 5 or RAID 1 (or 0+1, which you can treat the same as RAID 1 for design purposes). I've noticed that many organizations deployed earlier versions of Exchange with predominantly RAID 5 configurations; however, organizations deploying Exchange 2000 are using mostly RAID 1/0+1 configurations. This trend might be related to Microsoft's recommendation of RAID 1/0+1 over RAID 5 and hardware vendors' preference for selling hardware for RAID 1/0+1. I prefer RAID 1/0+1. RAID 5 incurs a tremendous write penalty when you use it with an application such as Exchange. System designers often underestimate this penalty and under-configure RAID 5 arrays. However, when designers properly configure a RAID 5 array and understand application I/O demands and RAID 5 overhead, RAID 5 is a viable solution. I suggest you read these rules of thumb before you decide which RAID level to use.
RULE 1: Expect .5 to 1 I/O per second per Messaging API (MAPI) user. This figure is typical, according to information from Microsoft, Exchange deployments, and test results. Thus, a server hosting 1000 users will require 1000 I/Os per second of disk I/O capability. Of course, MAPI users' needs vary, so you need to understand your users' profiles. If you use other protocols, such as POP or IMAP, your actual mileage might vary quite a bit, and you need to perform workload-characterization testing.
RULE 2: RAID has a write penalty. Depending on the RAID level you select, you must factor the overhead into your storage design. RAID 0 has no overhead because it provides no protection. RAID 1/0+1 incurs a penalty of 1*reads + 2*writes. This means that for every application write, the system must complete two physical I/Os to the array. RAID 5 has an even heavier penalty of 1*reads + 4*writes.
RULE 3: Exchange random I/O is 50 percent read and 50 percent write. Database I/O is the most important I/O design consideration for an Exchange server. I've seen Exchange performance data with read/write mixes such as 40/60 or 60/40, but for design purposes, a 50/50 ratio is usually a safe bet.
RULE 4: A disk or spindle can sustain about 100 random I/Os per second. This estimate is conservative (some disks can manage 120 I/Os per second) but will usually serve you well. This number applies only to random I/O; most disks can sustain much greater sequential I/O traffic (sequential I/O traffic applies to Exchange transaction logs). Because Exchange database I/O is random, we'll use the 100 I/O per second per disk rule.
The first step in applying these rules is to look at the user load you plan for your server at the Storage Group (SG) and database level. For example, if you have 1000 users on a server, and they're split between two SGs with dedicated arrays for their databases (500 users per array), you can anticipate a peak load of 500 I/Os per second for each array (see Rule 1). Next, factor in the RAID overhead and application demand. Applying Rules 3 and 4 to the example of 500 MAPI users on an array, you can calculate that for RAID 1/0+1, 500 I/Os per second from Exchange will require 750 I/Os per second from the disk subsystem with RAID overhead factored in (750=\{250+2*250\}). For RAID 5, this number is 1250 I/Os per second (1250=\{250+4*250\}). Then determine the number of spindles required for the array (see Rule 4). For RAID 5, you need 12 or 13 disk drives (1250/100=12.5). For RAID 1/0+1, you need only 7 or 8 disk drives (750/100=7.5). The penalty you pay for RAID 5 (approximately 40 percent) is obvious, and I usually prefer RAID 1/0+1, although on the surface, RAID 5 appears to be more cost effective.
You need to consider many operational and cost factors when making your Exchange storage-allocation decisions. These rules of thumb have served me well, and I hope you'll find them useful as you design your Exchange deployments.
