[HECnet] OpenVMS 6.1 Cluster - Alpha not booting to form cluster

[Hans Vlems]

   In an NI cluster you can get away with expectedvotes=votes. IMHO disk corruption can only happen if another host accesses a local disk outside the DLM. In a CI or DSSI cluster this can happen and lead to multiply allocated blocks errors.  

An alpha takes more time waiting to form a cluster, even with expectedvotes set to votes than a VAX. I haven't tried it on an rx2600 as yet.  

In production I once configured a two node VAX 3100 NI cluster. Expectedvotes set to 2 and votes to 1. Each node had a local disk designated as quorum disk, one vote. All other disks were shadows et between the two systems. This thoroughly unsupported configuration ran for years until DEC forced a micro VAX    2000 on us. The supported cluster had more user down time once one   of the host went down. In the unsupported cluster the vote of a quorum disk came into play only if the other VAX failed and almost noticeable, no cluster reconfiguration that took many seconds.  
Hans

Van: Brian Schenkenberger, VAXman-
Verzonden: dinsdag 8 oktober 2013 13:15
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] OpenVMS 6.1 Cluster - Alpha not booting to form cluster


Mark Wickens <mark at wickensonline.co.uk> writes:

>On 08/10/2013 11:33, Brian Schenkenberger, VAXman- wrote:
>> Mark Wickens <mark at wickensonline.co.uk> writes:
>>
>>> Just wondered if anyone would know why my Alpha when booting hangs at
>>> the point where it attempting to determine whether to join or form a VMS
>>> cluster? It is clustered with a VAX - if I boot the VAX first the VAX
>>> creates a cluster which the Alpha will then happily join when turned on,
>>> but if I power the Alpha without the VAX it just hangs.
>>>
>>> Both are running an install straight from an original VMS 6.1
>>> installation disk.
>> Just 2 nodes?
>>
>> What's your quorum configuration?
>>
>> Post:
>>
>> $ MCR SYSGEN SHOW VOTES
>> $ MCR SYSGEN SHOW EXPECTED_VOTES
>>
>> ..from each node.
>I think you, sir, may have found the issue:
>
>On RIPLEY (the Alpha):
>
>$ mcr sysgen show votes
>Parameter Name Current Default Min. Max. Unit Dynamic
>-------------- ------- ------- ------- ------- ---- 
>-------
>VOTES 1 1 0 127 Votes
>$ mcr sysgen show expected votes
>Parameter Name Current Default Min. Max. Unit Dynamic
>-------------- ------- ------- ------- ------- ---- 
>-------
>EXPECTED_VOTES 2 1 1 127 Votes
>
>
>On DALLAS (the VAX):
>
>$ mcr sysgen show votes
>Parameter Name Current Default Min. Max. Unit Dynamic
>-------------- ------- ------- ------- ------- ---- 
>-------
>VOTES 1 1 0 127 Votes
>$ mcr sysgen show expected votes
>Parameter Name Current Default Min. Max. Unit Dynamic
>-------------- ------- ------- ------- ------- ---- 
>-------
>EXPECTED_VOTES 1 1 1 127 Votes


OK. First, 2 node clusters can be problematic due to not realy having the
necessary number of node to properly form a cluster. The minimum is three
nodes to form a cluster.

However, let's look at what you said.

You said that the VAX boots and forms a cluster. It has one vote and the
expected votes is one. Therefore, when you boot it, it sees the necessary
number of votes to continue booting and form a cluster.

You also said that Alpha boots and hangs trying to form a cluster. It too
has one vote but its expected votes is two. Therefore, until the VAX has
booted, the number of votes is not present and the Alpha will hang. 

If you lower expected votes, the Alpha wil boot just like the VAX does. I
would caution you read the VMS documentation regarding clusters and how to
determine quorum. You risk, in the configuration of two nodes where each
has one vote and expected votes of one, partitioning the cluster resulting
in data corruption.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.