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.
Microsoft's Feature Pack deployment guide (shipped by the OEMs who sell Windows Storage Server systems) specifies three baseline configurations. (You need to ask your vendor for performance data to determine whether the vendor's recommended configurations will work for your environment.) The baseline configurations are
- one Exchange server, with up to 250 mailboxes hosted on a single-CPU Windows Storage Server computer that has four physical disks in a RAID-5 set;
- one Exchange server, with up to 750 mailboxes hosted by a dual-CPU Feature Pack server with eight physical disks: four in a RAID-5 array for the databases, plus one mirrored pair each for the logs and OS; or
- one or two Exchange servers, with up to 1500 mailboxes split between two storage groups (SGs). In this configuration, Microsoft recommends six physical disks: four for a RAID-5 set containing the databases, plus one mirrored pair for the SGs' transaction logs.
Setting Up the Feature Pack
When you install the Feature Pack (which you need to get from the OEM that sold you your Windows Storage Server machine), it makes some changes to the storage server. The Feature Pack adds a new task (New Share for Exchange Files) to the Web UI. You'll use this task to create Exchange-specific stores on the Windows Storage Server machine. The Feature Pack also creates a new share to hold the software that you need to install on the Exchange server. Thus, you don't need a separate installation for your Exchange 2003 servers.
You do need to install the Exchange server components of the Feature Pack, however. When you do, you get a pair of tools to help you move your Exchange databases to their new home, plus a Windows service that redirects requests for pages in the Store to the databases at their new location. The service uses Dfs to consolidate all the individual database locations into one Dfs root, which the Feature Pack mapping service then maps as a drive; the Feature Pack mapping service can take requests from the Store for individual database pages and turn them into Dfs paths. Exchange 2003 doesn't accept a Universal Naming Convention (UNC) path as a database location, but it does accept a Dfs path that just happens to resolve to a UNC path.
After all the software is installed, your next task is to move your databases. Begin by using the New Share for Exchange Files task to create a share on Windows Storage Server to hold the databases and log files. All the databases from one server must go in the same folder; the Feature Pack supports up to four SGs from two Exchange servers. After you create these shares, you use the database-moving tools to move your Exchange data to the storage server.
You can choose between two tools that have different capabilities but work the same way. The Remote Storage Wizard lets you use a simple GUI to move your databases. WSSExchMove.exe is a command-line tool that lets you duplicate your databases instead of moving them and gives you a way to script moves so that you can perform them as part of an unattended installation. Whichever tool you use, you must run it from the Exchange server. Note that you can only move databases; you can't create a new database directly on the Windows Storage Server computer. The Remote Storage Wizard and WSSExchMove.exe do the following:
- Dismount the databases that you're moving. If you're moving log files, the tools dismount all databases in the SG that you're moving.
- Check the databases for consistency. This check is similar to the one that the Exchange Store does at start-up. The tools won't move inconsistent databases.
- Set the read-only attribute on the original databases and logs, then copy the databases, log files, or both to their new location.
- Create a new Dfs link for each moved EDB and STM file. If you moved the transaction logs, they get new links, too.
- Update the local server with information about the location of the Dfs link targets (which are, of course, on Windows Storage Server).
- Remount the stores.
If you use the Remote Storage Wizard, it deletes the original databases after these six steps are finished. If you're safety-minded, you might prefer to use WSSExchMove.exe with the /n switch, which keeps the original files in their original locations. (It should go without saying that you need to make a full online backup of your server before you move the files.) For maximum safety, you can create a new, empty mailbox database on your Exchange server and move it to the Windows Storage Server machine, then use Exchange System Manager (ESM) to move your users' mailboxes to the new database. This method is slower than using the built-in tools but lets you move mailboxes in small groups until you're satisfied with your setup.
Operation and Maintenance
In typical day-to-day operation, an Exchange database that's hosted on a Feature Pack server should work just as it would if it were hosted locally. (The exception, of course, is if network latency or the load on the storage server is excessive, both of which you can ascertain by using Performance Monitor to watch the disk and network I/O counters.) However, maintaining your server is somewhat different because most maintenance tasks need to run where the databases are.
Maintenance tasks fall into four categories: backup and restore, running Eseutil, tasks that use the Recovery Storage Group, and those that use Microsoft Volume Shadow Copy Service (VSS). Let's look at each category.
You'd expect backups to run fastest when you perform them from the server that hosts the databases. However, you'll probably obtain the best performance by putting your backup device on the Exchange server. If you put the device on the Windows Storage Server system, doing online backups means transferring data twice (once from Windows Storage Server to the Exchange server, where the Extensible Storage Engine--ESE--backup API runs, then back to the storage server to be written to tape).
In most cases, you'll run Eseutil on Windows Storage Server because Eseutil requires local access to physical database pages. The exception is Eseutil's soft recovery mode, which plays back transaction logs to make a database consistent. Microsoft recommends using the /r switch from the Exchange server, not the storage server.
The Feature Pack supports using the Recovery Storage Group for fast recovery, but you have to create a Recovery Storage Group on your Exchange server, then move it to the Windows Storage Server system before you attempt to mount databases in it. The Recovery Storage Group counts against the total number of SGs that the Feature Pack supports.
VSS support on Windows Storage Server and the Feature Pack can be a bit confusing. Windows Storage Server supports VSS on ordinary file shares; when used this way, VSS keeps shadow copies of protected files so that users can easily recover old versions of files. However, when you say "VSS" to an Exchange administrator, he or she will most likely think of using VSS to make point-in-time copies of databases or SGs, which the Feature Pack doesn't currently support. You can use VSS to protect your databases by making offline copies of them, just as if they were Microsoft Word or Microsoft Office Visio 2003 documents in a file share. However, when you do so, you essentially make an offline backup and are subject to all the restrictions and hassles detailed in the Microsoft article "Offline Backup and Restoration Procedures for Exchange" (http://support.microsoft.com/?kbid=296788).
An Intriguing Approach
If Windows Storage Server were just another bits-in-a-box solution, it wouldn't be very interesting. However, given its tight integration with Active Directory (AD), its ability to host Exchange data, and its broad vendor support, Windows Storage Server is intriguing. One nifty feature is that you can use the same Windows Storage Server system to host file shares and Exchange shares at the same time, meaning that you can easily consolidate multiple servers in one system without having to invest in a SAN and the specialized expertise it requires. If your environment fits into Microsoft's target market, you might find that compared with a SAN, the Windows Storage Server Feature Pack combination delivers a lower-cost, easier-to-manage solution for your Exchange storage.
