Last auf den Wirtssystemen / Baustellen für die Zukunft

Freifunk Rheinland e.V.
1

Fortsetzung der Diskussion von Backbone Frankfurt Totalausfall?, da die Antwort darauf dort nichts zu suchen hat und total ohne Bezug zum Thema wäre:

Die Domäne Wupper versorgt mit vier Servern über 1500 Knoten – ca. 375 Knoten/Superknoten. Dies ist aber nicht der Grund für die hohe Nutzung der CPU. Je höher die Bandbreite, desto höher die zur Verschlüsselung aufzubringende Rechenleistung. Jeder Superknoten wird in Wupper mit um die 60-100 Mbit/s ausgelastet.

Wir sind schon längst nach Berlin umgezogen … Am liebsten würde ich überhaupt keine Superknoten nutzen, da ich eigentlich Freifunk- und Batbone- und nicht Backbone/VPN-Infrastruktur aufbauen wollte. Aber wir sind nicht bei „wünsch’ Dir was“ sondern bei „so is’ es“.

Es liegt neben all den anderen vServern auch an an Wupper, dass ein Wirtsystem voll ausgelastet ist. Machen wir uns nichts vor, die Server sind total überbelegt. Dies wird auch so bleiben, bis die Mitglieder nicht den halbtotalen Überblick über die Vereinsfinanzen erhalten haben, um

  • eigene Server zu Akquirieren
  • ihre Servernutzung an die gesammelten Spenden anzupassen
  • den Freifunknutzern aufzuzeigen, dass sie noch mehr spenden müssen

Des Weiteren sollten Mitglieder die Befugnis erhalten nach Absprache mit dem Vorstand im Namen des Vereins Server zu akquirieren, um

  • den Vorstand zu entlasten
  • für die Server gesammelten Spenden steuerlich absetzen zu können
  • den eigenen Bedarf und Wachstum anzupassen
  • eine Sachspende erhalten zu können
  • Bsp.: Unternehmen bietet Hardware/Netzwerk gegen Geld an, das Geld wird vom Unternehmen am Rechnungstag sowie jeder weiteren Rechnung in eine Spende umgewandelt

Dies sollte nach einer Richtlinie geschehen (z. B. dieser Hoster ist empfehlenswert, da beste Leistung/Preis). IMHO fahren wir durch die Virtualisierung extrem effizient, da nach meinem Kenntnisstand die Virtualisierung die Ressourcen gleichmäßig auf die einzelnen Domänen verteilt. Wupper mag ja auf den ersten Blick viele Ressourcen benötigen, Wupper leistet aber auch viel. Genaues kann ich nicht sagen, da mein Aufruf zum Domänenvergleich vor ein paar Wochen keinen großen Anklang fand. Wupper hat aber unterm Strich nur vier vServer mit vier IPs für 1500 Knoten.

Es liegt im Verantwortungsbereich jedes Superknotenadministrators die zur Verfügung gestellten Ressourcen maximal effizient zu nutzen und notfalls bei Engpässen die Bandbreite zu drosseln. Es bringt nichts ein System mit einem Kern bei einer Load höher eins zu betreiben, da Paketverluste auftreten, die mehr Frust als Nutzen verursachen. Deshalb sind sogenannte „Offloader“ eigentlich grober Unfug, da bei solchen Lösungen über eine andere, effizientere Art der Anbindung nachgedacht werden sollte, die sich für die Superknoten besser eignet, als den verglichen mit normalen Queens höheren Datenstrom mit fastd zu verschlüsseln. In so einem Fall muss innerhalb der Freifunk-Gemeinschaft/Domäne gesprochen werden, wie dies effizienter verwirklicht werden kann, statt als Freifunk-Nutzer darauf zu pochen, dass man mit einem 100/10-Mbit/s-Anschluss ein Anrecht auf die maximale Freifunk-Bandbreite hat. Will man mehr, so muss dies effizienter – notfalls unverschlüsselt – erfolgen.

