Lastausgleich zwischen den Gateways?

Moin!

Wir betreiben ein Freifunk Netz auf Gluon Basis und haben seit ca. einem Monat ein zweites Gateway in Betrieb genommen. Leider will sich die Last nicht wirklich zwischen den beiden aufteilen. Das announcierten einer höheren Bandbreite durch BATMAN-adv führte nicht zum gewünschten Ergebnis.

Wie kann ich es erreichen das die Clients gleichmässig auf beide Gateways verteilt werden? Hintergrund ist, das unsere VPN Tunnel auf dem ersten GW nur ca. 10 MBit bei uns leistet und wir uns durch ein zweites Gateway neben Ausfallsicherheit mehr Performance erhoft haben. Leider ist das nicht eingetreten. Das alte GW ist weiterhin quasi überlastet und das andere dümpelt nur vor sich hin.

Den Grund habe ich vermutlich auch schon eingekreist. Das alte GW antwortet auf DHCP Requests schneller als das neue. Ca. 10 ms Ping unterschied zwischen alten und neuen GW innerhalb unseres Freifunk Netzes. Ein abschalten des ersten GW, damit sich die Clients auf dem zweiten GW verbinden und das erneute wiedereinschalten des ersten GW brachte nur kurzzeitig Besserung. Fast alle Clients sind wieder auf das erste GW zurück gewandert und das zweite GW dümpelt wieder vor sich hin.

Weiß mir jetzt keinen Rat mehr. Jemand ne Idee was man noch versuchen könnte?

1 Like

Wie wäre es die Menge der Tunnel auf dem überlasteten Gateway zu begrenzen?

So haben wir es bei uns gemacht…

Aktuell sind wir dabei einen Mechanismus auf DNS Basis zu entwickeln, der anhand der SNMP Counter noch besser ausbalanciert.

Allerdings wird das bei euch nicht viel Sinn machen bei zwei Gateways.

1 Like

Ein peer-Limit bei fastd auf dem schwachen Gateway einzurichten dürfte tatsächlich die einfachste Lösung sein. Davon abgesehen ist es bei der derzeit eingesetzten Topologie tatsächlich sinnvoller gleichwertige Gateways zu bauen. Eine Lastverteilung ist derzeit weder explizit noch implizit vorgesehen.

2 Likes

Je mehr Gateways es werden, desto schwieriger wird der Ausgleich, das skaliert eben wie Du schon sagst nicht automatisch.

Mit 2 fastd Sessions, je eine für Nodes und Server untereinander verteilt sich die Leistung pro Gateway schon mal ein wenig besser auf die CPU’s und lässt (wie auch über die peer groups möglich!) ein peer limit dediziert in der fastd Session der Nodes zu.

Dennoch balanciert das die Gateways dann nicht aus, je mehr Gateways man hat, desto stärker wird der Effekt deutlich. Deshalb wollten wir, um nicht unnötig Ressourcen in Load-Balancer zu verschwenden, ein simples Scriptbasiertes Loadbalancing mittels DNS ausprobieren.

Ich verstehe die Antworten jetzt so das es keine Möglichkeit gibt das auf einfache weise zu realisieren. Würde ich die Anzahl der fastd Tunnel auf GW 1 verringern und GW 2 sollte mal ausfallen, dann haben nur noch X Knoten Verbindung zu einem GW und die anderen hängen ist der Luft ohne Anbindung. Irgenwie nicht befriedigend.

Das neue GW ist natürlich auch bei einem anderen Anbieter gehostet und das GW ist leider sowohl von Kabeldeutschland als auch Telekom Anschlüssen Ping Zeit technisch weiter weg.

Weil Du den Lastenausgleich in der Tunnelmenge durch ein Redundanzsystem einkalkulieren musst.

Wenn Du pro Server 100 Tunnel zulässt maximal und 200 Tunnel insgesamt hast, dann brauchst Du eben 3 Gateways.

Aktuell haben wir 50 fastd Tunnel je GW. Und nen drittes GW kommt Finanztechnisch noch nicht in Frage für uns. Bislang generieren wir keine Einnahmen und die ganze Technik wird von 2 Enthusiasten gestemmt.

Was sind denn das für Server die da angemietet sind?

Günstige. GW1 ein VServer 2 Kerne a 3,3 GHz und 1 GB RAM garantiert. 100 MBit Netzanschluss mit Fairflat. Das zweite ein Blechserver 4x 1,5 GHz CPU 8 GB RAM und 1000 MBit Fullflat. Mit dem GW1 stoßen wir immer wieder an die Fairflat an und werden dann auf 10 MBit vom Anbieter begrenzt. Leider weit im vorraus schon bezahlt, sowohl der Server als auch die VPN Tunnel.

Wir haben auch günstige Server im Einsatz gehabt und teilweise immer noch im Einsatz. Wir haben uns allerdings Anbieter rausgesucht, die trotz des niedrigen Preises von einem 5er im Monat, nicht gedrosselt haben.

