Load Balancing der OpenVPN Clients funktioniert, leider kein Performancegewinn

JeGr

Hast du es auf einem Rechner mal mit einem Downloadmanager versucht, der ggf. 3-4 gleichzeitige Verbindungen aufbaut um deine Tunnel auszulasten? Wie sieht denn die CPU/Load/IRQ Last aus?

Gruß

Habt ihr Ideen, woran das liegen könnte?

Ich denke das man OpenVPN nur mit brachialer CPU power und mehr Kernprozessor so richtig auf trapp bringen kann.
Wenn man mehrere Tunnel aufbaut, kann je ein Tunnel über einen CPU Kern abgearbeitet werden, klar keine echte oder
richtige Multi-CPU Benutzung, aber auch immer noch besser als alle Tunnel über einen CPU laufen zu lassen.

Was ist das denn für eine CPU die dort werkelt und vor allem wie schnell ist die denn genau?

un1que

@JeGr:
Ja, das meinte ich mit mehreren Verbindungen.

Die CPU Last liegt bei durchschnittlich 12MB/s Download bei ca. 20-35%, teilweise geht sie kurzzeitig auf 55-60% hoch (soweit ich das aus dem Dashboard Widget deuten kann). Wenn ich aber unter Status > Monitoring schaue, dann wird mir als Höchstwert von system util. - ca. 25% angezeigt. Was stimmt denn nun oder müsste ich dann noch user util. (ca. 18% als max. Wert) dazu addieren?

Wo finde ich die Werte für Load und IRQ raus, die benötigt werden? Kann man sich irgendwo die Auslastung nach Cores anschauen?

@BlueKobold:
Das ist die Intel N3700 CPU mit 4 Cores á 1.6GHz und Turbo Boost bis jeweils 2.4GHz***** - sollte doch ausreichend sein? Ich meine, ich erreiche ja die Geschwindigkeiten um die 20MB/s auf der 200er Leitung, allerdings bisher nur dann, wenn ich auf 2 Computern einen Downloads starte und auch dann ist die CPU immer noch nicht voll ausgelastet. Sollte doch wohl eher auf einen Konfigurationsfehler oder fehlende Optimierung hindeuten, wenn man mit einem Computer nur ca. die Hälfte schafft?

*****Ich gehe zwar davon aus, dass pfSense bei Bedarf den Turbo Boost auch wirklich nutzt (alle Einstellungen sind gesetzt, BIOS: Turbo Mode, P-State - SW_ALL, C-State - C7 & pfSense Advanced > Misc: PowerD + Hiadaptive), aber könnte man das trotzdem irgendwie auf verlässliche Art und Weise überprüfen?

PS: Habe am WE zum Testen mal die 2.4 Beta installiert. Zuvor waren bei mir alle Hardware Crypto Einstellungen ausgeschaltet. Jetzt habe ich unter Advanced > Misc AES-NI ausgewählt, reicht das oder muss ich noch für jeden VPN Client eine Hardware Crypto einstellen (allerdings hätte ich nur die Intel RDRAND zur Auswahl)?

PPS: Seit der Erstellung des Threads habe ich halt ein wenig rumprobiert, verschiedene Einstellungen geändert und eben auch die 2.4 Beta installiert. Es scheint sich einiges gebessert zu haben und ich erreiche teilweise auch schon brauchbare Ergebnisse (v.a. wenn ich mit der GCM Verschlüsselungsmethode teste). Ich werde jetzt im Laufe der nächsten Tage noch weitere Tests durchführen und melde mich dann nochmal mit den Ergebnissen.
Wäre aber trotzdem schön, wenn man auf meine Fragen in diesem Post eingehen könnte.

JeGr

Wo finde ich die Werte für Load und IRQ raus, die benötigt werden? Kann man sich irgendwo die Auslastung nach Cores anschauen?

Am Besten gar nicht via UI, damit die UI nicht auf die Performance drückt, sondern per SSH einloggen und mit "top" mal nachsehen was die CPU macht und wer wieviel Prozent abgreift.

Jetzt habe ich unter Advanced > Misc AES-NI ausgewählt, reicht das oder muss ich noch für jeden VPN Client eine Hardware Crypto einstellen (allerdings hätte ich nur die Intel RDRAND zur Auswahl)?

Nein für OpenVPN muss nichts ausgewählt sein, hier gehts nur um das Kernel Modul AESNI.ko und das wird IMHO nur für IPSec wirklich benötigt (es sei denn 2.4 macht da was signifikant anders).

Grüße

un1que

@JeGr:

Wo finde ich die Werte für Load und IRQ raus, die benötigt werden? Kann man sich irgendwo die Auslastung nach Cores anschauen?

