I've received several inquiries regarding my two-part column about Exchange 2000 Server sizing (December 22 and December 29). Many of you want more specifics about how Exchange Server accesses its database files and more detailed storage design guidelines for Exchange 2000 servers, so let's look at the key Exchange 2000 files and their design guidelines.
Like previous versions of Exchange, Exchange 2000 has transaction log files that are accessed in a strictly sequential I/O pattern using small synchronous I/Os. These files are vital to the database, and you should isolate them for both performance and safety purposes. With Exchange 2000, we now have the concept of multiple storage groups (SGs), or database engine instances, which forces the question of whether to have a separate volume or array for each SG's transaction logs or combine the transaction logs from all SGs onto one array. This decision depends on how much storage you can afford and want to manage. My general rule is to separate sequential from random I/O: If you combine all transaction logs onto one array, the I/O pattern is randomized. In my opinion, the decision only matters from a management and disaster recovery viewpoint because I haven't seen many cases where transaction log volumes incur heavy disk I/O. Also, as long as you have a robust controller and cache design, don't forget to use controller write-back caching for transaction log files.
For the Exchange property store (.edb files), nothing from a storage design point of view has really changed for Exchange 2000. These key database files are organized into a B-Tree database structure using a 4KB page size. A B-Tree structure causes random I/O patterns (synchronous reads and asynchronous writes) with a read/write ratio of approximately 50/50. Following my general rule, these files need their own array or volume. The design decision then becomes how many databases and SGs to combine on a single array. As a start, I suggest you combine all the databases from an SG on one array (if you use clustering, you must combine the files from each virtual server onto discrete LUNs anyway). If you find that you have disk performance problems and can isolate database files that are "hot spots," your design may warrant a further look. As is the case with the transaction log files, write-back caching will aid immeasurably with these files as well.
The last database file type for Exchange 2000 is the streaming store (.stm files). This file type is a "new animal" when it comes to storage design. Not only do these files differ structurally (they're not B-Tree structures; they're organized into groups of 16 4KB "runs"), but Exchange accesses them differently than it accesses property store files. STM files are accessed via the Exchange Installable File System (ExIFS), which is a new high-performance kernel-mode component in Exchange 2000. Using ExIFS, Exchange 2000 typically accesses STM files in 32KB I/Os but can access them in much larger I/O sizes as well. This means that there is a potential design requirement for further separation of these files from the property store files. In truth, I haven't seen a case where this separation is justified, but performance data for Exchange 2000 is still somewhat nonexistent. In addition, because Internet protocol clients use the streaming store exclusively, many Exchange servers supporting Messaging API (MAPI) won't exercise it (because most deployments are still MAPI-based). As more Exchange 2000 servers are deployed to support Internet protocol clients, we might see this situation change. For now, I recommend you combine the STM files with the EDB files for the lowest total cost of ownership (TCO). However, don't assume there will never be a day when these files don't need their own array.
Storage design for Exchange servers is somewhat of an art because so many design questions depend on other factors. However, understanding the different files that Exchange 2000 uses and how it accesses those files is the key. By applying some simple rules and practicing good performance management, you should be able to deploy Exchange servers whose disk subsystems can keep up with users.