Mounting of HBVS disks in sylogicals.com fails on a node.

[Jon Pinkley]

Mark,

If each of the shadow members has only a single system with a direct connection, i.e. if DKA300 is directly attached only to nodeA and DKC300 is directly attached only to nodeB, and you can't share the SCSI bus between the systems, you may be interested in trying to avoid a full copy when the member is reintroduced when a system boots.

If you are running non-VAX VMS 7.3+, you should be able to take advantage of write bitmaps to minimize the time it takes to return a member to steady state.

If a member's only path is via the system that is being shutdown, that system can request that the member be dismounted by the other system (using sysman). The command to dismount is

$ dismount /policy=minicopy

The bitmap is created on the node that does the dismount, therefore the dismount must be done on a node that will remain up during the reboot.

I haven't used the method John Gillings recommended, [/policy=require_members], but I just tried it and it works.

So in syshutdwn

$! with LOG_IO priv
$! if member only accessible via this node
$! request other node to dismount member
$! with use of sysmanini this can be done with single dcl command line.

Contents of exe_other_node.sysmanini
set environment /node=
set profile/priv=log_io

$ define/user sysmanini exe_other_node.sysmanini
$ mcr sysman do dismount/policy=minicopy

When disks are mounted, you do not have to specify /policy=minicopy unless you want the mount to fail if the member can't be mounted without a full copy. If a minicopy bitmap exists, it will be used. You can specify /policy=require_members, although this is most important on the initial mount of the virtual unit, to ensure that the most recent member is used as the master.

I've attached an example showing commands and their effect on bitmaps and remounting of a member (that was static during the time it was dismounted).

Good Luck,

Jon

[Jon Pinkley]

Here's the attachment I left off.

Jon

[MarkOfAus]

Bart,

"do you use the logical name SHUTDOWN$INFORM_NODES"

No, but I must say that was the first thing I checked for.

Regards,
Mark.

[MarkOfAus]

Hoff,

" Ok, so EMU1 is the primary and EMU2 is the secondary. I'd (still) mount the disks as previously stated, specifying all nodes and the full path. And I'd use the wait loop as previously specified. (I tend to combine the whole MOUNT sequence into the subroutine; the test for existence and the wait, a test for having been mounted and the MOUNT, etc.) "

Ok, I will rationalise the approach; point taken.

"And I'd look to configure shared SCSI buses (assuming the two systems are co-located within the range of appropriate SCSI cables), as this substantially improves uptime and reduces network load."

The systems are geographically seperated, and have their own closed fibre connections.


"As for the disaster-level processing and the usual sorts of situations, I'd simply look to avoid starting the applications on the secondaries, or (better) at coding the "

No problem there as the licensing we have precludes running the application on both servers. So the secondary server is really just idling behind the scenes as a real-time backup, receiving data.


"...Or (best) to code the environment to use all of the available cluster member nodes in parallel. I've found that manual switch-over processes tend to fail during disasters; best to have these set up as automatic as us reasonably feasible. Humans can tend to be the error trigger, particularly for seldom-used sequences."

I guess I don't have an option, given the constraints, so a manual switch-over is the only way I can go, for now.

Regards,
Mark.

[MarkOfAus]

Jon,

"If each of the shadow members has only a single system with a direct connection, i.e. if DKA300 is directly attached only to nodeA and DKC300 is directly attached only to nodeB, and you can't share the SCSI bus between the systems, you may be interested in trying to avoid a full copy when the member is reintroduced when a system boots."

You are correct. Each system has its own disks, no shared storage (Vms 7.3-2).

You are also astute. I had looked at the minicopy, for future usage, because the disk at issue today is only a 36GB disk, so when it comes back into the shadow set the full copy is fairly quick. When the 300G disks are added in the next few weeks, that "fairly quick" copy will be a "bloody long one".

"So in syshutdwn

$! with LOG_IO priv
$! if member only accessible via this node
$! request other node to dismount member
$! with use of sysmanini this can be done with single dcl command line.

Contents of exe_other_node.sysmanini
set environment /node=
set profile/priv=log_io

$ define/user sysmanini exe_other_node.sysmanini
$ mcr sysman do dismount/policy=minicopy
"

