VPN-bedienerlading verduidelik: gebruikers, CPU of oplyn?

’n Poort wat op 0.4 lading staan, kan steeds vir elke gebruiker agter hom kruip. Gemiddelde lading tel take wat hardloopbaar is of in ononderbroke slaap vasgevang sit, en op ’n gasheer met vier kerns is een versadigde proses genoeg om dit na 1.0 te stoot terwyl drie kerns ledig sit. Om daardie syfer as oorskotkapasiteit te lees, is die algemeenste fout by die keuse van ’n eindpunt. Wat ’n tonnel werklik beperk, is gewoonlik een van vier dinge: een besige kern, die oplyn, die tou voor dit, of ’n per-sessie-beleid wat niemand gedokumenteer het nie.

Gemiddelde lading tel take, nie deurloop nie

Die kern neem monsters van die loopry en die aantal take wat op I/O wag, en glad dan albei oor een, vyf en vyftien minute. Niks in daardie definisie noem grepe, pakkette of tonnels nie. ’n Gasheer wie se berging vasgekeer is, kan ’n hoë lading rapporteer met byna geen verkeer nie, en ’n gasheer wat ’n gigabit deur ’n kern-datapad stoot, kan ’n gemaklike een rapporteer.

Om lading met tonnelwerkverrigting te korreleer, verg dus ’n siening per kern. As een kern vasgepen is, sal die saamgestelde persentasie op ’n paneelbord steeds goed lyk:

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

Die derde opdrag is die een wat die meeste op VPN-gashere saak maak. Gebruikerruimte-pakketverwerking in OpenVPN 2.x is grootliks per proses geserialiseer, so ’n enkele besige draad kan die plafon word terwyl die paneelbord oorvloedige ledige kapasiteit rapporteer. As een draad die grootste deel van ’n kern tydens jou stadige tydperk beset, is die gasheer nie in die geheel ondervoorsien nie; dit word beperk in die dimensie wat toevallig saak maak.

Let ook op die tydsberekening. Vyftienminuutgemiddeldes verberg die uitbarsting wat ’n oproep verwoes het, so ’n skermskoot wat ná die klag geneem is, is swak bewyse. Neem monsters tydens die probleem, en hou die tydstempel by die uitset.

Die oplyn en die tou voor dit

Koppelvlaktellings beantwoord die bandwydtevraag wat syfers vir die verwerkingseenheid nie kan nie. Hulle skei ook kapasiteit van verlies, wat verskillende foute met verskillende regstellings is:

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

’n Skakel wat tydens jou toets naby sy toegewysde tempo is, is die verklaring, en geen hoeveelheid spaar verwerkingsvermoë verander dit nie. Die qdisc-reël voeg die besonderheid by wat vir interaktiewe verkeer saak maak: agterstand en wegvalle vertel jou of pakkette in ’n tou wag voordat hulle vertrek. ’n Tou wat onder ’n groot oplaai vol raak, lewer presies die simptoom wat mense aan die afgeleë bediener wyte, naamlik trae oproepe op ’n verbinding wat steeds goed presteer in maatstawwe.

Hertoesendingstellers vang die geval waar pakkette vertrek maar nooit skoon aankom nie. As hertoesendings in die stadige venster klim en die koppelvlak nêrens naby kapasiteit is nie, woon die probleem in die pad eerder as op die gasheer, en om na ’n ander eindpunt in dieselfde stad te skuif sal nie help nie.

Sessietellings beskryf vraag, nie oorskot nie

Elke publieke gids wys een of ander aantal gekoppelde gebruikers, en byna nie een van hulle vertel jou wat daardie gebruikers doen nie. Twintig sessies wat interaktiewe werk doen en vier sessies wat groot lêers aftrek, lewer baie verskillende ladings op dieselfde hardeware. Die tweede patroon is onsigbaar in ’n gebruikerstelling, en dit is die een wat ’n aand verwoes. Dus word ’n sessiesyfer die beste gelees as ’n aanduiding van vraag, nooit as ’n stelling oor spaar kapasiteit nie.

Op ’n gasheer wat jy beheer, gee die statuslêer die ontbrekende dimensie. OpenVPN skryf ’n periodieke momentopname wat per-kliënt grepetellers insluit, wat genoeg is om te sien of een sessie vir die hele oplyn verantwoordelik is:

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

Twee monsters tien sekondes uitmekaar verander daardie kumulatiewe tellings in ’n tempo per kliënt. Dit is die meting waarvoor ’n gebruikerstelling instaan, en dit is ook hoe jy ontdek dat ’n enkele verkeerd opgestelde kliënt elke aand op dieselfde uur die skakel versadig.

Per-sessie-limiete skuil in beleid

’n Bediener kan ledig wees en steeds weier om jou bandwydte te gee. Tempolimiete, bandwydteplafonne per kliënt en verkeersvorming word dikwels per gemeenskaplike naam of per poel toegepas, so twee gebruikers op dieselfde poort kan heeltemal verskillende resultate kry. Die meganisme is nie subtiel nie, maar dit is van buite onsigbaar omdat die tonnel in albei gevalle normaal opkom.

Soek na vorming op die tonnelkoppelvlak eerder as op die fisiese een. Kyk of die limiet die gebruiker, die sertifikaat of die adrespoel volg. As jou toetsrekening in die onbegrensde poel beland, sal jy aflei dat die bediener reg is en die klaende gebruiker verkeerd. Daardie afleiding is erger as geen afleiding nie, want dit sluit die kaartjie.

Vergelyk twee eindpunte met een vaste taak

Die kliëntkant-eksperiment is steeds die moeite werd om te doen, maar net as die veranderlikes vasgepen is. Gebruik dieselfde toestel, dieselfde toegangsnetwerk, dieselfde protokol en dieselfde bestemminglêer, en herhaal dan teen ’n tweede eindpunt op ’n soortgelyke afstand. Enigiets wat tussen lopies verander, insluitend die tyd van die dag, besmet die resultaat.

Teken mislukkings net so noukeurig aan as suksesse. ’n Reeks waar drie eindpunte werk en een keer uit, is meer insiggewend as vier spoedsyfers, want dit wys op ’n pad- of beleidsprobleem eerder as ’n kapasiteitsprobleem. Hardloop elke geval minstens twee keer; ’n enkele stadige monster bewys niks op ’n gedeelde netwerk nie.

Laastens, hou die syfers wat jy versamel het by die bewering wat hulle ondersteun. "Hierdie eindpunt het die oordrag in dieselfde venster hanteer waarin die ander een vasgehaak het" is verdedigbaar, terwyl "hierdie eindpunt is vinniger" ’n argument uitlok wat jy nie met ’n tuisbladpunt kan wen nie. Die OpenVPN 2.6-handleiding dokumenteer die statuslêer en die vormingsopsies as jy die presiese opdragte vir die gasheerkant nodig het.