Încărcarea unui server VPN explicată: utilizatori, CPU sau uplink?

Un gateway cu încărcare 0.4 poate totuşi trena pentru fiecare utilizator din spatele lui. Încărcarea medie numără sarcinile care pot fi rulate sau care sunt blocate într-un somn neîntreruptibil, iar pe un host cu patru nuclee un singur proces saturat ajunge pentru a o împinge spre 1.0 în timp ce trei nuclee stau degeaba. Să citeşti acel număr ca rezervă este cea mai frecventă greşeală la alegerea unui endpoint. Ce limitează de fapt un tunel este de obicei unul din patru lucruri: un nucleu ocupat, uplinkul, coada din faţa lui sau o politică pe sesiune pe care nimeni nu a documentat-o.

Încărcarea medie numără sarcini, nu debit

Kernelul eşantionează coada de execuţie şi numărul de sarcini care aşteaptă intrare şi ieşire, apoi le netezeşte pe amândouă pe parcursul a unu, cinci şi cincisprezece minute. Nimic din acea definiţie nu menţionează bytes, pachete sau tuneluri. Un host cu stocarea blocată poate raporta o încărcare mare cu aproape niciun trafic, iar un host care împinge un gigabit pe o cale de date a kernelului poate raporta una confortabilă.

Prin urmare, corelarea încărcării cu performanţa tunelului cere o vedere pe fiecare nucleu. Dacă un nucleu este ocupat complet, procentul agregat dintr-un panou va arăta în continuare bine:

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

A treia comandă este cea care contează cel mai mult pe hosturile VPN. Procesarea pachetelor în spaţiul utilizator în OpenVPN 2.x este în mare parte serializată pe proces, aşa că un singur thread ocupat poate deveni plafonul în timp ce panoul raportează capacitate liberă din belşug. Dacă un thread ţine cea mai mare parte a unui nucleu în perioada ta lentă, hostul nu este subdimensionat în ansamblu; este limitat în dimensiunea care se întâmplă să conteze.

Observă şi momentul. Mediile pe cincisprezece minute ascund izbucnirea care a stricat un apel, aşa că o captură de ecran făcută după reclamaţie este o dovadă slabă. Eşantionează în timpul problemei şi păstrează marca de timp împreună cu ieşirea.

Uplinkul şi coada din faţa lui

Contoarele interfeţei răspund la întrebarea despre lăţimea de bandă la care cifrele CPU nu pot răspunde. Ele separă şi capacitatea de pierdere, iar acestea sunt defecţiuni diferite cu remedii diferite:

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

O legătură apropiată de rata alocată în timpul testului este explicaţia, iar nicio cantitate de CPU liber nu schimbă asta. Linia qdisc adaugă detaliul care contează pentru traficul interactiv: restanţa şi pierderile îţi spun dacă pachetele aşteaptă într-o coadă înainte de a pleca. O coadă care se umple sub o încărcare mare produce exact simptomul pe care oamenii îl pun pe seama serverului îndepărtat, adică apeluri lente pe o conexiune care încă stă bine la teste.

Contoarele de retransmisie prind cazul în care pachetele pleacă dar nu ajung niciodată curat. Dacă retransmisiile cresc în fereastra lentă şi interfaţa este departe de capacitate, problema este pe cale, nu pe host, iar mutarea pe alt endpoint din acelaşi oraş nu va ajuta.

Numărul de sesiuni descrie cererea, nu rezerva

Fiecare director public afişează un anumit număr de utilizatori conectaţi, şi aproape niciunul nu îţi spune ce fac acei utilizatori. Douăzeci de sesiuni cu muncă interactivă şi patru sesiuni care trag fişiere mari produc încărcări foarte diferite pe acelaşi hardware. Al doilea model este invizibil într-un număr de utilizatori, şi el este cel care strică o seară. Aşa că un număr de sesiuni se citeşte cel mai bine ca indiciu despre cerere, niciodată ca afirmaţie despre capacitatea liberă.

Pe un host pe care îl controlezi, fişierul de stare oferă dimensiunea lipsă. OpenVPN scrie instantanee periodice care includ contoare de bytes pe client, şi asta ajunge pentru a vedea dacă o singură sesiune este responsabilă pentru întregul uplink:

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

Două eşantioane la zece secunde distanţă transformă acele contoare cumulative într-o rată pe client. Aceasta este măsurătoarea pe care o înlocuieşte un număr de utilizatori, şi tot aşa descoperi că un singur client configurat greşit satură legătura în fiecare noapte la aceeaşi oră.

Limitele pe sesiune se ascund în politică

Un server poate fi inactiv şi totuşi să îţi refuze lăţimea de bandă. Limitele de rată, plafoanele de lăţime de bandă pe client şi modelarea traficului se aplică adesea pe nume comun sau pe pool, aşa că doi utilizatori pe acelaşi gateway pot obţine rezultate foarte diferite. Mecanismul nu este subtil, dar este invizibil din exterior pentru că tunelul se ridică normal în ambele cazuri.

Caută modelarea pe interfaţa tunelului, nu pe cea fizică. Verifică dacă limita urmează utilizatorul, certificatul sau poolul de adrese. Dacă contul tău de test ajunge în poolul fără plafon, vei concluziona că serverul este în regulă şi că utilizatorul care se plânge greşeşte. Acea concluzie este mai rea decât nicio concluzie, pentru că închide tichetul.

Compară două endpointuri cu o singură sarcină fixă

Experimentul din partea clientului merită încă făcut, dar numai dacă variabilele sunt fixate. Foloseşte acelaşi dispozitiv, aceeaşi reţea de acces, acelaşi protocol şi acelaşi fişier destinaţie, apoi repetă împotriva unui al doilea endpoint la o distanţă similară. Orice se schimbă între execuţii, inclusiv ora din zi, contaminează rezultatul.

Notează eşecurile la fel de atent ca reuşitele. O serie în care trei endpointuri funcţionează şi unul expiră este mai informativă decât patru cifre de viteză, pentru că indică o problemă de cale sau de politică, nu de capacitate. Rulează fiecare caz cel puţin de două ori; un singur eşantion lent nu dovedeşte nimic într-o reţea partajată.

În cele din urmă, păstrează cifrele strânse împreună cu afirmaţia pe care o susţin. "Acest endpoint a dus transferul în aceeaşi fereastră în care celălalt s-a blocat" este de apărat, în timp ce "acest endpoint este mai rapid" invită la o dispută pe care nu o poţi câştiga cu un scor de pagina principală. Manualul OpenVPN 2.6 documentează fişierul de stare şi opţiunile de modelare dacă ai nevoie de directivele exacte pentru partea de host.