Hallo zusammen,
ich hatte heute ein paar Stunden Zeit mir die Wuppdizität von Wupper zur PrimeTime anzuschauen und bin froh und erschrocken zugleich. Froh, weil Freifunk so schön genutzt wird; erschrocken, weil der Aufbau doch langsam von der Geschwindigkeit der Prozessoren der Superknoten limitiert wird. Es steht vor uns nun die Zeit, in der nun die Maximalleistung aus der zur Verfügung stehenden Infrastruktur herausgekitzelt wird. Ich habe mehrererere Optimierungsansätze im Hut vorbereitet.
Bevor die Frage nach neuer Infrastruktur für Wupper gestellt wird möchte ich kurz entwarnen: es ist „eigentlich“ noch sehr viel Luft nach oben. Tagsüber reicht ein Superknoten. Doch abends kommen die Nutzer und da fängt es an schief zu werden: Batman bevorzugt die Server in Düsseldorf und dann nur einen davon, was je nach Broadcastdomäne zufällig ist. Kurzes Schreckensbild (load), sortiert nach GW-Nummer:
1.62 1.47 1.44 1/115 31800
1.47 1.49 1.50 1/113 15215
4.25 4.65 3.87 3/121 31989
3.02 2.64 2.79 2/122 2227
Das sind virtualisierte Zweikernmaschinen. Die Zahl sollte 2 nicht übersteigen. Wie man sieht ist w2 ganz besonders bei den Knoten beliebt …
Ich habe nun als ersten Versuch ein wenig mit Wuppers Broadcastdomänen herum jongliert. Dies ist herausgekommen:
1.71 2.05 2.11 2/114 11234
1.59 1.86 2.21 2/114 26023
1.60 1.56 1.41 1/121 24132
2.42 2.36 2.41 3/121 16555
Ich habe GL verboten sich mit w2 und w3 zu verbinden und DUS mit w2. Eine ganz einfache Maßnahme, die spürbar Wirkung zeigt. Diese kann man später mit irgendeinen Zustandsautomaten verfeinern. Diesen entwerfe ich bei Gelegenheit.
Leider habe ich bisher versäumt die Load aufzuzeichnen, um aus der Vergangenheit für die Zukunft zu lernen. Ich kann mich aber immer noch notfalls der Tools der Virtualisierung bedienen.
Während ich schreibe, sieht die Laage so aus:
1.67 1.75 1.93 3/113 15089
2.40 2.75 2.56 6/112 29612
0.77 0.92 1.03 2/122 28596
3.96 3.49 3.03 1/120 21106
Ich habe deshalb WUP vom w3 verbannt.
Batman/die Wolke lässt sich in meinen Augen so steuern:
- Broadcastdomänenweit
- ein-/ausschalten des GWs
- globales Zulassen der fastd-Knoten
- Knotenzpezifisch
- über einen ausgeklügelten Mechanismus einzelnen Knoten die Verbindung zu bestimmten Superknoten erlauben; während der PrimeTime die Tunnelanzahl serverseitig auf einen Tunnel begrenzen.
- Wolkenseitig verwaltet
- mittels Alfred werden un- und ausgelastete Knoten angekündigt, eine FSM auf dem Knoten erledigt weise Entscheidung eines Tunnelwechsels. Nachteil: Verbindung kann bei Fehlimplementierung abreißen – ein weiterer Ausfallpunkt
Dies ist nur ganz grob umschrieben … es gibt noch mehr Möglichkeiten.
In Wuppertal, wo wir acht Superknoten fahren, beobachte ich, dass nach längerer Zeit mehr Knoten mit bestimmten Superknoten verbunden sind. Superknoten werden auch unausgelastet, wenn sie nach einer Wartung wieder erscheinen.
nach 20 min:
1.45 1.46 1.52 2/113 16704
2.64 2.44 2.34 2/112 31034
0.51 0.80 0.95 1/120 30418
1.96 2.22 2.66 1/122 24424
… ein Spagat …
Fortsetzung folgt.
Bei der Gelegenheit (wo ich schon so viel schreibe): ich hatte immer Sorge, dass auf den Superknoten die Ports für NAT nicht ausreichen werden. Auf dem ffcs2015 habe ich gelernt, dass das RAM der limitierende Faktor hierbei ist. Dies ist aber anderer Thread und OT. Vollständigkeitshalber nur so viel zur Laage:
~ $ conntrack -L --src-nat > /dev/null
0
conntrack v1.4.2 (conntrack-tools): 2448 flow entries have been shown.
1
conntrack v1.4.2 (conntrack-tools): 7380 flow entries have been shown.
2
conntrack v1.4.2 (conntrack-tools): 11787 flow entries have been shown.
3
conntrack v1.4.2 (conntrack-tools): 15715 flow entries have been shown.
der Limit liegt bei net.netfilter.nf_conntrack_max = 32008 und kann noch erhöht werden, da die Superknoten (1 GiB RAM) nur ein Viertel des RAMs nutzen (höchstens, eher ein Achtel in der Regel). 25000 habe ich aber schon beobachtet 
und nun sieht es so aus
0.61 1.17 1.41 1/115 17531
2.63 2.71 2.56 2/114 31847
1.32 1.13 1.04 2/123 31327
1.53 1.82 2.25 4/123 26176
Wupper … jetzt neu – mit Schieflast.
ps. das bleibt natürlich nicht so, dass GL jetzt über Robaix mit 40 ms mehr Latenz gefahren wird. Es wird bald pro Knoten im Rundlauf-Verfahren entschieden. Vorerst freut Euch über den Durchsatz *g
pps. es ist nun an der Zeit alle Superknoten aus Wupper in die Firmware einzutragen, damit ein Knoten auf ein mal sich nicht mit einem „zur Verfügung stehenden“ Superknoten verbinden kann, nur weil dieser nicht in der site.conf hinterlegt ist. Gleichzeitig ist dies die Gelegenheit eigene (zukünftige) Superknoten zu hinterlegen.
pppppps
1.28 1.21 1.31 2/113 18276
1.85 2.36 2.49 7/112 32552
1.19 1.19 1.10 2/120 32157
1.54 1.79 2.02 2/122 27625