Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

3 Site VMS Cluster with Shadowing and Quorum Site

 
SOLVED
Go to solution
Yves HUDON
Advisor

3 Site VMS Cluster with Shadowing and Quorum Site

Hi,
Question regarding the configuration of a Quorum Server on in a 3 site Cluster using Shadowing.

We project to use :
- 1 ES47, 1 ES80 and 2 Blade BL870c on site 1 ;
- 1 EVA8100 on site 1 ;
- 1 ES47, 1 ES80 and 2 Blade BL870c on site 2 ;
- 1 EVA8100 on site 2 ;
- 2 FC Fabric with 2 x 4Gb/s links each ;
- 1 private NSPOF LAN for SCS, DecNEt ;
- Intersite LAN link 10 Gb/s ;
- On site 1 and 2 there is 2 systems disk;
- 1 for Alpha ;
- 1 for Itanium ;
- SYSUAF is on a common disk ;

- 1 BL860c use as a Quorum Server on site 3 ;
- This server have is own local disks ;

Is it better :

1) To configure the Quorum Server just using is own local disk and sharing the SCS and DecNet communication between the others nodes of the Cluster ?

2) Then, to configure the Quorum Server with is own SYSUAF file instead of mounting the common disk of the cluster ?

3) If we use a separate SYSUAF file on Quorum Server, do the SYSMAN command "SET ENVIRONMENT/CLUSTER" will prompt us for the password of the "system" account ?

3.1) If we use a separate SYSUAF file, since SYSMAN use DecNET, setting a PROXY account in SYSUAF file on the Cluster side and on the Quorum Server side be a way to resolve the prompt of a password ?

YvEs H.
8 REPLIES 8
John Gillings
Honored Contributor

Re: 3 Site VMS Cluster with Shadowing and Quorum Site

Yves,

If you're going to go to the trouble of having a quorum site, you should go the whole way!

I'd expect the quorum node to have its own, local system disk. Maybe locally mirrored (controller based?). The goal is to make your system disk effectively read only.

ALL your cluster environment files (there are LOTS more files than just SYSUAF, see the comments in SYLOGICALS.TEMPLATE) should be on a common disk shared across the cluster. The ideal would be a three member shadow set, one member physically on each site. For the paranoid, each shadow member would also be controller mirrored. The storage doesn't need to be big, or particularly fast.

This set of files defines your cluster. In theory, you should be able to recover your whole system by clean installing OpenVMS from distribution media, then pointing the logical names at your environment files (the procedure for doing this should be on the common disk).

Make sure you have a backup for your cluster data. I like to keep a copy of every file on the same disk, then a second set of copies on another disk, from which they can be sent to tape.

Having separate files will just cause confusion and make any recovery procedures more complex and error prone. Recoveries are stressful enough without having the added complication of trying to resolve mismatched, expired or forgotten passwords.
A crucible of informative mistakes
Hoff
Honored Contributor

Re: 3 Site VMS Cluster with Shadowing and Quorum Site

John's suggestions here are quite reasonable.

If you do decide to run distinct and parallel SYSUAF files (rather than shadow-level copies), you need to coordinate UIC and identifier values across all hosts. Which means any usernames that occur in more than one SYSUAF file must have the same UIC, and the same for matching identifiers in the RIGHTSLIST.

I'd consider an limited SYSUAF file here via the SYSUAFALT file and the UAFALTERNATE parameter (which is where I think you're going), but that's irrespective of John's comments. This SYSUAFALT file here serves strictly as a backstop; I tend to use that as a fast way to reboot with only limited server access among the user community. As John comments, I'd also run with the same shared SYSUAF file in production.

And if you're asking these (good) questions, the next series of questions involves the "what have you missed?" discussion in your DT and archival and system configuration and policies and procedures and administrative processes.
comarow
Trusted Contributor

Re: 3 Site VMS Cluster with Shadowing and Quorum Site

Hello,

If the quorum disk is locally attached,
it serves no purpose. It simply adds votes
if that system is up and adds to the load.

