Exchange and SANs: No Magic Bullet, Part 2

Mark Twain once observed that the difference between the right word and precisely the right word is the same as the difference between a lightning bug and getting hit by lightning. In the same vein, I want to continue last week's discussion, in which I wrote about some of the characteristics of SANs that make them either well suited or poorly suited for particular applications. I'll delve into some specifics of SAN configuration for Exchange.

First, let's talk about an initial consideration: spindles. Microsoft has long advocated the practice of assigning separate physical disks for transaction logs and mailbox data. When the company introduced Exchange 2000, it extended that recommendation to include separate physical disks, where possible, for each set of .edb and .stm files in each storage group. This recommendation still holds true for SANs: If you can dedicate physical disks for Exchange by putting them into Exchange-only logical volumes, you'll get better Exchange performance. Not every support engineer at every vendor is hip to this idea; if your engineer pushes for disk sharing, push back. For accuracy's sake, I have to point out that disk sharing is sometimes inevitable; it's sometimes difficult to justify the cost of additional expensive disks just because of some nebulous claimed performance benefit.

The next consideration is RAID configuration. Let's say you need 2TB of Exchange storage on your SAN. You could reach that total with several combinations; three possibilities would be a 6-disk RAID-5 array of 400GB drives, a 16-drive RAID-1+0 array of 250GB drives, or a 15-drive RAID-5 array of 146GB drives. The 6-disk array would seem to have the lowest up-front cost, but it would also likely have the lowest performance because it has the smallest number of spindles; it's also somewhat less failure resilient because of the smaller number of drives. The 16-drive and 15-drive arrays would likely cost about the same but could have potentially different performance characteristics--not because of the disk counts but because of the I/O patterns for which each RAID type is optimized.

The third consideration is capacity. SAN vendors often cite performance numbers or use the Exchange 2003 Jetstress tool for performance demonstrations on lightly loaded disks. Using a small percentage of the disks favors the SAN controller and cache mechanisms, but it probably doesn't reflect what your SAN will actually look like in production unless you stuff it full of physical disks and move data around to use each physical disk as little as possible. This is like storing your socks in 25 dresser drawers, with each drawer containing one or two pairs of socks--it isn't very realistic. More likely, your disks will steadily fill up over time, so make sure that you conduct any performance tests on fuller disks--70 percent to 80 percent loading is probably ideal.

Dell and HP both offer storage calculators that let you estimate how many disks you need--and how to configure them--to support a given user population. You can use these calculators as a starting point in planning your configuration. However, the bottom line with Exchange and SANs is that you can't guarantee a particular level of performance unless you take the three factors I mentioned above into account. That doesn't mean that you won't get good performance from a configuration with low spindle counts, an inappropriate RAID level, or heavily loaded disks. It just means that the level of performance you get might not be consistent, and you could end up wasting money trying to fix problems that would be better avoided from the start.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.