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
Storage Architecture Design
Before we get started it is useful to briefly cover some of the supported Storage Architectures for Exchange 2010 and 2007.
Even if you choose the best sized RAID level to your needs – if you have not selected the correct hardware which the RAID infrastructure sits upon then you will not realize any benefits within your investment.
Direct Attached Storage:
This is the traditional type of storage that comes with most servers. In essence – storage is directly attached to the server via SCSI or SATA –via a supported hardware RAID or SCSI controller.
DAS will normally support all RAID types which are relevant to Exchange, and is found mainly being used for basic Exchange servers (e.g. with no DAG or HA) or for dedicated DAG nodes (in the case of Exchange 2010).
Disk Performance with DAS normally ranges from good to excellent (this also depends on the type of disks that you use in the enclosures and the RAID configuration).
SAN Storage – SCSI, iSCSI or FC-AL
SAN storage is typically made up of external storage enclosures which are made available to the host computer via SCSI interconnects, iSCSI or fiber channel.
SAN is usually found in “clustered environments” disk is shared between a number of machines which are dedicated to Exchange server.
In Exchange 2007 it would be unlikely that if you were using a clustering technology such as CCR you would have a SAN array per node, in the case of Exchange 2010 the same principle applies to DAG nodes – you would not consider having a SAN on a per node basis.
The Performance SAN Storage which is connected via SCSI varies from good to excellent.
However in the case of iSCSI to maintain the performance edge you should be looking to isolate the IP packets which encapsulate the SCSI protocol from the wider LAN (e.g. by using a dedicated network backbone or VLANS).
Physical Disk Technologies
Broadly these fall into the following categories – SATA (Serial ATA), SAS (Serial Attached SCSI), and more recently Solid-State (SSD).
There is a very good overview of Disk types included here but suffice to say and on balance (if you are looking for a good trade-off between cost and performance) you might be looking at 2.5-inch SAS drives rated at a minimum of 10,000 RPM.
As a point of note, the article suggests that 2.5 SAS drives offer poor capacity – however HP, for example make drives in this form factor rated at 600GB which is not too bad.
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 via the disk subsystem to the other, 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.
When using RAID 1 you should always consider using disks of the same size within the Array (as the available space will be dictated by the smallest available disk – and considering that you will lose 50% of the overall space available, therefore having different sized disks only increases wasted space and ultimately cost).
Figure 1: RAID 1 Simple Example
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)
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.
Figure 2: RAID 5 Simple Example
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 and 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
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.
Figure 3: RAID 10 Simple Example
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 and 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.
