topic Re: server failover with nics in Operating System - Linux

server failover with nics

Anoop Bhat — Fri, 15 Oct 2004 09:58:32 GMT

I have two proliants which i would like to "cluster" for lack of a better word.

i want to team two nics (one from each machine) in a way where if one machine fails, then the other will pick up.

Any suggestions on how to do this?

Someone suggested ultramonkey.org but I thought i would ask about it here since its an HP product.

thanks

Re: server failover with nics

Steven E. Protter — Fri, 15 Oct 2004 10:23:35 GMT

You have several options. Proliants will work with ServiceGuard, which has been ported to Linux. It requires some money and some shared storage but it works very well.

There are other alternatives.

Red Hat Enterprise Edition has a clustering technology built in. That costs less.

There is also a low/no cost alternative called ha-linux. http://www.ha-linux.org

I'm working with this latter product to increase the availability of my web servers.

If you've got the budget and want HP to support you, I'd go for ServiceGuard.

SEP

Re: server failover with nics

Anoop Bhat — Fri, 15 Oct 2004 11:35:16 GMT

steven, thanks for the prompt reply.

i noticed redhat's clustering service but it needs a san connection and stuff like that.

i'm looking into ha-linux as i type this to find a free solution that doesn't need me to have two server that are san attached.

thanks.

Re: server failover with nics

Anoop Bhat — Fri, 15 Oct 2004 12:57:41 GMT

I also wanted to add that I want to do this without the use of any sort of director.

I want to use two machines that will broadcast a virtual ip and have serverB take over if serverA does for some reason.

is this possible? This would reduce for one thing but it increases the difficulty of this project.

thanks.

Re: server failover with nics

Darrin St. Amant — Fri, 15 Oct 2004 13:38:34 GMT

Anoop,

No matter what solution u use your going to have to have a shared storage device, be it SCSI, or SAN, because the cluster will have to have a quorum disk. This quorum, shared disk, is used for node uptime integrity.

cheers!
ds.

Re: server failover with nics

Steven E. Protter — Fri, 15 Oct 2004 13:45:55 GMT

ha-linux seems to be able to do the job.

The feature that should be of interest is the ip failover.

Example

host1 is 192.168.0.41
host2 is 192.168.0.42

The two hosts are connected by a heatbeat lan. I use a dedicated hub.

If host1 fails this is detected by the ha-linux configuration and host2 takes over the ip address 192.168.0.41. The individual services or appliations taht you want to fail over need to be configured to work correctly on host2 with the newly failed over IP address.

Is it virtual ip address or network card teaming? No. Does it maintain high availablity? Yes.

With Intel NIC card's I've been able to add an additional feature to Red Hat ES 3 and Fedora.

I've been able to take two of these cards and bond them to one single ip address. This does not effect ha-linux, but it does improve the chances of the server staying on the network in the even of a single card failure.

I've got this feature activated on a little NAS device I designed for my Enterprise. It works well and improves bandwidth when both cards are up.

SEP

Re: server failover with nics

Anoop Bhat — Fri, 15 Oct 2004 13:54:00 GMT

Yes, i don't believe a quorum disk is needed in the linux-ha case which actually seems quite plausible.

However, I'm wondering if i need the private network at all.

each of these machines has 2 nics and I'd like to team them and then use the linux-ha heartbeat on the virtual ip and have them determine if one is down or up over the virtual ip.

does this sound plausible?

Re: server failover with nics

Darrin St. Amant — Fri, 15 Oct 2004 13:55:37 GMT

oops I stand corrected....

Linux-HA has no special shared disk requirements.

so this is probably what your looking for.

ds

Re: server failover with nics

Steven E. Protter — Fri, 15 Oct 2004 14:01:49 GMT

Does it need the hearbeat LAN? Maybe not.

Do you need to do it?

Yes.

The way HA works is that you set applications to fail over between nodes. It there is significant congestion on your network failover or TOC crash could be triggered in your cluster.

That is bad.

SEP

Re: server failover with nics

Darrin St. Amant — Fri, 15 Oct 2004 14:01:58 GMT

check out configs here. Think your going to need seperate your heartbeat/LAN comm on interfaces...

Basic Configurations
A Basic Single IP Address Configuration (newbies start here)
A Two IP address Active/Active Configuration
A Basic Apache Web Server Configuration
Two Apache Web Servers in an Active/Active Configuration

http://linuxha.trick.ca/GettingStartedWithHeartbeat

Re: server failover with nics

Serviceguard for Linux — Fri, 15 Oct 2004 19:19:48 GMT

A Couple of points -

Red hat clustering is subscription, so you pay for it every year.

Serviceguard can be implemented without shared storage. Any reasonable cluster must have a quorum mechanism. When heartbeats are not received, you need to determine if its because of networking issues or problems with the other server. When shared storage is available, there are algorithms that can use that shared storage and account for networking problems.

Serviceguard has two options. One is this disk based mechanism. It also implements a "quorum service" running on another system (can be a PC). This way if your apps don't require shared storage, you don't have to spend the $$s.

Re: server failover with nics

Anoop Bhat — Tue, 19 Oct 2004 10:43:48 GMT

Thanks for all the responses everyone.

I've implemented the heartbeat package and thus far i'm pretty satisfied with it.

I haven't had to pay for any extra hardware.

Currently, I've got two dual homed 360 G3's and the heartbeat runs over the bonded nics.

It fails over quite well.

However, in the case where i down eth0 and up it again, the heartbeat just fails entirely.

any ideas why? technically eth1 does pick up the heartbeat if eth0 is down but if i up eth0 again, the virtual ip for the heartbeat just craps out and i'm not certain why.

thanks