Re: NIC failover

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

Oliver Brandmueller schrieb:
> Hallo.
>
> On Tue, Apr 26, 2005 at 12:57:45PM +0200, Oliver Fromme wrote:
>
>>Das ist eigentlich nicht besonders üblich, und zwar aus dem
>>Grund, weil ein NIC nicht unbedingt das ist, was am häufig-
>>sten ausfällt, sondern eher so Dinge wie Lüfter, Netzteile
>>oder Festplatten.
>
>
> Eben - und weil Lüfter, Netzteile und machmal sogar die beliebten
> Verbindungsstellen ausfallen (Kabel, Stecker), ist ein NIC Failover eine
> durchaus interessante und preiswerte Ergänzung beim Thema Redundanz;
> denn auch Switches haben Netzteile und Lüfter und benötigen manchmal
> Softwareupdates. Und wenn Du einen zentralen Storage hast (sprich NFS
> Server), dann hast Du das Problem einfach. Entweder fängst Du an mit
> verschiedenen Netzen auf zwei Switches und verlierst mit einem Switch
> die Hälfte Deiner Kapazitäten oder aber Du hast zwei Switches und die
> Server machen NIC Failover und alles läuft mit der kompletten Kapazität
> weiter, auch wenn Du einen Switch offline nehmen mußt (oder der das im
> schlimmsten Falle nachts von allein tut). Auch zur Anbindung an
> redundant ausgelegte Loadbalancer macht sich das nicht gerade schlecht.

es geht mir eigentlich um simple redundanz mehrerer switches (und ich
will mit trunking und spanning tree nicht mit kanonen auf spatzen
schiessen) - die hostseitige redundanz ist durch RRDNS in diesem fall
sowieso gegeben und somit nicht relevant.

>
> Das ist der Grund, warum man Netzwerkkarten mit zwei Ports und Failover
> Features erfunden hat, nicht weil eine Netzwerkkarte ausfallen könnte.

eben - das ist ein wichtiger punkt.

>
>
>>Wenn Hochverfügbarkeit gefordert ist, wird man daher eher den
>>kompletten Server redundant ausle- gen, sprich, zwei Rechner ins Rack
>>schrauben (und dann ei- nen separaten Loadbalancer verwenden und/oder
>>VRRP oder meinetwegen eine selbstgebaute Fail-over-Lösung). Damit ist
>>natürlich automatisch auch der NIC bzw. der Switch-port redundant.

ack

>
>
> Die Rechnung ist zu einfach. Wenn Du Deine Arbeit mit einem Rechner
> erledigen kannst und einen zweiten als Redundanz danebenstellst, dann
> ist die Sache relativ einfach. Wenn Du aber Load hast, die Du mit 8
> Rechner abfackeln kannst, dann stellst Du als Redundanz 10 hin und nicht
> 16. Dann dürfen Dir aber beim Ausfall eines Switches nicht 5 Rechner aus
> dem Loadbalancing fallen - dann ist nämlich jeder einzelne Switch ein
> Single Point of Failure.

absolut

>
>
>>Bei netgraph ist vermutlich ng_one2many das Naheliegendste.
>>Das erledigt aber nur die Verteilung der Pakete über ein
>>oder mehrere Interfaces; Du bräuchtest nach wie vor einen
>>Mechanismus, der bei einem NIC-Ausfall umstellt.
>
>
> Es gibt Failover-fähige Dual-NICs; ich glaube, die Frage des OP ist eher
> dahingehend zu verstehen, ob FreeBSD diese Fähigkeit sinnvoll
> unterstützt. Hier muß ich nach miener derzeitigen Kenntnis sagen, daß
> FreeBSD in Sachen NIC Failover noch etwas hintan steht.
>
> http://www.etinc.com/index.php?page=etfailover.htm

