GW-Struktur

Christian Dresel fff at chrisi01.de
Mi Sep 23 08:30:29 CEST 2015


Guten Morgen

ich hab mal versucht ein wenig zusammen zu stellen was zukünftig Sinn
machen könnte, dabei bedacht was bald noch an Gateways (zumindest wovon
mir Infos vorliegen) kommt sowie den Wunsch von Tim ro1 möglichst
rauszulassen (Was in der aktuellen Konfiguration noch relativ schwer
ist). Dies ist die absolute Minimalkonfiguration und dabei hab ich schon
bemerkt das nicht alles so klappt da zu wenig Gateways da sind. Ich hab
jetzt minimale Erfahrung was so ein Server in etwa packt und zumindest
bei meinen sollte man schauen nicht mehr als 255 Clients drauf zu
werfen, dann ist der Speed auch absolut i.O. (noch im guten einstelligen
MBit Bereich [wenn nicht gerade jeder dicke DL laufen hat, was aber jetzt in der Nürnberger Hood absolut nicht der Fall war, der allermeiste Traffic war irgendein Overhead über den openvpn Mullvad Tunnel ging nur sehr wenig raus im Verhätlnis was übers fastd reinkam] was ja schon das Ziel sein sollte). Daher macht es eher
weniger Sinn den Server in mehrere verschiedene Hoods zu stecken.


So hier mal meine "Idee", gern darf herumgewurschtelt werden wenn jemand andere, bessere Ideen hat (oder ich seinen eigenen Server falsch eingeordnet habe):


Default
nue1.freifunk-franken.de
ro1.freifunk-franken.de


Fürth
ChrisDServer
Klee (V2.0)?
delphiN will doch auch mal irgendwann einen aufstellen soviel ich mitbekommen habe, da er meines wissens aus Fürth kommt, geh ich einfach mal davon aus das es ein Kleeblattserver werden soll?


Nürnberg
Mayosemmel sein neuer (?) nach meiner Info will er nach NBG.
!!wer kann hier noch einen 2. stellen?!!


Hassberge
fff-has
fff-has2
fff-has3


HassbergeSued
fff-has1
fff-has2
fff-has3
(Hassberge hab ich wenig Einblick, ich hab einfach mal die Server genommen die da sind)


Erlangen
nue1.freifunk-franken.de
ro1.freifunk-franken.de



Würzburg
fff-wue1
!!auch hier fehlt ein 2.!!


BGL
watzmann
staufen



Ansbach hat ihr eigenes Zeug oder?



Problem Nürnberg&Würzburg:
ro1 will ich ja eher drausen lassen -> Tims Wunsch. nue1 wenn man
rein nimmt, langweilen sich die anderen Server dein "Er gibt allen Clients IPs
hat aber nach Berlin ne dünne Leitung" kommt dann wieder zum tragen.
Hier wären wohl ein paar neue Gateways wünschenswert oder haben die
Hassberge Server noch Ressourcen über und könnten da mit übernehmen?


Für Erlangen und default haben wir so gar keine Server, vielleicht macht
nue1 da durchaus Sinn, ob und was in Erlangen zukünftig geplant ist,
ist mir nicht bekannt.


mfg


Christian



Am 22.09.2015 um 00:11 schrieb Michael Fritscher:
> Hi,
>
> wir sollten uns glaube ich so langsam mal Gedanken um die GW-Struktur machen.
>
> Wir haben einige Server, die in allen Hoods mit drinhängen, sowie Hoods,
> wo 5 GWs herumwerkeln. Unter denen gibt es mittlerweile einen ziemlichen
> Verhau an GRE-Links.
>
> Das ist zwar alles schön und gut, produziert aber ziemlichen Overhead und
> auch unnötigen Traffic. Außerdem macht es die Konfigurationsdateien und
> die Fehlersuche nicht gerade übersichtlicher.
>
> Deswegen mein Vorschlag:
>    * Jeder Gateway sollte in max. 3 Hoods drin sein.
Erfahrungsgemäß, zumindest bei meinen, zuviel. Bei größeren Gateways 
vielleicht i.O. Rest hab ich oben bereits geschrieben.
Ich mein 255 Clients pro Gateway, wir haben rund 10 Gateways von einem 
2500 Clientspeak sind wir noch weit entfernt und dann sind das auch 
reine Peakwerte. Wenn man es schafft die Clients halbwegs sinnvoll auf 
die Gateways zu verteilen sollte man mit 255 Clients pro Gateway noch 
etwas hinkommen (und wenn wir das haben, stehen vielleicht schon wieder 
neue Gateways rum?!). Und bei 255 Clients auf 3 Hoods zu verteilen macht 
in meinen Augen wenig Sinn.
>    * Jede Hood sollte 3 GWs haben - was ein guter Kompromiss zwischen
> Ausfallsicherheit und Overhead sein sollte. Davon sollte(n) einer,
> besser 2 einen direkten (=nicht über olsrd) Uplink ins Internet haben.
>    * Jeder Gateway sollte 2-3 GREs zu GWs haben, die wenig bis keine
> gemeinsame Hoods haben (Hood-intern sind die GWs ja eh per fastd
> verflochten)
hab ich zu wenig Erfahrung um das zu planen, wer will darf gerne oben 
mal anfangen eine sinnvolle Struktur zu schaffen.
>    * Wenn wir mehr Server haben sollten wir die Hoods verkleinern.
davon sind wir glaub ich noch etwas entfernt wenn ich mir das oben so 
angucke ;)
>
> Weitere eher administrative Vorschläge:
>    * Jeder Gateway sollte min. 2 Admins haben - zum einen wegen der
> Erreichbarkeit, außerdem können so Neulinge besser eingearbeitet und
> betreut werden. Ganz ehrlich ist m.E. ein GW mit zu viel Verantwortung
> verbunden als dass ein (Linux & Netzwerk-) Neuling ein GW alleine
> betreiben sollte.
>    * Wenn bemerkt wird, dass ein GW beispielsweise einen fehlerhaften
> Uplink hat, diesen aber weiterhin announct, sollte er temporär per
> KeyExchange gekickt werden, um Schaden vom Netzwerk zu vermeiden.
>    * Traffic-Statistik für alle Interfaces sowie olsrd-Daten sollten
> Pflicht werden (ob jetzt vnstat oder mrtg ist egal) - darüber können
> schnell Probleme festgestellt werden.
>    * Man könnte sich überlegen, ob man einen Service baut, der anhand der
> gewünschten Hoods, GREs etc. automatisiert GW-Konfigurationstemplates
> erstellt - dann wären die einheitlich und es gäbe weniger Raum für
> Fehler.
>    * Alternativ könnte man sich überlegen, ob eine Ausgabe von ifconfig -a,
> ip route/rule show, ip route/rule show table sowie
> /etc/network/interfaces zwingend "irgendwo" hinterlegt und aktuell
> gehalten werden muss (Dinge wie öffentliche IPs maskieren sind erstmal
> Details;)  )
>    * Eine weitere Alternative wäre ein über ein Script bereitgestellte API,
> die jedes GW haben muss und worüber die aktuelle Konfiguration
> eingesammelt werden kann. Wäre eventuell was fürn keyxchange.
>
> Das sind einfach so meine Ideen zu diesem Themenkomplex, wo nichts in
> Stein gemeiselt ist;-)  Aber ich denke, dass wir so langsam eine Größe
> erreicht haben, wo man sich darüber zumindest mal Gedanken machen sollte.
>
> Viele Grüße,
> Michael




Mehr Informationen über die Mailingliste franken-dev