Baustellen auf diesem Gebiet:

  • „offloader“ effizienter anbinden
  • fastd-Effizienz durch Ingenieurskunst verbessern
  • wo es machbar ist, auf Verschlüsselung verzichten
  • effizienter verschlüsseln mit Blick auf das Machbare auf den kleinen Routern und den großen „Offloadern“ (AES/fastd/… siehe Stromverschlüsselung)
  • Softwareinterrupts minimieren, in denen die Maschine mit dem Warten beschäftigt ist
  • private Server als Puffer beim Domänenwachstum verwenden, bei derer Überlauf neue Infrastruktur unbürokratisch beschaffen wird
  • Anzahl der fastd-Tunnel auf einen pro Queen minimieren
  • batman wird so gleichmäßiger auf die Server verteilt, wodurch die Nutzer vom zuständigen und nicht dem besser, flotter oder Latenz ärmer angebundenen Superknoten eine IP mit dessen GW-IP erhalten
  • Batman verbessern, damit
  • die Ausfallrate der Server und dadurch hervorgerufenen künstlichen Engpässen sinkt
  • unterschiedliche Schnittstellen (fastd/n2n/L2TP/…) gleichzeitig über den Batman-Mechanismus an Batman angebunden werden
  • Dezentralität steigern
  • Vermaschung in der Freifunk-Gemeinschaft erhöhen
    • WLAN/LAN/MAN-Batbone ausbauen
    • AP/fastd-zu-Superknoten vermeiden
  • „Fiber to the Roof“
  • Superknoten im Keller
  • Peering mit ansässigen Unternehmen/Forschungs-/Bildungseinrichtungen
    • muss kein Transit sein, fragen kostet aber nichts

Es gibt viel zu tun. Ich habe bei mir bemerkt, dass ich mich immer weiter vom Freifunk entferne, je mehr ich mich auf die Superknoten konzentriere. Wir alle verlieren den Blick für den Freifunk, wenn wir unsere Denkweise nur auf Queen-Superknoten beschränken. So lange, wie wir im Verein/Freifunkgemeinschaft so handeln wie bisher, so lange müssen wir mit den Engpässen leben und das beste d’raus machen.

  • kommuniziert mit den Nutzern
  • sammelt Spenden für die Infrastruktur (machen alle vor Weihnachten)
  • veröffentlicht die derzeitige Finanzlage, damit wir handlungsfähig bleiben

Ich habe vergessen, worauf ich eigentlich hinaus wollte. Ach ja, Wupper verbraucht viele Ressourcen – wie effizient sind die anderen Domänen? Ich will ja lernen nicht so viel zu verbrauchen.

3 „Gefällt mir“
2

es sollte allen klar sein, dass dies erst der Anfang der Probleme ist. Denn es kommen noch massig Flüchtlingsunterkünfte hinzu, nicht nur in Wupper, die alle eine hohe Auslastung haben (werden).

D.h. es müssen dringend vom Vorstand die von Phip gestellten Fragen verbindlich beantwortet werden, vor allem: wie Server einbinden/bezahlen und was ist an Geld da. Wir brauchen Planungssicherheit und Grundlagen zum Akquirieren von Spenden für langfristige Serverinvestitionen.

Wenn das nicht bald kommt, fährt FFRL mit seiner Struktur vor den Baum. Rien ne vas plus.
Und dann ist das Image von FF und dem Verein bei allen NGOs und Kommunen dahin und die Kommerziellen machen den Schampus auf und lachen sich krumm auf und die Leidtragenden sind die Flüchtlinge und all die Aktiven, die dann im Sand sitzen.

3

Habe den Namen angepasst.

4

Batman verbessern, damit
die Ausfallrate der Server und dadurch hervorgerufenen künstlichen Engpässen sinkt
unterschiedliche Schnittstellen (fastd/n2n/L2TP/…) gleichzeitig über den Batman-Mechanismus an Batman angebunden werden

Batman ist nicht die Lösung, hier muss endlich ein Schnitt gemacht werden und z.b. Babel verwendet werden.
Meiner Meinung nach sogar mit manueller IP-Vergabe/Konfiguration, denn das tolle „Zero-Conf“ bzw"Ich-möchte-gar-nicht-erst-lernen-wie-netzwerk-funktioniert"-Modus fördert nur das wir immer weiter zentralisieren weil keiner weiß was passiert und wie es funktioniert. Also Batman zurücklassen und auch gar nicht erst drüber nachdenken was man dabei noch verbessern könnte. Das geht nämlich bei Layer2 Mesh nur bis zu einem gewissen Grad und den haben wir schon überschritten. Alles was wir jetzt machen ist Symptombekämpfung.

