Re: Doppelte Anbindung

Peter Ross wrote:
> Oliver Fromme wrote:
> > Weil es nicht von FreeBSD stammt. Es wurde unter OpenBSD
> > entwickelt (unter dem Namen »trunk«). Später wurde es
> > nach FreeBSD portiert, da es zahlreiche Features bietet,
> > die mit Bordmitteln bis dahin nicht oder nur mit großem
> > Aufwand zu realisieren waren, z.B. FEC, das ziemlich
> > populär ist (sogar mein billiger NoName-Switch daheim
> > kann FEC).
>
> Dafür gibts eigentlich ng_fec(4).

Ja, aber das ist FreeBSD-spezifisch. Es wäre ja irgendwie
blöd gewesen, beim lagg(4)-Import von OpenBSD nach FreeBSD
den FEC-Support herauszuschneiden, nur weil's dafür schon
ein NG-Modul gibt.

Der Vorteil von lagg(4) besteht gerade darin, dass es ver-
schiedene Arten von Link-Aggregation in einem Tool vereint,
mit gemeinsamer Konfiguration, die man leicht ändern kann,
siehe die Beispiele in der Manpage. An einer Netgraph-
Topologie herumzuwursteln finde ich immer unintuitiv.
(Was aber evtl. ein Problem der vorhandenen Tools ist,
nicht ein prinzipielles Problem von NG an sich.)

Übrigens sieht es beim Bridging genauso aus wie bei Link-
Aggregation: Es gibt if_bridge(4) und ng_bridge(4).
Ersteres kann man mit mit ein, zwei ifconfig-Kommandos
bzw. zwei Zeilen in /etc/rc.conf einrichten, siehe die
Manpage. Die NG-Variante dagegen ist so komplex, dass
in der Manpage nichtmal ein Beispiel enthalten ist, sondern
es auf das Skript /usr/share/examples/netgraph/ether.bridge
verweist -- ein Skript mit knapp 200 Zeilen.

Und noch ein Punkt: Der Sourcecode von lagg(4) ist kleiner
als der von ng_fec(4) und ng_one2many(4) zusammen, obwohl
es deutlich mehr Features hat. Das ist auch nicht weiter
verwundertlich, da ng_fec und ng_one2many sicherlich viel
duplizierten Code enthalten.

Also, um ganz ehrlich zu sein, wenn ng_fec und nf_one2many
aus dem Source-tree herausgeschmissen würden, würde ich
ihnen keine Träne nachweinen.

> Ich habe bei FreeBSD öfter das Gefühl, daß es einen ganzen Kasten an
> Tools gibt, die aber nicht ins Auge springen, wenn man irgendetwas damit
> realisieren kann. Netgraph, GEOM etc.

GEOM funktioniert eigentlich sehr gut, auch ohne dass es
einem »ins Auge springen« muss. Wer z.B. einen Mirror
aufsetzen will, sagt entweder »apropos mirror«, was ihn
zu gmirror(8) führt, oder er schaut ins Handbook unter
Mirroring, wo er es ebenfalls findet. Gleiches gilt
für gjournal, geli usw., es ist alles ziemlich gut im
Handbook dokumentiert.

Netgraph wird im Handbook nicht näher erklärt, es wird nur
an einigen Stellen am Rande erwähnt, wo es als Mittel zum
Zweck eingesetzt wird (PPPoE, Bluetooth). Im Kapitel über
Bridging wird ausdrücklich if_bridge(4) der Vorzug gegeben.

> Das mag manche abschrecken, manchmal übersieht man auch was.
>
> Wie bekommt man z.B. mit FreeBSD eine Cluster-Lösung hin? Für annähernd
> jeden Bedarf ist so ziemlich alles da.

Das ist jetzt wieder ein ganz anderes Thema. Das Hauptpro-
blem ist, dass verschiedene Leute verschiedene Dinge unter
einem »Cluster« verstehen. Echtes Clustering kann man mit
FreeBSD nicht machen (und wird es auf absehbare Zeit auch
nicht können).

Wenn man dagegen so Dinge wie Loadbalancing oder Fail-over
auf Applikationsebene meint, dafür gibt es natürlich ver-
schiedene Lösungen. Teilweise haben die mit dem OS gar
nichts zu tun bzw. sind nicht FreeBSD-spezifisch; insofern
würde ich es nicht FreeBSD zur Last legen, wenn einem da
etwas nicht »ins Auge springt«.

Natürlich gibt es auch FreeBSD-Support für gewisse Funk-
tionen, die für »Clustering« nützlich sind; ich denke da
z.B. an CARP. Dazu gab's mal einen prima Artikel in
einer Online-Publikation (ich weiß ausm Kopf nicht, wo,
aber wozu gibt es Google).

Was ich damit sagen will: Wer weiß, was er sucht, der
findet auch die Infos dazu. Oder zumindest die Info,
dass es das Gesuchte nicht gibt.

Übrigens gibt es auch eine Mailingliste freebsd-cluster.

> Unter Linux gibt es halt 'ne fertige Lösung, und das mag für viele der
> Grund sein, daß man Linux nimmt. bis hin zur Annahme, daß FreeBSD das
> nicht kann.

Die Annahme ist erstmal korrekt, aus meiner Sicht.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message