A shadow disk can not be used as a quorum disk, (however you can use mirrored disks that appear to VMS as one volume.

The disk should able to be seen on all systems and not shadowed, and the allocation class for it must not be zero.

Bob Comarow
Jan van den Ende
Honored Contributor

Re: 3 Site VMS Cluster with Shadowing and Quorum Site

Yves,

DO heed Hoff's remark about "what have we missed"
Keith Parris has a lot of stuff on that, and it is much easier to follow existing tracks than trying to find ALL yourself (but if you are planning this stuff, you probably already got there.

One more thing on redundant shadow members:
John wrote
>>>
For the paranoid, each shadow member would also be controller mirrored.
<<<
It may be worth mentioning that recently the 3-member limit was relaxed, you can now have 2 members at each site (even with facility for an extra member to split off for backup purposes)

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
John Gillings
Honored Contributor

Re: 3 Site VMS Cluster with Shadowing and Quorum Site

re: jpe

>It may be worth mentioning that recently
>the 3-member limit was relaxed, you can
>now have 2 members at each site

News to me! I knew this was planned, but didn't notice it actually get released. What's the minimum version & patch level that supports >3 members?

The help file on V8.3-1H1 still says "Binds up to three physical devices into a shadow set..."

re: Bob,

There is no quorum disk here, it's a quorum node (or, indeed a quorum site).
A crucible of informative mistakes
Paul Jerrom
Valued Contributor
Solution

Re: 3 Site VMS Cluster with Shadowing and Quorum Site

Howdy,

My site sounds cunningly similar to what you want to achieve. 2 x rx2620 as the production nodes. 1x Alpha DS10 as quorum node. All in different machine rooms in different buildings around the site. rx2620s create shadow sets of one or more disks on each server. DS10 does not mount any disk that is mounted on the rx2620s.
DS10 has its own sysuaf and rightslist, partly because I do not want users logging in to the the ds10. (Yes, I know I could have smarts built into the sylogin, but why bother?)
I have proxys between the ds10 and rx2620s. SYSMAN works happily between all three nodes without prompting for a password.
Seems stable enough, cluster was formed Oct 12 2005 and hasn't been down since.

Have fun.
PJ
Have fun,

Peejay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If it can't be done with a VT220, who needs it?
Jur van der Burg
Respected Contributor

Re: 3 Site VMS Cluster with Shadowing and Quorum Site

John,

Shadowing with > 3 members will work in V8.4:

$ mou/sys dsa0:/shad=($1$dkb0:,$1$dkb100:,$1$dkb200:,$1$dkb300:) s1
%MOUNT-I-MOUNTED, S1 mounted on _DSA0:
%MOUNT-I-SHDWMEMSUCC, _$1$DKB0: (THEALP) is now a valid member of the shadow set
%MOUNT-I-SHDWMEMCOPY, _$1$DKB100: (THEALP) added to the shadow set with a copy operation
%MOUNT-I-SHDWMEMCOPY, _$1$DKB200: (THEALP) added to the shadow set with a copy operation
%MOUNT-I-SHDWMEMCOPY, _$1$DKB300: (THEALP) added to the shadow set with a copy operation

%%%%%%%%%%% OPCOM 24-MAR-2009 11:08:51.82 %%%%%%%%%%%
Message from user SYSTEM on THEALP
%SHADOW_SERVER-I-SSRVBEGCPY, BEGINNING copy operation on _DSA0: at LBN: 0, I/O size: 127 blocks, ID number: 12000227

$ sh dev dsa0

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA0: Mounted 0 S1 514448 1 1
$1$DKB0: (THEALP) ShadowSetMember 0 (member of DSA0:)
$1$DKB100: (THEALP) ShadowCopying 0 (copy trgt DSA0: 15% copied)
$1$DKB200: (THEALP) ShadowCopying 0 (copy trgt DSA0: 15% copied)
$1$DKB300: (THEALP) ShadowCopying 0 (copy trgt DSA0: 15% copied)

Fwiw,

Jur.
Highlighted
Yves HUDON
Advisor

Re: 3 Site VMS Cluster with Shadowing and Quorum Site

Thanks you for all your answers, it is helpfull.

YH