Exchange Layout Best Practices

  • Separate Windows Server and Exchange Application files by putting them on LUNs that are different LUNs from the Storage Group.
  • The SMTP directory (Exchsrvr\Mailroot) directory should be on disk optimized for performance, and should be on a volume large enough to accommodate a burst in size (such as occurs when a destination server fails).
  • Content Indexing files should be moved onto a different disk than the paging files (they default onto the same disk).
  • Each Storage Group should be completely populated by databases before creating another database to increase application performance. The size of the databases is determined by target recovery times. Exchange Standard Edition can have 1 SG, Enterprise Edition can have up to 4. Each storage group can have up to 5 DB in each edition, and the recovery SG is separate in both editions.
  • Users should be distributed so that DB size is equal across the server for recovery purposes. In some cases, users with dramatically different use profiles can be moved around to optimize performance (spread out the heavy users). Single instance storage is per database, so it is possible to save some storage space by keeping workgroups together within a single database.
  • Each data lun should have one 4 drive parity group per 400 expected IOPS for RAID10, or 275 expected IOPS for RAID 5 (9900V, from PPK450. What should 9500 and USP be?).
  • Increase capacity in a given SG should use additional LDEVs from the same parity groups provided the number of IOPS has been achieved. It is best to spread the capacity utilized equally from all parity groups (i.e., if you need 800 IOPS for a SG, use two dedicated RAID10 2+2 parity groups and pull all LDEVs from the same parity group until desired capacity is achieved.)
  • For rapid recovery flexibility and performance reasons, the database files (.edb and .stm) should be located on a separate LUN from the transaction logs.
  • Individual logs and databases should not share parity groups.
  • All LDEVs for a database or log should be turned into a LUSE volume, striping isn't necessary.
  • Even in cases where IOPS of a database are less than one parity group, data and log LUNs should not use LDEVs from the same parity group.
  • In cases where QuickShadow (copy-on-write or incremental copies) is utilized, the performance should be scaled so that both production and maintenance activities (such as ESEUTIL and backup) can be serviced by the production LUNs since most IO will be shared between production and maintenance.
  • Use Windows Clustering to improve availability.
  • Run Jetstress to test the configuration prior to putting it into production.
  • Reference "Exchange Server 2003 Performance and Scalability Guide", "Exchange Server 2003 High Availability Guide", and "Exchange Server 2003 Disaster Recovery Planning Guide" for more information. (