Cluster with EVA

[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.