Load Balancing

Wir betreiben mehrere Gatways, zu denen sich Nodes verbinden können. Diese VPN-Verbindung funktioniert mit fastd. Jeder Knoten hält immer höchstens eine fastd-Verbindung zu einem Gateway. Welches Gateway das ist, entscheidet sich unserer Erfahrung nach eher zufällig. Das führt dazu, dass ohne manuellen Eingriff auch stark ausgelastete Gateways neue Nodes aufnehmen und sich die Last nicht gleichmäßig verteilt.

Wir haben daher einen Mechanismus entwickelt, um die Last zwischen unseren Gateways besser zu verteilen. Dieser besteht aus zwei Komponenten:

• dem Präferenz-Konzept, mit dem Gateways ausdrücken wie stark sie gewillt sind, neue Knoten aufzunehmen,
• dem Verteilungsmechanismus, mit dem Nodes auf die Gateways verteilt werden

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 kann selbst bestimmen, wie es die Präferenz berechnet. Im Prinzip kann ein Gateway auch unterschiedliche Werte für einzelne Segmente liefern. Aktuell verwenden alle Gateways vereinfacht gesagt eine Präferenz, die auf dem Traffic-Peak in den letzten 24 Stunden basiert.

Jedes Gateway wird seine Präferenz als JSON-Dokument per HTTP unter dem Pfad /data/gwstatus.json zur Verfügung stellen. Das Format ist in einem JSON-Schema beschrieben.

Basierend auf einer Idee von NeoRaider verwenden wir eine Verzögerung bei der Antwort auf initalen Handshake eines Nodes.

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 ein on-verify Script im Einsatz, das die Antwort auf den Handshake abhängig von der Präferenz des Gateways um bis zu 8 Sekunden verzögert. Damit kommen wenig ausgelastete Gateways stark ausgelasteten zuvor und werden daher bevorzugt.

Bei einer Verzögerung des Handshake um 10 Sekunden kamen bei unseren Tests keine Verbindung mehr zustande.

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 Gluon-Patch, der das Delay entfernt.

Wir haben ein Grafana-Dashboard um die Präferenzen und Tunnel zu überwachen.

Unsere Implementierung steht auf Github zur Verfügung.