class Best Practice for Supporting Storage Configuration Redundant Array of Independent Disks (RAID) is often used to both improve the performance characteristics of individual disks (by striping data across several disks) as well as to provide protection from individual disk failures. With the advancements in Exchange 2010 high availability, RAID is no longer a required component for Exchange 2010 storage design. However, RAID is still an essential piece to Exchange 2010 storage design for stand-alone servers as well as high availability solutions that require either additional performance or greater storage reliability. The following table provides guidance for the common RAID types that can be used with the Exchange 2010 Mailbox server. Stand-alone: supported/best High availability: supported/best Data type practices practices OS/System/Pagefile All RAID types All RAID types supported. Volume supported. Best practice: RAID 1/10. Best practice: RAID 1/10. Exchange Mailbox All RAID types All RAID types supported. Database File (EDB) supported. Just a bunch of disks (JBOD)/Raidless Volume Best practice: supported (3 or more database copies). 5,400/7,200 disks = Best practice: 5,400/7,200 disks = RAID1/10 only. RAID1/10 only or JBOD. Best practice: When lagged, database copies should have either two or more lagged copies or lagged copies should be protected with RAID. Exchange Mailbox All RAID types All RAID types supported. Database Log Volume supported. JBOD/Raidless supported (3 or more Best practice = database copies). RAID1/10. Best practice = RAID1/10. Best practice: When lagged database copies should have either two or more lagged copies or lagged copies should be protected with RAID.
class Best Practice for Supporting Storage Configuration Redundant Array of Independent Disks (RAID) is often used to both improve the performance characteristics of individual disks (by striping data across several disks) as well as to provide protection from individual disk failures. With the advancements in Exchange 2010 high availability, RAID is no longer a required component for Exchange 2010 storage design. However, RAID is still an essential piece to Exchange 2010 storage design for stand-alone servers as well as high availability solutions that require either additional performance or greater storage reliability. The following table provides guidance for the common RAID types that can be used with the Exchange 2010 Mailbox server. Data type Stand-alone: supported/best practices High availability: supported/best practices OS/System/Pagefile Volume All RAID types supported. Best practice: RAID 1/10. All RAID types supported. Best practice: RAID 1/10. Exchange Mailbox Database File (EDB) Volume All RAID types supported. Best practice: 5,400/7,200 disks = RAID1/10 only. All RAID types supported. Just a bunch of disks (JBOD)/Raidless supported (3 or more database copies). Best practice: 5,400/7,200 disks = RAID1/10 only or JBOD. Best practice: When lagged, database copies should have either two or more lagged copies or lagged copies should be protected with RAID. Exchange Mailbox Database Log Volume All RAID types supported. Best practice = RAID1/10. All RAID types supported. JBOD/Raidless supported (3 or more database copies). Best practice = RAID1/10. Best practice: When lagged database copies should have either two or more lagged copies or lagged copies should be protected with RAID.
467c984d85b41842e63287d5deafdbf7_MOFA%20Exchange%202010%20Design.docx