Setting up RAID arrays for Small Business Server …

I wrote this a long time ago, but it still holds true today …

Windows Small Business Server is an extremely popular complete operating system for small to medium business throughout the world. It contains most applications that a business requires in a simple to install and manage package.

This article concentrates on the storage needs of SBS, in particular creating the correct RAID arrays to get the best performance and flexibility from your system. It goes without saying that you require a system with sufficient CPU and memory capacity, but that information can be provided by any system integrator.

Horses for Courses … different raid types for different types of data

While there are many different “types” of RAID arrays, they fall into two basic categories … Parity and Non-Parity RAID arrays. Each has their benefits and detractions, with each type being suited to different kinds of data.

Non-parity RAID

Non-parity RAID can be simply defined as RAID 1 (mirror), RAID 10 (stripe of mirrors) and RAID 1E (stripe of mirrors on odd numbers of disks).

The benefits of non-parity RAID is that they have very good write speeds, especially for small data writes. This makes them very well suited to support Operating Systems and any kind of database files.

The downside to non-parity RAID is the cost … they take up considerable disk space. For example a RAID 1 (mirror) gives 50% usable space from the disk drives (2 drives gives 1 drive space).

Parity RAID

Parity RAID can be simply defined as RAID 5 (distributed parity capable of surviving single disk failures), RAID 6 (distributed parity capable of surviving 2 disk failures) and RAID 5EE – a different kind of RAID 5 that contains both parity data and hot spare disk space.

Parity RAID is the great all-rounder of RAID arrays. RAID 5 is generally good for most types of read and writes, and gives quite good streaming write speeds, but it suffers from performance problems when writing small amounts of data (such as database and operating system writes). It is the most economical of RAID arrays in that the equation for capacity is N-1 (you lose one disk’s worth of capacity). For example, 3 drives in a RAID 5 will give 2 drives worth of capacity. 10 drives in a RAID 5 will give 9 drives worth of capacity.

Hot Spare Disks

A hot spare disk is a hard drive that does not contain data, but is simply spare to the system. When a drive fails a hot spare disk will “kick-in” and replace the failed drive, rebuilding all the RAID arrays affected by the disk failure in as short a time as possible.

This is very important. It minimises the time in which the system is at risk of a second drive failure (which in most cases would cause data loss). The system rebuilds automatically putting the RAID arrays back into a safe state, allowing the administrator time to source and replace the failed drive.

So if there is room in the system, and the customer can afford the implementation, then put a hot spare in the box. Especially if the customer site is well-away from an easy supply of hard drives (remote location), it makes a great deal of sense to have the hot spare kick-in and rebuild the array as quickly as possible, giving the system administrator time to source that replacement drive and re-implement a hot spare.

Different types of hard drives

The two basic types of hard drives available on the market today are SATA and SAS. For the sake of this exercise I’ll ignore SSD because of the price … people who are using SBS are doing so because it’s quite cheap … so it seems a bit silly to put really expensive SSD drives in the box.

SATA drives are cheap, fairly reliable and have a large capacity. They are commonly found in desktop and laptop systems, and are now finding their way into servers because of price and capacity requirements. The thing to note about SATA drives is their inability to do many things at once. They are single-tasking devices with fairly slow response times … in other words they are great for streaming but in database applications they suffer from not being able to react at the speed of their more expensive cousins.

SAS drives on the other hand are smaller, much more expensive and very much faster. SAS drives are excellent for database and operating system work because they do multiple things at once (multi-tasking) and have very fast response times. In other words they react very quickly to the small reads and write requests from databases.

Different types of drive controllers

Inside all servers is (or should be) a RAID controller. A RAID controller gives a system the ability to survive drive failures without losing data, and allows a system administrator to create different performance sections within the one system.

RAID is a compromise between performance, reliability, cost and capacity (pick any 3). While I say it is a “compromise” I don’t mean this as a detraction. RAID controllers are essential to server systems to ensure continuity of data to an organisation (and help minimise expensive system downtime).

Some manufacturers create RAID controllers that connect only SATA hard drives (SATA controllers). These are limited in the number of drives they can attach to and will only work with SATA drives.

