Re: NIC failover

Oliver Brandmueller <ob(at)e-gitt.net> wrote:
> 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.

Wweshalb man zwei (redundante) Server an zwei getrennte
Switches (oder Loadbalancer à la Alteon) anschließen würde.
Dazu braucht man kein NIC-Failover.

> Und wenn Du einen zentralen Storage hast (sprich NFS
> Server), dann hast Du das Problem einfach.

Das kommt jetzt sehr auf die Größenordnung (und Preislage)
an. Bei jedem besseren NAS-System (z.B. ein NetApp-Filer-
Cluster) hast Du das Problem nicht.

> Entweder fängst Du an mit
> verschiedenen Netzen auf zwei Switches und verlierst mit einem Switch
> die Hälfte Deiner Kapazitäten

Ich dachte, es ging hier erstmal rein um Verfügbarkeit,
nicht um Load-Balancing, man verliert also erstmal gar
nichts, wenn einer der beiden Server allein für die Zur-
verfügungstellung des Dienstes genügt. Redundanz auf
Serverebene braucht man sowieso.

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

Ich nahm an, um genau so einen Fall ginge es hier.

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

Das stimmt natürlich (bzw. Loadbalancer statt Switches).

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

Nicht weitergehend als bei Dual-NICs ohne diese Fähigkeit,
oder einfach zwei separate NICs.

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

Dieses Problem kann man -- zumindest bei Verwendung von
ng_one2many(4) -- umgehen, indem man den beteiligten NICs
dieselbe MAC-Adresse gibt. Die Switches müssen dann beim
Umschalten natürlich umlernen, aber das geht i.allg. recht
schnell.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message