|
Home > Archive > WebSphere Edge Server > January 2004 > Use ND4.0.3 for HighAvailability on LinuxRH7.3
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Use ND4.0.3 for HighAvailability on LinuxRH7.3
|
|
|
| Hi
I have 2 IBM servers with Linux RH7.3 2.4.18xx kernel that I use as a FW
Cluster (Hot-Standby).
I try to use HighAvailability function in ND 4.0.3 as "take-over" sw.
I have it up and running, but the "switching" time for client going thru the
FW-cluster are quite long (about 3 min) if I don't clear the arptable on the
clients.
As a workaround I change MAC addresses with ifconfig ethx hw ether
40:00:20:F7:0E:xx, so the "HighAvailability" ip addresses always have the
same MAC address after switching between Primary/Backup. I have put these
commands in goActive and goStandby on both servers.
The "switching" time is bether, but it should be bether (15 sec -> 1 min)
This apply to a ping-test between to w2k serveres.
My questions:
Do I need to use arp_hidden patch ?
What will happened if I don't use it?
Here is my config file on primary, backup file is almost the same (different
ipaddress)
ndcontrol set loglevel 1
ndcontrol executor start
ndcontrol highavailability heartbeat add 192.168.7.51 192.168.7.52
ndcontrol highavailability heartbeat add 192.168.67.11 192.168.67.12
ndcontrol highavailability heartbeat add 192.168.73.3 192.168.73.4
ndcontrol highavailability backup add primary=192.168.7.51 auto 12345
ndcontrol highavailability reach add 192.168.7.60
ndcontrol highavailability reach add 192.168.67.59
ndcontrol highavailability reach add 10.247.73.34
ndcontrol highavailability reach add 192.168.72.34
ndcontrol highavailability reach add 192.168.7.100
ndcontrol highavailability reach add 192.168.67.60
ndcontrol manager start manager.log 10004
Rune
| |
|
| Rune,
When a takeover/failover occurs, the newly active ND will send out a
gratuitous arp for the cluster IPs that are moving. The one thing I
don't see in your configuration are the clusters. In this case, you're
not going to be loadbalancing but the clusters represent the Firewall
IPs that you want to move and stay with whichever ND is "active". The
go* scripts might be moving IPs but if there is no matching "cluster
add" then there will not be a grat arp sent out. That means you have to
wait for the clients to time out on their arp entries and send another
arp request.
In regards to the arp_hidden patch, you must have that if you are ever
going to have the loopback aliased on Linux. For example, unpatched
kernels will respond to arp queries for a loopback aliased IP -- even
though it's on the loopback. That can cause clients to be sent to the
"standby" ND instead of the active since it might respond to the
client's arp query first. In this case with no load balancing, it may
not be a big deal except that you'll be getting traffic through the
standby Firewall and may not expect or want that.
If you choose not to have the loopback aliased, then the problem you'll
encounter is that the grat arp is sent immediately during failovers;
however, goActive can take 10-20 seconds to run to actually move the IP
over. If the loopback is not aliased, then the box will not accept the
incoming cluster traffic, eventhough ND notified the network to send
traffic to this newly active box. So you would experience an outage of
10-20 seconds (more or less). That may be acceptable or preferred over
patching the kernel.
Hope that cleared some things up.
Jeff
| |
|
| Thanx Jeff
Yes I did understand some of it.
The configuration I have done are from Redbook for Network Dispatcher 3.6.
and there the cluster address (alias) are set in goActive
Question:
Should I remove cluster address from goActive and use ndcontrol cluster
configure 192.168.6.60 instead ?
Rune
"JLee" <leeja@NOSPAMus.ibm.com> wrote in message
news:3EB1358B.1040100@NOSPAMus.ibm.com...quote:
> Rune,
>
> When a takeover/failover occurs, the newly active ND will send out a
> gratuitous arp for the cluster IPs that are moving. The one thing I
> don't see in your configuration are the clusters. In this case, you're
> not going to be loadbalancing but the clusters represent the Firewall
> IPs that you want to move and stay with whichever ND is "active". The
> go* scripts might be moving IPs but if there is no matching "cluster
> add" then there will not be a grat arp sent out. That means you have to
> wait for the clients to time out on their arp entries and send another
> arp request.
>
> In regards to the arp_hidden patch, you must have that if you are ever
> going to have the loopback aliased on Linux. For example, unpatched
> kernels will respond to arp queries for a loopback aliased IP -- even
> though it's on the loopback. That can cause clients to be sent to the
> "standby" ND instead of the active since it might respond to the
> client's arp query first. In this case with no load balancing, it may
> not be a big deal except that you'll be getting traffic through the
> standby Firewall and may not expect or want that.
>
> If you choose not to have the loopback aliased, then the problem you'll
> encounter is that the grat arp is sent immediately during failovers;
> however, goActive can take 10-20 seconds to run to actually move the IP
> over. If the loopback is not aliased, then the box will not accept the
> incoming cluster traffic, eventhough ND notified the network to send
> traffic to this newly active box. So you would experience an outage of
> 10-20 seconds (more or less). That may be acceptable or preferred over
> patching the kernel.
>
> Hope that cleared some things up.
>
> Jeff
>
| |
|
| Rune,
If you're moving IPs in the go* scripts, then you'll want to have your
config do matching 'cluster add' commands. That ensures that ND sends
the grat arp out for the moving IP. So whatever IP represents the
active Firewall ... place it in the config and the go* scripts and you
should be okay.
Jeff
|
|
|
|
|