Nutzer oder Durchsatz? Einen VPN-Server für echte Last dimensionieren

Zehn ruhende Konten kosten weniger als eine nächtliche Sicherung, die den Tunnel sättigt, und eine Nutzerzahl kann diesen Unterschied nicht zeigen. Einen VPN-Server zu dimensionieren ist ein Vergleich zweier Zahlen: der Nebenläufigkeit, die Sie tatsächlich tragen, und der Ressource, die zuerst ausgeht. Die meisten Kapazitätsfehler entstehen daraus, dass man die erste Zahl wählt und die zweite nie misst. Tun Sie beides, in dieser Reihenfolge, und die Hardwareentscheidung ist kein Ratespiel mehr.

Kontozahl und Spitzenstunde vergleichen

Die Kontozahl ist eine Lizenz und eine Supportgrenze; die Spitzenstunde ist eine Last. Listen Sie die Arbeit auf, die sich in dieser Stunde überlappt: Anrufe, Fernverwaltung, große Downloads, Sicherungen und die Anfragen privater Anwendungen, die Menschen warten lassen. Markieren Sie dann für jeden Posten, ob er das Gateway überquert und in welche Richtung. Anrufe sind symmetrisch und verzögerungsempfindlich, während eine Sicherung in eine Richtung läuft und einen langsamen Start verträgt, also belasten sie verschiedene Teile des Pfades.

Die Richtung entscheidet, welche Anbindung zählt. Ein Hausanschluss ist selten symmetrisch, und eine Filiale, die den ganzen Tag herunterlädt, stößt an ihre Downstream-Grenze, lange bevor das Gateway ins Schwitzen kommt. Schreiben Sie Richtung und Tunnelumfang neben jeden Posten, denn ein Gateway nur mit privaten Zielen und eines mit dem gesamten Internetverkehr sind zwei verschiedene Dimensionierungsprobleme.

Fügen Sie Hintergrundlast als eigene Zeile hinzu: Client-Updates, Telemetrie und was der Host außer Weiterleiten noch tut. Diese Bytes vergisst man leicht, und dieselbe Schnittstelle zählt sie mit.

Finden Sie die Ressource, die vor der Anbindung ausgeht

Die Anbindung ist nur ein Kandidat. Die Kryptoarbeit eines einzelnen Tunnels kann einen Kern auslasten, während die Schnittstelle halb leer dasitzt, und eine gesättigte Warteschlange kann Anrufe bei einem Durchsatz unbrauchbar machen, der im Diagramm mittelmäßig aussieht. Ein Ziel, das eine langsame Route entfernt ist, kann vom Platz des Clients aus auch wie eine Schwäche des Gateways aussehen. Drei Beobachtungen trennen diese Fälle, und keine braucht einen Burst-Test.

Messen Sie mit einer Übertragung, die Sie laufen lassen dürfen, und fügen Sie die nebenläufige Arbeit in Schritten hinzu statt alles auf einmal. Lesen Sie die Dauerrate und die interaktive Antwort zusammen, denn ein reiner Spitzenratentest verbirgt eine Sitzung, die unbrauchbar geworden ist. Ein Gateway, das seinen maximalen Durchsatz erreicht, während Anrufe abbrechen, hat den Test nicht bestanden.

Wiederholen Sie dann den Lauf mit gestoppten optionalen Lasten. Eine Grenze, die sich verschiebt, wenn die Sicherung aufhört, war nie die Grenze des Gateways.

Machen Sie aus dem Vergleich eine Zahl, die Sie verteidigen können

Wählen Sie die ausgegangene Ressource und drücken Sie die Anforderung in ihren Einheiten aus: Kerne bei einer Zielauslastung während der Spitzenstunde, Bit pro Sekunde in jeder Richtung oder nebenläufige Sitzungen unter einer Verzögerungsgrenze. Lassen Sie Raum für Updates, Diagnose und Wiederherstellung, denn ein Server an seiner gemessenen Obergrenze hat nichts mehr für die Arbeit übrig, die ihn am Laufen hält. Schreiben Sie dann die Zahlen neben die Konfiguration, die sie erzeugt hat, einschließlich Klientenzahl und verwendetem Test.

Eine Nutzer-pro-Kern-Zahl ist die am wenigsten übertragbare Zahl in dieser Übung, weil sie eine Protokollmischung und ein Geräteprofil annimmt, die der nächste Standort nicht teilt. Behalten Sie die Messung und verwerfen Sie die Formel. Wenn jemand Kapazität für fünfzig weitere Nutzer verlangt, ist die ehrliche Antwort das Spitzenstundenprofil dieser fünfzig, keine Multiplikation.

Halten Sie die Antwortzeit ebenso wie den Durchsatz fest. Kapazität, die nur Massenübertragung bewahrt, ist keine Kapazität für die Menschen im Anruf, und die nächste Überprüfung wird nach dem Unterschied fragen.

Zwischen Hochskalieren und Aufteilen der Rolle wählen

Wenn die gemessene Grenze ein Kern ist, helfen mehr Kerne gleicher Taktrate womöglich nicht; ein schnellerer Kern oder ein anderes Workermodell kann. Wenn die Grenze die Gesamt-CPU ist, ist eine größere Instanz die direkte Lösung. Wenn die Grenze die Zugangsanbindung ist, hilft keine Serveränderung und der Vergleich endet beim Anbieter. Die Web- und VPN-Rolle auf getrennte Hosts zu verteilen kauft Isolation zum Preis einer zweiten Verwaltungsfläche.

Vergleichen Sie diese Optionen mit der festgehaltenen Zahl statt miteinander. Eine Änderung, die eine Ressource verdoppelt, die nicht der Engpass war, ist Aufwand ohne Nutzen, und der Eintrag ist es, der Ihnen erlaubt, das ohne Diskussion zu sagen. Messen Sie nach der Änderung mit derselben Last erneut, sonst haben Sie eine Vermutung durch eine andere ersetzt.