Brugere eller gennemstrømning? Dimensionering af en VPN-server til reel belastning
Kontotal dimensionerer ikke en gateway; det gør overlappende arbejde. Sammenlign samtidige overførsler, CPU pr. kerne og køer, og skriv derefter belastningen ned.
Ti inaktive konti koster mindre end én natlig sikkerhedskopi, der mætter tunnelen, og et brugertal kan ikke vise den forskel. Dimensionering af en VPN-server er en sammenligning mellem to tal: den samtidighed, du faktisk bærer, og den ressource, der løber tør først. De fleste kapacitetsfejl opstår, fordi man vælger det første tal og aldrig måler det andet. Gør begge dele i den rækkefølge, og hardwarebeslutningen er ikke længere et gæt.
Sammenlign kontotallet med den travle time
Kontotallet er en licens og en støttegrænse; den travle time er en belastning. Skriv det arbejde op, der overlapper i den time: opkald, fjernadministration, store downloads, sikkerhedskopier og de private applikationsanmodninger, der holder folk ventende. Markér derefter for hvert punkt, om det passerer gatewayen og i hvilken retning. Opkald er symmetriske og følsomme over for forsinkelse, mens en sikkerhedskopi er en retning og tåler en langsom start, så de belaster forskellige dele af vejen.
Retningen afgør, hvilken forbindelse der betyder noget. En hjemmeopkobling er sjældent symmetrisk, og en filial, der downloader hele dagen, rammer sin nedstrømsgrænse længe før, gatewayen begynder at svede. Skriv retningen og tunnelens omfang ved hvert punkt, fordi en gateway med kun private destinationer og en med al internettrafik er to forskellige dimensioneringsproblemer.
Tilføj baggrundsbelastning som sin egen række: klientopdateringer, telemetri og hvad værten ellers laver ud over at videresende. De bytes er nemme at glemme, og de tælles af den samme grænseflade.
Find den ressource, der løber tør før forbindelsen
Forbindelsen er kun én kandidat. Kryptoarbejdet i en enkelt tunnel kan låse en kerne, mens grænsefladen står halvt ledig, og en mættet kø kan gøre opkald ubrugelige ved en gennemstrømning, der ser middelmådig ud på en graf. En destination, der er én langsom rute væk, kan også se ud som gateway-svaghed fra klientens stol. Tre observationer skiller disse tilfælde, og ingen af dem kræver en burst-test.
| Observation | What to inspect |
|---|---|
| one core busy, bytes steady | per-core CPU, implementation, offload status |
| calls degrade during transfers | queueing and the access link |
| one remote destination slow | that route and its service |
Mål med en overførsel, du har lov til at køre, og tilføj det samtidige arbejde i trin i stedet for alt på én gang. Læs den vedvarende hastighed og den interaktive respons sammen, fordi en test af spidshastigheden alene skjuler en session, der er blevet ubrugelig. En gateway, der passerer sin maksimale gennemstrømning, mens opkald falder fra hinanden, har ikke bestået testen.
Gentag derefter kørslen med valgfrie belastninger stoppet. En grænse, der flytter sig, når sikkerhedskopien stopper, var aldrig gatewayens grænse.
Gør sammenligningen til et tal, du kan forsvare
Vælg den ressource, der løb tør, og udtryk kravet i dens enheder: kerner ved en måludnyttelse i den travle time, bit per sekund i hver retning eller samtidige sessioner under en forsinkelsesgrænse. Levn plads til opdateringer, diagnostik og genopretning, fordi en server, der sidder på sit målte loft, ikke har noget tilbage til det arbejde, der holder den kørende. Skriv derefter tallene ved siden af den konfiguration, der gav dem, inklusive klienttallet og den anvendte test.
Et tal for brugere pr. kerne er det mindst flytbare tal i denne øvelse, fordi det forudsætter en protokolblanding og en enhedsprofil, som det næste sted ikke deler. Behold målingen og drop formlen. Når nogen beder om kapacitet til halvtreds ekstra brugere, er det ærlige svar den travle times profil for de halvtreds, ikke en multiplikation.
Notér responstiden såvel som gennemstrømningen. Kapacitet, der kun bevarer bulkoverførsel, er ikke kapacitet for folk på opkald, og den næste gennemgang vil spørge til forskellen.
Vælg mellem at skalere op og at dele rollen
Når den målte grænse er én kerne, hjælper flere kerner med samme hastighed måske ikke; en hurtigere kerne eller en anderledes arbejdermodel kan. Når grænsen er samlet CPU, er en større instans den direkte løsning. Når grænsen er adgangsforbindelsen, hjælper ingen serverændring, og sammenligningen slutter hos udbyderen. At dele web- og VPN-rollerne på separate værter køber isolering for prisen af en anden administrationsflade.
Sammenlign de muligheder med det registrerede tal i stedet for med hinanden. En ændring, der fordobler en ressource, som ikke var begrænsningen, er en udgift uden gavn, og registreringen er det, der lader dig sige det uden en diskussion. Mål igen efter ændringen med samme belastning, ellers har du erstattet et gæt med et andet.