Original Question:
We have an AlphaServer 4100, running DEC Unix 4.0B, functioning as our
Oracle server.
It has two HSZ50's attached controlling two RAID-5 arrays... (One
controller per array.)
We're planning on adding redundant controllers but we're questioning the
use of RAID-5.
Essentially, we've been reading that Oracle would perform better on
RAID-0+1.
We have no problems with ordering more drives and redoing the arrays...
But what we're worried
about is that if a drive fails, won't someone have to be around to break
the mirror? Is there
any way to have things failover to the functional mirror automatically?
(The only mirroring
experience I have is software level on Solaris...)
Decision:
With all the info you guys sent me, I've been able to convince management
(and myself) to convert our exisiting
RAID5 strings to RAID0+1. Since our Oracle database will be one of those
creatures that ends up with a lot of
writes to it, RAID0+1 will increase out performance... Now at least I
don't have as much to worry about if a drive
fails! Thanks for all your help...
Answers:
From: PabiaM_at_war.wyeth.com
You are right about raid 0+1 compared to raid 5. During our pilot
where we used a Sun E10000 with Storageworks HSZ50
controllers, we found out that raid5 was a bottleneck. We are
currently using raid0+1. The HSZ70 controllers are even faster
with raid0+1.
The spareset disk you define is going to be used as a spare for
both raid5 disks and any mirrored disks. So if a mirror member
fails, the spareset kicks in automatically.
Max
-----
From: alan_at_nabeth.cxo.dec.com
In the event of an unrecoverable I/O error on a drive
in a mirrored array, the controller will take care of
removing the offending member. If you have any spare
drives and they're set up correctly, the controller
will add the a spare to the reduced array and start
copying the data.
If you mirror the drives in software using LSM, it
tends to be more optimistic about a drive's chances
of recovery and will tend to keep the drive around.
On reads, if the failing drive can't return data, then
the other drive will be used. On writes, it may eventually
have to give up and remove the drive, since keeping the
array consistent is paramount.
-----
From: i769646_at_smrs013a.mdc.com
If you are using controller-based mirroring, the failover to the mirror
device is automatic. Additionally, if you have extra spindles in the
cabinet configured in the "spareset", when the controller detects a
drive failure it will remove the failed device from the mirrorset, mark it
into
the "failedset", select a device from the "spareset" and configure it into
the
mirrorset and begin a mirror copy -- all without any human intervention!
When your friendly, local technician replaces the failed device, THEN a
human must remove the "spareset" device from the mirrorset and bring the
replacement back into the mirror (I would just configure the replaced drive
as
the only device in the spareset and force the original spareset drive into
the
failedset and let the controller take care of the rest. After the
controller
brings the replaced drive back into the mirrorset you can move the drive in
the
failedset back into the spareset and it will be ready to replace the next
failed
device.)
--CHRis
========================================================================
Chris H. Ruhnke Phone: (314)233-7314
IBM Global Services M/S S306-6340 FAX : (314)234-2262
325 J.S. McDonnell Blvd Email:
i769646_at_smrs013.mdc.com
Hazelwood, MO 63042
-----
From: GGuethlein_at_GiantOfMaryland.com
The following <<SNIP>> is a reply I sent to another maillist
user. It contains much info relevant to your question.
<<<<<<<<<<<< SNIP START >>>>>>>>>>>>>>
My understanding is that , in general, hardware mirroring
and/or striping is faster. I believe this is because of the
caching built into the controller. You also free up CPU
cycles that would otherwise be required for the LSM software
to work it's magic.
OTHER CONSIDERATIONS :
What is your complete physical configuration? Will the
drives be on separate controllers (ie. different I/O channels)?
How about the nature of the data? Will you mostly read it, or
write it? What would better work for Oracle (1 or 2
filesystems) and/or your needs?
CONCERNING YOUR FIRST STATEMENT :
"running on hardware striping and LSM for mirroring."
I'm assuming (Yes, I know about ass-u-me) that you are
using RAID0 (disk striping) and RAID1 (disk mirroring). The
preferred method is to create mirror pairs and then stripe
across them. This reduces your risk of data loss (-VS-
striping and then mirroring) by reducing the number of disks
that have to fail to prevent access to your data. There is no
other performance difference, as you still generate the same
number of I/O's.
This information comes from "The RAIDBook", published by
"The RAID Advisory Board". It has been my bible for working
with RAID and LSM. You should get your hands on a copy if
you can (try your vendor, that's where I got mine).
We use Informix in our shop, which has a 2GB DBSpace
limitation. I implemented a RAID Array 410, using 4GB
drives, as follows :
1.) created 3 mirror pairs across internal RAID channels
2.) created 1 stripeset across the 3 mirror pairs
3.) passed the 12GB unit to Unix
4.) used LSM to create 6 x 2GB volumes
5.) fed the 6 x 2GB volumes to Informix as raw partitions
6.) created multiple Informix DBSpaces in each raw partition
by using offsets within the create DBSpace command.
This has been very effective in an PeopleSoft system & never
experienced an outage.
Hope this information helps you out. If you can't get the
RAIDBook (and have some specific questions) let me know.
If I can find the answer, I can fax you the text.
<<<<<<<<<<<< SNIP END >>>>>>>>>>>>>>
Specific to your question, Lisa:
1.) I have an 8400 that uses LSM (software) for mirroring.
On that system I DO have to manually break the mirror pair,
replace the failed disk, relabel the disk, put it back into LSM
and then re-mirror the LSM volume. Then life is good again.
2.) I have a 4100 running dual-redundant SWXCR's (HSZ40's
I think ??) in a RAIDArray 410 (described above in steps 1-6).
By default, the controllers have a "SPARESET". I put two
extra drives (on different I/O pathways) in the RA410 and
assigned them to the "SPARESET". When a data drive fails,
one of the "SPARESET" drives will automatically be moved
in to replace it. This maintains your mirror pair, and therefore
your data availability. You can simply replace the failed drive
and a.) add it to the SPARESET, or b.) re-optimize your
system by manually moving the data back to its original
location. There are autopage features and other bells &
whistles too (but I havn't had time to research them).
3.) DEC mirroring, at least with LSM (software) isn't like
other vendors mirroring. For instance, IBM (and it sounds
like Solaris) "mirroring" only lets you get to the mirror copy of
the data if the primary copy fails (IS THIS CORRECT ?).
DEC's LSM mirroring (better referred to as "SHADOWING")
allows you to access both halves of the mirror pair for reads.
The drive you use depends on which drive head is physically
closer to the block of data to be read, and the "preferred read
path" that you assign. I **think** this holds true for the DEC
hardware-based mirroring too. At least, the hardware-based
mirroring should automatically allow access to the other data
disk (Or what would be the benefit of it ?) {That last sentence
is my own reasoning !!!}
I hope this info helps you out. My offer for more info still
stands. Let me know if you have more questions, and I'll try
to help.
-----
From: DINMAN_at_aladdin-asi.com
We have and 4100 with 4.0.b and two HSZ50's as well. We are running
PROGRESS databases with RAID 0/1 (mirroring at the hardware level thru the
HSZ50's as well as striping thru the HSZ50's)
We have been told by multiple sources that PROGRESS databases do not like
RAID5. The mirroring takes up more drives but works like a charm.
Essentially we have the 2 HSZ50's setup to share the IO load with failover
so that if one controller fails, the other one picks up the full load with
no interruption in service. We have each disk mirrored and have made sure
that the primary disks are on one controller and the mirror disks are on
the other controller. In addition the HSZ50's let us configure a hot
backup disk on each controller.
I heartily recommend taking full advantage of the HSZ50's for mirroring and
striping. That relieves the load of mirroring from your CPU. DEC has a
really fine configuration tool SWCC (Storage Works Command Console) for
either a graphical or command line configuration interface. Download it
free from DEC.
Also we maxed out the cache on both controllers to 128meg. Please note
that the firmware on both HSZ50's must be identical versions for the
redundant/shared setup to work.
Dale
-----
From: Zieglerr_at_novechem.com
Nope. You can have a 'hot spare' defined and it'll be managed for you.
-----
From: rrodgers_at_ci.ft-wayne.in.us
If you are using HSZ50s you can define striped mirrorsets. You should have
disks defined in a SPARESET that are used to automatically rebuild the
mirror in the event of a disk failure. BTW...be sure to define the
stripesets across HSZ50 ports. If you attempt to define a stripeset that
uses 2 disks on the same port the controller software will tell you this is
bad for performance.
Randy Rodgers
Senior Systems Programmer
Allen County Information Systems
RM B16 - City/County Building
One Main Street
Fort Wayne, IN 46802
(219) 427-5727
rrodgers_at_ci.ft-wayne.in.us
-----
From: smullin_at_gecits.ge.com
Call it "RAID" not RAID 5 in DEC's case. They have code that is "dynamic"
and flips to RAID 3 at init time depending on your # of disk, chunksize
etc....
I've benchmarked it, it's very fast, very minor perf hit. I did a straight
write for ten minutes cost me an extra 40 seconds if I remember right
against the same UN-mirrored stripe.
I LSM mirror DECs raid containers, it's self healing. Think about a mirror
never failing AND self healing when a unit fails...sounds like EMC doesn't
it? { ' : > (Yes, EMC has BIG Cache, but get more system memory and use it
dynamically with UBC/SGA tuning)
17 HSZ52's-256mem_cache, LSM mirrored (8 sets), DEC Raid, 6 RZ1CB disk
each, 2 sparesets disk per HSZ52 64 chunksize (SAP / Oracle ) 256 transfer
size And a few other JBOD mirrors here and there.
Sincerely,
-Stephen
g GE Capital
Information Technology Solutions WISE Project
________________________________________________________
Stephen Mullin phone:_____ (770)300-3373
WISE Project (SAP) dialcomm:____ 8* 270-3373
smullin_at_gecits.ge.com
________________________________________________________
-----
From: sanghvi_at_proto.wilm.ge.com
We are running 100gb+ oracle database under Raid 5
and have not noticed any I/O bottleneck.
Arun Sanghvi
GE-Nuclear Energy
Received on Fri Jun 19 1998 - 15:54:16 NZST