quorum disk question for 2 - 3 node Alpha Cluster

[nipun_2]

Hi,
I am in the process of clustering (Ev68 DS25) alpha workstation (still to start factory installation) so with DS25 and XP1000 (both already clustered).

Please Note: I will refer the new (EV68 DS25) as EV68

Discussion Below:
V 7.3-1, have a common system disk , connected via Ethernet cable. DS25 contains the system disk and can perform if the node (XP1000) is shut down. When I add EV68 DS25 I also want it to behave like XP1000. So if I shut down EV68 or XP1000 or both , still the DS25 will work

I saw the command from the forum and gave
$ mc sysgen show disk_quorum

Parameter Name Current Default Min. Max. Unit Dynamic

DISK_QUORUM " " " " " " "ZZZZ" Ascii


Does this mean I don't have quorum disk?

If NOT - do I need to have one since it is now going to be a 3 node cluster. Do I have to first add the 3rd node and then setup the quorum disk or before?

If YES - how to find out the current expected votes and for future do I need to have 3 votes per node for the above functioning

I was looking at the strategies at http://h71000.www7.hp.com/DOC/732FINAL/6318/6318pro_019.html#index_x_735
but couldn't correlate for my case.

Once again, thanks in advance and any
submitsuggestions comments are highly valued

[Kris Clippeleyr]

Nipun,

If the system parameter DISK_QUORUM is blank, then you do not have a quorum disk.
If you're planning for a cluster of a three (3) nodes, I strongly recommend that you make all three of them voting members (one vote each) and that you set the EXPECTED_VOTES parameter to three (3).
In that case, when a node tries to joins your cluster will not be able to run by itself, it has to see one other voting member. This prohibits a so-called "split" cluster. (Note that quorum is calculated as the sum of all votes in the cluster plus 2, and then divided by 2; in the case described above it's (3+2)/2=2).
If you shutdown a node properly (i.e. specify the REMOVE_NODE option when SYS$SYSTEM:SHUTDOWN asks for it, quorum will be adjusted, so the cluster can continue without the node that is shut down.

Hope this helps,
Kris (aka Qkcl)

[Ian Miller.]

note that to make a quorum disk work you need a disk accessable in shared storage i.e. storage that is seperate from the alphaservers and directly accessable by more than one alpha.

[nipun_2]

In response to Kris and Ian,
Thank you for your suggestions.

For now it is not possible for me to keep the system disk separate from the Alpha Server (DS25)as it inside the machine. In future I am thinking of transferring the system disk to a separate storage.

So in this case how should I go about with the Quorum disk and still have the setup (for server to run even if all or one node is shutdown).

I wanted to get cluster done first and then start moving the system disk.Sort of one step at a time :).

[Mobeen_1]

Nipun,
Yes its always better to have a quorum disk. If you like to have only one node running, then a quorum disk is needed.

rgds
Mobeen

[Ian Miller. · Accepted solution]

with your current hardware arrangement (system disk inside DS25) then you should have one vote for the DS25 and 0 vote for the other two as the cluster can only work if the DS25 is on.

For future arrangement you need some shared storage.

[Jan van den Ende]

Nipun,

in your intended hardware config it is not even POSSIBLE to configure a disk that can be seen from each node irrespective of which other nodes are up, so a quorum disk is not even possible.

Ian's config is by far the wisest.
It _DOES_ mean that your cluster depends on the node with the system disk.
If that node is not running, your cluster is down. If you (yor management) do not think that acceptable, then you MUST add shared storage!

(stricktly speaking, if you want a really complex config, then you CAN shadow your system disk with a member drive in each node, and set up each node to be a satellite of the others. And then, it would not be wise to depend on any single connection. But that really is for the daredevil artists, and "Please, do not try this at home")

So, you has best follow Ian's advice.

Proost.

Have one on me.

Jan

[John Gillings]

re: Kris (aka Qkcl)

"If you shutdown a node properly (i.e. specify the REMOVE_NODE option when SYS$SYSTEM:SHUTDOWN asks for it, quorum will be adjusted, so the cluster can continue without the node that is shut down."

Sorry, I have to disagree. REMOVE_NODE should only be used if you wish to remove a node PERMANENTLY from the cluster (or at least for an extended period). QUORUM will always be recalculated after a cluster transition. REMOVE_NODE causes EXPECTED_VOTES to be recalculated.

In this three node three VOTES configuration, it actually won't make any difference.

Consider four nodes with one vote each. If I shut down one node normally, EXPECTED_VOTES remains at four, quorum is maintained with three nodes and the cluster continues. If I then shutdown another node, expected votes is still four and quorum is lost, so the cluster hangs waiting for a node to return.

If I used REMOVE_NODE when shutting down the first node, then EXPECTED_VOTES would have been recalculated to three. Shutting down a second node doesn't lose quorum, so the cluster can continue with two nodes.

HOWEVER, this is only "safe" if the first node was physically disconnected from the cluster interconnect.

Now, the biggest issue with the type of cluster proposed by nipun is where are the cluster common files going to reside? If there is no shared storage, there is nowhere to store the shared files. Similarly, nowhere to use as a quorum disk. That means it's not possible to have a 3 node cluster in which any SINGLE node can run on its own.

Your cluster IS the cluster configuration files, so think about where and how they will be maintained and build your cluster around them.

[nipun_2]

Thank you all for your response. I now have better idea of how future organisation should be.

For current setup I will follow Ian's suggestion of keeping the server (DS25) with votes 1 and rest of the nodes (Xp1000 and EV68) with votes 0. So it should be (1+2)/2 = 1. Where expected vote limit is 1.

I just believe this kind of answers my question but if you have suggestions for future arrangement of shared storage (for e.g SCSI is good enough or another connector) Please feel free to comment on that.


One short question is when I am using Cluster_config LANCP utility in case if I am missing information at that time can I just hit Ctrl/Z or Ctrl/C and exit or would all that create problems when I again start the Cluster_Config file. Does the actual process of adding a root and other data happen only after I have answered all the Cluster_Config questions?

One other short question (just curious) I beilieve with my config I should have SYS0 and SYS1 as I have DS25 server and XP1000 node. However when I log in as System and try to go up the level I can only reach till SYS$SYSRoot:[000000] and SYS$COMMON.

[Joseph Huber_1]

Does the actual process of adding a root and other data happen only after I have answered all the Cluster_Config questions?

It happens somewhere in the middle. But that should not be problem, the procedure does a cleanup after a control-Y. It is not forbidden to read cluster_config*.com: just do it and see what is done on control_y !


One other short question (just curious) I beilieve with my config I should have SYS0 and SYS1 as I have DS25 server and XP1000 node. However when I log in as System and try to go up the level I can only reach till SYS$SYSRoot:[000000] and SYS$COMMON.

Sys$root and sys$common are "rooted" logicals. If you translate the logicals, You will see that the roots are sys$sysdevice:[sys*].