Adaptec RAID controllers are “SAS” controllers. This means they talk to SAS drives AND SATA drives. In fact you can connect both SAS and SATA hard disks to the same RAID controller. This gives great flexibility in building a system by using drive types that suit your data needs, but we’ll talk about that later.

The components of SBS

These can be fairly simply defined as:

The Operating System

Of course there may be other specialised applications a user runs on Windows SBS, but for the moment we’ll concentrate on the components that come with the standard install package.

Why is this an issue? The different components of SBS have different data characteristics. You can basically put them in two categories … database-type data and general-purpose or “streaming” data.

With SBS the operating system (Windows Server), Exchange and SQL all have database-type characteristics … many small read and writes to the underlying disks in a completely random manner.

The data portion of the disks (Word, Excel, Powerpoint, customer data) are generally less dependent on speed, with large capacity being much more of an issue to the system administrator and end-user.

Basically, with SBS, what you want is a disk structure that is good for database, AND a disk structure that is good for general storage … however they are not the same thing.

Building RAID arrays … the old and new ways of the world

In the past, and still with many of our competitors, the building block of a RAID array was a complete disk drive. This meant that if you wanted to create a mirror of 2 x 250gb drives, the mirror consumed both drives completely and no space was left on the drives for any other use.

Similarly, a RAID 5 on 4 disks used the complete space of all 4 disks … giving no flexibility to the system builder do anything else with those drives.

Now if you had an unlimited number of hard drives to play with then this would not seem much of a problem … however that is not the economic or practical reality of building computer systems today.

Adaptec RAID controllers use a different methodology to building RAID arrays. Instead of the basic building block of the array being a complete drive, it is now a portion of the disk (being whatever size portion you want to use). This is commonly called a “container”.

Therefore a RAID array on an Adaptec RAID controller can be made up from small containers on different hard drives. It is possible to create different RAID types on the same set of disks using this approach.

For example … if I had 4 hard drives in my 1U server, I could create a RAID 10 of say 50Gb capacity across all 4 hard drives. This would in fact use only 25Gb from each of the hard drives. The rest of the space on the drives can then be utilised by the RAID card to create other RAID arrays (of the same or different types).

Putting this all together … the problems

SBS is an unusual software package … it places demands on a system for both database and streaming-type data, generally on lower-end server system. By its very nature Microsoft have created a system that users see as being a cheaper solution than purchasing all the individual components, with many users carrying that cost saving mindset across to the hardware that the system is installed on.

This pretty much means SATA disks. While SAS disks would be much better, they are generally too expensive for the type of customer who is installing SBS, especially if the customer is looking for capacity as well as performance.

While I have nothing against SATA disks, and they are perfect for streaming and general-purpose data, they are not ideally suited to database applications. Now as we have read before, SBS has some applications that have database-type read and write characteristics, and some applications that are much more general in nature.

This means that running SATA drives puts the database components at a disadvantage. To counter this it is essential to run these components on a non-parity RAID array (preferably a RAID 1E or RAID 10).

However, RAID 1E or RAID 10 consume a great deal of disk space (50%), which makes them much less suitable for the general data storage that comes with the majority of the customer’s data.

So here is the problem.  What we really want is SAS drives running non-parity RAID for database applications, and SATA drives running parity RAID for general data storage. All of a sudden to get the best performance and flexibility from your SBS system you need to spend a lot of money on the server hardware. This flies in the face of saving money by using SBS in the first place.

The solution (or at least one of them)

The majority of users will use SATA drives for their SBS system … price and capacity dictate that this is the most sensible way to go.

So …

Using an example of a server with 4 x 500gb hard drives, the following scenario would be an ideal implementation for an SBS system.

1 x 50Gb RAID 10 array for the Operating System

1 x 100Gb RAID 10 array for Exchange and SQL

1 x 1.2Tb RAID 5 for general data

The benefits of this implementation are:

Both the OS and Exchange/SQL applications reside on a non-parity RAID array (RAID 10). This gives them the best disk performance that can be achieved with 4 disks (while still retaining data safety).

The data volume would reside in the large RAID 5 array. This gives good performance for general file serving, while maximising the capacity of the remaining space on the drives.

