Microsoft did a good job driving down the database I/O requirements in Exchange Server 2010. However, Exchange administrators still need to do their part to prevent fragmentation from impacting I/O -- especially
There are several different methods to prevent virtualized mailbox server fragmentation because fragmentation occurs at three different tiers: on the hypervisor storage level, on virtual hard disk files and the mailbox database. Here’s how to manage defragmentation at each level.
The hypervisor storage level
The first tier where fragmentation occurs is the hypervisor storage level. This is especially true for Exchange shops that use Hyper-V, but do not use a storage area network (SAN). In a SAN environment, each virtual hard drive file is traditionally placed on a dedicated logical unit number (LUN). Smaller Exchange shops that do not use SANs often place multiple virtual hard disk files onto a single hardware array.
This is problematic for two reasons. First, all of the virtual hard disk files that share the array compete for disk I/O. You must use hardware that can provide sufficient I/O to keep up with the demand to alleviate this problem.
Placing multiple virtual hard disk files onto a single hardware array can also be problematic because Hyper-V creates dynamically expanding virtual hard disk files by default. These files expand as data is added to the virtual hard disk. If multiple dynamically expanding virtual hard disk files reside on a common storage array, then the virtual hard disk files can become fragmented at the storage level.
If you're currently using Hyper-V, I strongly recommend only creating fixed length virtual hard disk files. If you are using VMware, this is a non-issue because VMware creates fixed length virtual hard disks by default. Using fixed length virtual hard disk files prevent storage level fragmentation from occurring.
Virtual hard disk file fragmentation
Fragmentation can also occur within a virtual hard disk (VHD) file. This is the same type of disk fragmentation that occurs when Exchange Server is installed on a physical server; the only difference is that the fragmentation occurs within a virtual hard disk rather than on a physical hard disk.
The best strategy for minimizing this type of fragmentation is to configure your Exchange mailbox server to use multiple virtual hard disks. For example, you could use one virtual hard disk for the Windows OS, another for the pagefile, a third virtual hard disk for the mailbox database and a fourth for the transaction logs. (This technique will not entirely prevent fragmentation, but will certainly help to minimize it).
Mailbox database defragmentation
The third tier fragmentation can occur at is within the mailbox database. As database pages are created and deleted, the database becomes fragmented. By default, Exchange Server 2010 runs a nightly maintenance cycle that performs various housekeeping chores. The most important chore is database defragmentation. This defragmentation does not remove empty space or shrink the database, but it does reorganize the database pages to make read and write operations more efficient.
The important thing to keep in mind is that the nightly maintenance cycle is extremely I/O intensive. Microsoft automatically schedules maintenance to occur late at night to minimize the performance impact caused by the defragmentation process.
For years, I've advised my clients and readers to modify the Exchange Server database maintenance schedule so that it doesn't overlap with the nightly backup. Backing up a database while simultaneously trying to defragment it can severely impact the server's performance.
Nightly backups are becoming less common as more and more Exchange shops are using continuous backup solutions. Even if you fall into that category, it doesn't hurt to take a look at your nightly maintenance schedule in your virtual environment.
If multiple virtual machines share a physical storage array, then it's possible that the nightly database defragmentation process could be impacted by I/O-intensive tasks running on other virtual servers. This includes virtual servers that are running applications other than Exchange Server 2010.
Ideally, you should avoid sharing physical storage devices among multiple virtual machines. However, budgetary reasons often make this option unavoidable. In these situations, you should determine exactly when each virtual machine produces the highest I/O and then schedule the Exchange Server maintenance cycle to run during non-peak times. This will not only improve performance, but will also reduce the chance that a storage bottleneck prevents Exchange from completing its maintenance tasks within the allotted time.
In addition to the techniques that I have described above, there are also third-party products specifically designed to combat fragmentation in virtual data centers. Two such products include PerfectDisk and Diskeeper.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in July 2011