HBVS, shutdown procedures, dismounting disks, SHADOW_MBR_TMO

From: Phillip Helbig---remove CLOTHES to reply (helbig_at_astro.multiCLOTHESvax.de)
Date: 05/09/04 

Date: Sun, 9 May 2004 20:05:12 +0000 (UTC)

Hobbyist cluster, all disks are physical SCSI disks (or, in one case, an
RF disk on a DSSI bus) MSCP served to all nodes. No SAN, no
controller-based RAID etc. Most of the disks are in shadow sets which,
unless it is the system disk, has members on more than one node. All
disks, whether shadowed or not, are mounted by all nodes in the cluster.

Occasionally, I want to reboot just one node in the cluster. I'm trying
to figure out what disks to dismount before doing a reboot. There are
the following categories of disks:

   A. non-shadowed disks on the node to be rebooted

   B. non-shadowed disks on other nodes

   C. shadow sets with all members on the node to be rebooted

   D. shadow sets with all members on other nodes

   E. shadow sets with some members on the node to be rebooted and some on
       other nodes

There is also the question whether the dismount needs to be done on the
node shutting down or on the other nodes.

I've had a look at SYS$SYSTEM:SHUTDOWN.COM, but the code is not very
easy to follow. :-|

Here is my gut feeling: B is not necessary, in E: I need to dismount the
members with a direct connection to the node to be rebooted, A is
probably necessary, as are C and D.

SHUTDOWN.COM does dismount some disks, of course. As the code is not
very easy to follow, does anyone know which of the A--E above it does?

How is any of this related to the value of SHADOW_MBR_TMO?
SHADOW_MBR_TMO is probably more relevant to an unexpected reboot without
a clean shutdown caused by a power outage, crash of a machine etc. The
default is 120 seconds. What, if any, disadvantages are there in
setting it to a very high value?

It seems that SHUTDOWN.COM invokes the site-specific shutdown procedure,
where my own dismount commands would logically be located, before
stopping the audit server and the smi server. This is unfortunate,
since if the corresponding files are not on the system disk (as in my
case, so that they can be common throughout the cluster and available to
all members which are up), this disk cannot be dismounted. A workaround
would be to shut down the audit server etc in my site-specific shutdown
procedure before dismounting the disk, but that seems rather ugly.

Relevant Pages

  • SUMMARY: Sun Cluster 3.2, did devices over 100
    ... Martin suggested setting the cluster back into install mode and configure the ... hdlm so that it doesn't show any disks. ... cleaning successfully a seond time), reboot, disks from storage made ... Find a way to get cluster to generate the missing device entries. ...
    (SunManagers)
  • Re: HBVS, shutdown procedures, dismounting disks, SHADOW_MBR_TMO
    ... We will have some disks that are ... served and available to the rest of the cluster during the reboot. ... OK, now let us consider shadow sets, which is more complicated. ... to dismount all shadow set members at least on the nodes they are local ...
    (comp.os.vms)
  • Re: shadow sets, cluster, merge, MVTIMEOUT, dismount
    ... you can go ahead and dismount disks which SHUTDOWN.COM will not ... the INSTALL PURGE is done very late in the shutdown code. ... cleared all your disks of installed images. ...
    (comp.os.vms)
  • miscellaneous puzzles
    ... When I have a shadow set (both members physically connected to node A ... all disks in the cluster MSCP-served) ... When I then DISMOUNT it on ... that the files reside in SYS$SYSROOT:isn't much help, ...
    (comp.os.vms)
  • Re: HBVS, shutdown procedures, dismounting disks, SHADOW_MBR_TMO
    ... We will have some disks that are ... > served and available to the rest of the cluster during the reboot. ... > rebooting system and another shadow set member on another node. ... If they are on the node going down---does SHUTDOWN dismount the physical ...
    (comp.os.vms)