Dazu kommen die etlichen Subdomains, das macht alles keinen sinn da es vertikale Skalierung ist.
Wir verbrennen hier Geld, Zeit und noch viel wichtiger: Admins. Denn da kann so langsam keiner mehr durchblicken. Selbst wenn wir für Düsseldorf, Neuss und Rheinufer Ansible verwenden um die Supernodes aufzusetzen.

Fastd wird niemals performant auf den kleinen Routern laufen weil es ein User-Space VPN ist. Dieser wird niemals an L2TP oder GRE rankommen. Außerdem belastet Fastd die Supernodes unnötig und sorgt dafür das frühzeitig neue Server konfiguriert werden müssen weil die CPU nicht hinterher kommt.
Verschlüsselung beim Mesh-VPN braucht auch kein Mensch, denn die Enkapsulierung der Daten hebelt die Störerhaftung aus und nicht die Verschlüsselung, ein Fakt der leider auch immer wieder falsch vermittelt wird.

Wer jetzt mit dem Argument kommt „Dann weiß man ja das die Person einen Freiunk Knoten hat“, dies ist hier nicht zulässig da auch bei Fastd-Paketen im IP-Header ein Server des FFRL steht :wink:

Wichtig ist den Nutzern auch ein Gefühl dafür zu vermitteln das sie nicht einfach 200-300 Router in einem Projekt aufstellen können ohne sich über die Kapazitäten im Mesh zu informieren.
Dies ist z.b. in Rheinufer mit Kleve passiert als diese 100-200 Router aufstellen wollten.

Es unterstreicht mal wieder wie wichtig es ist das die Leute sich mit der Materie beschäftigen und nicht einfach wild drauf losbauen.

5 „Gefällt mir“
5

Es ist natürlich schön, wenn man durch seine Ausbildung oder seinen Job zufällig diese Kenntnisse hat, wenn man auf den Freifunk stößt. Wäre es nicht möglich, als Steckdosenfunker anzufangen, hätte ich mich wahrscheinlich nie mit Freifunk auseinandergesetzt.

Der Einstieg ist für Otto-Normaluser jetzt schon eine Hürde. Es gibt tausende verschiedene Freifunk-Firmwares - Geräteauswahl mal Hardwareversionen mal Communities mal Firmwareversionen. Wenn der Laptop keine Ethernet-Schnittstelle hat, muss man einen Adapter dazukaufen. Dazu kommt der Garantieverlust. Ein Freifunk-Callcenter oder einen Installationsdienst gibt es auch nicht. Gruselig. :scream:

Ja, das Argument ist eher mau. Wenn man mal großflächig die Sites einsammelt, die offen im Netz stehen, ist der Freifunker schnell als solcher zu erkennen. ABER DAS SIND JA NUR HARMLOSE METADATEN. :smiley:

Ja - wenn ich lese, dass die Daten einfach nur einmal durch das Freifunk-Netz gehen wegen der Störerhaftung, klingt das nach keiner großen Sache.

Zum Start hatte ich keinen Begriff davon, dass das irgendwie viel Geld kosten kann oder in irgendeiner Form bandbreitenlimitiert ist. Da ist halt irgendwo was im Internet, was die Daten umherschubst, klappt halt irgendwie.

Also doch die Freifunk-Akademie, wo man zum Start einen Freifunk-Führerschein machen kann. :wink:

1 „Gefällt mir“
6

Es ist natürlich schön, wenn man durch seine Ausbildung oder seinen Job zufällig diese Kenntnisse hat, wenn man auf den Freifunk stößt. Wäre es nicht möglich, als Steckdosenfunker anzufangen, hätte ich mich wahrscheinlich nie mit Freifunk auseinandergesetzt.

Ich habe mein gesamtes IT-Wissen autodidaktisch gelernt, dazu zählt auch Freifunk. Schule soll nur lehren wie man selbst lernt, wenn man sich ernsthaft für eine Materie interessiert kann man diese auch erlernen.
Der Mythos „Es wurde mir nicht beigebracht“ ist etwas das heute leider viel zu oft verwendet wird.

