Operating System - OpenVMS
1748268 Members
3698 Online
108760 Solutions
New Discussion юеВ

Re: Automatic mounting of HBVS disks in systartup_vms.com

 
SOLVED
Go to solution
John Gillings
Honored Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

Mark,

Yes you can trust the generation number (GN) to protect your data, BUT (and this is BIG BIG BUT!) MOUNT needs to be able to see ALL the generation numbers of ALL potential virtual units to know which one is the latest.

For example, if we have VU1 with GN=X and VU2 with GN>X

If we MOUNT VU1 and form a new shadowset using VU1 alone, MOUNT has no knowledge of VU2. The generation number of the newly formed shadow set will be updated, and will be higher than that of VU2. If VU2 is now added to the shadowset, it will be overwritten, thus losing data.

A close-to foolproof mechanism is to always specify ALL members in a MOUNT command and include /POLICY=REQUIRE_MEMBERS. If any VUs aren't available, the MOUNT will fail. This should eliminate the scenario above.

The only problem is, if you're recovering from a site failure, you know there will be some members missing, and therefore the mounts will fail. You'll therefore require some kind of manual override to recover the systems with reduced shadowsets. One possibility is to use a user defined SYSGEN parameter to override the policy, but a safer option for disaster recovery is to skip all attempts to mount automatically and do the recovery by hand.
A crucible of informative mistakes
Wim Van den Wyngaert
Honored Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

We do it as John Gillings said. We use USERD2 with values 1 and 2 (default 0) for regulating special action :
1 : not all disks are required but only continue if at least 1 disk is present
2 : try mount with available disks and continue if it fails

Note that we wait up to 60 seconds for the devices to become existing and available (slow config process). After this we abort the boot (unless userd2 says to continue)

Wim
Wim
MarkOfAus
Valued Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

Jon,

" A close-to foolproof mechanism is to always specify ALL members in a MOUNT command and include /POLICY=REQUIRE_MEMBERS. If any VUs aren't available, the MOUNT will fail. This should eliminate the scenario above.
"

Can you then clarify something for me. Is the /policy=require only applicable at mount time? That is, if we need to bring down a node or take a disk out of shadow set, will this be allowed? If that is the case, then /policy=require_members is the answer.

MarkOfAus
Valued Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

John,
Apologies.


" A close-to foolproof mechanism is to always specify ALL members in a MOUNT command and include /POLICY=REQUIRE_MEMBERS. If any VUs aren't available, the MOUNT will fail. This should eliminate the scenario above.
"

Can you then clarify something for me. Is the /policy=require only applicable at mount time? That is, if we need to bring down a node or take a disk out of shadow set, will this be allowed? If that is the case, then /policy=require_members is the answer.
MarkOfAus
Valued Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

John,
Apologies.


" A close-to foolproof mechanism is to always specify ALL members in a MOUNT command and include /POLICY=REQUIRE_MEMBERS. If any VUs aren't available, the MOUNT will fail. This should eliminate the scenario above.
"

Can you then clarify something for me? Is the /policy=require only applicable at mount time? That is, if we need to bring down a node or take a disk out of shadow set, will this be allowed? If that is the case, then /policy=require_members is the answer.
Volker Halle
Honored Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

Mark,

while checking the keywords for MOUNT/POLICY, you may also consider the /POLICY=VERIFY_LABEL keyword.

This keyword will only allow disks to become a copy target, if they have a label of 'SCRATCH_DISK'.

In your LD: example, you could have at least prevented overwriting LDA1: with /POL=VERIFY_LABEL

Volker.
John Gillings
Honored Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

Mark,

/POLICY=REQUIRE_MEMBERS means all volumes in the MOUNT command must be accessible for the mount to complete. Once the shadowset is created, members may be removed or added as per normal. Once the shadowset is established, as long as you don't dismount the last member, the generation number should protect you (on the other hand, it's a good policy to never reduce a shadowset below 2 members).

The purpose of REQUIRE_MEMBERS is to satisfy exactly your concern - to make sure the correct member is chosen as the master when a shadowset is first formed.

