„Angeblich“? Ich nehme an, du meinst damit, dass du dich da auf Aussagen von anderen (vermutlich upstream) stützt, oder?
Falls das stimmt (wird sich ja bald herausstellen): Gibt es da schon eine Liste von Möglichkeiten, wie man danach noch weitermachen kann? Muss ja noch nichts entschieden oder vollständig evaluiert sein, eine einfache Auflistung von Möglichkeiten als FYI wäre ganz schön. Das ist nämlich ein wenig frustrierend, da sich das bis jetzt für mich als Außenstehenden so anhört, dass uns bald alles um die Ohren fliegt und nicht bekannt ist, ob man da wirklich was dran ändern können wird.
Außerdem bin ich gerade verwirrt. Zumindest @maltis hatte mir mal in einem anderen Faden gesagt, dass es zum Splitten von Domains keinen sinnvollen Grund gibt. Aber so ein Radikalschnitt würde zumindest das Problem mit der großen Broadcast-Domäne doch lösen, oder nicht? (Mir ist klar: Man verlagert das Problem auch nur weiter nach hinten, bis die Teildomänen eben wieder so groß sind…)
Wenn ich BATMAN richtig verstanden habe, führt doch mittelfristig kein Weg daran vorbei, die Geo-Locations (also die physikalische Entfernung) beim Broadcasting zu berücksichtigen.
der >1km entfernte Knoten muß ja nix von meinen Clients wissen (so lange die nicht selber für irgendwas Server sind)
…aber vielleicht hab ich das ja auch nur falsch verstanden.
Der Maltis ist nicht allwissend
Grundsätzlich haben wir es hier mit etwas zu tun, was es so noch nicht gab. Daher ist es schwierig auf Erfahrungswerte zurückzugreifen.
Lasst unsere Admins mal schauen und eben Erfahrungswerte sammeln. Paderborn und Hamburg haben jeweils ca 600+ Nodes in einer Domäne mit (imho) ähnlichem Setup laufen. Rheinufer hatte heute Mittag 401 und Ruhrgebiet 441 Nodes. Ich könnte mir vorstellen, dass auch der kommende 31c3 Gelegenheit für Austausch bieten wird.
Mit dem @pberndro habe ich mich heute auch schon kurz über mögliche Kapazitätsgrenzen und Lösungen unterhalten. Für Konkretes ist es aber noch zu früh.
Übrigens auch eine interessante und unvorherschaubare Komponente in diesem Problemkomplex ist die Tatsache, das B.A.T.M.A.N. stetig weiterentwickelt wird. Mal schauen, was da noch so kommt.
Lasst unsere Admins mal schauen und eben Erfahrungswerte sammeln. Paderborn und Hamburg haben jeweils ca 600+ Nodes in einer Domäne mit (imho) ähnlichem Setup laufen. Rheinufer hatte heute Mittag 401 und Ruhrgebiet 441 Nodes.
Das klingt schonmal ganz gut und erstmal beruhigend.
Müssen wir wohl einfach schauen…
Da wir im Gluon den Split Horizon Patch des Batman benutzen, ist der Batman Upstream Traffic auf den DSL Leitungen kurzfristig kein Problem, Hamburg hat laut Leo ca. 60 kbit/s:
Anhand der Alfred Daten haben:
Ruhrgebiet 435 Router im Netz
Rheinufer 330 Router im Netz
Also sogar noch deutlich weniger Router als die Hamburger.
Ich habe nun insgesamt vier Supernodes am Laufen. Alle vier nehmen Verbindungen von Nodes an, jedoch die beiden schwächeren Systeme, die auch routen, nur bis zu jeweils 100. Die stärkeren Systeme nehmen beliebig viele Nodes (Fastd Peers) entgegen, sind aber bisher nicht fürs Routing zuständig, sondern leiten die Verbindungen nur über die zweite Fastd-Instanz weiter. Diese ist mit AES-128 gesichert, was auf den Xeon-Prozessoren bessere Leistung bietet, als der auf den Node-Verbindungen laufende Cipher SALSA-2012.
Momentan haben die Supernodes alle etwa 50-60% Auslastung. Es ist also angezeigt, möglichst bald weitere Systeme an den Start zu bringen. Dann werde ich auch Routing auf allen Supernodes konfigurieren. Das erfordert jedoch auch Arbeit am Rheinland Backbone, die nicht ohne Unterstützung beginnen möchte. Beim Congress werden wir dazu vielleicht Gelegenheit haben.
Der Split wird nicht aus politischen Gründen notwendig (wie es vermutlich @maltis gemeint hat), sondern aus technischen. Du bemerkst bereits richtig, dass es etwas mit dem Broadcast-Traffic zu tun hat. Da gibt es Optimierungsmöglichkeiten, wie @CHRlS weiter unten angemerkt hat. Dennoch stoßen wir irgendwann an eine Skalierungsgrenze und müssen dann splitten.
Wenn wir das tun, müssen wir vorher genug fähige Admins im Team haben. Beide entstehenden Domänen sollen autonom sein und ihre Probleme eigenständig lösen können. Das ist eins der schwierigen Probleme bei diesem Vorgang. Zu der technischen Durchführung gibt es mehrere Ideen; lasst uns diese nicht an dieser Stelle diskutieren, denn das führt uns von dem akuten Problem weg.
Rheinufer muss zum jetzigen Zeitpunkt mindestens 6 Supernodes haben, besser 8, da selbst bei 6 das festgelegte 100 Router / 2 Supernodes Verhältnis schon wieder leicht überschritten ist.
Ja, ich weiß. Wir haben 6 CPU am Laufen, da zwei der Supernodes Dual-Xeon-Systeme sind. Wenn mehr notwendig erscheint, müssen wir die Formel mit dem Vorstand neu bestimmen.
Und: 400 Nodes sind verdammt viel. Vor ein paar Monaten waren es noch die Hälfte. Ich bin beeindruckt und mein Tatendrang ist größer denn je.
Hier kann man schöne sehen, wie der Traffic (Grün/Violett) sich auf vier Systeme verteilt hat und die CPU-Last (Gelb) ebenso. Die Lücke bei Rheinufer1 ist ein Absturz des Systems (Kernel Panic), der heute Mittag geschehen ist. Die Ursache ist mir unklar.
Ich weiß nicht, ob das Paket weiterentwickelt wurde oder es einfach nur 2013.4.0 enthält und mit DKMS ein Kernelupdate vereinfachen soll. Auf die Schnelle habe ich gerade nichts darüber gefunden.
Ich würde es mit der von @phip verlinkten Version versuchen, die hat auch noch zusätzliche Patches und ist so gesehen „kompatibler“ mit der Version auf den Nodes.
Das war übrigens der Grund, warum ich akut nochmal einen Satz Experimental-Builds für Gluon gemacht habe. In der Hoffnung damit die „verschwundenen Nodes“ im alfred oder beim ipv6-batman-routing reduzieren zu können. Bin mir aber unschlüssig, ob das hilft, denn der Effekt tritt immer noch auf, wenn auch gefühlt seltener.
Gefühlt liegt die Grenze des Machbaren bei 500 Routern pro Domain.
Weil irgendwann der elende Broadcast-Traffic (egal ob mit oder ohne Split-Horizon-Patch) so arg wird, dass Standort mit „DSL-Lite“ schlicht gar nicht mehr genug Upstream haben und schon mit dem Broadcast-Mist ihren Upload „saturieren“.
P.S.: Communities statis zu bilden „Nach Ortschaften“ mag nahe liegen.
Meine Vermutung ist jedoch, dass dabei stets sehr unterschieldich große Gebilde bei herauskommen, da das Wachstum nicht überall gleich bleiben wird. Ausserdem wird man immer wieder von neuem Teilen müssen.
Schöner wäre es, diese Segmentierung des Netzes irgendwie automatisiert hinzubekommen.
Idee „in die Tüte gesprochen“:
Man könnte man anhand der AP-Stationen herum (auch den „Nicht-Freifunk-ESSIDs“, alles was ein iw scan so ausgibt) anhand freier Datenbanken schon gut geographich lokalisieren. (Falls bei der Einrichtung keine Koordinaten hinterlegt wurden)
Und dann könnte man die Nodes nach einem ersten Handshake mit einem „Dispatcher“ gemäß Geokoordinaten und gehörter Nachbarn in eine regionale Wolke geben (also ihnen die Liste der für sie zuständigen Supernodes übergeben.)
Wie man das öffentliche Routing der IPv6-Adressen dann hinbekommt, das müsste man noch prüfen, evtl. nochmal umswitchen nach diesem Dispatch) #
Auf jeden Fall hätte man Wolken, die in ihren Grenzen je nach Netzentwicklung durchaus dynamisch wandern könnten. Langsam zwar, aber eben so, dass sie Lastsituation in den einzelnen Teildomains ähnlich bleiben.
Wie gesagt bei 620 Nodes hat Hamburg derzeit 60 kb/s upload „waste“, das skaliert also noch deutlich größer…da ist bislang noch niemand im Zwang gewesen splitten zu müssen!