Das Chaos was du beschreibst ist das Resultat daraus was momentan falsch läuft. Früher gab es zwar auch 2 - 3 Freifunk-Firmwares, aber diese waren größtenteils kompatibel untereinander und es war mehr eine „Mode-Frage“ was man benutzt.
Für die Anbindung ans FFRL-Backbone sollte gar keine spezielle Firmware für die Domain notwendig sein und diese sollte nicht von einem community Supernode abhängen. Warum bieten wir nicht auch Layer 3 VPN für OLSR basierte Firmwares an ohne das die User sich erst Supernodes / Gateways / VPN-Server selbst aufsetzen müssen?

Und bezüglich IP’s eintragen: Das könnte man auch mit Config-Tokens ala „Modem-Installations-Code“ realisieren. Aber weiterhin auf Batman zu bauen „Weil es einfacher ist“ ist nachsichtig und auch bei unserem Wachstum nicht mehr tragbar.

Wichtig ist auch zu erkennen das es hier nicht nur um Meinungen geht sondern auch darum das wir anhand von Fakten entscheiden müssen wie man weiter vorgeht. Batman-Advanced ist rein faktisch der falsche Weg und wird uns mit einem unüberschaubarem Chaos bescheren.

Also doch die Freifunk-Akademie, wo man zum Start einen Freifunk-Führerschein machen kann.

Von einer Akademie kann keine Rede sein, aber es liegt in der Verantwortung des Node-Betreibers oder des dafür Verantwortlichen (Admin der den Kneipenrouter betreut) zu wissen was er dort tut. Zumindest so grob das er weiß das man z.b. nicht für jede Node im Mesh einen Uplink via VPN braucht oder eben nicht 200 Router aufstellt ohne zu hinterfragen.

Das selbe sehe ich bei Communities, hier ist es notwendig das sich Leute finden die auf technischer ebene die Projekte der lokalen Communities betreuen. Dies kann nicht ohne Vorwissen einfach hochgezogen werden, man hat auch als Techniker eine Verantwortung. Selbst wenn man nur Leihe ist.

2 „Gefällt mir“
7

Die Lösung, um die CPU Last runter zu bekommen, ist im Ruhrgebiet teilweise schon aktiv, l2tp. Bspw. @chrisno hat da bislang sehr positive Erfahrungen mit gemacht.

8

Ja da sind wir momentan auch bei dies zu implementieren.
Das L2TP Gluon Paket kommt auch ursprünglich von mir :wink:

Aber dennoch löst es das Problem nicht das wir ab 200~ Nodes wieder Splitten müssen um den Uplink der Nodebetreiber zu schonen und die Airtime nicht soweit zu belegen das UDP nur wenige Hops überlebt.
Auch sollte der von @SenorKaffee angesprochene Firmware-Urwald ein Ende haben, wir sollten eine Firmware haben woran wir gemeinsam arbeiten.

Leider zeigt dies auch ein weiteres Problem: Wir haben kaum Devs und vieles lastet auf den wenigen die wir haben.
Viele der Probleme könnten sinnvoll gelöst werden wenn wir mehr Entwickler mit Know-How hätten. Vieles was wir heute machen wäre unnötig.

3 „Gefällt mir“
9

Zwischenschritte sind leider wichtig, wenn auch anstrengend und nervig.

Erstmal auf die möglichen und machbaren Dinge umstellen und dann weiter sehen - irgendwie muss man mit den begrenzten Ressourcen klar kommen.

1 „Gefällt mir“
10

Nicht nur nervig und anstregend sonder auch zunehmend unmöglich. Ich habe dieses Jahr mehr Gateways aufgesetzt als im Jahr zuvor. Wir haben zu großes Wachstum um halt mit solchen Zwischenlösungen lang genug Abhilfe zu schaffen.

Neuss und Düsseldorf müssten jetzt z.b. erneut Splitten um performant zu bleiben, denn wenn wir Performance ala Schweden-Exits haben benötigen wir gar keinen Provider-Status und könnten einfach ne Hand voll Schweden-Exits mieten.

(Zur Info, wir wollen frühstens ab 150, spätestens ab 250 Nodes splitten)