Brilliant! Thank you Jon, I will do this.

[MarkOfAus]

Bart,

"regarding the suppression of the shutdown messages on other cluster members, do you use the logical name SHUTDOWN$INFORM_NODES ?"


I think you may be onto something, though. I was under the impression that if it was blank it notifies none. Perhaps I should revise that assumption to "if it is blank, it will notify all nodes."?

Regards,
Mark.

[Jon Pinkley]

If anyone is aware of a better way to handle the "member with a single connection" case, than using sysman, I would be interested.

I have read the "HP Volume Shadowing for OpenVMS Alpha 7.3-2" manual, and it is silent on the subject as far as I know. The main focus of minicopy is for backups. However, from experience I can say that a master minicopy bitmap on a system with only an MSCP served connection is sufficient to avoid a full copy, and that the bitmap survives on the node it is created on, across the removal and reintroduction of the other node with the direct connection.

A nice "enhancement" to dismount/policy=minicopy would be the ability to specify a node for which the dismount should be initiated, and therefore where the master bitmap should be created.

For example:

$ dismount/policy=minicopy=node:omega $4$DKC300: ! not implemented !!!
would tell omega to dismount the member and create the master minicopy bitmap. Perhaps there could be a list of nodes specified, in which case the first node in the list that was currently a cluster member would master the bitmap. The check for log_io privilege would be on the requesting node, so this assumes the security domain is the cluster, i.e. homogenous privileges on all nodes of the cluster (shared SYSAUF).

Also, if anyone knows of any problems with my suggestion, I would also like to hear about them, as I have never seen this recommended or documented.

Jon

[MarkOfAus]

Jon,

"I have read the "HP Volume Shadowing for OpenVMS Alpha 7.3-2" manual, and it is silent on the subject as far as I know. The main focus of minicopy is for backups. However, from experience I can say that a master minicopy bitmap on a system with only an MSCP served connection is sufficient to avoid a full copy, and that the bitmap survives on the node it is created on, across the removal and reintroduction of the other node with the direct connection.
"

The manual is helpful, but as you suggest, it is often one-tracked in its explanations. No alternative scenarios are given, because, to me, examples mean much more than paragraph after paragraph of explanatory notes. Often the manuals assume a level of OpenVMS knowledge by the reader that is not there.

"A nice "enhancement" to dismount/policy=minicopy would be the ability to specify a node for which the dismount should be initiated, and therefore where the master bitmap should be created.
"

This is a brilliant idea, and I can't understand why it isn't available BUT the LOG_IO privilege issue seems a sticking point and is probably why using sysman is the only way to do it.

I am going to use your suggestion today, first manually then in a command file at shutdown.

[Martin Hughes]

I think we had a similar discussion about 6 months ago. Using SMISERVER to perform the dismount on another node is an option I hadn't considered. That would certainly allow you to create the master write bitmap where it belongs.

I'm still inclined to handle the dismount/mount processes manually though. Mounting and dismounting locally attached shadowset members can be a dangerous business, and I'd argue that you have less control if you automate the process. I tend to just write the mount/dismount scripts and then execute them when and where I choose.

[Jon Pinkley]

I believe the thread Martin is referring to is this one:

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

After thinking a bit more about this, there should really be an option to "do the right thing" when dismounting a virtual unit at shutdown. I.e. if the virtual unit has at least one member that has a direct path to another cluster member, but there are some members of the virtual unit that are directly attached only to the system being shutdown, then the dismount should first initiate a dismount of the members that have no direct paths to other cluster members, and this dismount should create a minicopy bitmap on a cluster member that currently has the virtual unit mounted, and has a direct connection to one of the other members.

The purpose of doing this is to avoid full copies when the system being shutdown reboots. Also, by dismounting the member, the remaining cluster nodes won't have to timeout the connection to the (MSCP served) member that stops responding when the MSCP serving node shuts down. With HBMM, multiple cluster nodes can have master copies, with minicopy, this doesn't seem to be possible, as the master copy is created on the node that creates the bitmap with the dismount of mount command.

Since this discussion is not related to "failure to mount disks", perhaps we should start a new topic discussing the use of minicopy during shutdown.

Jon