SUMMARY: DiskSuite RAID's across machines

G'day folks,

(Here's the second of my delayed summaries <grin>)...

First, here's my original question:
>We have recently built a machine with 2 internal disks (fully mirrored) and
>an external SCSI enclosure (6 disks, 4 in a raid5 - with 1 hot spare and 1
>"blank").  At present, there are metadbs on all 8 drives - with the two
>internals each having 4 copies (so that the box can boot without the
>external enclosure) and the externals 1 each (for a total of 14 replicas).
>
>Now, the client wants a second machine setup to mirror (no pun intended) the
>configuration of their production box.  But, here's the kicker - we have to
>use the same external enclosure.  So, is there some way to tell the second
>machine about a raid5 without having to reinitialise the disks if/when we
>plug them in (losing 50+GB data is not an option <grin>).
>
>Also, I'm interested in people's comments about the setup of the metadbs.
>Is there a better way?  We can't just put replicas on the external enclosure
>(as whichever machine doesn't have it won't boot).  We can't just put them
>on the internal disks in case of failure.

Considering the content of some of the responses I got, I could probably have
been a lot clearer in my original posting.  Let me clarify a few things:
	The two machines, A and B, are not networked together in any way.
	Machine B will be a "hot-swap copy" of A, kept locked away in another
	building so it can be put in place quickly if A should fail.
	The enclosure housing the raid is just a desktop multi-pack, not an
	A1000 or similar.
	We only have DiskSuite, not a full-blown install of Veritas,
	available.

Okay, so here's how to do it...  RTFM.  :-(  Moving a raid from one machine
to another is simply a matter of remembering to use the '-k' switch to
metainit when the raid is defined the second time.  There is a major caveat
with this as DiskSuite will "mark" the raid as OKAY even if it crashed
horribly on the other system.

Now, for the second part of my question - and this is where things get very
tricky.  How to spread out the database replicas to try and ensure maximum
availability.  Here again, the purpose of each machine has to be borne in
mind - so we have currently only gone with the following:
	2 replicas on each of the 2 internal drives.

Here's the reasoning:
	If the enclosure is unavailable anyhow, the machine won't boot
	multi-user as (at least) one fsck will fail.  This is okay as the
	client will want to occasionally power up the backup system to
	do patching, reconfigurations, etc. to keep it synced with the
	production unit.  They may even use a "swap" approach wherein they
	make the changes on the backup and do a quick change-over at a
	convenient time - temporarily reversing the roles of the two
	machines.
	If an internal drive fails, it will need to be replaced anyhow,
	meaning the current fallback machine can fulfill its role in the
	Contingency Plan.
	If both happen, there has been a major catastrophe of some sort. 
	They will go back to backups with other disks, etc.

	We can't put database replicas on any of the external drives to
	assure the 50%+1 rule of availability as they couldn't tell me
	just how they were going to maintain the drives setup.  Remember,
	there's a raid, a hotspare and a "blank" but that may change at any
	point.

And, one important point to remember with database replicas is that their
placement is truly dynamic - in that, so long as you have somewhere to put
them, you can add/delete them at any time.  The above setup may change over
time.

Oh, just to complicate things a little further, the disks in system B are not
the same size as those in A - they're not even the same size as each other.
Does anybody know exactly what information DiskSuite 4.2.1 (these are Solaris
8 boxes) keeps in the database replicas?  Another concern I had about putting
replicas on the external drives was that some sort of sizing information may
have been written as well as state data (which could lead to corruption of 
the mirrors on the internal drives).

If anybody wishes to discuss the pros and cons of replica placements, feel
free to drop me a line off-list.  We could always submit a post-discussion
SUMMARY back to the list.

As always, thanks for your time folks - in particular, kudos to Shridar
Bachu, Hichael Morton, Kevin Buterbaugh, Colin Bigam and Craig Burtenshaw.

Ciao.

-- 
-------------------------------------------------------+---------------------
Daniel Baldoni BAppSc, PGradDipCompSci                 |  Technical Director
require 'std/disclaimer.pl'                            |  LcdS Pty. Ltd.
-------------------------------------------------------+  856B Canning Hwy
Phone/FAX:  +61-8-9364-8171                            |  Applecross
Mobile:     041-888-9794                               |  WA 6153
URL:        http://www.lcds.com.au/                    |  Australia
-------------------------------------------------------+---------------------
"Any time there's something so ridiculous that no rational systems programmer
 would even consider trying it, they send for me."; paraphrased from "King Of
 The Murgos" by David Eddings.  (I'm not good, just crazy)
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers