Of the four subsystems in an Exchange server, the disk subsystem receives the least amount of proper attention. I continually find that administrators spend hours discussing whether the Exchange server should have a 3.2GHz CPU or a 3.4GHz CPU, but spend only a few minutes of consideration on the disk subsystem. Yet everything the Exchange server does involves the disk subsystem in some way. Table 1 provides overall guidance for the design of an Exchange mailbox server disk subsystem for DAS. (For Exchange environments that use NAS or a SAN, you'll need to contact your storage vendor for disk-configuration recommendations.) I don't have the space in this article to cover all the architecture and design options for an Exchange disk subsystem, but I will point out some common mistakes that I run into regularly.
Whether Exchange disk storage uses DAS, NAS, or SAN, the Exchange disk drives shouldn't be shared with or used by other applications. Exchange is sensitive to disk latency, and the inherent random nature of Exchange database activity further amplifies that sensitivity. The Microsoft article " Exchange Server and network-attached storage" (http://support.microsoft.com/?kbid=317173) is a good starting point for learning about the effects of disk sensitivity and disk latency.
A key point to remember when dealing with the Exchange disk subsystem is this: Spindles are your friends. You can never have too many spindles for an Exchange mailbox server. The more spindles you dedicate to an Exchange back-end server, the greater the disk I/O rate the server can support and the better the server's performance. Too often, administrators (and managers) focus on disk size rather than spindle count. For example, suppose you have an Exchange server that needs to support 2000 users, with a 150MB mailbox size limit. Is buying a couple of 300GB disks adequate? If you answered "Yes," you're suffering from a false sense of security. Users are, in actuality, disk I/O consumers. Each active Exchange user (or mailbox) requires a certain amount of disk I/O, typically between .1 and .8 I/O operations per second (IOPS) per user (high-end users can require more than 1.0 IOPS.) The average high-performance SCSI disk drive (depending on make and model) supports about 120 IOPS, so the only way you can successfully satisfy the requirements in our example is by adding spindles. This is especially true for the volume (or LUN) that supports the Exchange databases. Exchange database volumes should consist of many smaller spindles (as opposed to a few large spindles). Exchange database activity is extremely random, and having more spindles to service these random disk requests is key to good Exchange performance. You can use Performance Monitor to find out how many IOPS your existing users are consuming. (Take a look at the Microsoft article "Optimizing Your Storage Architecture," http://tinyurl.com/bpn2k, for more information.)
Another mistake is assuming that RAID 5, instead of RAID 0+1 (or RAID 1+0, depending on your hardware implementation) is better for local disk storage. RAID 5 requires more spindles to achieve the same performance as RAID 1+0 because of the added disk writes that RAID 5 must make. RAID 5 might work fine for smaller Exchange servers in remote branch offices, but for dedicated Exchange back-end servers that support many users and large mailbox storage limits, RAID 5 isn't necessarily the best choice. (If you're using SAN technology for your Exchange disk storage, this might not be the case. Contact your storage vendor for help designing SAN storage.)
Sharing Exchange transactions or database logs with other applications can hurt Exchange performance. As Table 1 mentions, Exchange transaction logs are 100 percent write and are sequential. Sharing either volume can cause excessive disk contention and performance degredation. For new Exchange installations, I recommend you run Microsoft Jetstress or Microsoft Exchange Load Simulator (LoadSim) to ensure that the disk subsystem can support the necessary number of mailboxes. (Of the two, Jetstress is the fastest and simplest to install, configure, and run.) These utilities can often uncover disk I/O problems before you put the new Exchange server into production. To find out more about these tools, see the Web-exclusive article "Exchange's Performance Testing Tools," November 2003, InstantDoc ID 40844.
Don't create logical volume sets on the same set of physical spindles. I've seen administrators create one large volume, then create individual logical partitions in an attempt to provide dedicated spindles ( separation) for Exchange transactions and database logs. The results are not good: Because all the logical partitions in the one large logical volume set use the same set of physical spindles, the Exchange server still suffers from disk contention.
One last piece of advice when it comes to disk subsystems: Many hardware vendors provide caching on their disk controllers. If these controllers have battery backup, consider enabling write-ahead caching, which tells the Exchange server that the write request has been committed to disk when in reality, the request is in memory. I've seen dramatic improvement in Exchange performance when this feature is enabled.
More Tips Next Month
Next month, I'll cover the remaining design considerations that round out our Top 10. In the meantime, you can begin documenting your design requirements and planning your AD and hardware requirements.
End of Article
Prev. page
1
[2]
next page -->
