RAID Controller Failover

On Wed, 12 Nov 2003 12:19:00 -0500, Bill Todd wrote:



Well, to be precise, the performance of RAID-1 and RAID-5 (and the
performance of disks) varies a lot more than those results indicate:
among other things, the use of extensive stable write-back cache and (on
Linux) reiserfs just smooths out a lot of this variation.

I agree, but the point of write-back cache is to improve the performance
that we are looking at. There is no doubt in a cacheless environment that
the performance differences between RAID-1 and RAID-5 are notable.
However, that was not the reason for my testing. The point of my testing
was to see just how much of a difference the caching on both the system
and the controller effected these operations. We have write-back cache on
both the host and the controller.

But it can't completely obscure the fundamentals.

Again, I'm not trying to argue the fundamentals.

write operations (rather than operations like file creation/deletion
where much of the updating is concentrated in a small number of blocks -
parent-directory updates, for example) where all that the large
write-back cache can do is allow the writes to be queue-optimized rather
than coalesced, RAID-1 will out-perform RAID-5 by a factor of around 2.

Agreed.

That might well tend to highlight the differences better (as long as the
database working set significantly exceeded the size of the cache), for
the reasons noted above.

We have run all of our databases with RAID-5 since HP's XP256 has been
around and have never seen performance degregation because of it. With
the amount of cache that come with enterprise level controllers I think
that there are few circumstances that would warrent the use of RAID-1
over RAID-5. Our EVA5000 has 2GB of cache per controller and write-back
was enabled on all disks when I was running my tests.

Jake

be spread out across the same number of disks. RAID-1 is actually RAID-1+0.

Is it a mirror of 2 stripes or a stripe of several mirrors?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com

On Wed, 12 Nov 2003 19:55:02 GMT, Jake Roersma
wrote:



We have run all of our databases with RAID-5 since HP's XP256 has been
around and have never seen performance degregation because of it. With
the amount of cache that come with enterprise level controllers I think
that there are few circumstances that would warrent the use of RAID-1
over RAID-5. Our EVA5000 has 2GB of cache per controller and write-back
was enabled on all disks when I was running my tests.

About the only reason today to run on 0+1 instead of 5 is A) dba
superstition and/or 2) uber protection requirements. Unless you run 3
disk raid groups in raid 5 1 is going to give better protection from
potential failures.

~F

On Thu, 13 Nov 2003 00:43:07 +0300, Maxim S. Shatskih wrote:

be spread out across the same number of disks. RAID-1 is actually RAID-1+0.

Is it a mirror of 2 stripes or a stripe of several mirrors?

Its a striped mirror of one stripe. So if you had 10 striped disks in
RAID-0, then you have 10 seperate striped disks that are mirroring the
RAID-0 stripe.

- Jake

Steve Holly wrote in
:

I'm an IT admin starting to look at building a SAN for my company and
I'm curious if anyone out there can explain how some of the popular
RAID vendors (i.e. EMC, Chaparral, Infortrend) handle failover
(resuming I/O with another RAID controller after one has failed)? I'm
mostly interested in failover on the storage side (as opposed to the
host side).

Specifically I'm interested in knowing if failover is generally
accomplished by a surviving controller taking over the failed
controller's (or failed port's) AL_PA('s) or if surviving controllers
actually alias failed controller's WWN's?

Or is this something that's generally handled at the switch level.

I'm trying to better understand how failover is accomplished
transparent to the host. Many thanks for any input regarding this.



The EMC Symetrix storage units have duplicate everything... duplicate
incomming fibre cards, duplicate bus to scsi cards, duplicate scsi cards,
and duplicate scsi bus to disk arrays.

I believe the state of any redundant scsi cards is kept the same at any
time, even if only one is actually writing. The software is smart enough
to know what is committed to disk and what is not, and so can recover from
write errors. Of course everything is battery backed up.