technik:loadbalancing

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
technik:loadbalancing [15.05.2021 - 17:28] – Roland Volkmanntechnik:loadbalancing [16.05.2021 - 13:35] (aktuell) – Formulierung geändert Roland Volkmann
Zeile 12: Zeile 12:
 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, um die Präferenz zu ermitteln, und unterscheiden dabei nicht zwischen den Segmenten. 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, um die Präferenz zu ermitteln, und unterscheiden dabei nicht zwischen den Segmenten.
  
-Ziel ist, den durch die Nodes transportierten Gesamt-Traffic des Freifunknetz so auf die Gateways zu verteilen, dass kein Gateway überlastet wird. Im Prinzip geht es also nicht darum, die VPN-Verbindungen der Nodes gleichmäßig zu verteilen, sondern den Traffic, der durch die Clients erzeugt wird.+Ziel ist, den durch die Nodes transportierten Gesamt-Traffic im Freifunknetz so auf die Gateways zu verteilen, dass kein Gateway überlastet wird. Im Prinzip geht es also nicht darum, die VPN-Verbindungen der Nodes gleichmäßig zu verteilen, sondern den Traffic, der durch die Clients erzeugt wird.
  
 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 ist der Traffic auch von der Tageszeit und äusseren Umständen abhängig, die nicht kalkulierbar sind (siehe kurze Spitze gegen 22 Uhr in der nachfolgenden Grafik).  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 ist der Traffic auch von der Tageszeit und äusseren Umständen abhängig, die nicht kalkulierbar sind (siehe kurze Spitze gegen 22 Uhr in der nachfolgenden Grafik). 
Zeile 20: Zeile 20:
 Wir greifen derzeit auf den Verlauf des Traffics in den letzten 24 Stunden zurück, konkret auf das Maximum der letzten 24 Stunden-Mittelwerte, und zusätzlich auf den jeweils aktuellen Traffic-Wert. Der Peak wird dann ins Verhältnis zu dem maximalen Durchsatz gesetzt, den das Gateway dauerhaft liefern kann (wird vom Gateway-Betreiber festgesetzt). So ergibt sich eine Präferenz von 100, wenn der Peak gleich Null ist, und eine Präferenz von 0, wenn der Peak dem definierten Maximalwert entspricht. Übersteigt der Peak den vorgegeben Maximalwert, wird die Präferenz negativ. Wir greifen derzeit auf den Verlauf des Traffics in den letzten 24 Stunden zurück, konkret auf das Maximum der letzten 24 Stunden-Mittelwerte, und zusätzlich auf den jeweils aktuellen Traffic-Wert. Der Peak wird dann ins Verhältnis zu dem maximalen Durchsatz gesetzt, den das Gateway dauerhaft liefern kann (wird vom Gateway-Betreiber festgesetzt). So ergibt sich eine Präferenz von 100, wenn der Peak gleich Null ist, und eine Präferenz von 0, wenn der Peak dem definierten Maximalwert entspricht. Übersteigt der Peak den vorgegeben Maximalwert, wird die Präferenz negativ.
  
-{{:technik:gateway-traffic.png?direct&600|}} {{ :technik:gw-preference.png?direct&600|}}+{{:technik:gateway-traffic.png?direct&600|}} {{:technik:gw-preference.png?direct&600|}}
  