das habe ich beim google`n (mit ungläubiger verwunderung) auch
festgestellt - darum auch das posting hier.

danke für den interessanten link, damit wäre mein problem gelöst.

>
> Hab ich gefunden, konnte aber noch nicht testen. Also keine AHnung, ob
> das mit 5.4 tut und die Software was taugt etc.

werd ich mir mal ansehen.

>
>
> Interessant (hab ich mich aber auch noch nicht weiter mit beschäftigen
> können) ist dann noch die Möglichkeit, daß man up/down events auf
> Interfaces mittlerweile in FBSD wohl triggern kann. Damit kannst Du
> unter Umständen eine der beiden Karten auf down setzen, wenn DU für die
> aktive ein DOWN event bekommst, dann setzt Du die deinerseits statisch
> auf down und das andere (standby) Interface auf UP. Natürlich mußt Du
> bei sowas höllisch aufpassen, weil Du ein echtes Problem bekommst, wenn
> beide Interfaces up sind und Du somit für eine IP mehrere ARP EInträge
> erzeugst. Die Interfaces sollten hierfür im Bridging mode stehen. Zudem
> mußt Du natürlich mit den arp caches aufpassen.

ist sicherlich nicht ungefährlich - wie triggert man diese events?

>
> - Olli
>
>
>
> ------------------------------------------------------------------------
>
> !DSPAM:426e2d84439592066032273!

-- 
mfg.
christian damm
technische leitung
phone: dw 42
email: christian.damm(at)diewebmaster.at
icq at work: 124464652
die webmaster - flötzerweg 156 - 4030 linz - austria
phone: +43-732-381242, fax: +43-732-381242-22, isdn (leonardo): 
+43-732-381242-33
homepage: www.diewebmaster.at, public email: office(at)diewebmaster.at	
below you will find my public PGP key!
please use whenever possible to encrypt email messages you send to me.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
mQGiBD6BdjoRBAD6ZEPqO2y3jbudyWuMfj+84mOAOFa13d+bHjNsx5M3IXl0KDjL
LJZe7mO4aVX5Uo6zWskuVztXk4EdvIt96XkPweazYX7SN3w41QD6/lHGkQr5PO/b
Qp/G2KLFLQXjXUJibXMbNK8j4RtSHPFwJAXVVVO2uigsCnanMbr5KXqQmQCg/w/q
srHviHQuJXcfpTKB4ys2xnsEAOkLTDwQ5Z5SjRoAkxJywneOyG11uRqvlBaBNjyx
5mb0T+zh5ed0jmu1a91F5VRrXzAKyWfA4jc1/jpYpHpDW72bk8eF/WltxQ5LMfaJ
nqPcNEukMkm/lGCfk+Prtktz9/MoRnhxHreEasEqhYILlPFjG0Tg4yd618TPuRdf
qkR4A/0VCGzBPK289npn1ssIiNntOd0Dtu8UnbZGx4uPOP3jJP8awNH/XpV4Q8VZ
ePoZnjamYjPGDPIiBtLI60Wx7z4tDXlqKSUy7GkddGw0dGnNyiiHu/ESjd2cYX8y
/WkRnWyHcBRb4aEe4vYAt2PwP3Iemt9VMoPXJRQU6e6BkUzsbLQvQ2hyaXN0aWFu
IERhbW0gPGNocmlzdGlhbi5kYW1tQGRpZXdlYm1hc3Rlci5hdD6JAFgEEBECABgF
Aj6BdjoICwMJCAcCAQoCGQEFGwMAAAAACgkQjWTAFtIJONrURgCfWAdk77WMgOIL
GAkzXJGUghdSufUAn2BNvaFF8f4SnqyVAX6MSCeZFQsouQINBD6BdjoQCAD2Qle3
CH8IF3KiutapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSG
SfgMg71l6RfUodNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJ
Zv8V+bv9kV7HAarTW56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgN
RR0PfIizHHxbLY7288kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv88
4bEpQBgRjXyEpwpy1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsi
GSa6q6Jew1XpMgs7AAICCADV9CD8D0TdkGRs7bKIzh8pc7uWAprhqLF6B/KdVo+k
URDNWLVzpuR1ZVu612xLK/a7Q875P2DTdAuc1eBc0/5Q/jXH6pzo/lDmNbrFvJtu
p+GRGyC3hJF25TBDRNhKfIQYT+9pm6sOyLw+mh+ruHKi+PEwvTQK/gPHr5GAGKor
0EmYdfIGm2t1kFSifCm+/1jeITtQedDAlcN8ESBY+b+gONa1H/7LdPrWHVUPUs9k
WDwHFvTh8u28ixCcRaiT2wOkk7n+a2NPIe8LIznlbgwB8GK/7axIEXOBd0XyCyft
pJxYDZ4kxtRAD6CnpqswCzSaGJmllGwFD4QyWKKIFgCwiQBMBBgRAgAMBQI+gXY6
BRsMAAAAAAoJEI1kwBbSCTjaiC8AoKfArhjrTMto6hm7gQFc7hh+9W6RAKDqZloe
VR7EixSKaBhw5bZ5WUYM0Q==
=l3K/
-----END PGP PUBLIC KEY BLOCK-----
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 - 14:22:48 CEST

search this site