standby ethernet interface in RHEL cluster

Herta Van den Eynde herta.vandeneynde at gmail.com
Wed May 9 22:59:31 UTC 2007


On 07/05/07, aix tiger <aix_tiger at yahoo.com> wrote:
> Guys
>
>   I have finally implemented a fully functional RHEL cluster. I used HP ILO device as fencing device and all things are working fine.
>
>   I need to know , however, what are the ways of having additional heartbeat mechanisms in RHEL cluster. Right now , i have my ethernet card as SPOF and it's failure are automatically promoted to node failure.
>
>   I dont want to use ethernet bonding as my network admin is not confident about ethernet chaneel bonding support on his network swtich.
>
>   Is it possible to configure additional ethernet card ( present on my cluster nodes ) as standby interface so that when service ethernet goes down , service ip address automatically moves to standby interface ( not through ethernet bonding )?
>
>   Please advice!!
>
>   Polani

Not sure I fully understand your setup.  How many network interface
cards  (NICs) do you currently have?

If you want to avoid your NICs from becoming single points of failure,
you could argue that you really need four per cluster member: one
public NIC for communication with your application/end user, one
private NIC for intercluster communication, and two as backup for each
of the other two.

In theory, you could define a virtual ip address on the public NIC
(and another on the private NIC), and have that address fail over to
the backup NIC in case of problems.  The catch is that you need a
monitoring program in place that detects the NIC failure and moves the
virtual ip address before the cluster software notices the failure and
evicts the member with the faulty NIC.  If network traffic is heavy,
that can get tricky, as you may see false negatives.

Brand NICs are pretty reliable.  Depending on what you are using this
cluster for, it may be more efficient to have the applications fail
over to the second node, and simply have a spare network card
available in case of problems.

Kind regards,

Herta




More information about the redhat-list mailing list