[Info-vax] Quorum strategy
Hans Bachner
hans at bachner.priv.at
Wed May 22 12:21:42 EDT 2019
John E. Malmberg schrieb am 22.05.2019 um 15:13:
> On 5/22/2019 3:44 AM, Marc Van Dyck wrote:
>> Our production environment is made of 3 clusters of two members each,
>> with a quorum disk. Each member has one vote, the quorum disk also,
>> so expected votes is 3 and the quorum is 2.
>>
>> Now, in our environment, one of the two cluster members is more
>> important than the other because there are application parts that
>> can run on this one only. We call this the primary member. The other one
>> is the secondary member.
>>
>> If case of system failure, if it is the secondary member that fails, we
>> can just switch the applications that ran on it to the primary. The
>> only price to pay will be a load more difficult to handle.
>>
>> If the primary member fails and can't be restarted, we shut down the
>> secondary too and restart it as primary. All data are on SAN storage,
>> including the system disk. So it is just a matter of shutting down,
>> change the boot flags, and restart.
> <snip>
>>
>> So, say that I give
>>
>> - 2 votes on the primary member
>> - 2 votes on the the quorum disk
>> - 1 vote on the secondary member
>
> The quorum disk is only needed if you need the secondary to survive for
> a period of time after the primary system fails, such as long enough for
> an orderly shutdown or do other diagnostics.
>
> If you do not give equal votes to the two systems and quorum disk, when
> the primary system goes down, the secondary system will hang until
> either the primary rejoins the cluster, or you adjust the number of
> votes on the secondary via the console.
>
> [snip]
With the vote distribution described by Marc, imho the secondary system
will happily continue to run as long as it has access to the quorum disk
even if the primary node goes down.
Hans.
More information about the Info-vax
mailing list