Am Besten gar nicht via UI, damit die UI nicht auf die Performance drückt, sondern per SSH einloggen und mit "top" mal nachsehen was die CPU macht und wer wieviel Prozent abgreift.

Ok, danke. Werde ich mal ausprobieren.

@JeGr:

Jetzt habe ich unter Advanced > Misc AES-NI ausgewählt, reicht das oder muss ich noch für jeden VPN Client eine Hardware Crypto einstellen (allerdings hätte ich nur die Intel RDRAND zur Auswahl)?

Nein für OpenVPN muss nichts ausgewählt sein, hier gehts nur um das Kernel Modul AESNI.ko und das wird IMHO nur für IPSec wirklich benötigt (es sei denn 2.4 macht da was signifikant anders).

Grüße

Gut, also bei OpenVPN nichts auswählen. Der AES-NI Punkt unter Advanced > Misc ist auch bei 2.4 für OpenVPN irrelevant? Bei unter 2.4 war die Performance ja sogar etwas schlechter, was viele Tests belegt haben. Aber ab 2.4, dachte ich, sollte man schon AES-NI in den Einstellungen definieren (v.a. für GCM), nicht?

Das ist die Intel N3700 CPU mit 4 Cores á 1.6GHz und Turbo Boost bis jeweils 2.4GHz* - sollte doch ausreichend sein?

Ja klar nur für wie viel soll die CPU ausreichend sein?

Wenn von 200 MBit/s nur 20 MBit/s erreicht werden ist das zwar schade aber für was benötigt man ein VPN?
Um von unterwegs alle anfallenden Sachen sicher nach Hause auf das NAS zu kopieren oder andersherum abzurufen, oder?

Aber wenn von 200 MBit/s ein Durchsatz von …. 20 MB/s..... erreicht werden, dann sind das doch 20 MB/s * 8 = 160 MBit/s
und plus den Overhead vom VPN und dem TCP/IP ist man da auch schon fast an der Grenze des theoretisch machbaren, oder?

Man kann sicherlich einige Sachen versuchen zu tunen aber mal mit mehr und mal mit weniger Glück!
Auf jeden Fall würde ich;

PowerD (hi adaptive) aktivieren und einstellen
Hyperthreading der CPU aktivieren im BIOS
TRIM aktivieren bei einer mSATA, SSD
und bei weiteren Problemen oder Wünschen;
die mbuf size auf 1000000 erhöhen bei 8 GB RAM
die numqueue Größe auf 2 oder 4 fest einstellen

Man kann damit auch experimentieren und nicht immer nur eine Sache verstellen, manchmal sind es mehrere Sachen in
unterschiedlicher Zusammensetzung. Man muss das je nach Hardware eben mal ausprobieren.

un1que

@BlueKobold:

Das ist die Intel N3700 CPU mit 4 Cores á 1.6GHz und Turbo Boost bis jeweils 2.4GHz* - sollte doch ausreichend sein?

Ja klar nur für wie viel soll die CPU ausreichend sein?

Wenn von 200 MBit/s nur 20 MBit/s erreicht werden ist das zwar schade aber für was benötigt man ein VPN?
Um von unterwegs alle anfallenden Sachen sicher nach Hause auf das NAS zu kopieren oder andersherum abzurufen, oder?

Nein, ausgehend bzw. eingehend auch, aber hier geht es nicht darum. Es waren aber schon 20MB/s gemeint, nicht Mbit, also ja - ca. 160Mbit/s und ja, ist schon ein guter Wert, wobei das auch "nur" das Ergebnis von vor paar Tagen (als ich den Thread erstellt habe) war. Am WE und gestern habe ich auch mal bis zu 22MB/s geschafft (mit der 2.4 Beta), kann also nur noch besser werden :)

@BlueKobold:

Man kann sicherlich einige Sachen versuchen zu tunen aber mal mit mehr und mal mit weniger Glück!
Auf jeden Fall würde ich;

PowerD (hi adaptive) aktivieren und einstellen [habe ich gemacht]

Hyperthreading der CPU aktivieren im BIOS [unterstützt der N3700 nicht, hat sich also erledigt… leider]

TRIM aktivieren bei einer mSATA, SSD [mSATA ist vorhanden; irgendwie finde ich aber keine brauchbare Anleitung, wie ich das anstellen kann - könntest du es bitte kurz beschreiben?]
und bei weiteren Problemen oder Wünschen;

