Re: NIC failover

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.

Oliver Fromme schrieb:
> 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
>

-- 
mfg.
chris
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message