[Linux-HA] Multiple NICS and IP Failover
alanr at unix.sh
Mon Mar 8 13:14:40 MST 2004
Russell Adams wrote:
> I've got an AIX HACMP/HAGEO cluster I'm using as a reference setting
> up a Heartbeat failover cluster for some print servers, and I'm
> concerned about a portion of the failover functionality.
> Perhaps someone can help make this clearer.
> I have two rackmounted Intel's running Redhat ES 2.1. They each have
> dual nics.
> Their sole purpose in life is to run LPRng for printing, and it runs
> on both hosts at all times. Its a simple enough service I'm not
> worried about moving it between nodes.
> I want to use Heartbeat/ipfail to maintain a cluster IP that fails
> over between the nodes to guarantee that printing is always available.
> My setup is as follows:
> Cluster Failover IP: 22.214.171.124
> eth0 172.17.1.11
> eth1 172.17.1.13
> eth0:0 126.96.36.199
> eth0 172.17.1.12
> eth1 172.17.1.14
> eth0:0 188.8.131.52
> Each server has a private/nonrouting IP address for each adapter
> (172.17), and then an alias for its node specific IP address.
> Heartbeat is correctly assigning the cluster IP to eth0:1, as another
> IP alias. I've tested heartbeat, and failover of the IP is working
> properly as well.
> The specific problem is on one adapter failing causes a cluster
> failover. If eth0 dies, and eth1 is still communicating, my goal is to
> have the cluster IP move to eth1 instead of failing over to Server2 as
> it does now.
> Is this not consistent with how Heartbeat is supposed to work?
> Also, a lovely feature to have would be if the node specific alias
> could failover between interfaces if an interface failed like it does
> in AIX, but I don't expect that.
That's built into Linux (which explains why we don't do it in heartbeat).
It's called channel bonding, or NIC bonding. I think it would also handle
your previous case too... For your service (where it's up all the time), I
don't understand why failing between nodes is a big deal. One thing takes
about as long as the other...
It also looks like you've made this more complicated than it needs to be,
and may be getting less redundancy for your money in the process. It saves
a few IP addresses too...
If I were to do this myself I'd think about something like this:
> Cluster Failover IP: 184.108.40.206
> eth0 172.17.1.11 (configured at boot time)
> eth0 172.17.1.12 (configured at boot time)
If you specify your haresources file like this, then you probably don't
need the route:
If you take your other two NICs and connect them to each other by a
crossover cable, and configure them with distinct IP addresses (for example
on 192.168.x.y) and turn on ipfail with a ping node configured to somewhere
interesting and useful, you'll be in good shape. It will move the IP
address, but it's roughly as fast as failing it over locally, and there are
no single points of failure in the cluster infrastructure.
But if you REALLY want what you say you want:
If you configure channel bonding failover between eth0 and eth1, and use
the bonding interface in your haresources file and in your ha.cf file, then
all should be well. If there's a single point of failure in commmunication
between the two machines through eth0 and eth1 (and there very well may be
- maybe a switch or router), you can either configure a serial port to
connect the two machines via serial or another pair of NICs. Without
truly-redundant communications, split brain can happen under some
See the list archives for several discussions on channel bonding.
> I've read in the Getting Started Guide that the interface used depends
> on the routing table. In this case, does that infer that Heartbeat
> considers only the interface with a public address valid for use?
It defaults to using routes to figure out which one to use. It doesn't
know from public or private IP addresses. When given no interface
information, it cares about routes. If there's a route to the subnet in
question, it chooses it.
Note that routes are irrelevant when you specify the interface and netmask
explicitly (like I did in the sample haresources file I gave above).
According to what I've been told, it's your choice which way you'd rather
Alan Robertson <alanr at unix.sh>
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
More information about the Linux-HA