The answer to this one lies in the order of the network cards. It appears
that for fddi cards, unix doesn't care about the order. However for ethernet
cards it does! In order to get around my problem I had to redefine tu0 to be
the heartbeat and tu1 to be the main LAN connection. Once done the ASE path
status came up correctly for both.
After speaking to Compaq about this, they did say that they have seen
instances like this with clusters using memory channel. So they recommend
that the cluster interconnect interface is always the first interface used
in rc.config.
Dave.
Original message....
I have a two node ASE cluster that is located in two separate computer
rooms. The cluster is running 4.0e and TCR1.5. I have two ethernet
interfaces set up. One is to the main LAN (tu0), the other to a 'heartbeat'
LAN (tu1) that directly connects the cluster members.
I have set up in ASE to have tu0 as the backup network, which is monitored
by ASE, and tu1 to be the primary network, not monitored.
However I think for some reason ASE is not using the primary network as the
HSM_PATH_STATUS for this interface does not appear to come up - extracts
from daemon.log below:
ASE: local HSM ***ALERT: HSM_NI_STATUS:10.33.16.74:UP:10.245.40.4:UP
ASE: local HSM ***ALERT: HSM_PATH_STATUS:10.33.16.73:UP:10.245.40.3:DOWN
I have checked the interface, and from a network level they function fine
(ping, telnet etc.)
As a side note, when the cluster was built and members added the original
CLUSTER_NET used was the tu0 interface. However I don't believe this has an
effect here as I have another cluster that was built like this and I have
rearranged the primary and backup ase networks ok.
Can anybody explain why the HSM_PATH_STATUS might not come up?
Thanks,
Dave Campbell
(dave.campbell_at_vf.vodafone.co.uk)
Received on Wed Jun 23 1999 - 15:21:49 NZST