Nodes crashing after breaking the mirror

[Jaimin Parikh]

Hi:

I have 3 node cluster and they are attached to a storage with HSG80 controllers (master and shadow).

When I break the mirror by modifying the mount_disks.dat, so that both master and shadow sets will work independently.

But, after breaking the mirror, systems and cluster is working fine, when I boot from primary set. But, nodes are crashing when I boot the systems from shadow disk sets.

Mount_disks.dat in both case is having appropriate disk entries, that is for sure.

Can anybody give in their thoughts to proceed?

What could be the propable cause of it?

I am breaking the mirror so that shadow disk set will be my rollback set, when I do a upgrade of software on master disk set.

Regards,
Jaimin

[Volker Halle]

Jaimin,

mount_disks.dat is not an OpenVMS component, so I can't guess what this file is doing. Please note that you are not normally supposed to enter shadow mount commands for the system disk into any procedures on your system. Just mount the additional shadowset members once and have the system re-form the shadowset in the most recent state during boot:

See Booting from a System Disk Shadowset in
http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML

Please try to capture the messages from the crash on the console terminal. Is it a SHADBOOTFAIL crash ? There should be a message preceeding the crash output. What does it say ? What is the value of R0 in the crash (SDA> EVA/COND R0) ?

Note that all systems need to boot from a source member of the system disk shadowset, ideally all systems should boot from the SAME physical member. If the boot disk is not currently part of system disk shadowset, but the system disk shadowset exists on any other node in the cluster, the new booting node will fail with SHADBOOTFAIL.

Volker.

[Uwe Zessin]

Sounds like you remove a member form the shadow set and then attempt to boot from it.

If that is true, the problem is that the disk has the same volume label like the already/still mounted shadowset that this member was removed from.
$ mount/override=(identification,shadow_membership) member:
$ set volume/label=NEW_LABEL member:
$ dismount member:

Also, the system parameters will tell the system that is booting from it to create the same virtual device (DSAu:). Do a conversational boot, then:
SYSBOOT> set shadow_sys_unit 1234

This would tell the system to use device DSA1234:, but still let into the cluster.

[Aleksander Sinigoj]

I don konow what mount_disk.dat does or is there another .com file to manipulate shadow set mounts and dismounts.

Consider that if you remove a member from a shadow set that member culd be treated as invalid.

You must not mount shadowed system disks in startup. Let this to VMS.

If you can sen a copy of mount_disks.dat and a .com procedure if exists.

[Jan van den Ende]

Jaimin,


when I do a upgrade of software on master disk set.


Just to make sure: you ARE talking of software other than the operating system, are you?

Because for the OS, you really should remove a node from the cluster, and temporarily have it defined as non-clusterd system.

The installation-and-upgrade manual is quite elaborate on the step-by-step porcedure, and you REALLY should adhere to rhat!!


For non-OS software, have you considered stting up the new version -next to- the existing, running software? That way, you have the old version(s) available as long need them, and you can test your new software as long as is needed before using it for production. Logical names will do all that for you.

Jan