Re: NIC failover

From: Christian Damm <christian.damm(at)diewebmaster.at>
Date: Tue, 26 Apr 2005 16:45:30 +0200

Oliver Fromme schrieb:
> Christian Damm <christian.damm(at)diewebmaster.at> wrote:
> > evtl. habe ich mich auch ein wenig unklar ausgedrückt:
> > mir geht es nur um die redundanz eines 24 port switch`es - bisher tut
> > meine shellscript lösung was sie soll, allerdings hat es mich sehr
> > verwundert dass es keine anderen (einfachen) lösungen für dieses problem
> > gibt.
>
> Und das wird nur für einen einzelnen Rechner benötigt?
> Oder für eine ganze Farm? Irgendwie fehlen da noch ein
> paar Infos über das Umfeld, damit man die Lage besser
> beurteilen kann (und die Sinnhaftigkeit von Lösungen).

scheint so

>
> In meiner ersten Mail nahm ich an, daß es nur für einen
> einzelnen Rechner benötigt wird (es klang irgendwie so
> in der Frage) -- und dann ergibt NIC-Redundanz definitiv
> keinen Sinn.

in dem fall hätte es wohl wirklich keinen sinn.
ich habe eine kleine serverfarm mit 8 hosts (6 MTA`s (postfix) + 2 DB
backends) - die MTA`s betreibe ich via round robin DNS (mx) redundant
bzw. load balanced. alle 8 hosts hangen ursprünglich an nem 24 port
10/100 switch (hp procurve 2524) und genau dieser sollte nun redundant
ausgelegt bzw. via failover protected werden.

meine low end lösung:
1.) ein zweiter hp procurve switch
2.) in jedem host ein zweiter NIC (oder ein dual port NIC)
3.) jeder host wird (via 2 x cat5 kabel) an jeweils einen switch connected
4.) einer der beiden NIC`s ist im normalfall DOWN
5.) mein shell script checkt (läuft auf jedem host) via cron auf
eventuelle ausfälle von switch1 und bringt im fehlerfall den master NIC
DOWN und den failover NIC UP.
6.) wenn switch1 tot wird switch2 verwendet

darum war meine frage: welche alternativen (auf applikations- bzw.
kernel-ebene) fallen euch da ein? gibt es failover NIC`s die von FreeBSD
supportet werden etc...

>
> Gruß
> Olli
>
>

-- 
mfg.
chris
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 26 Apr 2005 - 16:50:55 CEST

search this site