Belasting van een VPN-server uitgelegd: gebruikers, CPU of uplink?

Een gateway met een belasting van 0.4 kan voor elke gebruiker erachter nog steeds kruipen. De gemiddelde belasting telt taken die uitvoerbaar zijn of vastzitten in ononderbroken slaap, en op een host met vier cores is één verzadigd proces genoeg om het richting 1.0 te duwen terwijl drie cores nietsdoen. Dat getal als reserve lezen is de meest voorkomende fout bij het kiezen van een eindpunt. Wat een tunnel werkelijk beperkt, is meestal een van vier dingen: één bezette core, de uplink, de wachtrij ervoor of een beleid per sessie dat niemand heeft gedocumenteerd.

De gemiddelde belasting telt taken, geen doorvoer

De kernel bemonstert de uitvoeringswachtrij en het aantal taken dat op invoer en uitvoer wacht, en vlakt beide vervolgens af over één, vijf en vijftien minuten. Niets in die definitie noemt bytes, pakketten of tunnels. Een host met vastgelopen opslag kan een hoge belasting melden met bijna geen verkeer, en een host die een gigabit door een kernel-datapad duwt kan een comfortabele melden.

Belasting correleren met tunnelprestaties vereist dus een blik per core. Als één core vol zit, ziet het totale percentage op een dashboard er nog steeds goed uit:

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

Het derde commando is degene die op VPN-hosts het meest telt. Pakketverwerking in gebruikersruimte in OpenVPN 2.x is grotendeels geserialiseerd per proces, dus één drukke thread kan het plafond worden terwijl het dashboard overvloedige vrije capaciteit meldt. Als één thread tijdens je trage periode het grootste deel van een core vasthoudt, is de host als geheel niet onderbemand; hij is beperkt in de dimensie die toevallig telt.

Let ook op de timing. Gemiddelden over vijftien minuten verbergen de uitbarsting die een gesprek verpestte, dus een schermafbeelding die na de klacht is gemaakt, is zwak bewijs. Neem monsters tijdens het probleem en bewaar de tijdstempel bij de uitvoer.

De uplink en de wachtrij ervoor

Interfacetellers beantwoorden de bandbreedtevraag die CPU-cijfers niet kunnen. Ze scheiden ook capaciteit van verlies, en dat zijn verschillende storingen met verschillende oplossingen:

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

Een link die tijdens je test dicht bij zijn toegewezen snelheid zit, is de verklaring, en geen enkele hoeveelheid vrije CPU verandert dat. De qdisc-regel voegt het detail toe dat voor interactief verkeer telt: achterstand en drops vertellen of pakketten in een wachtrij wachten voordat ze vertrekken. Een wachtrij die volloopt onder een grote upload veroorzaakt precies het symptoom dat mensen de externe server verwijten, namelijk trage gesprekken op een verbinding die in benchmarks nog goed scoort.

Hertransmissietellers vangen het geval waarin pakketten vertrekken maar nooit schoon aankomen. Als hertransmissies in het trage venster stijgen en de interface ver van zijn capaciteit is, zit het probleem in het pad en niet op de host, en overstappen naar een ander eindpunt in dezelfde stad helpt niet.

Sessieaantallen beschrijven vraag, geen reserve

Elke openbare gids toont een of ander aantal verbonden gebruikers, en bijna geen enkele vertelt je wat die gebruikers doen. Twintig sessies met interactief werk en vier sessies die grote bestanden trekken, veroorzaken heel verschillende belastingen op dezelfde hardware. Het tweede patroon is onzichtbaar in een gebruikersaantal, en juist dat verpest een avond. Een sessieaantal lees je dus het beste als een hint over de vraag, nooit als een uitspraak over vrije capaciteit.

Op een host die je beheert, geeft het statusbestand de ontbrekende dimensie. OpenVPN schrijft een periodieke momentopname met bytetellers per client, en dat is genoeg om te zien of één sessie verantwoordelijk is voor de hele uplink:

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

Twee monsters tien seconden uit elkaar maken van die cumulatieve tellers een snelheid per client. Dat is de meting waarvoor een gebruikersaantal in de plaats staat, en zo ontdek je ook dat één verkeerd geconfigureerde client elke nacht op hetzelfde uur de link verzadigt.

Limieten per sessie schuilen in het beleid

Een server kan inactief zijn en je toch bandbreedte weigeren. Snelheidslimieten, bandbreedteplafonds per client en traffic shaping worden vaak per common name of per pool toegepast, dus twee gebruikers op dezelfde gateway kunnen heel verschillende resultaten krijgen. Het mechanisme is niet subtiel, maar het is van buitenaf onzichtbaar omdat de tunnel in beide gevallen normaal opkomt.

Zoek shaping op de tunnelinterface en niet op de fysieke. Controleer of de limiet de gebruiker, het certificaat of de adrespool volgt. Als je testaccount in de pool zonder plafond terechtkomt, concludeer je dat de server in orde is en dat de klagende gebruiker ongelijk heeft. Die conclusie is erger dan geen conclusie, want ze sluit het ticket.

Vergelijk twee eindpunten met één vaste taak

Het experiment aan de clientkant is nog steeds de moeite waard, maar alleen als de variabelen vastliggen. Gebruik hetzelfde apparaat, hetzelfde toegangsnetwerk, hetzelfde protocol en hetzelfde doelbestand, en herhaal het dan tegen een tweede eindpunt op vergelijkbare afstand. Alles wat tussen runs verandert, inclusief het tijdstip van de dag, verontreinigt het resultaat.

Leg fouten even zorgvuldig vast als successen. Een reeks waarin drie eindpunten werken en één in een timeout loopt, is informatiever dan vier snelheidscijfers, omdat ze wijst op een pad- of beleidsprobleem en niet op een capaciteitsprobleem. Voer elk geval minstens twee keer uit; één langzaam monster bewijst niets op een gedeeld netwerk.

Bewaar ten slotte de cijfers die je hebt verzameld samen met de bewering die ze ondersteunen. "Dit eindpunt rondde de overdracht af in hetzelfde venster waarin het andere vastliep" is verdedigbaar, terwijl "dit eindpunt is sneller" uitnodigt tot een discussie die je niet kunt winnen met een score van een startpagina. De OpenVPN 2.6-handleiding documenteert het statusbestand en de shaping-opties als je de exacte richtlijnen voor de hostkant nodig hebt.