Raid Considerations for Exchange 2010

  • Posted By: Steven Sher

This article will provide a simple and basic primer, to the relevant RAID levels which can be considered with either Exchange 2010 or Exchange 2007.


Figure 1: RAID 1 Simple Example

Introduction

RAID levels are one of the key design and sizing elements for a resilient and high performing Exchange installation. Many Exchange admins will be familiar with the basic best practice recommendations for RAID, but it is important to understand which particular type of RAID configuration should be applied and where.

It is intended that this article will provide a simple and basic primer, to the relevant RAID levels which can be considered with either Exchange 2010 or Exchange 2007.

  • SAN vs DAS vs iSCSI
  • RAID 1
  • RAID 5
  • RAID 10
  • Cost to Benefit ratios

Traditional Exchange RAID levels

During the evolution of Exchange the general RAID recommendations have remained pretty much constant – e.g. RAID 1 for Transaction Log volumes and RAID 5 for Database volumes.

Recently, the RAID recommendations at the “best practice” level have changed to RAID 10 for both Transaction Logs and Databases.

RAID Level Overview and how they fit with Exchange

RAID 1 (Mirroring)

In its simplest form, data from one disk is copied to another disk via the disk subsystem, RAID 1 consists of a minimum and maximum of two disks (or two disks and one “hot spare”).

This configuration will sustain the loss of a single disk without losing any data or performance.

Relationship and usage within Exchange 2010

RAID 1 has typically been the corner stone for the Transaction logs volume (although depending on your budget RAID 10 can also be considered – but I would imagine that this would only pay dividends in very large environment with huge transactional I/O).

RAID 1 works well for Transaction Log purposes due to its good write performance as opposed to RAID 5 generally being better for reads, it is important to note that the logs should be on their own dedicated RAID 1 volume away from Database LUNS.

RAID 1 can be used for Database volumes as well – however your databases will be limited by the overall size of individual disks within the RAID 1 set.

For example; if you can only afford x2 1TB disks – the overall combined size of your databases might be limited to say around 800GB as you would not wish to fill the disks to capacity – and you can only have 2 disks in a RAID 1 set.

Pros & Cons of RAID 1

  • Simple and well supported by a wide range of RAID controllers
  • Relatively cost effective
  • Good level of resilience in proportion to the number of disks needed (you can lose 50% of your disks without losing data)
  • Good Write Performance
  • Loss of 50% of your available space (if you have x 2 drives of 72GB each you will only have access to 72GB when they are configured as RAID1)

Figure 2: RAID 5 Simple Example

RAID 5

RAID 5 is based upon the striping of RAID 0 with redundancy in the form of a parity block. Information is written across all disks with a parity block for all data written within each stripe. You can lose a single disk from the array – where the data will be rebuilt onto a replacement disk from the information contained in the parity block.

In order to form a RAID 5 array you will need a minimum of 3 disks – however most configurations contain 4 or 5 disks where one disk is a dedicated “hot spare”.

For best performance within Exchange 2010 you should be looking to have no more than 7 disks per RAID 5 array, and you should pay attention to the rebuild priority functions of your RAID controller.

If a disk fails the process of rebuilding can have an adverse impact on the performance of your Exchange infrastructure. To mitigate this you will need to refer to the recommended best practices from your RAID controller’s manufacturer.

Relationship and usage within Exchange 2010

RAID 5 has traditionally been the cost effective mainstay of the Database LUNS. RAID 5 offers a good trade-off between available disk space, performance and resilience.

Pros & Cons of RAID 5

  • Simple and well supported by a wide range of RAID controllers
  • Relatively cost effective
  • Reasonable level of resilience – you can lose 1 of your disks without losing data
  • Good level of space utilization (e.g. you get to leverage more of the space on the disks in the array over that of RAID 1 or RAID 1+0)
  • Good overall Performance
  • Long rebuild times of failed drives increases risk of a secondary failure destroying your array
  • Disk rebuild impacts upon overall performance of the array

Figure 3: RAID 10 Simple Example

RAID 10 (1+0)

RAID 10 (or RAID 1+0) combines the features of RAID 1 and RAID 0 to create a mirror of stripes – in essence information is striped across two arrays and then mirrored.

In order to implement RAID 10 you will need a minimum of 4 drives (of the same capacity) and expect to lose 50% of the available space when the array is formed.

When configured correctly one disk from each mirrored array can fail with no data loss – therefore considering the example in figure 3 – 2 disks can fail.

Relationship and usage within Exchange 2010

RAID 10 can be used for both the Transaction Logs and Databases LUNS as the performance and resilience that it offers is suitable for both.

Bearing in mind that you need 4 disks to form a RAID 10 array that makes it quite an expensive proposition (consider 4 drives at 300GB each = 1.2 TB – in RAID 10 you can only use 600GB).

Given the expense, if you are a small to medium sized company whom are really interested in performance – I would consider RAID 10 for the Databases only and use RAID 1 for the Transaction Logs.

If cost is a real issue you should opt for RAID 5.

Pros & Cons

  • Excellent Read and Write performance
  • Excellent redundancy
  • Excellent rebuild performance
  • Poor Space utilization
  • Expensive (based on the space utilization)

Analyzing IOPS performance to needs

All of this work with RAID and by choosing the correct hardware boils down to optimizing disk IOPS (and of course resilience).

IOPS (Input/output operations per second) are the most basic measure of how quickly data can be read from and written to a disk. IOPS are dependent on the type of enclosure, type of disk, RAID level chosen.

Of course, this article has covered what are GENERALLY considered to be the most common guidelines for RAID selection in terms of Exchange 2010 – however in order to achieve the IOPS the RAID choice and disk layout should be backed up with a lot more investigation –the science of sizing your disk, RAID to other critical components of Exchange such as the Memory & CPU.

The process of doing involves a lot of information gathering – for example;

  • Determining your average Mailbox user profiles (low, medium heavy) throughout your organization
  • Determining the amount of mail traffic within your environment (relevant to the HT and Edge roles as they also use Database and Transaction log files)
  • Analyzing the impact of 3rd party applications on Exchange

However, there is a tool which Microsoft provide (Role Requirements Calculator) which is essential for any Exchange admin when planning their RAID and overall storage architecture located here.

When choosing a RAID layout (or any other aspect of your 2010 sizing) you should be doing it in conjunction with this tool.

Cost to benefit ratios

The key message in Exchange 2010 and Exchange 2007 is performance over capacity – especially when configurations such as RAID 10 with high end RAID controllers combined with large amounts of RAM are considered best practice.

This can be very much at odds with organizations trying to keep IT capital costs low.

The key thing to keep in mind is that you can achieve good performance be keeping your design in line with the actual requirements of your organization and not necessarily always purchasing the high end technology.

For example; If you organization consists of 3000 mailboxes, where the average user profile is between low to medium, and you wish to implement DAG – you might be looking at using eSATA disk SFF, with a medium end RAID controller with battery backed write cache configured in DAS on RAID 1 and 5 split across two servers.

This would be cheaper than SAS disks configured in RAID 1 and 10 – and deliver the right performance point for you (as long of course if you have invested in the correct amounts of RAM and CPU sizing).

Summary

In this article we have covered the most common RAID levels for Exchange and Exchange 2010 and discussed some of the thought processes that you may wish to work through in selecting the most appropriate to your needs.

Original Article can be found at www.msexchange.org

Leave a Comment