Gibts ne Liste mit empfehlenswerten Anbietern bezüglich Traffic?

Ihr könntet die DHCP Server synchronisieren und als Router das Gateway mitteilen was gerade Kapazität frei hat.

Ich reanimiere dies Thema mal, weil bei uns das Problem auch auftrat. Gestern waren es 137, 143 und 37 Verbindungen auf gw01/03/04, gw01zumindest hat die eine (v)CPU zeitweise voll ausgelastet.

Wir haben nun 4 GWs am Start, nach Begrenzung auf 80 Peers auf gw01 und gw04 sieht es jetzt so aus:

gw01	online	0	0	80	nein	Debian 7
gw03	online	1	0	60	nein	Ubuntu LTS
gw04	online	1	0	115	nein	Debian 7
gw07	online	2	0	74	nein	14.04

Weder verstehe ich, warum gw04 115 statt 80 Verbindung hat (lt. Log werden wg. lokaler Restriktionen Verbindungen abgelehnt), noch, warum sich das so komisch verteilt – und warum die Summe nicht die rd. 400 ergibt, die 198+ Knoten * 2 Verbindungen ergeben sollte – 164,5 Knoten klingt arg komisch :wink:
gw01, gw03, gw07 sind VMs auf 3 verschiedenen HVs im RZ Gütersloh, gw04 ist extern angemietet. Nächste Baustelle (gw02 und gw05 sind in Vorbereitung): wie die GWs untereinander verbinden, derzeit ist jedes GW zu jedem anderen GW per Knoten-fastd verbunden. @CHRlS, Du sprachst von zweiter fastd-Instanz — wie, falls, habt Ihr die zusammengeklebt (Blog/Wiki dazu?) und welche Erfahrungen habt Ihr gemacht?

1 Like

Verbindungen aller Supernodes mit allen Supernodes, kannst Du entweder in einer eigenen fastd Instanz auf eigenem Port oder per gretap machen.

Zu empfehlen ist mit ansteigender Menge an Supernodes entweder ein zentraler Server für die Peer Files der mittels rsync synchronisiert (so ist es bei mir noch) wird oder ein Repo (so wird es bald sein), damit alle Supernodes immer einen identischen Stand haben.

Die Peer Files für die jeweiligen lokalen fastd Instanzen wird vom fastd automatisch erkannt und ignoriert, stört also nicht.

Wenn die fastd.conf richtig ist und max peers angegeben wurde, dann wird das zumindest in der fastd v16 und v17 auch gnadenlos umgesetzt. Bislang hatten wir keinen Fehler in der Richtung.

Die Tunnel Anzahl wird jedoch über alle Connections in allen verbundenen Instanzen gezählt und in der ffmap angezeigt, was bedeutet das die Tunnelmenge der Supernodes untereinander auf die Menge der Client Verbindungen auch fortlaufend aufaddiert bleibt. Das max peers wird aber nur für die jeweilige Instanz umgesetzt. Sobald man die Server aus der Client fastd Instanz raus hat, connecten dort wirklich 80 Node Tunnel, wenn man max peers auf 80 hat.

Hmm, da wir seit jeher jeden rein lassen (und jetzt immerhin blacklisten können ;)), ist die Schlüsselsynchronisation kein Thema. Aber wir haben trotz Limit von 80 87 bzw. 94 Verbindungen …

Ich meinte vielmehr Peer Files der Server untereinander, wenn man dafür eine eigene fastd Instanz hat…irgendwie müssen die ja wissen wohin sie connecten sollen

Wie viele Verbindungen waren es denn, als ihr das Limit konfiguriert habt?

Das Limit beendet keine bestehenden Verbindungen, sondern laesst nur keine neunen zu, wenn die Maximalzahl ueberschritten ist.

um die Verbindungen auf 80 zu bekommen, entweder ‚von Hand‘ Verbindungen abschiessen, oder Server booten…

Beides nicht angenehm

Den fastd in der Nacht neuzustatten geht einfacher.

Wie begrenzt man denn überhaupt die Anzahl fastd peers? Was muss man in welcher Config ändern?

Und wie kann man auf der Konsole ermitteln (also ohne meshviewer), wieviele Clients gerade wirklich mit dem Gateway verbunden sind?

Gibt es da gute Anleitungen?

peer limit 80;

http://fastd.readthedocs.org/en/v17/manual/config.html

Aktuelle Nutzungsdaten kann man sich aus dem Unix Socket ziehen:

Ohne IP-Adressen zu loggen bspw:

/tmp/status.pl /tmp/fastd.sock | jq . | sed -r 's/(\b[0-9]{1,3}\.){3}[0-9]{1,3}\b'/127\.0\.0\.1/ > /tmp/fastd.json

status.pl Script dort:

1 Like