Most Exchange Server pros believe that Exchange doesn't support Network Attached Storage (NAS) devices. This idea has been around for a long while, even though versions earlier than Exchange 2000 Server actually could be used with some types of NAS units. (For an overview of the history of Exchange and NAS interaction, see the Web-exclusive sidebar "Exchange and NAS," http://www.windowsitpro.com/microsoftexchangeoutlook, InstantDoc ID 43547.) Thus, Microsoft recently made waves when it announced that it was extending Windows Storage Server 2003 to allow its use with Exchange Server 2003. (For information about Windows Storage Server, see the Web-exclusive sidebar "Bits in a Box," InstantDoc ID 43548.) The Windows Storage Server 2003 Feature Pack (which I simply call the Feature Pack hereafter) lets you put your Exchange 2003 databases and logs on a Windows Storage Server machine.
Is that a good idea? It depends. Windows Storage Server is relatively new, and many Exchange administrators aren't familiar with it. Let's look at how Windows Storage Server works with Exchange 2003 and when using it as an Exchange storage mechanism does (and doesn't) make sense.
What Exchange Wants
It's helpful to consider the architectural aspects of Exchange's implementation that lead to specific requirements for an Exchange server's storage subsystem. Each Exchange mailbox or public folder database contains a pair of files: a property store (EDB) file, composed of 4KB pages, and a streaming store (STM) file, made up of runs (from 16KB to 64KB) of 4KB pages. The access pattern for EDB files tends to be highly random, while I/O to STM files is much more sequential. However, there are often correlations between I/O operations on this pair of files because, under many conditions, message properties remain in the EDB file while message content is streamed to the STM file.
Consequently, performance gurus have long recommended keeping logs and database files on separate physical disks when possible. Good disaster-recovery practice also calls for separating logs and database files because losing them both would make restoring the database to the point of failure difficult, if not impossible. So, the first thing Exchange needs is adequate storage space, properly provisioned, for the databases and transaction logs you're using.
The second Exchange requirement--low latency (i.e., the time that elapses between when a write is requested and when it's finished)--is closely related to the first requirement. Exchange uses asynchronous I/O for writes, so it doesn't have to hold pending write requests until previous ones have finished. However, if Exchange has to wait too long for write requests to finish, timing and dependency problems can occur, resulting in extremely poor performance. Exchange's second requirement is simply to keep latency to a minimum.
The third requirement isn't a requirement as much as it is a good idea: Have a lot of physical disk spindles backing the Exchange databases. Each disk in a server can generate a certain number of I/O operations per second. The more disks you have, the more I/O operations per second your server can provide and the more Exchange clients it can handle simultaneously. High-end Storage Area Networks (SANs) might have hundreds of physical disks, but most of us have more modest configurations.
The fourth requirement needs no real explanation: You need to protect the data stored on disk against physical failures. Backups are necessary, of course, as a last-ditch way to recover data when it can't be read from disk. However, most Exchange administrators rely on some type of mirroring or striping with parity, either through a hardware controller in the server or SAN or via the built-in Windows disk mirroring and striping capability.
The Feature Pack Delivers
Windows Storage Server itself provides some of the things Exchange needs. In particular, it meets the fourth (data protection) requirement by providing hardware or software RAID, depending on the model of hardware you buy. (Several vendors also offer hot-swappable disks and other redundancy features on their high-end models.) Likewise, most vendors offer a range of disk sizes and configurations, including some with as many as eight built-in disk bays, thus meeting the third requirement (a lot of disk spindles). The first two requirements (adequate storage space and low latency) are the big ones, though, and to be able to use the Feature Pack to deliver them, you have to be thoughtful in your design and configuration.
First, it's important to understand the target market for the Feature Pack: small and midsized businesses with as many as 1500 Exchange mailboxes and one or two Exchange servers. One Feature Pack server can host up to 1500 mailboxes connected to a single Exchange server, a pair of standalone servers, or a clustered pair of servers. There's no hard limit on the number of mailboxes, but for larger numbers of mailboxes, Direct Attached Storage (DAS) or SAN storage will likely provide lower latency than a Feature Pack server.
Second, you should understand how to connect the Exchange and Windows Storage Server computers. Microsoft recommends the use of Gigabit Ethernet, which provides lower latency and faster performance than 100Base-T. The simplest and most reliable way to set up Gigabit Ethernet is to use a crossover cable between your Exchange server and the Feature Pack server; that way, there's no chance that an intervening hub, switch, or router will fail and damage your Exchange data. Your design goal should be to provide a dedicated Gigabit Ethernet path for each Exchange server that connects to the server that hosts the Feature Pack.
You can use Windows Storage Server to hold Exchange data in a couple of ways. One option is to have Windows Storage Server host just the databases while the logs remain on your Exchange server. This configuration provides good protection (because the logs and databases are on separate machines) and helps keep latency from being a problem for transaction-log writes. You can also store both the logs and databases on the Feature Pack server, a configuration that might make sense if your Windows Storage Server system has better or faster hardware than your Exchange server does. However, that approach doesn't separate the logs and databases, rendering you vulnerable to a failure of the server that hosts them.