Shadowing on an Alphaserver 1000a

[Dave Brennan_1]

Hi,

I recently started work on two AlphaServer 1000a systems which I have put into a LAN cluster.

I then wanted to shadow some data disks from system to system, but keep getting a failure creating the shadow set as follows:-

$ sh dev dra1:/full

Disk ECHO$DRA1:, device type DRX00, is online, file-oriented device, shareable,
available to cluster, error logging is enabled.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 0 Default buffer size 512
Current preferred CPU Id 0 Fastpath 1
Host name "ECHO" Host type, avail AlphaServer 1000A 5/400
, yes

Disk INCA$DRA1:, device type 1 Member JBOD, is online, file-oriented device,
shareable, served to cluster via MSCP Server, error logging is enabled.

Error count 0 Operations completed 546
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 0 Default buffer size 512
Total blocks 35563520 Sectors per track 64
Total cylinders 34730 Tracks per cylinder 16

$ init /shadow=inca$dra1 common
$ mount dsa10:/shadow=(inca$dra1:,echo$dra1)/sys common
%MOUNT-F-NOMASTER, no master member found for this virtual unit
%MOUNT-I-SHDWMEMFAIL, _INCA$DRA1: failed as a member of the shadow set
-MOUNT-F-NOTSHDWDEV, not a valid shadow set member
%MOUNT-I-SHDWMEMFAIL, _ECHO$DRA1: failed as a member of the shadow set
-MOUNT-F-NOTSHDWDEV, not a valid shadow set member
$

Why if I can init it as a shadow set does it not have a master member or is it just that shadowing is not supported on the old KSPSC interface anymore?

[Dale A. Marcy]

Dave,

I believe to create shadow sets it is required to have non-zero disk allocation class. Once you have set the sysgen parameter ALLOCLASS for both systems, I believe you will be able to mount the disks.

[Dale A. Marcy]

Sorry, I submitted my first reply too soon. You do not specify version of VMS, but in the VMS V7.3-2 manual Volume Shadowing for OpenVMS starting on page 37, it lists the different sysgen parameters that affect volume shadowing.

[Uwe Zessin]

I don't know if shadowing works on the KZPSC, but Dale is correct in saying that you need to set up allocation classes for the shadow-set members.

[Jan van den Ende]

Dave,

I guess we need more info to fully help, but as a start:

-- I assume that you _DO_ have the shadowing licence loaded.

-- If you did not dismount INCA$DRA1 between your SHOW and your MOUNT, then it _IS_ already mounted, which prevents it being entered into a shadow set.

-- If the INCA disk is the system disk, then you must create the shadow set during bootstrap.

You should set SHADOW_SYS_DISK to "1", and if you would like your system disk shadow set to be DSA10, SHADOW_SYS_UNIT to "10"
(best done by AUTOGEN from, or at least also entered into, MODPARAMS.DAT)

For non-shadow disk, dismount it.
From your text I presume that you want the contents of INCA to stay, and if I am correct, then first create a single-member set of this disk:
$ MOUN/SYS DSA10: /SHADOW=INCA$DRA1: common

I usually prefer NOT to refer to the fysical devices nor shadow sets by driver-and-controller derived names, but for future compatibility define human-reasonable names early in the bootstrap (in, or called by SYLOGICALS.COM)
assumming from now on:

DEFINE/SYSTEM/EXECUTIV/TRANS=CONCEAL DISK1 DSA10:
and
DISK1E ECHO$DRA1:
DISK1I INCA$DRA1:

(of course you choose names that mean something to _YOUR_ site!!)

After you have your single-member set with the correct data, now is the time to synchronise the other member.
$ MOUNT/SYS DISK1 /SHAD=(DISK1E,DISK1I) COMMON
(I did not notice the volume label in your SHOW DEVICE, I assume it is "COOMON", if not, make it so, or use the existing label)

Now the shadow-copy starts. This takes hours!

