Wie viele Kerne braucht OpenVPN? Das hängt vom Pfad ab

Zwei Server mit gleicher Prozessorzahl können sehr unterschiedlichen Durchsatz liefern, denn die entscheidende Zahl ist, wie viele Kerne der aktive Datenpfad tatsächlich nutzen kann. Ein einzelner Userspace-Daemon, der die Pakete eines Clients verarbeitet, ist auf einen Kern begrenzt, während ein ausgelagerter Kernel-Pfad diese Arbeit verteilen kann. Keine der beiden Aussagen sagt, was eine bestimmte Maschine für Ihren Verkehr leisten wird, deshalb kommt die Messung vor dem Zählen der Kerne.

Der Vergleich unten handelt davon, wo Pakete verarbeitet werden, nicht davon, welches Produkt abstrakt schneller ist. Das sind verschiedene Fragen mit verschiedenen Antworten.

Ein Kern pro Strom auf dem Userspace-Pfad

In einer traditionellen Community OpenVPN Instanz wird der Datenkanal im Userspace verarbeitet, und eine ausgelastete Verbindung kann einen Prozessor belegen, während die Gesamtauslastung der Maschine unauffällig bleibt. Deshalb ändert das Hinzufügen von Kernen an einem Host, der auf einem einzigen Strom bereits gesättigt ist, nichts: Der Scheduler hat keine Möglichkeit, diese Arbeit zu teilen. Die Struktur eines Prozesses pro Client begrenzt die Übertragung eines Clients auf die Kapazität eines Kerns, unabhängig von der Gesamtzahl der Kerne. Lesen Sie während eines Tests die Auslastung pro Kern statt der Sammelzahl, sonst erscheint der Engpass als freie Reserve.

Mehrere Serverinstanzen auf einem Host zu betreiben verteilt getrennte Clients auf Prozesse. Es parallelisiert keine bestehende Verbindung und kostet getrennte Pools, Listener und Routing-Entscheidungen.

Der andere Pfad: Pakete im Kernel

Offload des Datenkanals verlagert die unterstützte Paketverarbeitung und Kryptografie in den Kernel, wo die Arbeit mehrere Kerne nutzen kann. Das verschiebt die Kapazitätsfrage von einem Kern auf die Maschine, aber nur für Konfigurationen, die die Implementierung unterstützt: ein kompatibles Kernelmodul, eine geeignete Datenchiffre und eine Konfiguration ohne die Funktionen, die das Offload ausschließt. Ein Modul zu installieren ist nicht dasselbe wie es zu nutzen, deshalb bestätigen Sie den aktiven Modus aus dem eigenen Protokoll oder der Statusausgabe der Verbindung. Ein Versionsbanner belegt, was verfügbar ist, nicht was läuft.

Offload beseitigt weder die Authentifizierung noch den Steuerkanal und macht nicht jede Bereitstellung mehrkernig. Es ist lokale Beschleunigung eines kompatiblen Datenpfads, und die Anforderungen unterscheiden sich je nach Plattform und Version.

Was der Vergleich tatsächlich entscheidet

Die eigentliche Wahl liegt zwischen dem Akzeptieren einer Obergrenze pro Strom, dem Verteilen von Clients über Instanzen und dem Wechsel zu einer unterstützten Offload-Konfiguration. Jede adressiert ein anderes Problem, und die falsche zu wählen kostet Geld, ohne die Zahl zu bewegen. Der Test, auf den es ankommt, ist der, der der Nutzung des Dienstes nachempfunden ist.

Messen Sie drei Formen: einen Client mit einer Übertragung, einen Client mit mehreren Strömen und mehrere Clients gemeinsam. Eine hohe Summe in der dritten belegt nicht, dass ein einzelner Download sie erreichen kann, und eine langsame Einzelübertragung belegt nicht, dass der Server seine Gesamtkapazität erschöpft hat. Die Ergebnisse beantworten verschiedene Fragen, und beide sind es wert.

Nur die mittlere Form sagt Ihnen, ob Nebenläufigkeit innerhalb eines Clients hilft, was meist eine Eigenschaft des Transports und des Pfads ist und nicht des Servers. Nur die erste nennt die Obergrenze, die eine einzelne Anwendung sehen wird. Halten Sie die Last zwischen den Läufen identisch, damit der Vergleich etwas bedeutet.

Messen, damit die Zahl etwas bedeutet

Notieren Sie die Versionen von Server und Client, den aktiven Datenpfad, die ausgehandelte Datenchiffre, die Übertragungsrichtung, Paketgrößen, Strömanzahl und Dauer. Beobachten Sie die Aktivität pro Kern sowie Paket- und Warteschlangenverluste an beiden Enden, denn die eigene Schnittstelle des Clients, das Netz des Anbieters oder der Zieldienst können zuerst zur Grenze werden. Ändern Sie jeweils eine Variable, denn ein Lauf, der Chiffre, Kompression, MTU und Offload gleichzeitig ändert, kann Ihnen nicht sagen, welche den Ausschlag gab. Behalten Sie während des Tests die Zugriffsrichtlinie bei, die Sie tatsächlich einführen wollen, denn ein Laboraufbau, den niemand betreiben wird, belegt wenig.

Lassen Sie dann Reserve für den Steuerkanal, für die Neuverhandlung und für alles andere, was auf dem Host läuft.

Berichten Sie, was die Konfiguration unter der beabsichtigten Nebenläufigkeit gehalten hat, statt einer Rate, die aus fremder Hardware extrapoliert wurde. Eine Zahl mit ihren Testbedingungen ist nützlich; ein Versprechen ohne sie ist eine Vermutung, die Ihnen später vorgehalten wird.