Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- technik:loadbalancing [16.05.2021 - 11:48] – Ergäzungen zum Monitoring und zur Implementierung Roland Volkmann
+++ technik:loadbalancing [16.05.2021 - 13:35] (aktuell) – Formulierung geändert Roland Volkmann
@@ Zeile 28: / Zeile 28: @@
 ===== 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.
-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.