Last på VPN-servere forklart: brukere, CPU eller uplink?

En gateway med last på 0.4 kan fortsatt krype for hver bruker bak den. Gjennomsnittslasten teller oppgaver som kan kjøres eller som står fast i uavbrutt søvn, og på en vert med fire kjerner er én mettet prosess nok til å skyve den mot 1.0 mens tre kjerner sitter ledige. Å lese det tallet som ledig kapasitet er den vanligste feilen ved valg av endepunkt. Det som faktisk begrenser en tunnel, er som regel én av fire ting: én opptatt kjerne, uplinken, køen foran den eller en policy per økt som ingen har dokumentert.

Gjennomsnittslasten teller oppgaver, ikke gjennomstrømning

Kjernen sampler køen av kjørbare oppgaver og antallet oppgaver som venter på inn- og utdata, og glatter deretter begge over ett, fem og femten minutter. Ingenting i den definisjonen nevner byte, pakker eller tunneler. En vert med fastlåst lagring kan rapportere høy last nesten uten trafikk, og en vert som presser en gigabit gjennom kjernens datasti kan rapportere en behagelig.

Å korrelere last med tunnelytelse krever derfor et blikk per kjerne. Hvis én kjerne er fullt belastet, vil den samlede prosenten på et dashbord fortsatt se fin ut:

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

Den tredje kommandoen er den som betyr mest på VPN-verter. Pakkebehandling i brukerland i OpenVPN 2.x er i stor grad serialisert per prosess, så én travel tråd kan bli taket mens dashbordet rapporterer rikelig med ledig kapasitet. Hvis én tråd holder mesteparten av en kjerne i den langsomme perioden din, er verten ikke underdimensjonert samlet sett; den er begrenset i den dimensjonen som tilfeldigvis betyr noe.

Legg merke til tidspunktet også. Femtenminuttersgjennomsnitt skjuler utbruddet som ødela en samtale, så et skjermbilde tatt etter klagen er svakt bevis. Ta prøver mens problemet pågår, og ta vare på tidsstempelet sammen med utdataene.

Uplinken og køen foran den

Grensesnitttellerne svarer på båndbreddespørsmålet som CPU-tall ikke kan. De skiller også kapasitet fra tap, som er forskjellige feil med forskjellige løsninger:

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

En lenke som under testen er nær sin tildelte hastighet, er forklaringen, og ingen mengde ledig CPU endrer det. qdisc-linjen legger til detaljen som betyr noe for interaktiv trafikk: etterslep og tap forteller om pakker venter i en kø før de forlater verten. En kø som fylles under en stor opplasting, gir nøyaktig det symptomet folk gir den eksterne serveren skylden for, altså trege samtaler på en forbindelse som fortsatt måler godt.

Videresendingstellere fanger tilfellet der pakker forlater verten, men aldri ankommer rent. Hvis videresendingene øker i det langsomme vinduet og grensesnittet er langt fra kapasitet, ligger problemet i banen og ikke på verten, og det hjelper ikke å flytte til et annet endepunkt i samme by.

Sesjonstall beskriver etterspørsel, ikke ledig kapasitet

Hver offentlig katalog viser et visst antall tilkoblede brukere, og nesten ingen av dem forteller hva disse brukerne gjør. Tjue økter med interaktivt arbeid og fire økter som henter store filer gir svært forskjellige laster på samme maskinvare. Det andre mønsteret er usynlig i et brukertall, og det er nettopp det som ødelegger en kveld. Derfor leses et sesjonstall best som et hint om etterspørsel, aldri som en uttalelse om ledig kapasitet.

På en vert du kontrollerer, gir statusfilen den manglende dimensjonen. OpenVPN skriver et regelmessig øyeblikksbilde med bytetellere per klient, og det er nok til å se om én økt er ansvarlig for hele uplinken:

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

To prøver ti sekunder fra hverandre gjør de kumulative tallene om til en hastighet per klient. Det er målingen et brukertall står i stedet for, og det er også slik du oppdager at én feilkonfigurert klient metter lenken hver natt på samme tid.

Grenser per økt gjemmer seg i policyen

En server kan være ledig og likevel nekte å gi deg båndbredde. Hastighetsgrenser, båndbreddetak per klient og trafikkforming brukes ofte per felles navn eller per pool, så to brukere på samme gateway kan få svært forskjellige resultater. Mekanismen er ikke subtil, men den er usynlig utenfra fordi tunnelen kommer opp normalt i begge tilfeller.

Se etter forming på tunnelgrensesnittet og ikke på det fysiske. Sjekk om grensen følger brukeren, sertifikatet eller adressepoolen. Hvis testkontoen din havner i poolen uten tak, vil du konkludere med at serveren er fin og at brukeren som klager tar feil. Den konklusjonen er verre enn ingen konklusjon, fordi den lukker saken.

Sammenlign to endepunkter med én fast oppgave

Forsøket på klientsiden er fortsatt verdt å kjøre, men bare hvis variablene er låst. Bruk samme enhet, samme aksessnett, samme protokoll og samme målfil, og gjenta deretter mot et andre endepunkt i lignende avstand. Alt som endrer seg mellom kjøringene, inkludert tiden på døgnet, forurenser resultatet.

Noter feil like nøye som suksesser. En serie der tre endepunkter virker og ett går ut på tid, er mer informativ enn fire hastighetstall, fordi den peker på et bane- eller policyproblem framfor et kapasitetsproblem. Kjør hvert tilfelle minst to ganger; én enkelt treg prøve beviser ingenting på et delt nettverk.

Til slutt: Ta vare på tallene du samlet inn sammen med påstanden de støtter. "Dette endepunktet fullførte overføringen i samme vindu som det andre stoppet opp" er forsvarlig, mens "dette endepunktet er raskere" inviterer til en diskusjon du ikke kan vinne med en skår fra en hjemmeside. OpenVPN 2.6-håndboken dokumenterer statusfilen og formingsvalgene hvis du trenger de nøyaktige direktivene for vertssiden.