Obremenitev strežnika VPN pojasnjena: uporabniki, CPU ali navzgor usmerjena povezava?

Prehod z obremenitvijo 0.4 lahko še vedno za vsakega uporabnika za njim leze. Povprečna obremenitev šteje opravila, ki jih je mogoče izvajati ali ki so obtičala v neprekinjenem spanju, in na gostitelju s štirimi jedri zadostuje ena nasičena procesna nit, da jo potisne proti 1.0, medtem ko tri jedra sedijo brez dela. Brati to število kot rezervo je najpogostejša napaka pri izbiri končne točke. Kar dejansko omejuje tunel, je običajno ena od štirih stvari: eno zasedeno jedro, navzgor usmerjena povezava, čakalna vrsta pred njo ali politika na sejo, ki je nihče ni dokumentiral.

Povprečna obremenitev šteje opravila, ne prepustnosti

Jedro vzorči čakalno vrsto izvajanja in število opravil, ki čakajo na vhod in izhod, nato oboje zgladi v eni, petih in petnajstih minutah. Nič v tej definiciji ne omenja bajtov, paketov ali tunelov. Gostitelj z zataknjeno shrambo lahko poroča o visoki obremenitvi skoraj brez prometa, gostitelj, ki potiska gigabit skozi podatkovno pot jedra, pa lahko poroča o udobni.

Zato povezovanje obremenitve z zmogljivostjo tunela zahteva pogled po jedrih. Če je eno jedro polno, bo skupni odstotek na nadzorni plošči še vedno videti dobro:

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

Tretji ukaz je tisti, ki na gostiteljih VPN šteje največ. Obdelava paketov v uporabniškem prostoru v OpenVPN 2.x je večinoma serializirana po procesih, zato lahko ena zasedena nit postane zgornja meja, medtem ko nadzorna plošča poroča o obilici proste zmogljivosti. Če ena nit v vašem počasnem obdobju drži večino jedra, gostitelj kot celota ni premalo dimenzioniran; omejen je v dimenziji, ki se slučajno šteje.

Bodite pozorni tudi na čas. Petnajstminutna povprečja skrijejo sunek, ki je pokvaril klic, zato je posnetek zaslona, narejen po pritožbi, šibek dokaz. Vzorčite med težavo in shranite časovni žig skupaj z izhodom.

Navzgor usmerjena povezava in čakalna vrsta pred njo

Števci vmesnika odgovarjajo na vprašanje o pasovni širini, na katero številke CPU ne morejo. Ločujejo tudi zmogljivost od izgub, to pa so različne okvare z različnimi popravki:

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

Povezava, ki je med vašim testom blizu dodeljene hitrosti, je razlaga in nobena količina prostega CPU tega ne spremeni. Vrstica qdisc doda podrobnost, pomembno za interaktivni promet: zaostanek in izgube povedo, ali paketi čakajo v čakalni vrsti, preden odidejo. Čakalna vrsta, ki se napolni pod velikim nalaganjem, ustvari natanko tisti simptom, ki ga ljudje pripišejo oddaljenemu strežniku, torej počasne klice na povezavi, ki na meritvah še vedno izgleda dobro.

Števci ponovnih prenosov ujamejo primer, ko paketi odidejo, a nikoli ne prispejo čisto. Če ponovni prenosi v počasnem oknu naraščajo in vmesnik še zdaleč ni pri zmogljivosti, je težava na poti in ne na gostitelju, selitev na drugo končno točko v istem mestu pa ne bo pomagala.

Število sej opisuje povpraševanje, ne rezerve

Vsak javni imenik prikazuje neko število povezanih uporabnikov in skoraj noben ne pove, kaj ti uporabniki počnejo. Dvajset sej z interaktivnim delom in štiri seje, ki vlečejo velike datoteke, ustvarijo zelo različne obremenitve na isti strojni opremi. Drugi vzorec je v številu uporabnikov neviden in prav ta pokvari večer. Zato je število sej najbolje brati kot namig o povpraševanju, nikoli kot trditev o prosti zmogljivosti.

Na gostitelju, ki ga nadzorujete, statusna datoteka da manjkajočo dimenzijo. OpenVPN piše redne posnetke, ki vključujejo bajtne števce na odjemalca, in to zadostuje, da vidite, ali je za celotno navzgor usmerjeno povezavo odgovorna ena seja:

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

Dva vzorca deset sekund narazen te kumulativne števce spremenita v hitrost na odjemalca. To je meritev, ki jo nadomešča število uporabnikov, in tako tudi odkrijete, da en napačno nastavljen odjemalec vsako noč ob isti uri nasiči povezavo.

Omejitve na sejo se skrivajo v politiki

Strežnik je lahko nedejaven in vam vseeno odreka pasovno širino. Omejitve hitrosti, zgornje meje pasovne širine na odjemalca in oblikovanje prometa se pogosto uporabljajo po skupnem imenu ali po hrambi, zato lahko dva uporabnika na istem prehodu dobita zelo različne rezultate. Mehanizem ni pretanek, a je od zunaj neviden, ker se tunel v obeh primerih dvigne normalno.

Oblikovanje iščite na vmesniku tunela in ne na fizičnem. Preverite, ali omejitev sledi uporabniku, potrdilu ali hrambi naslovov. Če vaš testni račun pade v hrambo brez zgornje meje, boste sklenili, da je strežnik v redu in da se uporabnik, ki se pritožuje, moti. Tak sklep je slabši od nobenega, ker zapre zahtevek.

Primerjajte dve končni točki z eno stalno nalogo

Poskus na strani odjemalca se še vedno splača izvesti, a le če so spremenljivke pritrjene. Uporabite isto napravo, isto dostopovno omrežje, isti protokol in isto ciljno datoteko, nato ponovite proti drugi končni točki na podobni razdalji. Karkoli se med izvajanji spremeni, vključno z delom dneva, onesnaži rezultat.

Neuspehe zapisujte enako skrbno kot uspehe. Niz, v katerem tri končne točke delujejo, ena pa se izteče, je bolj informativen od štirih številk hitrosti, ker kaže na težavo poti ali politike in ne zmogljivosti. Vsak primer zaženite vsaj dvakrat; en sam počasen vzorec v skupnem omrežju ničesar ne dokaže.

Nazadnje, shranite zbrane številke skupaj s trditvijo, ki jo podpirajo. "Ta končna točka je prenos opravila v istem oknu, v katerem se je druga zataknila" je branljivo, medtem ko "ta končna točka je hitrejša" vabi v prepir, ki ga z oceno z domače strani ne morete dobiti. Priročnik OpenVPN 2.6 dokumentira statusno datoteko in možnosti oblikovanja, če potrebujete natančne direktive za stran gostitelja.