Ocfs2 users - Nov 2008 - Generic question about cluster communication (with user mode heartbeat)

I'm using ocfs2 on sles 10 (sp2)with user mode heartbeat on two node
cluster.

ocfs2-tools-devel-1.4.0-0.5
ocfs2-tools-1.4.0-0.5
ocfs2console-1.4.0-0.5
heartbeat-2.1.4-0.4

heartbeat clustering is configured to use two separate network
interfaces eth0 and eth1. iSCSI SAN is accessed via eth2 and eth3.

on /etc/ocfs2/cluster.conf I have configured ocfs2 cluster nodes with
addresses from interface eth0.

What happens if interface eth0 (or switch behind it) goes down when
cluster is on line? Do nodes still see others/heartbeat via eth1?


Reason I'm asking this that during offline hardware maintenance network
cable (eth)  of second node was disconnected. And when I was trying to
start cluster I cannot get ocfs2 up before I connected that cable.

User mode heartbeat and other cluster services were working fine at same
time with degraded network connections.


Regards

Petri Asikainen

When eth0 went down, ocfs2 (specifically o2net/o2dlm) was unable to talk
to the other node. So the result is expected.

Have you looked into bonding the two and using that bonded interface for
both heartbeat and ocfs2?

Sunil

Petri Asikainen wrote:
> I'm using ocfs2 on sles 10 (sp2)with user mode heartbeat on two node
> cluster.
>
> ocfs2-tools-devel-1.4.0-0.5
> ocfs2-tools-1.4.0-0.5
> ocfs2console-1.4.0-0.5
> heartbeat-2.1.4-0.4
>
> heartbeat clustering is configured to use two separate network
> interfaces eth0 and eth1. iSCSI SAN is accessed via eth2 and eth3.
>
> on /etc/ocfs2/cluster.conf I have configured ocfs2 cluster nodes with
> addresses from interface eth0.
>
> What happens if interface eth0 (or switch behind it) goes down when
> cluster is on line? Do nodes still see others/heartbeat via eth1?
>
> Reason I'm asking this that during offline hardware maintenance network
> cable (eth)  of second node was disconnected. And when I was trying to
> start cluster I cannot get ocfs2 up before I connected that cable.
>
> User mode heartbeat and other cluster services were working fine at same
> time with degraded network connections.
>
> Regards
>
> Petri Asikainen
>