Es ist der berühmte Stein den Sisyphos den Berg hinauf rollen soll.

2 „Gefällt mir“
11

Schweden-Tunnel ist keine Option, nur weil der/die zuständige(n) Person(en) des Vereinsvorstandes nicht die notwendigen Informationen liefern. Dann brauchen wir keinen Verein und haben ein Präsentationsproblem für all jene, die bislang mit dem Verein sich präsentiert haben. (bis hin zu rechtlichen Problemen, die z.B. dadurch dann entstehen, wenn eine Kommune einen Ratsbeschluss hat, mit dem Verein Freifunk zu realisieren.)

Es muss möglich gemacht werden, dass ebenso schnell und einfach, wie Errichtung eines Schwedentunnels, eben ein neuer Server unter Vereinsflagge für (zu FFRLeV gehörende) Domäne xyz aufgestellt, bezahlt und gemanaged wird.

Dieses Manko kann nicht dadurch „geheilt“ werden, dass man die Verpflichtung des Vereinsvorstandes aus falscher Rücksichtnahme und evtl. persönlichen Beziehungen schleifen lässt. Wie es momentan läuft ist es nicht mehr lange hinnehmbar. Andernfalls knallt der Verein und wir haben den Supergau aus Imageschaden und Rechtsfolgen.

12

Vielleicht ergibt sich morgen die Chance das mal bei den entsprechenden Personen zu thematisieren…

13

wobei ich anmerken muss, dass die nicht satzungs- und rechtskonform ist. Also Beschlüsse, so weit rechtlich relevant, anfechtbar.

14

@Pinky Ich glaube du redest von was völlig anderem.
Ich rede von der Performance bei Layer 2 Meshes und der Performance die man noch hat wenn man mehr als 250 Nodes hat.
Also Hotspot taugt die Node dann noch was, aber 2-3 Hops weiter reicht es nicht mal mehr für UDP basierte Anwendungen.

Mir ist das Backbone jetzt erst mal egal :wink: Das läuft soweit OK, ich rede von den technischen Unzulänglichkeiten & Performanceproblemen bei Batman-Advanced bzw Layer 2 Meshes.

15

@CyrusFox ja, hier laufen zwei Themen durcheinander, weil @phip den ganzen Komplex angesprochen hat: Technik, Organisation, Recht, etc., also alles, was hakt und wo verbindliche Antworten ausstehen…

Evtl., wäre Themensplitting sinnvoll.

Aber da Du Schwedentunnell als möglichen Lösungsweg nanntest, sind wir damit natürlich (auch) bei den nichttechnischen Fragen.

16

Das mit dem Schwedentunnel war eher darauf bezogen das teilweise das Mesh so langsam ist das man gar nicht merkt ob Schweden-Exit oder FFRL-Backbone dahinter sitzen, gerade nach mehreren Hops ist dies der Fall und schlimmer wenn das Mesh Netz zu voll ist.

17

Aktuell liegt es aus meiner Sicht weniger an vollen Netzen oder dem Layer2, sondern vielmehr an zu wenig Server Ressourcen, da alle Server total am Limit laufen…

1 „Gefällt mir“
18

gut, aber @phip merkte z.B. vor Verlegung nach Berlin an, dass er 4 x 4 kernel VMs benötigt und @pberndro merkte zwar an, dass direkt Bestellung ginge, hat aber bis heute nicht auf die entsprechende Frage dann geantwortet.
Also wenn man die notwendigen Informationen nicht hat, stockt alles. Und das hat nun gar nichts mit Technik zu tun, sondern mit (tja, womit? Vereinspolitik? Unfähigkeit? Mobbing? Kein Interesse? sonst was? - Überlastung scheidet aus, wenn genügend Zeit besteht, um nicht absolut dringende Bastelarbeiten von Softwareupdates am Wiki händisch zu machen).

Das muss vorrangig vor technischen Fragen geklärt werden.

19

4-Kern VM’s wären vermutlich im Übrigen nicht notwendig, wenn man die l2tp Implementierung vornimmt.

welche Bestellung ist gemeint?

20

3 Beiträge wurden in ein neues Thema verschoben: Recht auf Zugriff auf geschützte Bereiche