The above assumes that you are very current on VMS version. Only recently (from memory: 7.3-1) has non-equal member shadowing available.
I would be surprised if "DRX00" and "JBOD" would match.
btw, that reminds me, even on dissimilar shadowing you can NOT add a smaller member to a bigger set, so in the above sequence you MUST start with the smaaleer one.
Maybe that requires and image backup from your JBOD to your DRX00 device.. {-:


Well, this should help you some paces further.
If you encounter more questions, please supply also your machine types and VMS version!

Proost.

Have one on me.

Seasonal greetings to all!

Jan

[Dave Brennan_1]

Ok some bits I missed out. Its VMS 7.3-2 with the latest patch bundle applied.

Currently both systems have the allocation class "as in the question asked when adding a node to the cluster set to 0".

I suspected allocation class but couldn't figure if they needed to be unique or match the scsi id currently set at 51 = INCA and 52 = ECHO.

I totally agree about not using physical names but what I am trying to figure out is if this is some cluster parameter or if its the fact that the KZPSC is presenting this as a JBOD 17GB disk and although it is a SCSI device SCSI is missing from the device configuration.

Suggestions as to what to set the ALLOCLASS parameter on INCA and ECHO would be much appreciated.

[Dave Brennan_1]

Ok looks like its nailed!

I set INCA's allocation class to 10 and ECHO's allocation class to 20. The shadow set now mounts and started a copy. I am now trying the "new to me"

init/shadow=($10$dra1:,$20$dra1:)/erase common

but it looks like a disk erase takes about the same time a shadow copy does.

Thanks all,

Dave

[Robert Brooks_1]

Thanks for using Host-Based Volume Shadowing!

If you use INIT /SHADOW, you will avoid
the subsequent shadow copy if all the
shadow set members are mounted at the same
time (that is, with a single MOUNT command).

However, if a merge is ever needed, you will have to pay the penalty for a full merge, as
INIT /SHADOW only affects the file system; unused blocks may still differ and a full merge simply goes from LBN 0 to the end of the disk in verifying that all data is the same. Note that by using /ERASE, all the non-filesystem data WILL be identical, so there will be fewer merge fixup operations if a merge is needed.

Also, since you have the latest V7.3-2 shadowing stuff, please take a look at Host-Based Minimerge (HBMM). It'll reduce the pain of a merge by a substantial amount!

--Rob Brooks

[Volker Halle]

Dave,

from the information provided, you seem to be shadowing 2 disks locally connected to 2 different systems (no shared disk-IO bus).

Note that when shutting down one of those systems for longer than SHADOW_MBR_TMO seconds, you'll break up your shadowset and have to re-form it with a FULL COPY after rebooting the system (local member on rebooted node will be target of a full copy).

The new (V7.3-1 or higher) shadowing MINI-COPY feature may be quite useful in these configurations:

If you want to shut down node INCA, issue the following command on node ECHO:

$ DISM $10$DRA1:/POLICY=MINICOPY

This will cause a Write Bitmap (SHOW DEV/BITMAP D) to be created on ECHO for this shadowset. Once you reboot node INCA and re-mount the shadowset, only those blocks of the shadowset, which have been written to while $10$DRA1: was not available, will need to be copied. This will greatly reduce the shadow copy time.

Volker.

[Volker Halle]

Dave,


but it looks like a disk erase takes about the same time a shadow copy does.


Yes, it does. The idea behind this feature is, that you can control, WHEN you start the INIT/ERASE, whereas you can't control when a (full) merge starts (e.g. due to a system crash).

Volker.

[Dave Brennan_1]

Ah yes mini merge, didn't have that the last time I worked on VMS (7.2).

I did think about joining the Alpha 1000a SCSI bus together, after all don't want the 5 years I spent in DEC Computer Special Systems going to waste, but I would have to give up a few disks.

Anyway this is just a home hobby system, 2 1000a systems on a back to back FDDI network with Ethernet to the outside world. I am going to use them as my MAIL/WEB servers. My wife wants to use them to introduce her students to archane computer languages such as Cobol and Fortran as a break from Microsoft VB.

[Uwe Zessin]

Dave,
if you like to build a shared bus, make sure that the bus uses the same allocation class on both nodes - a nice chance to start playing with port allocation classes...

[Jan van den Ende]

.. and make sure your bus has a different ID on both systems, both of which of course may not conflict with any other devices!

Proost.

Have one on me.

Seasonal greetings to all!

Jan

[Dave Brennan_1]

I tried it early in this project but in order to configure the disks you have to initialize them via the KZPSC, which takes about 7 hours. Any SCSI conflict will cause the KZPSC to drop the config and request a reinitialize. The first time it happened I thought I had blown the controller, so was happy to do the re-initialise. The second time I decided I would swith to a LAN cluster.

[Uwe Zessin]

Sorry, that's a misunderstanding. You cannot build a shared SCSI bus with a backplane RAID controller. They usually do not allow one to change their SCSI ID to make them unique and, most important, they do not provide any synchronization of their meta data, cache and don't have multi-initiator support.

[Dave Brennan_1]

Ok need to stop this as its working. Tomorrow I want us all to focus on my XDMCP problem.......but thats next year.

Happy new VMS year to all.