Hi,

We're going to be purchasing a database server from IBM. Although the
database itself will be housed on a 10-drive SCSI-based external storage
unit, the operating system will reside on two drives housed in the server
itself. The drives will be mirrored (RAID 1). I noticed that the server
quote makes no mention of a RAID card to handle these two drives so I asked
our sales rep about it. He stated that RAID for the O/S volume will be
handled "in the software."

I need to get a handle on exactly what this means. It seems to me that
if RAID is handled by software, the CPU would have to get involved each time
a read/write occurs to this volume. I was hoping to keep the CPU focused on
SQL Server without it getting distracted by handling the RAID mirror. The
sales rep makes the case that most of the O/S is loaded into memory at
startup anyway so there shouldn't be too much reading/writing to the O/S
volume in the course of the day. I do buy his argument, but I figured I'd
get your opinions first to see if what he's saying is in fact correct.

Thanks,

Hulio

[ Post a follow-up to this message ]

The One We Call 'Dave' wrote:
> Hi,
>
>     We're going to be purchasing a database server from IBM. Although the
> database itself will be housed on a 10-drive SCSI-based external storage
> unit, the operating system will reside on two drives housed in the server
> itself. The drives will be mirrored (RAID 1). I noticed that the server
> quote makes no mention of a RAID card to handle these two drives so I aske
d
> our sales rep about it. He stated that RAID for the O/S volume will be
> handled "in the software."
>
>     I need to get a handle on exactly what this means. It seems to me that
> if RAID is handled by software, the CPU would have to get involved each ti
me
> a read/write occurs to this volume. I was hoping to keep the CPU focused o
n
> SQL Server without it getting distracted by handling the RAID mirror.

About the only conditions where the CPU would be significantly
'distracted' by handling the mirroring would be after one of the disks
failed and it was rebuilding a new replacement.  Otherwise, any
additional overhead on reads should be virtually undetectable, though
for writes the CPU will have to coordinate two disk accesses in parallel
rather than the single access it would perform to a hardware-supported
mirror.

The
> sales rep makes the case that most of the O/S is loaded into memory at
> startup anyway so there shouldn't be too much reading/writing to the O/S
> volume in the course of the day.

As noted above, save for active restoration of a failed disk the only
overhead that should be noticeable at all is for write operations.  If
the system is paging its little heart out then the additional write
overhead could start to become an issue, I suppose - but then again if
it's paging that frantically you've got far worse problems to worry
about.  Otherwise, writes to the system disk likely shouldn't be
frequent enough for it to matter much, so software mirroring sounds like
inexpensive but effective insurance.

- bill

[ Post a follow-up to this message ]

Software RAID normally refers to RAID algorithms implemented by the
operating system (Windows server O/S's can handle RAID1 & RAID5 from
memory, XP can handle RAID1 only from memory).  If that's indeed what
the sales rep is talking about then I fail to see how that's possible
for the OS itself.

Many servers (I haven't checked out any offerings from IBM) come with a
RAID controller on-board (a hard-wired board or IC on the motherboard
itself) and don't need a daughter-board card to implement RAID for the
internal drives.  This is often called ROMB ("RAID on main-board" or
"RAID on mother-board").  Perhaps this is what the rep is talking about.

In any case, the only RAID calculation that is CPU intensive is writes
across stripes (especially with parity) - so we're talking RAID5
particularly (and RAID 0 to a lesser degree I think).  If you're just
mirroring the volume then "in-software" RAID can often be just as good
as hardware RAID.  This is, in fact, a strategy sometimes used for data
volumes - to create two RAID 0 stripes (of the same size) with a
hardware RAID controller and then mirror those two volumes with the
operating system RAID to get a good RAID 1/0 volume with very basic RAID
algorithms.

--
*mike hodgson*
http://sqlnerd.blogspot.com



Bill Todd wrote:

> The One We Call 'Dave' wrote:
> 
>
>
> About the only conditions where the CPU would be significantly
> 'distracted' by handling the mirroring would be after one of the disks
> failed and it was rebuilding a new replacement.  Otherwise, any
> additional overhead on reads should be virtually undetectable, though
> for writes the CPU will have to coordinate two disk accesses in
> parallel rather than the single access it would perform to a
> hardware-supported mirror.
>
>  The
> 
>
>
> As noted above, save for active restoration of a failed disk the only
> overhead that should be noticeable at all is for write operations.  If
> the system is paging its little heart out then the additional write
> overhead could start to become an issue, I suppose - but then again if
> it's paging that frantically you've got far worse problems to worry
> about.  Otherwise, writes to the system disk likely shouldn't be
> frequent enough for it to matter much, so software mirroring sounds
> like inexpensive but effective insurance.
>
> - bill

[ Post a follow-up to this message ]

Mike Hodgson wrote:[vbcol=seagreen]
> Software RAID normally refers to RAID algorithms implemented by the
> operating system (Windows server O/S's can handle RAID1 & RAID5 from
> memory, XP can handle RAID1 only from memory).  If that's indeed what
> the sales rep is talking about then I fail to see how that's possible
> for the OS itself.
>
> Many servers (I haven't checked out any offerings from IBM) come with a
> RAID controller on-board (a hard-wired board or IC on the motherboard
> itself) and don't need a daughter-board card to implement RAID for the
> internal drives.  This is often called ROMB ("RAID on main-board" or
> "RAID on mother-board").  Perhaps this is what the rep is talking about.
>
> In any case, the only RAID calculation that is CPU intensive is writes
> across stripes (especially with parity) - so we're talking RAID5
> particularly (and RAID 0 to a lesser degree I think).  If you're just
> mirroring the volume then "in-software" RAID can often be just as good
> as hardware RAID.  This is, in fact, a strategy sometimes used for data
> volumes - to create two RAID 0 stripes (of the same size) with a
> hardware RAID controller and then mirror those two volumes with the
> operating system RAID to get a good RAID 1/0 volume with very basic RAID
> algorithms.
>
> --
> *mike hodgson*
> http://sqlnerd.blogspot.com
>
>
>
> Bill Todd wrote: 

We are running IBM servers, and I think it's standard that they comes
with a RAID controller for the build in disks. At least that's what we
get with all the servers we're using and I don't remember that I've ever
specifically specified that it should be with a RAID controller.

Regards
Steen

[ Post a follow-up to this message ]