Re: HBVS, shutdown procedures, dismounting disks, SHADOW_MBR_TMO

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

Date: Tue, 11 May 2004 21:03:37 +0000 (UTC)

In article <c7qq6q$27mr$1@godfrey.mcc.ac.uk>, Tony Arnold
<tony.arnold@man.ac.uk> writes:

> I'm not sure what problem you are trying to solve here! Let us consider
> a few scenarios.
>
> Firstly, let us assume no shadow sets. We will have some disks that are
> local to the system being rebooted which are either mounted locally and
> possibly by other systems in the cluster. There will also be some disks
> mounted by this system but served by some other system in the cluster.
>
> Disks that are local and not mounted by any other system will be
> dismounted cleanly by SHUTDOWN.COM.

Makes sense. Presumably, SHUTDOWN.COM will stop all applications which
might be writing to this disk first (otherwise it couldn't dismount it
cleanly).

> Disks that are local and also mounted by other system in the cluster,
> wil be dismounted by the local system, but remain mounted by the others.
> Access to this disk by the other systems will hang until the system has
> been rebooted. If the system is down for long enough, the disks will go
> inteop mount verify timeout on the other systems, but if you are just
> rebooting, this is usually not a problem.

OK. But if they are away long enough to mount-verify timeout, then
apparently I have to reboot the other nodes in order to be able to mount
them on all nodes again.

> Disks that are served by other systems but mounted locally should also
> be dismounted cleanly by SHUTDOWN.COM. These disks should continue to be
> served and available to the rest of the cluster during the reboot.

Makes sense.

> OK, now let us consider shadow sets, which is more complicated. I think
> the complication arises when you have one shadow set member on the
> rebooting system and another shadow set member on another node.

If they are all on other nodes, then I don't see any problem.

If they are on the node going down---does SHUTDOWN dismount the physical
members, or the shadow set itself. If the former, is it guaranteed to
come back up without a copy or merge being required?

> I'm not too sure about this, but I believe that if another node has a
> file open or is accessing the shadow set at the time you reboot, then a
> shadow merge or copy will be required when you reboot as one member of
> the set may have changed and the other not.

Right.

> To avoid this you would have
> to dismount all shadow set members at least on the nodes they are local
> too and possibly cluster wide. To do so, you would also have to kill of
> any application that is accessing these disks. But then if there are no
> files open on the shadow set during the reboot, then no shadow
> copy/merge will be needed and you therefore would not have to dismount
> the disks in this situation.

This is the main problem. If just one node goes down, I have to live
with a copy. However, what about a cluster-wide shutdown? With all
cluster-wide files moved to a shadow set off the system disk, normally
these applications are still running when I can dismount the shadow set
(by hand or in SYSHUTDWN.COM), which means I can't dismount it without
killing them first. So, either I do SET AUDIT/SERVER=EXIT etc by hand
(nasty), or wait until the disk (presumably the individual members) get
dismounted automatically. If I specify CLUSTER_SHUTDOWN, should the
shadow set come back without a need for merge or copy?

Relevant Pages

  • Re: Errors during shadow set merge
    ... I have been getting errors during shadow set merges since I bought ... getting 16 errors on DKA0 and 83 errors on ... I will swap out one of the disks and give it a try. ... Then I merged the shadowset on the problem machine. ...
    (comp.os.vms)
  • Re: DISMOUNT/POLICY=MINICOPY
    ... You need to reboot the node that is not serving the disks. ... If both members of the shadow set are served ny one node, ... > across two VAX nodes, some split across a VAX node and an ALPHA node. ...
    (comp.os.vms)
  • Re: Errors during shadow set merge
    ... I have been getting errors during shadow set merges since I bought ... getting 16 errors on DKA0 and 83 errors on ... I will swap out one of the disks and give it a try. ... Then I merged the shadowset on the problem machine. ...
    (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)
  • shadow sets, cluster, merge, MVTIMEOUT, dismount
    ... I have only SCSI disks. ... In the case of system disks, both members have ... has files open on a shadow set and this shadow set disappears, ... necessary to dismount it on B and C in order to avoid a merge? ...
    (comp.os.vms)