[Info-vax] Shadow System Disk between two Hosts

[George Cornelius]

Phillip Helbig---undress to reply wrote:
> In article <joss11$448$1 at news.belwue.de>,
> gartmann at nonsense.immunbio.mpg.de (Christoph Gartmann) writes: 
> 
> 
>>according to the manuals it should be possible to shadow a system disk between
>>two nodes. 
> 
> 
> If you have the proper hardware.
> 
> 
>>I have to Itanium boxes, connected via ethernet and forming a
>>cluster under OpenVMS 8.4. Currently each has its own system disk. Is it
>>possible to have these disks form a shadow set and still have each node boot
>>from a single member of this disk?
> 
> 
> A system ALWAYS boots from a single member of a shadow set.

Except satellite nodes - see below.

>                                                              The shadow
> set is then rebuilt early in the boot sequence.  (I recommend specifying 
> two shadow members in a list as the boot device.  I don't think more 
> than 2 is possible (might depend on the console firmware), though of 
> course a shadow set can have more than 2 members.)
> 
> I prefer a system disk for each boot node (shadow sets, of course) since 
> one can then test things out on one system while the other continues to 
> run.  If you want to avoid maintaining more than one system disk, in 
> your case I would recommend configuring one as a satellite.  Your 
> cluster won't work unless both members are up anyway (unless you have a 
> quorum disk).  (Well, you could give one machine a majority of the 
> votes, but then it will always have to be in the cluster, so it then 
> isn't very flexible.)
> 
> To have two boot servers boot off the same disk, you have to have a disk 
> which can have two controllers connected to it, or perhaps some sort of 
> SAN.

In the old CI and DSSI hardware days, a single shadow set as a
shared system disk was a reasonable, and desirable, configuration.

Under SCSI clustering, it was possible but perhaps less robust, even
with HSZ series storage controllers on the shared SCSI bus.

Now with SAN controllers, we're back to having a very good way to
share.

But two hosts with one system disk shadow member on each host is
guaranteed to cause you trouble.  Even if you do find a way to
make it work, every time you find another way it can fail you'll
be saying, "And why did I think I wanted to do this?"

The fly in the ointment is that as soon as one node goes down,
its local shadow member becomes stale.  If you do manage to boot
to it, you will be punished when you try to join the cluster,
with the likely outcome being a "shadow member incompatibility"
crash.

And you do not have an option of booting to a remote shadow set
except as a satellite node - booting via a network from a remote
host.  Note that this can probably be made to work, since you
can likely start a shadow copy on the satellite node to add
its shadow member back in after booting.  An assymetric
configuration, and the boot situation must be reversed if the
boot node's shadow member ever fails.  [Hmm.  Can a boot node
on the fly be converted to booting off one of its own satellites
just by configuring the satellite as a boot host? Inquiring minds
do ... or maybe don't ... want to know.]

George