General Storage Principles

  • Article

 

Regardless of the applications that you are running, consider the following storage principles to help you maximize capacity, performance, and availability.

  • Specialized hardware solutions

    You can decrease CPU processing time by implementing a specialized hardware solution, such as a hardware RAID arrangement on the external storage array or a SAN that incorporates RAID technology. However, specialized hardware storage systems can be expensive. You should not spend more money on the storage system than you expect to recover in saved time and data if a failure occurs.

    When you select a specialized hardware solution, consider the following:

    • For preventing data loss, a RAID arrangement is recommended. For high availability of an application or service, consider multiple disk controllers, a RAID solution, or a Microsoft Windows® Clustering solution.

    • Servers that do not host mailboxes or public folders, such as connector servers, may not benefit from advanced storage solutions. These servers typically store data for a short time and then forward the data to another server. In some cases, you may prefer RAID-0 configuration for these types of servers.

  • Storing Exchange data

    All data that is stored on Exchange is not managed in the same manner. Therefore, a single storage solution for all data types is not the most efficient. With regard to Exchange, you have to consider that transaction log files are accessed sequentially, and databases are accessed randomly.

    According to general storage principles, you should keep the transaction log files (sequential I/O) from databases (random I/O) on separate disk arrays to maximize I/O performance and increase fault tolerance.

    In addition, you should store the transaction log files for each storage group on a separate disk array. Storing sequentially accessed files separately keeps the disk heads in position for sequential I/O. This reduces the time that is required to locate data.

  • Disk capacity and performance

    Using a storage configuration with multiple small disks always results in faster performance than using a storage configuration with a single large disk. In general, more disks result in faster performance. You should size each hard disk so that you have enough capacity on it to perform online defragmentation of Exchange databases.

    For example, if one of the branch offices in your organization wants to store 72 gigabytes (GB) of Exchange data, consider using eight 18-GB disks instead of two 72-GB disks. Eight 18-GB disks (144 GB total capacity) enable you to achieve high performance with your 72 GB of Exchange data, and also provide the disk space necessary to perform online defragmentation.

  • Volume Shadow Copy Service

    Consider using Volume Shadow Copy Service capabilities in coordination with your SAN solution. Volume Shadow Copy Service enables you to perform backups without affecting the performance of your back-end servers. In addition, using Volume Shadow Copy Service can improve backup times and significantly improve the time that it takes to restore Exchange database files. For more information, see Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003.

  • Storage group configuration

    Microsoft Exchange Server 2003 supports up to four storage groups. Each storage group has its own set of transaction log files and supports up to five databases. How you configure your storage groups affects Exchange performance, including how long it takes to back up and restore Exchange databases.

    In versions of Exchange that are earlier than Exchange 2003, we generally recommended that a storage group be filled with five databases before creating an additional storage group. Beginning with Exchange 2003, the recommended database and storage group configuration has changed. When you use Exchange 2003 or a later version of Exchange, we now recommend that you add an additional storage group for each new database until the maximum number of storage groups has been created. We recommend that you do this instead of adding multiple databases within a single storage group.

    The reasons for this new recommendation include the following: taking advantage of virtual memory management improvements in Exchange 2003, improved recoverability, and better manageability of disk I/O.

    Understand that databases in a storage group are not fully independent because they share transaction log files. As the number of databases in a storage group increases, more transaction log files are created during regular operation. The larger number of transaction log files requires additional time for transaction log replay during recovery procedures. The longer time for transaction log replay leads to longer recovery times. When you maximize the number of storage groups on a server, you can take advantage of separating log traffic. Additionally, by minimizing the number or databases and their size, data recoverability is improved by decreasing the time that is required to back up and restore Exchange.

For More Information

For more information about how to configure storage groups, see "Storage Group Configuration" in Best Practices for Configuring Exchange Back-End Storage.

For more information about how to configure storage groups, see Microsoft Knowledge Base article How to configure storage groups in Exchange Server 2003.