VPN-Serverlast erklärt: Nutzer, CPU oder Uplink?

Ein Gateway mit einer Last von 0.4 kann für jeden Nutzer dahinter trotzdem kriechen. Die durchschnittliche Last zählt Aufgaben, die lauffähig sind oder in unterbrechungsfreiem Schlaf festhängen, und auf einem Host mit vier Kernen reicht ein einziger gesättigter Prozess, um sie in Richtung 1.0 zu drücken, während drei Kerne gelangweilt dasitzen. Diese Zahl als Reserve zu lesen ist der häufigste Fehler bei der Endpunktauswahl. Was einen Tunnel tatsächlich begrenzt, ist meist eines von vier Dingen: ein beschäftigter Kern, die Anbindung, die Warteschlange davor oder eine Richtlinie pro Sitzung, die niemand dokumentiert hat.

Die durchschnittliche Last zählt Aufgaben, nicht Durchsatz

Der Kernel beprobt die Ausführungswarteschlange und die Zahl der auf Ein- und Ausgabe wartenden Aufgaben und glättet beides über eine, fünf und fünfzehn Minuten. Nichts in dieser Definition erwähnt Bytes, Pakete oder Tunnel. Ein Host mit blockiertem Speicher kann eine hohe Last bei fast keinem Verkehr melden, und ein Host, der ein Gigabit über einen Kernel-Datenpfad schiebt, kann eine entspannte melden.

Die Last mit der Tunnel-Leistung zu korrelieren erfordert daher eine Sicht pro Kern. Ist ein Kern voll ausgelastet, sieht der Gesamtprozentsatz auf einem Dashboard trotzdem gut aus:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

Der dritte Befehl ist der wichtigste auf VPN-Hosts. Die Paketverarbeitung im Userspace ist in OpenVPN 2.x weitgehend pro Prozess serialisiert, sodass ein einzelner beschäftigter Thread zur Obergrenze werden kann, während das Dashboard reichlich Leerlaufkapazität meldet. Wenn ein Thread während Ihrer langsamen Phase den größten Teil eines Kerns belegt, ist der Host insgesamt nicht unterdimensioniert; er ist in der Dimension begrenzt, die zufällig zählt.

Achten Sie auch auf den Zeitpunkt. Fünfzehn-Minuten-Mittel verbergen den Ausbruch, der einen Anruf ruiniert hat, daher ist ein Screenshot nach der Beschwerde schwacher Beweis. Messen Sie während des Problems und bewahren Sie den Zeitstempel mit der Ausgabe auf.

Die Anbindung und die Warteschlange davor

Schnittstellenzähler beantworten die Bandbreitenfrage, die CPU-Zahlen nicht beantworten können. Sie trennen auch Kapazität von Verlust, was unterschiedliche Fehler mit unterschiedlichen Behebungen sind:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Eine Strecke, die während Ihres Tests nahe an ihrer bereitgestellten Rate liegt, ist die Erklärung, und keine Menge freier CPU ändert das. Die qdisc-Zeile ergänzt das Detail, das für interaktiven Verkehr zählt: Rückstau und Verluste sagen Ihnen, ob Pakete vor dem Verlassen in einer Warteschlange warten. Eine Warteschlange, die sich unter einem großen Upload füllt, erzeugt genau das Symptom, das Leute dem entfernten Server zuschreiben, also zähe Anrufe auf einer Verbindung, die im Benchmark noch gut abschneidet.

Zähler für Neuübertragungen erfassen den Fall, dass Pakete hinausgehen, aber nie sauber ankommen. Steigen die Neuübertragungen im langsamen Fenster und ist die Schnittstelle weit von ihrer Kapazität entfernt, liegt das Problem im Pfad und nicht auf dem Host, und ein Wechsel zu einem anderen Endpunkt derselben Stadt hilft nicht.

Sitzungszahlen beschreiben Nachfrage, nicht Reserve

Jedes öffentliche Verzeichnis zeigt irgendeine Zahl verbundener Nutzer, und fast keines verrät Ihnen, was diese Nutzer tun. Zwanzig Sitzungen mit interaktiver Arbeit und vier Sitzungen, die große Dateien ziehen, erzeugen auf derselben Hardware sehr unterschiedliche Lasten. Das zweite Muster ist in einer Nutzerzahl unsichtbar, und genau es ruiniert einen Abend. Eine Sitzungszahl liest man daher am besten als Hinweis auf die Nachfrage, nie als Aussage über freie Kapazität.

Auf einem Host, den Sie kontrollieren, liefert die Statusdatei die fehlende Dimension. OpenVPN schreibt eine regelmäßige Momentaufnahme mit Byte-Zählern pro Client, und das reicht, um zu sehen, ob eine Sitzung für die ganze Anbindung verantwortlich ist:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Zwei Proben im Abstand von zehn Sekunden verwandeln diese kumulativen Zähler in eine Rate pro Client. Das ist die Messung, für die eine Nutzerzahl einsteht, und so entdecken Sie auch, dass ein einzelner falsch konfigurierter Client die Strecke jede Nacht zur selben Stunde sättigt.

Limits pro Sitzung verstecken sich in der Richtlinie

Ein Server kann untätig sein und Ihnen trotzdem Bandbreite verweigern. Ratenbegrenzungen, Bandbreitendeckel pro Client und Traffic-Shaping werden oft pro Common Name oder pro Pool angewendet, sodass zwei Nutzer am selben Gateway völlig unterschiedliche Ergebnisse bekommen können. Der Mechanismus ist nicht subtil, aber von außen unsichtbar, weil der Tunnel in beiden Fällen normal hochkommt.

Suchen Sie Shaping an der Tunnel-Schnittstelle statt an der physischen. Prüfen Sie, ob das Limit dem Nutzer, dem Zertifikat oder dem Adresspool folgt. Landet Ihr Testkonto im ungedeckelten Pool, werden Sie schließen, dass der Server in Ordnung ist und der klagende Nutzer sich irrt. Diese Schlussfolgerung ist schlimmer als keine, weil sie das Ticket schließt.

Vergleichen Sie zwei Endpunkte mit einer festen Aufgabe

Das Experiment auf der Client-Seite lohnt sich weiterhin, aber nur, wenn die Variablen festgenagelt sind. Verwenden Sie dasselbe Gerät, dasselbe Zugangsnetz, dasselbe Protokoll und dieselbe Zieldatei, und wiederholen Sie es dann gegen einen zweiten Endpunkt in ähnlicher Entfernung. Alles, was sich zwischen den Läufen ändert, einschließlich der Tageszeit, verfälscht das Ergebnis.

Halten Sie Fehlschläge so sorgfältig fest wie Erfolge. Eine Reihe, in der drei Endpunkte funktionieren und einer in einen Timeout läuft, ist aussagekräftiger als vier Geschwindigkeitszahlen, weil sie auf ein Pfad- oder Richtlinienproblem deutet statt auf ein Kapazitätsproblem. Führen Sie jeden Fall mindestens zweimal aus; eine einzelne langsame Probe beweist in einem geteilten Netz nichts.

Zum Schluss: Bewahren Sie die gesammelten Zahlen zusammen mit der Aussage auf, die sie stützen. "Dieser Endpunkt hat die Übertragung in demselben Fenster geschafft, in dem der andere stockte" ist vertretbar, während "dieser Endpunkt ist schneller" zu einem Streit einlädt, den Sie mit einer Startseiten-Bewertung nicht gewinnen. Das OpenVPN-2.6-Handbuch dokumentiert die Statusdatei und die Shaping-Optionen, falls Sie die genauen Anweisungen für die Host-Seite brauchen.