... because the H/W components performing this are sooo fast!
as
"Johnson, Tracy" <[log in to unmask]>@RAVEN.UTC.EDU> on 01/12/2000
04:38:34 PM
Please respond to "Johnson, Tracy" <[log in to unmask]>
Sent by: HP-3000 Systems Discussion <[log in to unmask]>
To: [log in to unmask]
cc:
Subject: Re: [HP3000-L] Mirrored Disk vs. Raid
So if RAID 5 has to go through extra processes to
recover, why do pundits think it's so wonderful?
Tracy Johnson
MSI Schaevitz Sensors
-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]]
for MPE:
RAID 1 is a one-to-one mirroring. duplicates disk space and H/W.
RAID 5 uses parity information on one disk. better for disc space
requirements but if a disk fails the missing info must re-calculated for
each byte as part of the RAID H/W.
We had RAID 5 with 3 or 5 disks where 2 or 4 have been used netto (2/3 or
4/5 of named disccap could be used).
RAID 0 is NO RAID (?! but it is named RAID)
RAID 2 to 4 are in between 1 and 5, distinguished by the formular and
stripping methods used accross several disks. I read this a while ago and
could look for more details if needed.
Best regards, Andreas, CSC, Germany
"Johnson, Tracy" <[log in to unmask]>@RAVEN.UTC.EDU> on 01/12/2000
03:35:06 PM
Please respond to "Johnson, Tracy" <[log in to unmask]>
Sent by: HP-3000 Systems Discussion <[log in to unmask]>
To: [log in to unmask]
cc:
Subject: Re: [HP3000-L] Mirrored Disk vs. Raid
I seem to get the opinion in conversations in a
similar vein to the HP3K vs 'x'.
i.e. That mirroring is 'old technology' vis-a-vis
'RAID' and why do I still use it?
Could someone post what all the RAID-n version
differences are?
Tracy Johnson
MSI Schaevitz Sensors
-----Original Message-----
From: Sletten Kenneth W KPWA [mailto:[log in to unmask]]
Sent: Thursday, November 30, 2000 8:43 PM
To: [log in to unmask]
Subject: Re: Mirrored Disk vs. Raid
Several people noticed that "Holloway, Rich" wrote:
> Hp has indicated the low priority is due to plans to drop
> the Mirror/ix product.
Bill Lancaster provided a "non-HP" answer:
> ......... Finally, someone mentioned that HP's plans are to
> eliminate Mirrored Disk/iX. I don't believe that to be the case.
> For one thing, many, many customers use the product.
> Second, there is no good reason to eliminate a product that
> is in wide use and has matured to the point where there isn't
> any active, major development against it. Third, it would raise
> a significant hue and cry. Last, it is an excellent solution,
> if chosen wisely.
Speaking as just one end-user, <bold-face> and <underline>
on "significant hue and cry": Using a little funding we managed
to latch on to before somebody beat us to it, I just bought four
more hot-swap modules with ST39173WC discs for our two
A3312A HASS units; i.e.: We are fully committed to Mirror/iX.
If that product was to "go away" any time while we are still
running our current 959-400, any attempt by me to go to my
managers and ask for what amounts to major $ (for us) to go to
hardware mirroring would have unhappy results:
(1) I would not get the $$.
(2) We would with renewed emphasis again get asked: "How
long would it take to port our in-house client-server app to NT
and SQL/Server ??
While I tend to expect that the real situation is as Bill related it,
I also doubt that Rich pulled "HP has indicated the low priority
is due to plans to drop the Mirror/ix product" out of thin air....
Given the seriousness of the question that has been raised, it
would improve my "comfort level" if someone from HP would
(hopefully) deny that Mirror/iX is going away any time soon...
... Maybe it is the Mirror/*UX* product that is going away (think
I heard / read that somewhere a while back) ????
Back to a technical Mirroring issue....: Bill also noted:
> ........ 2. Keep the production data protected with Mirrored
> Disk/iX but add Model 20 disk arrays to protect your system
> volume set. I already mentioned a concern about this option.
Realizing that it is not an ideal "solution", I came up with what I
would like to think is a "poor man's" improvement over our
current exposure for our non-mirrored and non-arrayed
<long_name>; given that we have two HASS enclosures that
will continue to have at least two out of eight spindle slots empty.
Here's the plan (critical technical reviews gratefully accepted):
Note our current <long_name> "baseline" is four 2GB internal
discs in the 959 SPU cabinet....
(1) Two of the new 9GB hot-swap HASS modules that are "in
the mail" will be kept on the shelf as "hot spares" (after rotating
them through one of our existing mirrored volume sets to verify
they are good). That way if one spindle blows up we can pop
in a good spare while still having one more spare in reserve;
(hopefully) allowing us to leisurely order a replacement spare
(about a grand per module, last reputable-vendor price we got).
(2) The other two new 9GB modules will be installed in two
empty slots in ONE of the HASS enclosures as the new
MPEXL_SYSTEM_VOLUME_SET. After making sure that our
<long_name> is well backed up, I will reconfigure to put LDEV
1 and LDEV2 on those two external 9GB drives in the one
HASS enclosure (which has the optional second power supply
and both fans); and follow with INSTALL of <long_name> only.
SIDEBAR: Our <long_name> is 99.99 percent "HP pure"; i.e.:
Not only all our user data but also all third-party accounts are
on one of three mirrored user volumes.... so we've only got
6.5 million sectors on our <long_name>.... Plus we have 1792
MB memory, so figure two 9GB spindles will get us by for our
<long_name> (realizing that at least one more spindle for that
would have been nice (which we can add that later if my
guesstimate is wrong and I scrounge a few more bucks) ).
(3) After (hopefully again) successfully completing above two
steps, if any of our spindles in either of the HASS units fails, we
will have two common spares on the shelf. If a <long_name>
spindle failure occurs with that volume resident in HASS, then
figure out whether LDEV 1 or LDEV 2 died; pop in hot spare;
and do quick INSTALL of <long-name> only.
Granted that takes us down for up to an hour or so total (actual
INSTALL time ~15-20 min last time we proactively replaced
<long_name> spindle; when predictive warned it was starting
to have problems (INSTALL much faster the byte-wise disc-to-
disc copy utility) ). While this won't fly for those who absolutely
cannot tolerate being down for even one hour during the day,
given expected frequency of 9GB spindle burn-out and the fact
we don't have the $$ for an array anyway, above was best
achievable solution I could come up with in our real world... It's
certainly a whole bunch quicker than waiting up to a day with
the system down for the HP CE to arrive on-site with a new
spindle.....
Ken Sletten
|
