Shadow System Disk - ES45 OpenVMS 7.3-2

[Kevin Raven (UK)]

This is out of my control....But we will be shadowing a system disk on an ES45 running OpenVMS 7.3-2. Whats the problem ?
The shadow set will consist of two SCSI drives in the internal drive cage. So we will be shadowing on the same SCSI bus. I think this will not be the fastest of shadow sets. Am I wrong ?

Also a second question....
If you set the BOOTDEF_DEV to be say :
DKA0, DKA100 - Both members of the System disk shadow set.
You then while booted have DKA0 missing from the shadow set for a few days. You then reboot. Will the server boot from DKA0 the stale disk ? And then try to add DKA100 to the shadow set ..the uptodate disk ?

[Karl Rohwedder · Accepted solution]

Kevin,

Shadowing the sytemdisk is no problem at all, you should take care in setting the app. systemparameter, esp. SHADOWING, SHADOW_SYS_DISK and SHADOW_SYS_UNIT.

Of course performance could be better, if 2 different busses would be used. But shadowing is a tool to enhance reliability 1st.

In your error scenario the stale DKA0 would be booted. To avoid cluttering the DKA100, it is strongly recommended, NOT to mount the systemdisk shadowset in your boot procedures.
In normal cases, shadowing software will mount the second member. In case of errors shadowing will detect, that DKA100 is newer and will not mount it into the shadwoset.

regards Kalle

[Kevin Raven (UK)]

It's a shame that the boot process would not test both disk defined in BOOTDEF_DEV and use either one or most uptodate time stamp to boot from.

So its down to the operator to detect that the shadow set is reduced on shutdown and ensure that the boot happens from the remaining member of the shadow set.
This is of course why you would need monitoring software. In my case this will be just a dev/training server and not be wired up to any monitoring.

[Martin Vorlaender]

Kevin,

see http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/00/00/27-con.html

especially:
>>>
The shadowing software detects boot attempts from a physical disk that is inconsistent with currently active shadow set members. In this case, the boot attempt detects the existence of the other shadow set members and determines (using the information in the SCB) that the boot device is not a valid member of the shadow set. When this occurs, the boot attempt fails with a SHADBOOTFAIL bugcheck message on the system console, and a dump file is written to the boot device.

The system bugchecks because it can boot only from a currently valid member of the system disk shadow set. If the boot device fails out of or is otherwise removed from the system disk shadow set, you must either mount the boot device back into the shadow set (and wait for the copy operation to complete) or modify the boot command file to boot from a current shadow set member.
<<<

HTH,
Martin

[The Brit]

Kevin,
if you check the link provided by Martin, and read item 6. under "Caution", the implication is that, Yes, the system will boot from the out-of-date disk, but NO, it will not add the other unit (and/or over-write it).
the implication is that since the boot device was not a part of the shadowset at shutdown, the two devices are no longer consistant, so the system will not shadow them. (Hence the warning about not shadowing them manually, as part of the startup script (which WOULD overwrite it))

Dave.

[Bart Zorn_1]

Do not forget to set the allocation class for the disks to some non-zero value.

You do this by setting the ALLOCLASS sysgen parameter, or by using port allocation classes and the DEVICE_NAMING parameter.

HTH,

Bart

[Jan van den Ende]

Kevin,

not strictly your question, but,
_NOW_ is the time to do some work-ahead to ease your *system management-) life in the future.

Now is the time to enable Dynamic Volume Expansion (and HostBasedMiniMerge, though that could be added at any later time).
And do some IO performance enhancement.

Your targetted second system member now is (or will be) sratch.

INIT that volume with suitable params.
- First, chose a decent cluster size.
And decent is certainly NOT the 3 you will get by default!
Any power of 2 will be much better. Most databases prefer multiples of 4, Alpha memory pages are 8 Kbyte = 16 blocks. And SANs have a REAL preference for multiples of 16, but 8 is also "reasonable".
-- Prepare for future disk growth, by INIT/SIZE=.. Max value is 1 Tbyte, limited by ( 1/8 Tbyte * clustersize ), another reason to chose at least 8 as clustersize.
-- add a "sufficiently high (for your site, but be generous)" value for /MAXFILES
-- review & adjust any other params

-- Do a BACKUP/IMAGE/NOINIT form the system disk to the intended shadow member (preferably when booted from CD, but at least with NO other system activity; then use /ignore=interlock. (Yes Hoff, I know, I know, but...)
-- Now, boot from your new disk, and add the old disk as a shadow member.
-- Do not forget to enable HBMM.

Success!

Proost.

Have one on me.

jpe

[Martin Vorlaender]

Kevin,

heed every one of Jan's suggestions. One small correction, though:

>>>
-- Prepare for future disk growth, by INIT/SIZE=
<<<

The qualifier that Jan probably thought of was /LIMIT. /SIZE sets the actual logical volume size.

cu,
Martin

[Jan van den Ende]

Martin,

You are right.
Just typed too hastily. That is why I also tend to point at the complete HELP!
Thanks for the correction.

Proost.

Have one on me.

jpe

[Kevin Raven (UK)]

Some very good points.
I will add the key points into the relevent technical cutover documents we have.
Thanks as always for the fast and valued input.
Long live the OpenVMS forum and OpenVMS.

Thanks
Kevin