Search Term Tuesday: June 17th Edition

by dave on June 17, 2008

Typical RAID 10 setup.

Image via Wikipedia

Having missed last weeks Search Term post (which actually was a good thing), I decided to delve deeper into the search term logs and see what the top reoccurring searches were for this week. Imagaine my suprise (or not) when I found that RAID and RAID group expandability was a consistent theme. To that end, let’s begin our overview.

Search Term #1: RAID 1 Group Expansion

I really shouldn’t be too suprised by this search since it typically will fall under our Microsoft SQL best practices layout for TempDB and Log files.  So, can you expand a RAID 1 group?

There are two direct answers to this and honestly, it really depends on how your array was designed to begin with.  If you designated that a pair of spindles should have a RAID 1 group created across them, you cannot expand that RAID group without migrating it off the spindles, destroying the originating RAID group, and recreating it as a RAID 1/0 (aka RAID 10). Now, if you took the other approach and started the RAID group as a RAID 1/0 (even with 2 disks), you can simply add in other drives to the set in pairs.  Remember, RAID 1/0 must expand in a minimum of 2 disk increments!!!

Search Term #2: RAID 1/0

Following up on the previous search term, I thought I’d jump into the basic reason(s) why you’d choose RAID 1/0 (or RAID 10) over RAID 1.

The first reason to choose RAID 10 over RAID 1 is based on expandibility. If you’re designing for SQL storage, for example, and not planning on doing TempDB or Log management, you’re going to need to allow for ongoing growth of those two critical SQL components.  Additionally, under the highest profile for performancing that Microsoft allows for, RAID 10 and striped MetaLUNs play a crucial part.  In that design, you’d have two 3+3 RAID 10 sets with a LUN striped across both for maximum reads/writes. A second reason for choosing RAID 1 over RAID 10 would be the primary protection of data. In a 1-to-1 disk scenario, rebuild is quick, and drive replacement rather simple.  That being said, you’re limited to the drive performance based on the drives you have as a mirrored pair.  For most db admins, this isn’t a critical issue SO LONG AS IT DOESN’T AFFECT RELIABILITY.  Performance, of course, is paramount, but, data reliability much more so. The third reason for choosing RAID 10 over RAID 1 would be the performancing requirements of your application. We touched on this briefly in reasons #1 and #2, but it does need another hard look. When we take performance monitoring statistics (PerfMon to the initiated. 😉 ) for your application sets, we’re looking to see the relative IOP need of that application during the course of a typical business day.  If we notice reads are more prevalent than writes, we’re going to route our design work a certain way.  If writes are more critical to your applications performance (think OLTP or PACS/DICOM writes), we’re going to design for the maximum write performance (RAID 10) with expandibility (striped MetaLUNs).  Make sense?

Zemanta Pixie