Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
technik:loadbalancing [13.05.2021 - 17:59] – nrb | technik:loadbalancing [16.05.2021 - 13:35] (aktuell) – Formulierung geändert Roland Volkmann | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Load Balancing ====== | ====== Load Balancing ====== | ||
- | Wir betreiben mehrere Gatways, zu denen sich Nodes verbinden können. Diese VPN-Verbindung funktioniert mit fastd. Jeder Knoten | + | Wir betreiben mehrere Gatways, zu denen sich die Nodes (Freifunk-Router) |
Wir haben daher einen Mechanismus entwickelt, um die Last zwischen unseren Gateways besser zu verteilen. Dieser besteht aus zwei Komponenten: | Wir haben daher einen Mechanismus entwickelt, um die Last zwischen unseren Gateways besser zu verteilen. Dieser besteht aus zwei Komponenten: | ||
- | * dem // | + | |
- | * dem // | + | * dem // |
- | ====== Die Präferenz | + | ===== Die Präferenz ===== |
- | Jedes Gateway gibt für jedes bediente Segment eine Präferenz bekannt. Eine Präferenz ist eine Ganzzahl zwischen -∞ und 100. Je größer die Präferenz, desto mehr ist ein Gateway gewillt, neue Nodes aufzunehmen. | + | Jedes Gateway gibt für jedes bediente Segment eine Präferenz bekannt, deren Berechnung es selbst bestimmen kann, auch unterschiedlich für die einzelnen Segmente. Eine Präferenz ist eine Ganzzahl zwischen -∞ und 100. Je größer die Präferenz, desto mehr ist ein Gateway gewillt, neue Nodes aufzunehmen. Aktuell (Stand Mai 2021) verwenden alle Gateways denselben Algorithmus, |
- | Jedes Gateway kann selbst bestimmen, wie es die Präferenz berechnet. Im Prinzip | + | Ziel ist, den durch die Nodes transportierten Gesamt-Traffic im Freifunknetz so auf die Gateways zu verteilen, dass kein Gateway überlastet wird. Im Prinzip |
- | Jedes Gateway wird seine Präferenz | + | Die Herausforderung bei der Präferenz-Bestimmung liegt nun darin, dass ein Gateway zum Zeitpunkt der Verbindungsanfrage eines Nodes nicht vorhersehen kann, welchen zusätzlichen Traffic das zur Folge hat. Darüber hinaus |
- | ====== Der Verteilungsmechanismus ====== | + | {{: |
- | Basierend | + | Wir greifen derzeit |
- | Wenn ein Node eine Verbindung zu einem Gateway aufbaut, schickt er Handshakes an die Gateways. Der Node wird eine Verbindung zu dem Gateway aufbauen, das zuerst auf den Handshake antwortet. | + | {{: |
- | Wir haben daher bei unseren Gateways | + | Im obigen Beispiel sieht man sehr schön, dass ein Gateway eine sehr niedrige Präferenz haben kann, obwohl |
- | Bei einer Verzögerung des Handshake um 10 Sekunden kamen bei unseren Tests keine Verbindung mehr zustande. | + | Jedes Gateway stellt seine Präferenz als JSON-Dokument per HTTP unter dem Pfad ''/ |
- | Wir haben außerdem beobachtet, dass fastd nicht alle Gateways gleichzeitig anfragt, sondern pro Gateway ein zufälliges Delay zwischen 0 und 3 Sekunden einfügt, um eine gleichmäßigere Verteilung zu erreichen. Da das mit diesem Mechanismus im Konflikt steht, haben wir seit Firmware 2.3 einen [[https:// | + | ===== Der Verteilungsmechanismus ===== |
- | ====== Monitoring ====== | + | Erste Ideen zur Verteilung basierten darauf, dass sich ein Gateway unterhalb einer minimalen Präferenz aus dem DNS austrägt, und so beim VPN-Verbindungsaufbau für die Nodes nicht mehr erreichbar ist. Steigt die Präferenz dann wieder über einen Schwellwert, |
- | Wir haben ein [[https://grafana.freifunk-stuttgart.de/d/oXoehOrMk/load-balancing? | + | Eine [[https://github.com/NeoRaider/fastd/issues/ |
- | ====== Implementierung ====== | + | Wenn ein Node eine Verbindung zu einem Gateway aufbaut, schickt er Handshakes an die Gateways. Der Node stellt die Verbindung dann zu dem Gateway her, das zuerst auf den Handshake antwortet. Verzögert man also auf den Gateways die Antwort auf den initalen Handshake eines Nodes in Abhängigkeit der Präferenz - je niedriger die Präferenz ist, um so länger die Verzögerung der Antwort - dann lässt sich damit eine Verteilung realisieren, |
- | [[https:// | + | Um Verzögerungen beim Verbindungsaufbau verwenden zu können, musste die fastd-Konfiguration auf den Gateways angepasst werden. Ursprünglich wurden den fastd-Instanzen die Dateien mit den Keys direkt zur Verfügung gestellt, so dass diese bei einer Verbindungsanfrage eigenständig ermitteln konnten, ob der Node zur Verbindung berechtigt ist. Will man statt dessen Einfluss auf den Verbindungsaufbau nehmen, so ist das durch die Nutzung eines Scriptes " |
+ | |||
+ | Wir haben zwar einen [[https:// | ||
+ | |||
+ | Deshalb muss auf den Gateways das [[https:// | ||
+ | |||
+ | Bei Tests hat sich gezeigt, dass die Verzögerung maximal 10 Sekunden betragen darf, damit überhaupt noch eine Verbindung zustande kommt. | ||
+ | |||
+ | Wir haben außerdem beobachtet, dass fastd nicht alle Gateways gleichzeitig anfragt, sondern pro Gateway ein zufälliges Delay zwischen 0 und 3 Sekunden einfügt, um eine gleichmäßigere Verteilung zu erreichen. Da das mit unserem Verzögerungsmechanismus auf den Gateways im Konflikt steht, haben wir seit Firmware 2.3 einen [[https:// | ||
+ | |||
+ | Geeignete Verzögerungswerte aus den Präferenzen zu ermitteln, lässt sich über unterschiedliche Funktionen (Kennlinien) realisieren. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Von uns wurde nach mehreren Versuchen die 50/ | ||
+ | * es auch ohne aktive Clients immer eine Grundlast im Freifunknetz gibt, die Präferenz also kaum über 80 steigt | ||
+ | * die Nodes eine einmal hergestellte Verbindung nur selten wieder trennen, also rechtzeitig gegengesteuert werden muss | ||
+ | * es unvorhersehbare Lastsprünge geben kann, d.h. ausreichend Reserve einzuplanen ist | ||
+ | |||
+ | Die bisherige Erfahrung bestärkt uns in der Annahme, dass wir hier eine sehr gute Lösung zum Load Balancing gefunden haben. | ||
+ | |||
+ | ===== Monitoring ===== | ||
+ | |||
+ | Wir haben ein [[https:// | ||
+ | Der Gesamt-Traffic im Freifunknetz und auf den Gateways wird [[https:// | ||
+ | |||
+ | ===== Implementierung ===== | ||
+ | |||
+ | [[https:// | ||
+ | * Die Präferenz wird im Script [[https:// | ||
+ | * Die Prüfung des fastd-Keys und das Delay ist in [[https:// |