Using an implementation like this, a user can get the best of both worlds. High-speed, non-parity RAID arrays for the OS and database applications, and a large parity array for their general fileserving data.

It is important to note that this feature resides on all Adaptec 3, 5 and 6 series RAID controllers. Competitors use a different technique – called slicing, to break a raid array up into different logical volumes (drives) for use by different parts of the operating system. The problem with this approach is simply the fact that the underlying RAID array is the same for all logical drives. So if a user chooses RAID 5 as the underlying RAID structure, then all disks are running on RAID 5 – which as we have read is not good for database. Adaptec have taken the approach that the RAID structure should be flexible, and a user should be able to match the RAID type to the data structure sitting on those disks.

The problems of growth …

Building a server that will have sufficient storage for a customer for the entire life of the server puts a large financial burden on the initial build of the server … paying for a lot of disks that you aren’t currently using is not a good use of business cash reserves.

So … start with the capacity you require. You can add drives to a system at any time, and expand the RAID arrays on your existing drives to incorporate the new drives. There are, of course, different caveats on this with different RAID types, RAID 5 and RAID 6 are idea candidates for adding drives and increasing the size of the system. (see note at end of this article)

Does this take a long time? … possibly (depends on the size of the disks). Does this mean a lot of downtime? … No. Once the disks are added to the system then it can be restarted and this expansion process completed in the background, while users are working on the system.

But what if I only have 3 disks?

3 disks brings about a slight change of plans to the solution described above. I’m no fan of mirrors … they are safe but not particularly fast, and they only use 2 of the 3 drives available.

In this case instead of the RAID 10 described in my first solution, you would use a new type of array called 1E. It’s basically a mirror on 3 or more drives. A mirror on an odd number of drives? Sounds weird doesn’t it, but it works, and is faster than a mirror because you have more disks working for you rather than the 2 of the mirror. This also works in my above solution because 3 disks will handle the RAID 5 capabilities of general file serving for SBS.

Using different disks types for ultimate performance/flexibility

My ideal solution for SBS (or just about any other server system for that matter), is to both combine RAID types and disk types in the one system. SAS drives are very fast, with rapid response times in database and OS applications. Therefore, my idea solution would be 3 drives with two RAID 1E created on them … one for the OS and another for the database portion of SBS.

I’d then add 3 or more SATA drives in a RAID 5 or 6 to create a large space for general fileserving duties. This combination places the database-type data on fast responding SAS disks, but keeps the cost down for the large capacity file-serving duties of the server.

Card types this works with

Adaptec’s Series 2, 3, 5 and 6 series cards can all create multiple arrays on the same set of disks. Note that the Series 2 (and 6E products) are entry level hardware RAID cards that can’t do RAID 5 or 6, but the Series 5 and 6 can create just about any RAID type you wish on as many drives as you wish to attach.

What happens when a disk dies in this scenario

For the technically-minded folks who’ve made it this far through this blurb, you’ll be wondering … what happens if a drive dies when there are 2 or more arrays on those disks. Nothing unusual or wonderous happens at all. All arrays that are located on the failed drive are impacted but keep running.

When the drive is replaced, or when the hot spare kicks in, all arrays are rebuilt and life goes on as normal.


(It’s always nice to see that word … means the ramble is almost finished) …

Windows Small Business Server and Adaptec RAID controllers make ideal partners. Adaptec’s ability to create different RAID types on the same set of disks helps get the most performance and capacity to enable SBS to fulfil the customer’s needs.

If you learnt RAID 5 years ago then it’s time to go back to school. A lot has changed. Multiple arrays on the same disks … different disk types in the same system … expanding systems on the fly while customers are still working …

Food for thought.


About Neil

Too old for this stuff ... should be out riding the Monster!
This entry was posted in Advisor - Neil, Application Environments, General, Platforms, Storage Applications, Storage Interconnects & RAID, Storage Management. Bookmark the permalink.

One Response to Setting up RAID arrays for Small Business Server …

  1. Jose Hernandez says:

    Thank you for your well written and clarifying article. I have excactly the challenge you describe… it’s actually a Database with FILESTREAM of images and attachments.

    I wanted to ask you if there has been any change in prices that would make an SSD an alternative over SAS.

    Thanks in advance

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>