6.2 Best practice 2: Plan and partition data

6.2 Best practice #2: Plan and partition data

One of the great new features of Exchange 2000/2003 is the ability to segment or partition both public and user data into manageable units. In previous versions of Exchange Server, we did not have this luxury. As a result, the number of users per server we could support was limited by the size of the information store and the disaster-recovery limitations imposed by the speed or our backup and recovery tools and processes. With Exchange 2000/2003, you have the ability to make some important decisions about how storage is allocated based on factors such as performance, recoverability, and management complexity. Since each storage group shares a set of log files, it is recommended for performance and management reasons that the log files be placed on separate disk devices from the database files. This is directly related to the nature of the I/O patterns for the individual database files. The transaction log files are accessed in a purely synchronous, sequential write pattern (except during replay). The property store (*.EDB) has an I/O pattern that is highly random in nature with small (4 KB) synchronous reads and asynchronous writes. Somewhat unknown (due to lack of widespread deployment of Internet Protocol–based clients) is the streaming store, which has an I/O pattern that is similar to the property store ( random in nature with synchronous reads and asynchronous writes), but with typically larger I/O sizes of 32 KB (and burst writes as large as 350 KB). The I/O access pattern for the Exchange database files, along with management considerations, is that key driver for partitioning and server design. In the event that you are deploying an Exchange server that supports predominantly Internet Protocol–based clients, seek Microsoft’s guidance on partitioning and designing your storage system for this scenario.

Since multiple databases can be configured within a storage group, you should design the size of each database within a storage group to be aligned with your recovery capabilities and time windows. For example, if your backup and restore facilities provide for a restore rate of 10 GB per hour and you have a 2-hour recovery window, it would be best to limit the size of each database to 20 GB or less. You should maintain these databases at limits that facilitate reasonable recovery times. Microsoft is recommending that the entire storage group be backed up as a unit (as opposed to backing up each database in the storage group individually). This ensures simplicity in your backup and restore procedures since all databases within the storage group share the same transaction log sequence. This also ensures that, since all databases in a storage group share the same transaction log set, the Exchange database engine will not truncate the transaction logs (during a full or incremental backup) until all databases in the storage group have been backed up. If you were only to back up individual databases, it is possible that log files would never be truncated, resulting in a greater potential for data loss.

When restoring data, you can restore a single database (MDB—*.EDB and *.STM files) without impacting other databases in the same storage group or in other storage groups. The other databases continue to provide services to clients. If other databases share the same physical storage devices such as a RAID array, there may be minor performance issues while databases are recovered. This issue, along with the potential for a loss of all databases sharing a single volume or array, makes a good case for separating databases onto separate physical disk devices or arrays for optimal performance and data protection. This partitioning of user data across multiple physical devices can isolate problems with hardware to a single database and only affects the users whose data resides there. To completely prepare for storage failure on an Exchange server, you should investigate data partitioning and plan to separate data into storage groups and databases.

To add further protection, you can even back up the partitioned data to different backup media. Remember that the concurrent recovery scenario limitation is on a per-storage-group basis. As long as you initiate separate backup and restore operations for each storage group, the Exchange database engine can operate on multiple storage groups at the same time. You can gain significant performance benefits by backing up storage groups in parallel with multiple backup devices. Parallel restore operations ensure that users who are not affected by an outage of one database can still access their data on another database. Taking advantage of these features in Exchange 2000/ 2003 and partitioning server data into manageable units of recovery and performance (based on SLAs as illustrated in Figure 6.2) will allow you to meet and exceed those service levels and provide the highest levels of availability to your Exchange clients.

Figure 6.2: Partitioned versus monolithic storage in Exchange Server.