As Volker has suggested, if he's right about the explanation for your "accident", that could have been prevented with /POLICY=VERIFY_LABEL.

See HELP MOUNT/POLICY. When used correctly, you can use it to construct MOUNT commands that will guarantee data integrity of the resulting shadowset, or fail.

Note - for maximum safety, you should write procedures to define all the shadowset actions you want to permit, and strictly enforce operational rules that ONLY those procedures may be used to affect shadowsets. No matter what you do, your shadowsets are always vulnerable to (privileged!) fat finger commands.

Look after your shadowsets and everything else will follow.
A crucible of informative mistakes
MarkOfAus
Valued Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

John,

"The purpose of REQUIRE_MEMBERS is to satisfy exactly your concern - to make sure the correct member is chosen as the master when a shadowset is first formed."

That's great. I will use it as the standard way of mounting disks automatically. On the occasions when it doesn't have the other disk accessible, I will use the USERD1 parameter to modify the behaviour of the automounting command file. Brilliant!


"As Volker has suggested, if he's right about the explanation for your "accident", that could have been prevented with /POLICY=VERIFY_LABEL."

Yes, I see it now. The label is what undid me, so I know in future to not use the same label or use the /policy=verify_label or use the "scratch_disk"


"Note - for maximum safety, you should write procedures to define all the shadowset actions you want to permit, and strictly enforce operational rules that ONLY those procedures may be used to affect shadowsets. No matter what you do, your shadowsets are always vulnerable to (privileged!) fat finger commands."

This is precisely what I am trying to pursue. As I am not the only one with the ability to modify/reboot/wreak havoc on the system but I am responsible for the procedures around operating the servers, I needed to create such procedures that avoid "fat finger commands." (so eloquently said).

Thank you for your sage advice.


MarkOfAus
Valued Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

Use /policy=require_member to prevent a possible corruption when creating shadow sets.

Use sysgen parameters to dictate the actions in non-normal situations OR manually mount the shadow sets with /confirm.

When creating shadow sets, avoid using the same label as the other device to prevent incorrect shadow copy master being set.

Thank you to all for your invaluable assistance.

Regards
Mark
Jon Pinkley
Honored Contributor

Re: Automatic mounting of HBVS disks in systartup_vms.com

Mark,

I realize this thread is closed, but I've done some experimenting, and the only way I can get a copy to go in the wrong direction is if I mount the newly initialized member into a single member shadowset, and then dismounting the DSA virtual unit. This sets the generation number to the current 64bit system time, which then looks more current than the other shadow member.

Initializing a disk sets the generation to zero, so unless something is done to change that, the newly initialized disk will not be used as the copy source. This is true whether or not init/shadow is used.

Here's a summary:

Preexisting conditions:

DSA99: mounted with members $4$lda1,$4$lda2 in steady state condition.

$dismount [/cluster] dsa99: ! at this point both $4$lda1 and $4$lda2 are identical.

$ init $4$lda1: itrcshad ! generation = 0
$ mount dsa99: /shadow=($4$lda1:,$4$lda2) /policy=require_members itrcshad ! this will overwrite $4$lda1, since $4$lda2 how has higher gen

If instead of the above, we did

$ init $4$lda1: itrcshad ! generation = 0
$ mount dsa99: /shadow=($4$lda1:) itrcshad/nocopy ! /nocopy ensures that this is the only member in the shadowset
$ dism dsa99: ! after this generation set to current time, i.e. more current than $4$lda2:
$ mount dsa99: /shadow=($4$lda1:,$4$lda2) /policy=require_members itrcshad ! this will overwrite $4$lda2, since $4$lda1 how has higher gen

When mounting shadowsets interactively, always use /confirm, as it will tell you what will be the copy target, and ask for your permission to proceed. If you don't expect a copy to occur, specify /nocopy to ensure that it does not.

To reset the shadow generation number to 0: $ mount/override=(shadow)

The advice about /require_members is good, and the advice to initialize to different label is good.

I have attached a log of my experiments showing the nitty gritty details, including the use of the freeware tool DISKBLOCK.

Have fun,

Jon
it depends