die mbuf size auf 1000000 erhöhen bei 8 GB RAM [also [i]kern.ipc.nmbclusters="1000000" unter System > Advanced > System Tunables hinzufügen? Könnte man das auch bei 4GB RAM machen oder wären das zu wenig bzw. dann einen kleineren Wert als 1000000 nehmen, richtig? Wobei ich auch sagen muss, dass die Anzeige bei mir die ganze Zeit bei 8% (ca. 20k/240k) steht, daher lass ich es besser sein oder?]

die numqueue Größe auf 2 oder 4 fest einstellen [was ist das und wie richte ich das ein, auch unter System Tunables?]

Man kann damit auch experimentieren und nicht immer nur eine Sache verstellen, manchmal sind es mehrere Sachen in
unterschiedlicher Zusammensetzung. Man muss das je nach Hardware eben mal ausprobieren.

Danke für die Tuning Tipps. Habe dazu ein paar Fragen gleich in das Zitat eingefügt, könntest du sie dir mal bitte ansehen?

@JeGr:
Also ich habe mir jetzt mal über Shell die Auslastung angesehen (danke für den Tipp, ist echt angenehmer und aktualisiert schneller und zuverlässiger) und habe folgendes festgestellt:
1. GCM und CBC erreiche ich nahezu dieselben Werte, nur ist die CPU Auslastung bei CBC spürbar höher.
2. GCM: Bei ca. 13MB/s liegt die Auslastung bei ca. 35-40%, bei ca. 20MB/s bei ca. 50-55% und geht teilweise ganz kurz auf 60-65% (evtl. auch wegen anderen Diensten) hoch.
CBC: Bei ca. 20MB/s liegt diese bei etwa 65-70% und geht teilweise kurzzeitig auf bis zu 80-85% hoch.
3. CBC: Mit einem Tunnel schaffe ich bis zu 18MB/s, aber im Schnitt um die 15MB/s. Mit 2 im Load Balance Modus bis zu 22MB/s, im Schnitt bei 16-17MB/s.

@all:
Ist bei mir bei 22MB/s wirklich schon Schluss, wegen Overhead und so (WAN-seitig lagen vor dem Test 219Mbit an, also rund 27,5MB)?
Was ich jetzt noch sehr komisch finde: ich erreiche bei einem einfachen Download (z.B. http://speedtest.belwue.net/http-dl.html) nur max. 6MB/s und teilweise wird die Datei mit durchschnittlich 3MB/s runtergeladen und geht ab und an auf 5MB/s hoch - woran liegt das, ist doch arg wenig? Ich meine, ich kann schon verstehen, dass bei VPN die Geschwindigkeiten um die 20MB+ nur bei mehreren Tunneln und mehreren gleichzeitigen Verbindungen möglich sind, aber so 3-5MB/s ist doch irgendwie schon sehr wenig, wie ich finde. Kann man in diese Richtung noch etwas tunen?

JeGr

Zu den Optimierungen: Vorsicht!

PowerD (hi adaptive) aktivieren und einstellen [habe ich gemacht]
-> würde ich nicht machen. Wenn hier nicht Stromsparen im Vordergrund steht, ist PowerD auf maximum das beste Setting, damit die CPU nicht ständig in Stromspar Modus wechselt und die Taktung reduziert.
Hyperthreading der CPU aktivieren im BIOS [unterstützt der N3700 nicht, hat sich also erledigt… leider]
-> HT ist bei Firewalls bzw. FreeBSD eh ein Thema, das man lieber sein lassen sollte. Warum hatte ich an anderer Stelle bereits mal gepostet. Schlußendlich gibts einfach genug Messungen die bescheinigen, dass das virtuelle Rumgebimsel von Hypertrhreading für Firewalls und Durchsatz nix bringt und sogar bremsen kann - also abschalten, nicht anschalten.
TRIM aktivieren bei einer mSATA, SSD

und bei weiteren Problemen oder Wünschen;

die mbuf size auf 1000000 erhöhen bei 8 GB RAM
-> Das hängt weniger an den 8GB RAM, als dass es mehr eine Interface Tuning empfehlung bei IGB und EM Interfaces (Intel) ist da hier die Buffer ggf. recht schnell vollaufen können. Man sieht den Wert aber im Interface und kann sich das anschauen ob man da ran sollte. Schaden tuts nicht und 4GB RAM reichen da auch.

die numqueue Größe auf 2 oder 4 fest einstellen [was ist das und wie richte ich das ein, auch unter System Tunables?]
-> Die NumQueues müssen eigentlich nur dann verändert werden, wenn es Probleme mit dem Auto Setting gibt - meist bei vielen CPUs/Kernen und aktivem Hyperthreading. Ansonsten sind die von selbst schon auf $AnzahlKerne. Der Wert ist Interface Spezifisch also bspw. hw.igb.num_queues=1

1. GCM und CBC erreiche ich nahezu dieselben Werte, nur ist die CPU Auslastung bei CBC spürbar höher.

Das ist ja auch der Clou :) Darum freuen sich viele mit schwacher CPU darauf, dass GCM kommt, damit die CPU entlastet wird und sie ggf. doch noch mehr Durchsatz bekommen.

