Volume Shadowing Copy After Reboot

[Allan Large]

I am trying to get an understanding of software Volume Shadowing.

In reading the documentation (which really needs to be updated), I found and have used the MOUNT/POLICY and DISMOUNT/POLICY commands to help insure that only an minicopy is performed when a shadow member is removed and then added back to the set .... when the system is not rebooted.

However, I cannot find where I can do this type of thing after a system reboot. Am I missing something or is a full copy always required after a reboot ?

Thanks in advance ....

[Bill Hall]

Allan,

Do you mean full merge rather than full copy? If your DSA devices a properly DISMOUNTed before the shutdown (you should probably do so in SYS$MANAGER:SYSHUTDWN.COM) they can be mounted at boot time without a merge.

I can't think of a reason why you would have a full shadow copy on boot. The shadow generation number would have to have been removed from the member being copied to.

Bill

[Allan Large]

Bill:

I am just getting a grasp on the commands to setup the volume shadowing correctly.

What we have are two itaniums, each with their own disks. One disk on each system is shadowed together. When either system reboots, the corresponding shadow member goes into a full copy.

I am reviewing the SET SHADOW/POLICY command now and feel that is going to be the answer, but I have yet to fully understand it. Am I headed in the right direction ?

[Mike Kier]

Allan,

I highly recommend you poke around Keith Parris' < http://www2.openvms.org/kparris/ > page for various white papers and presentations he's done around volume shadowing and around high availability and DR in general.

[Bill Hall]

Allan,

Please clarify the description of your two systems. Are they clustered? Are both systems being shutdown together?
Attaching the output from a $show shadow/full on both systems might help us understand your environment better.

Bill

[Allan Large]

OK .. I thought I had this figured out but apparently not, so I am reopening this thread.

I have a couple of questions so I will start with this one and will progress to others later.

QUESTION: Is there a way to configure volume shadowing such that when a node in a cluster crashes and reboots, the disk on that node that is a member of a shadow set doesn't have to go through a full copy ? Or does the fact that it was a "dirty" dismount always force the full copy ?

[The Brit]

Allan,
When you say "2 Itaniums with their own disks.." are you referring to internal disks or SAN disks?

To press an earlier question! Are these two systems clustered??

If a system is subjected to an orderly shutdown then there should never be a need to perform a shadow copy at startup. At worst, there may be need to "rebuild" the volume (usually because when the system shutdown and dismounted the disks, there may have been files open, or installed, e.g. pagefiles on some disks).
If a cluster node "crashes", then when it reboots it will have to perform a "merge" operation. This could be a full merge (which can take a significant amount of time, and will normal affect io performance), or if you have it enabled, the system will perform a "mini-merge", which takes seconds, and is normally completed by the time the system is fully booted.

The volume shadowing qualifiers that you are refering to really are not part of this discussion (since volume shadowing pre-dates them by many years.)

Give us more information about your configuration.

1. Cluster configuration.
2. Storage information.
3. Blades or Rack

Dave.

[Jon Pinkley]

Allan,

Please read the following thread (to the end).

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1118643

If your shadow sets contain members that are only available to other cluster members via MSCP serving, shadowing will work, but there are many limitations. Shadowing works best when every node has direct (non-MSCP served) access to each member. If your two nodes don't have direct access to your members, then you won't be able to do what you want in the general case. Also, if you have only two nodes, and no shared storage, then you won't be able to use a quorum disk, so your cluster will stall if the loss of a node causes the cluster quorum to be lost.

Please cut and paste the output of the following into a text file (for example, a file created with notepad), save it to a .txt file, and attach the file to your next reply. The output will fill several pages, and saving it to a text file will make it much easier to read than trying to read the ITRC mangled output. (Please do NOT attach a WORD .doc file, or a WORDPAD .rtf file). Then we can determine a bit about your configuration:

Replace DSAxxx with one of the shadow set virtual unit devices that you for having problems with.

$ mcr sysman set environment/cluster
SYSMAN> do show device/full DSAxxx

Also, can you please show us the exact commands you are using to mount and dismount your disks?

Jon

[Steve Reece_3]

"QUESTION: Is there a way to configure volume shadowing such that when a node in a cluster crashes and reboots, the disk on that node that is a member of a shadow set doesn't have to go through a full copy ? Or does the fact that it was a "dirty" dismount always force the full copy ?"



If the systems crash, I'd expect a shadow copy to result.
Cluster design is something that isn't really covered very well in all of the material that I've seen as far as disk storage is concerned. In general, I'd always suggest shared storage between cluster members (whether it be a shared SCSI bus or a shared disk array with SAN connectivity. A disk on the array can then be used as a quorum disk in the case of a two node cluster and no shadow copies occur once a node reboots after a crash.

I've been party to clusters formed with SmartArray storage and local SAN connected storage (when the client had insufficient funds to join two storage networks together cross-site) they're not something I'd ever like to do again. If one node crashes, reboots, the shadow copy starts but then the second node crashes, you're up to your armpits in disks that have partial shadow copies and partial updates and it's back to tape to recover the situation.

Steve

[Allan Large]

The following is a test scenario that I have set up in order to demonstrate the issue we are having with volume shadowing.

We have 2 rx2620's with 32mg internal drives running OpenVMS 8.3 that are clustered together in a 2 node cluster. For the purpose of this demonstration, one node is setup with a quorum disk so that it will remain "up" when the 2nd node is shutdown.

In the attached text file, you will see the drives $2$dka100 and $3$dka100 that are the shadow members.

You will then see the formation of the shadow disks ... starting with the initialization of the disks, setting the shadow policy and the mounting of the shadow set. The MOUNT command is issued on both systems.

After the shadow set is formed, you will see the output of the SHOW DEV/FULL DSA0 as well as the SHOW SHADOW command.

Then in preparation for a reboot of one node, the DISMOUNT command is issued and then the system is rebooted.

While the one node is rebooting, a change is made on DSA0 (a directory is created).

NOW ... when the rebooted node comes up and the shadow disk is mounted, it goes into a FULL COPY. It is my understanding that it should do either a mini-copy ....

What am I doing wrong ?