Cluster with EVA

[WilliamSmith11]

Hi I am installing a cluster system in two machines ES45 and DS25 using a storage EVA3000 as the storage,
May somebody give me some idea about what is necessary to tuning.

I was getting a problem with the quorum disk , it was not possible to form the cluster when I had my quorum disk as a separate disk.

The solution was that the quorom be the boot disk in one of the two system,
Both machines can see the quorum and the boot disk from the prompt.

thank you

[Kris Clippeleyr · Accepted solution]

William,

Might this be related to the problem discussed in another thread?
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=886474
To form a cluster with a quorum disk, the 1st node to boot up will try to create the QUORUM.DAT file on the quorum disk. That disk has to be mounted quite early in the boot sequence, and the booting node must have enough votes to form the cluster.

Regards,
Kris (aka Qkcl)

[Jan van den Ende]

William,

what you have created now, is a cluster that depeends much too heavily on the quorum disk.
Since it is also the system disk for one node, loosing it also looses your cluster.

And maybe unrelated, but out of pure curiosity: WHY two system disks? Things get SOOOO much easier if you have only one common system disk!
... and if you DO have those disks available anyhow, then combining them into one shadow set adds A LOT of extra redundancy (just contrary to your single-system-dependant quorum disk.

hth,

Proost.

Have one on me.

jpe

[Ian Miller.]

both systems should have direct (not MSCP) access to the quorum disk otherwise there is no point.

[comarow]

Where is yoursystem disk.

Now there is an issue with using a quorum disk on fiber. It can reply quicker than a a keep alive message from the lan. Than the other node will clue exit.

This is a problem especially with large clusters where a small part of the cluster sees the quorum disk and loses connection to the rest of the cluster, and the rest of the cluster clue exits.

That said, for a two node cluster, there is no point in having a local system disk as a quorum disk, since that node has to be up. All you are doing is adding overhead, might as well give that system one vote and the other node 0 votes.

I suspect you weren't able to build quorum.dat on the eva disks, because you didn't have enough votes to boot without the quorum disk vote. Try setting the quorum disk to a shared device, and conversationally setting the votes on the booting node to a large number. It will then build quorum.dat. Then you can reset your voting scheme.

Bob C

[WilliamSmith11]

At first time we had only a boot disk for both machines in the EVA3000, but the customer have and applications that require separate Operating system.

The quorum disk also is in the EVA, but at first was a separate Virtual disk.

I am from the hardware support team; I asked to the software support about why the quorum has been set in one of the operating system disk, they explain to me that it was the only way that they were able to form the cluster.

When they try to form the cluster there was a lot of error and the only disk that was able to be take as an option of quorum was the
1$1dga1 and not the 1$1dga3 that was the initial disk that I have been presented to the system as the quorum disk.

1$1dga1 was the OS for the DS25
1$1dga2 the second disk that the customer need as a separated OS system disk for a ES45
1$1dga3 the quorum disk

All these disk were configured using the wwidmgr for that the systems can be able to see the disk from the >>> prompt.


The cluster has 3 votes,
I am going to ask them about the exact parameter that has been set in the nodes.

Have someone the guided procedure to form install the cluster using and EVA and VMS as the operating system (7.3-1),

All the Vms patches have been applied.

Thank I will appreciate your help.

W.S

[comarow]

But if the quorum disk can only been mscp served, than there's no advantage to having one.

Something is configured wrong, the quorum disk should be viewable from both systems at boot time.

[Volker Halle]

William,

there is no need to configure the quorum disk access path with WWIDMGR. This is only needed for boot (and dump) disks.

Boot your first node with EXPECTED_VOTES=1 (temporarily), DISK_QUORUM="$1$DGA3:" and QDSKVOTES=1. Once the system is up, mount/sys $1$DGA3: and CLUSTER_SERVER will create the QUORUM file. Check with SHOW CLUSTER/CONT 'add cluster', you should see QF_VOTES=YES

Once this is done, reset EXPECTED_VOTES=3 and reboot the node, this will prove, that everything works as expected and that one node together with the quorum disk works fine. Then boot your second node and check, whether it can also acess the QUORUM disk locally.

Volker.

[Edgar Ulloa]

I had the same issues
I build my cluster with same machines and same eva storage..

The principal issue was because you have
4 principal network cards for each machines.

you needs to define the principal network card

ewa-0 and eia-0 ( close in decnet the circuits and links) fisicly put in your principal card speed 100 full duplex

and the quorum will be found inmediatly.

If you have more issues with your cluster tell me I will put in production next week the mine.

Edgar

eulloa@tecnasa.com

[Uwe Zessin]

I have never heard that a VMScluster has a requirement for a 'principal' (master) network interface. All nodes must be able to talk to all nodes, however.

If both nodes cannot talk over the network interconnect, then you have a problem that is completely independent from a potential quorum disk problem.

WATCH OUT! In that case, do NOT play with VOTES and EXPECTED_VOTES settings, because that can cause a 'partitioned' cluster - well, better call that two single-node clusters on the same storage array which will happily corrupt your disks.

You only hope is that you have properly configured your quorum disk, so that both node learn from each other through the quorum file and prevent any corruption.

[Edgar Ulloa]

Uwe
I only write how fix the issue.
with 2 nodes
votes=1
expected_votes =3

==== always this parameters -----

I want
disk_quorum $1$dga3:

system ds25 live in $1$dga1
system es45 live $1$dga2

I can't join the quorum $1$dga3 in both nodes

before my quorum was in same system disk
$1$dga1:

when I change the cards speed and full duplex
define only one card exit
also verify the patch fibre scsi and cluster for ovms 7.3-1

now im running and both nodes see well my quorum disk $1$dga3:

Also in the startup_vms.com always first must be run decnet before tcp-ip.

whiliam try that if you have issues send me email I passed for same troublets and now im fine.

if you will be run decnet/phase iv and lat verify your lat$link because the cards will be give you head ache
cheers

[Anton van Ruitenbeek]

SCS looks over the cards (it doesn't have to be configured for DecNET or TCP). Its already up before any network is started !!
LAT is very easy to do. In SYS$STARTUP:LAT$SYSTARTUP.COM you can add a link for every NIC card. So LAT will run over every card which is available !
If you are using DecNET OSI and using phase IV functionality DECNet must be up before IP may start (is written in the manuals). If you're not using phase IV functionality (you have to set it off) it doesn't mather. This has to do with the modification of the MAC-adress (it become a translation of the DECNet address) on the phase IV interface.

And yes, if the quorum disk is the systemdisk (of one of the machines) it doesn't make any sence.

AvR

[comarow]

There is no advantage to having a quorum disk on a disk only seen by the system disk.

Why not a shared system disk? It will cut your system management in 1/2.

1,000s of customers use non system disks as quroum disks. However, there are paremeters in case the quorum disk responds faster than the other systems on the network. It could then become your network and the other nodes clue exit. There is a workaround.


Something is wrong with your configuration.

To explain why the quorum disk should be a non busy disk, if an io is forced to wait, such as during backups, you will get lost connection to quorum disk.

There are parameters which say which disk is presented at boot time.

[comarow]

On the "principal" network connection,
the utility scacp
$mcr scacp lets you set priorities on your preferred path.

It will still test all paths. If you want to reduce redundancy and traffic, you can turn them off for cluster traffic in scacp.

Once again your quorum disk in a 2 node cluster is a great idea, as it gives you flexibility. It should not be the system disk as it has too much activity and you will get lost connection to quorum disk messages when activity builds up, especially backup.