3. CBC: Mit einem Tunnel schaffe ich bis zu 18MB/s, aber im Schnitt um die 15MB/s. Mit 2 im Load Balance Modus bis zu 22MB/s, im Schnitt bei 16-17MB/s.

Dann sollte das mit GCM ja auch zu packen sein. Prinzipiell kann man Bandbreiten immer ganz schlecht an einer Seite messen, wenn du die andere nicht kontrollierst. Daher kann ich keine genauen Tips geben, warum es mit 2 Tunneln 22MB/s sind, mit einem aber nicht. Theoretisch solltest du das mit einem auch haben, aber das kommt auch auf die Gegenseite an. Und dann auch noch, ob da bspw. adaptive compression und co mitspielen oder nicht.

Gruß

un1que

@JeGr:

PowerD (hi adaptive) aktivieren und einstellen [habe ich gemacht]
-> würde ich nicht machen. Wenn hier nicht Stromsparen im Vordergrund steht, ist PowerD auf maximum das beste Setting, damit die CPU nicht ständig in Stromspar Modus wechselt und die Taktung reduziert.

Naja, ist ja jetzt nicht so, dass die CPU ständig mit sehr viel VPN Traffik zu werkeln hat. Wenn sie dann aber einmal hochgedreht hat, wird sie ja mittendrin im Prozess nicht wieder drosseln, sondern erst, wenn die Leistung nicht mehr benötigt wird - so habe ich diese Funktion zumindest verstanden.
Ist ja in erster Linie ein Heimrouter und sollte so wenig wie möglich verbrauchen, dabei aber - sobald benötigt - Power bringen. Ich dachte, für diesen Zweck wäre die Einstellung bestens geeignet, nicht?

Danke auch für die weiteren Tipps, werde ich berücksichtigen.

@JeGr:

3. CBC: Mit einem Tunnel schaffe ich bis zu 18MB/s, aber im Schnitt um die 15MB/s. Mit 2 im Load Balance Modus bis zu 22MB/s, im Schnitt bei 16-17MB/s.

Dann sollte das mit GCM ja auch zu packen sein. Prinzipiell kann man Bandbreiten immer ganz schlecht an einer Seite messen, wenn du die andere nicht kontrollierst. Daher kann ich keine genauen Tips geben, warum es mit 2 Tunneln 22MB/s sind, mit einem aber nicht. Theoretisch solltest du das mit einem auch haben, aber das kommt auch auf die Gegenseite an. Und dann auch noch, ob da bspw. adaptive compression und co mitspielen oder nicht.

Ja, ich weiß, wenn man die Gegenstelle nicht kontrollieren kann, dann ist es schwieriger zu sagen, woran es liegen könnte. Aber so schlimm ist es dann nicht mehr, wenn ich letztendlich "nur" mit 2 Tunneln die Maximalwerte erreiche.
GCM habe ich noch nicht so ausgiebig getestet, kann aber tatsächlich sein, dass ich damit auch mal die volle Leistung durch einen Tunnel abrufen kann, mal sehen.
Die Komprimierung wird mir ja serverseitig mit "comp-lzo" vorgegeben, daher habe ich wohl auch keinen Spielraum für Optimierungen. Außer, dass es bei der Beta 2 Varianten gibt: "compress lzo, equivalent to comp-lzo yes for compatibility" und "Legacy Style, comp-lzo yes" und ob es da einen Unterschied zwischen den beiden gibt, muss ich wohl noch herausfinden.

Aber vielmehr Sorgen macht mir jetzt die Tatsache, dass mit einer einzigen Verbindung nur 3-5MB/s gehen. Gibt es vllt. auch noch dafür irgendwelche Tuning Tipps oder irgendwelche Gedanken?

un1que

Also scheinbar funktioniert doch alles so wie es soll, nur gab es wohl mit CBC deutliche Performanceeinbußen, die jetzt mit GCM Geschichte sind.

