[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference spezko::cluster

Title:	+ OpenVMS Clusters - The best clusters in the world! +
Notice:	This conference is COMPANY CONFIDENTIAL. See #1.3
Moderator:	PROXY::MOORE

Created:	Fri Aug 26 1988
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5320
Total number of notes:	23384

5224.0. "Access to remote shadowset ?" by ONOIS1::LESAOS () Wed Feb 05 1997 10:03

I have a customer who asked me a question about accessing remote shadowset in a
FDDI cluster.
He has 2 AlphaServers 4000 (OVMS 6.2-1H3) and configured them with ALPRD0 as a
"master" (VOTES=2) and ALPRD1 as a "slave" (VOTES=1). The reconfiguration of
the cluster will be done manually in the case of a member failure.

Here's his configuration :

                                FDDI
               +=========================================+
               |                                         |
               |                                         |
               |                                         |
          =====+=====                                =====+=====
          | ALPRD0  |                                | ALPRD1  |
          |         |                                |         |
          |         |                                |         |
          |         |                                |         |
          ===========                                ===========
      KZPDA|       |KZPSC                        KZPDA|       |KZPSC
           |       |                                  |       |
           |       |                                  |       |
$1$DKB100--+       +--$1$DRA3              $2$DKB100--+       +--$2$DRA3
   (RZ28)  |       |  (RZ28)                  (RZ28)  |       |  (RZ28)
           |       |                                  |       |
      ...  |       |  ...                        ...  |       |  ...
           |       |                                  |       |
          SCSI    SCSI                               SCSI    SCSI


He mounted the system disks as shadowsets on both nodes, that is

on ALPRD0 : DS200 host based shadowset of ($1$DKB100,$1$DRA3),
on ALPRD1 : DS201 host based shadowset of ($2$DKB100,$2$DRA3).

When the cluster is on and running, we can see the local DS20x device, the
local and remote members (MSCP served), but not the remote DS20x.

Is there any possibility to make the remote shadowset accessible ? (DS200 from
ALPRD1, DS201 from ALPRD0).
If not, why?

PATRICK.

T.R	Title	User	Personal Name	Date	Lines
5224.1	If you MOUNT it, they will appear	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Wed Feb 05 1997 10:15`	13
	:Is there any possibility to make the remote shadowset accessible ? (DS200 from :ALPRD1, DS201 from ALPRD0). Sure -- MOUNT both shadowsets in both places: MOUNT/SYSTEM DS200:/SHADOW=($1$DKB100,$1$DRA3)... MOUNT/SYSTEM DS201:/SHADOW=($2$DKB100,$2$DRA3)... I tend to prefer to use a site-local variation of the example command procedure SYS$EXAMPLES:MSCPMOUNT.COM to do all disk mounts, rather than using MOUNT/CLUSTER.
5224.2		EVMS::MORONEY	UHF Computers	`Wed Feb 05 1997 11:39`	13
	>When the cluster is on and running, we can see the local DS20x device, the >local and remote members (MSCP served), but not the remote DS20x. Shadow set virtual units are never served. The underlying member disks are what is served. >Is there any possibility to make the remote shadowset accessible ? (DS200 from >ALPRD1, DS201 from ALPRD0). Just issue the appropiate MOUNT/SYSTEM on both nodes. The SHDRIVERs coordinate the shadowsets. -Mike
5224.3		AMCFAC::RABAHY	dtn 471-5160, outside 1-810-347-5160	`Wed Feb 05 1997 16:45`	6
	The problem with not using mount/cluster is if the member volumes are not available at system startup time then the mount/system fails. Later, when the member volumes do become available they are not mounted by the nodes that need them. The alternative to mount/cluster is a looping procedure.
5224.4		EVMS::MORONEY	UHF Computers	`Wed Feb 05 1997 18:00`	19
	re .3: It is best to have a "wait until everything is available" procedure regardless, since if some but not all members are available you'll get only the available member(s) included in the set, and when the other member(s) get added later the new members will be out of date and you'll get an unnecessary copy. Also consider the sequence: 2 member shadowset 1 member (member A) fails out of the set for whatever reason. Application continues using and updating the 1 member shadowset Cluster eventually shut down and is rebooted. At reboot only member A is seen at first when shadow set is first mounted. Member B becomes available and another node adds it with a MOUNT command Old data is copied over new data! This wouldn't happen if you waited until all members became available before automatically mounting the set.
5224.5	MSCPMOUNT	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Thu Feb 06 1997 10:03`	7
	:It is best to have a "wait until everything is available" procedure regardless, :since if some but not all members are available you'll get only the available :member(s) included in the set, and when the other member(s) get added later :the new members will be out of date and you'll get an unnecessary copy. And that's what MSCPMOUNT does...