Re: long, boring explanation of minicopy (and HBVS, in general)
From: Phillip Helbig---remove CLOTHES to reply (helbig_at_astro.multiCLOTHESvax.de)
Date: 05/31/04
- Next message: Phillip Helbig---remove CLOTHES to reply: "Re: CA'S INGRES DATABASE TO BE RELEASED INTO OPEN SOURCE"
- Previous message: Alfred Falk: "Cluster disk mount problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 31 May 2004 20:46:21 +0000 (UTC)
In article <1040531030244.3379B-100000@Ives.egh.com>, John Santos
<JOHN@egh.com> writes:
> If you are simply rebooting a node (i.e. for installing an ECO),
> don't dismount anything on the other nodes! (You can do local
> dismounts (DISMOUNT without the /CLUSTER) in syshutdwn.com, if
> you want to, but shutdown.com does this anyway, a little later.)
> Any access to the missing disk(s) should stall in mount-verify
> until the node comes back up, and enables MSCP serving (very early
> in the boot process), and then should resume.
>
> At least, this is true for non-shadowed disks.
Right.
> For shadowed disks, I'm not sure if the surviving nodes put the disk
> into mount-verify when they discover the missing disk, or if they
> immediately kick the missing disk out of the shadow set. I think it
> waits for SHADOW_MBR_TMO seconds (dynamic, default=2 minutes, which
> may be too short for a VAX or a system with a huge amount of memory)
> and then kicks the disk out of the shadow set. So if you don't
> mind brief hangs while accessing (writing, since reading can proceed
> from the other member?) the shadow set, this is probably the way to go.
For a quick, planned reboot, I agree. On the other hand, for a VMS
upgrade (which takes a while), this would be too long. Also, there are
unplanned outages, when the node doesn't reboot after a crash, a disk
goes bad etc.
> Another option is to remove only the locally served disks from
> the shadow-set. If you initially mount the shadowsets (on the
> Alpha nodes) with /POLICY=MINICOPY, then when the VAX dismounts
> its disks (the members, not the shadowsets), then the Alphas
> should create write bitmaps for the VAX disks, and then do a
> MINICOPY when the VAX reboots and adds its disks back into the
> shadowsets. (Not sure if you have to say "/cluster" or if this
> is implied when you remove a disk from a shadowset, since it makes
> no sense to me to have or for VMS to allow different shadowset
> membership on different nodes.)
Reading HELP, it appears that the proper DISMOUNT command is enough.
However, as I mentioned in my previous post, there seem to be several
confusing points. Also, if the MINICOPY couldn't have been done, I
would have expected my MOUNT command to fail, as HELP says.
- Next message: Phillip Helbig---remove CLOTHES to reply: "Re: CA'S INGRES DATABASE TO BE RELEASED INTO OPEN SOURCE"
- Previous message: Alfred Falk: "Cluster disk mount problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