Mich interessiert es sehr, wie genau das Failover im Zusammenhang mit dem Load Balancer funktionieren?
(Wenn ich bspw. 3 Tunnel nehme und dort jeweils Tier 1-3 vergebe, dann ist klar: wenn der 1. Tunnel ausfällt, dann kommt der 2. ins Spiel usw.)
Wenn ich nun aber jeweils 2 Tunnel pro Tier definiere, wie genau läuft es dann? Wenn Tunnel_1@Tier_1 ausfällt, läuft dann alles ausschließlich über den Tunnel_2@Tier_1 (und der Umschwung auf Tier 2 geschieht nur bei Ausfall beider Tunnel aus Tier 1) oder werden auch die anderen Tunnel aus Tier 2 mitbenutzt?

Noch eine allgemeine Frage zum Failover: unter Advanced => Misc kann man "State Killing on Gateway Failure" einstellen - damit soll es wohl reibungsloser laufen, richtig? Ein Problem sehe ich allerdings darin, dass dann wirklich alle States gekillt werden (auch von Verbindungen, welche über andere Gateways laufen) und somit Live-Streams oder VOIP Verbindungen abgebrochen werden, obwohl sie nichts mit dem ausgefallenen Gateway zu tun haben. Hat man einen wirklichen Nachteil, wenn man das "State Killing on Gateway Failure" nicht nutzt?

JeGr

Hi,

mehrere gleiche Tiers sollten den Effekt haben, dass Verbindungen über die Gateways des Tiers entsprechend round robin rausgehen und damit beide Leitungen nutzen. Das ist zumindest auch das Bild, was wir hier in verschiedenen Setups sehen. Beispiel 4 verschiedene GWs an 4 Leitungen -> die Clients dahinter teilen sich die Bandbreite der 4 Gateways. Fällt eines aus, steht eben insg. nur noch die Bandbreite von 3 zur Verfügung. Natürlich ist das kein "schön gewichtetes" loadbalancing und kein additives Setup (3x50 MBit/s != 150MBit/s) aber in den Setups wo es genutzt wird, sind die Clients deutlich zufriedener (gerade wenn man jetzt häufiger mal Linespeed hat ;)).

State Killing tut genau das, macht aber IMHO eher bei so etwas wie VPN Verbindungen Sinn, wo natürlich die Verbindung gekillt werden soll, wenn das VPN down ist, damit kein Traffic unverschlüsselt über die Leitung tröpfelt. Für ein LoadBalancing Setup ist das eher unpraktisch, wenn dann eher bei einem Failover Setup, bei dem die 2. Leitung kleiner ist als die primäre und man erzwingen will, dass die Verbindungen wieder über die primäre Leitung aufgebaut werden (und nicht erst wenn der State mal einen Timeout bekommt).

Gruß

un1que

@JeGr:

Hi,

mehrere gleiche Tiers sollten den Effekt haben, dass Verbindungen über die Gateways des Tiers entsprechend round robin rausgehen und damit beide Leitungen nutzen. Das ist zumindest auch das Bild, was wir hier in verschiedenen Setups sehen. Beispiel 4 verschiedene GWs an 4 Leitungen -> die Clients dahinter teilen sich die Bandbreite der 4 Gateways. Fällt eines aus, steht eben insg. nur noch die Bandbreite von 3 zur Verfügung. Natürlich ist das kein "schön gewichtetes" loadbalancing und kein additives Setup (3x50 MBit/s != 150MBit/s) aber in den Setups wo es genutzt wird, sind die Clients deutlich zufriedener (gerade wenn man jetzt häufiger mal Linespeed hat ;)).

Ja, das mit den gleichen Tiers habe ich verstanden, dass es wohl ein "einfaches" Failover ist. Aber wie gesagt, mich interessiert es, wie es aussieht, wenn in jedem Tier mehr als 1 Gateway definiert ist? Wird es dann genau so gehandhabt, als wäre nur 1 GW pro Tier eingerichtet (dass das Tier erst dann gewechselt wird, sobald alle enthaltenen GW's down sind) oder gibt es eine gewisse Ausnahmeregelung (Umschwung auf ein anderes Tier bereits beim Ausfall eines GW's)?

@JeGr:

State Killing tut genau das, macht aber IMHO eher bei so etwas wie VPN Verbindungen Sinn, wo natürlich die Verbindung gekillt werden soll, wenn das VPN down ist, damit kein Traffic unverschlüsselt über die Leitung tröpfelt. Für ein LoadBalancing Setup ist das eher unpraktisch, wenn dann eher bei einem Failover Setup, bei dem die 2. Leitung kleiner ist als die primäre und man erzwingen will, dass die Verbindungen wieder über die primäre Leitung aufgebaut werden (und nicht erst wenn der State mal einen Timeout bekommt).

Gruß

Also, wenn man das automatische Wechseln der Gateways per Rules unterbunden hat, dann gibt es keine Vorteile beim State Kill, richtig?