-Im obigen Beispiel sieht man sehr schön, warum ein Gateway eine sehr niedrige Präferenz haben kann, obwohl der aktuelle Traffic gar nicht am Maximalwert liegt (wäre hier 250 MBit/s).+Im obigen Beispiel sieht man sehr schön, dass ein Gateway eine sehr niedrige Präferenz haben kann, obwohl der aktuelle Traffic gar nicht am Maximalwert liegt (wäre hier 250 MBit/s).
  
 Jedes Gateway stellt seine Präferenz als JSON-Dokument per HTTP unter dem Pfad ''/data/gwstatus.json'' zur Verfügung. Das Format ist in einem [[https://github.com/freifunk-stuttgart/loadbalancer/blob/main/schema.json|JSON-Schema beschrieben]]. Jedes Gateway stellt seine Präferenz als JSON-Dokument per HTTP unter dem Pfad ''/data/gwstatus.json'' zur Verfügung. Das Format ist in einem [[https://github.com/freifunk-stuttgart/loadbalancer/blob/main/schema.json|JSON-Schema beschrieben]].
Zeile 28: Zeile 28:
 ===== Der Verteilungsmechanismus ===== ===== Der Verteilungsmechanismus =====
  
-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, trägt sich das Gateway erneut ein. Hierbei müsste aber eine aufwendige Koordination zwischen den Gateways implementiert werden, wenn man auf eine zentrale Verteilinstanz verzichten will, damit zu keiner Zeit alle Gateways ausgetragen sind.+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, trägt sich das Gateway erneut ein. Hierbei müsste aber eine aufwendige Koordination zwischen den Gateways implementiert werden, wenn man auf eine zentrale Verteilinstanz verzichten will, damit zu keiner Zeit alle Gateways gleichzeitig ausgetragen sind.
  
 Eine [[https://github.com/NeoRaider/fastd/issues/10#issuecomment-718249816|Idee von NeoRaider]] hat uns einen neuen Ansatz geliefert. Eine [[https://github.com/NeoRaider/fastd/issues/10#issuecomment-718249816|Idee von NeoRaider]] hat uns einen neuen Ansatz geliefert.
  
-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, ohne dass die Gateways untereinander kommunizieren müssen.+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, ohne dass sich die Gateways untereinander abstimmen müssen.
  
 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 "on-verify" möglich, aber beim Original-fastd nur, wenn die Key-Dateien nicht mehr direkt angeboten werden. 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 "on-verify" möglich, aber beim Original-fastd nur, wenn die Key-Dateien nicht mehr direkt angeboten werden.
Zeile 42: Zeile 42:
 Bei Tests hat sich gezeigt, dass die Verzögerung maximal 10 Sekunden betragen darf, damit überhaupt noch eine Verbindung zustande kommt.  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://gitlab.freifunk-stuttgart.de/firmware/ffs-pipeline-nightly/-/blob/6fcf96d1e30710300dd84fffaba4839389d16712/patches/0002-add-patch-to-remove-fastd-random-delay-on-inital-han.patch|Gluon-Patch, der das Delay auf den Nodes entfernt]].+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://gitlab.freifunk-stuttgart.de/firmware/ffs-pipeline-nightly/-/blob/6fcf96d1e30710300dd84fffaba4839389d16712/patches/0002-add-patch-to-remove-fastd-random-delay-on-inital-han.patch|Gluon-Patch]], der das Delay auf den Nodes entfernt.
  
 Geeignete Verzögerungswerte aus den Präferenzen zu ermitteln, lässt sich über unterschiedliche Funktionen (Kennlinien) realisieren. Geeignete Verzögerungswerte aus den Präferenzen zu ermitteln, lässt sich über unterschiedliche Funktionen (Kennlinien) realisieren.
-{{ :technik:fastd-delay.png?direct&800 |}}+ 
 +{{:technik:fastd-delay.png?direct&600|}}
  
 Von uns wurde nach mehreren Versuchen die 50/2-Kennlinie (grün) implementiert. Sie berücksichtigt, dass Von uns wurde nach mehreren Versuchen die 50/2-Kennlinie (grün) implementiert. Sie berücksichtigt, dass
Zeile 56: Zeile 57:
 ===== Monitoring ===== ===== Monitoring =====
  
-Wir haben ein [[https://grafana.freifunk-stuttgart.de/d/oXoehOrMk/load-balancing?orgId=1|Grafana-Dashboard um die Präferenzen und Tunnel zu überwachen]].+Wir haben ein [[https://grafana.freifunk-stuttgart.de/d/oXoehOrMk/load-balancing?orgId=1|Grafana-Dashboard]], um die Präferenzen und Tunnel zu überwachen. 
 +Der Gesamt-Traffic im Freifunknetz und auf den Gateways wird [[https://grafanagw.gw.freifunk-stuttgart.de/d/000000008/gateways?orgId=1|hier]] dargestellt. 
  
 ===== Implementierung ===== ===== Implementierung =====
  
-[[https://github.com/freifunk-stuttgart/loadbalancer|Unsere Implementierung steht auf Github]] zur Verfügung.+[[https://github.com/freifunk-stuttgart/loadbalancer|Unsere Implementierung]] steht auf Github zur Verfügung: 
 +  * Die Präferenz wird im Script [[https://github.com/freifunk-stuttgart/loadbalancer/blob/main/genGwStatus.py|genGwStatus.py]] ermittelt, das per cron alle 5 Minuten ausgeführt wird 
 +  * Die Prüfung des fastd-Keys und das Delay ist in [[https://github.com/freifunk-stuttgart/loadbalancer/blob/main/fastd-verify.py|fastd-verify.py]] realisiert, das vom [[https://fastd.readthedocs.io/en/stable/manual/config.html#main-configuration|fastd]] bei jedem Verbindungsversuch (Handshake) aufgerufen wird und die notwendigen Informationen per Environmentvariablen zur Verfügung stellt.
  • technik/loadbalancing.1621099685.txt.gz
  • Zuletzt geändert: vor 3 Jahren
  • von Roland Volkmann