Re: NIC failover

On Tue, Apr 26, 2005 at 01:54:49PM +0200, Oliver Brandmueller wrote:
> 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.
>
> Das ist der Grund, warum man Netzwerkkarten mit zwei Ports und Failover
> Features erfunden hat, nicht weil eine Netzwerkkarte ausfallen könnte.

Das ist absolut nicht der Grund, weil die meisten Karten mit diesem
Feature erwarten, dass diese am gleichen Switch hängen, damit das
Spielchen funktioniert.
Sowas ist eher auf Fernebene interessant, wo Switch-Uplinks über lange
Glasfaserstrecken laufen und somit auch für Störungen anfällig sind,
aber nicht am Server selber.

> > 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.
>
> 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.

Dafür nimmt kein normal denkender Mensch NIC-Failover, sondern
IP-Failover, nicht zuletzt, weil du ja eh bereits einen Load-Balancer
da stehen hast.

Du möchtest dir in dem Zusammenhang vermutlich auch mal carp(4) ansehen.

> > 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.

Mit ist keine Fail-Over-fähige NIC bekannt.
Allesamt sind normale Dual-NIC mit Software - im Regelfall per FEC,
was aber, wie oben schon erwähnt, den gleichen Switch voraussetzt.

> http://www.etinc.com/index.php?page=etfailover.htm
>
> Hab ich gefunden, konnte aber noch nicht testen. Also keine AHnung, ob
> das mit 5.4 tut und die Software was taugt etc.

Toll - proprietärer Kram.
Die vorhandenen Standards finden keine Erwähnung, von daher gehe ich
davon aus, dass der Hersteller seinen eigenen Kram gemacht hat.

> 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

Du kannst dich nicht auf ein Up/Down verlassen, wenn du davon ausgehst,
dass ein Kabel defekt sein kann.
In dem Fall ist nämlich mitunter nur eine Datenrichtung gestört.
Du musst schon ein höherliegendes Protokoll haben, dass die
tatsächliche Funktionalität prüft.

> 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.

Deshalb gehen alle ordendlichen Verfahren hin und verlagern das auf eine
virtuelle NIC, bei der nach dem Failover die neue mit der gleichen MAC
weiterläuft - setzt natürlich voraus, dass auch die Switche mitspielen
und das STP für eine schnelle Migration der MAC auf den neuen Port
sorgt.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message