Opterećenje VPN poslužitelja objašnjeno: korisnici, CPU ili uplink?

Prolaz s opterećenjem 0.4 još uvijek može puzati za svakog korisnika iza sebe. Prosječno opterećenje broji zadatke koji se mogu izvršavati ili zapeli u neprekinutom snu, a na hostu s četiri jezgre dovoljan je jedan zasićeni proces da ga gurne prema 1.0 dok tri jezgre sjede besposlene. Čitati taj broj kao rezervu najčešća je pogreška pri odabiru krajnje točke. Ono što zapravo ograničava tunel obično je jedna od četiri stvari: jedna zauzeta jezgra, uplink, red ispred njega ili pravilo po sesiji koje nitko nije dokumentirao.

Prosječno opterećenje broji zadatke, ne propusnost

Jezgra uzorkuje red izvršavanja i broj zadataka koji čekaju ulaz i izlaz, a zatim oboje izglađuje kroz jednu, pet i petnaest minuta. Ništa u toj definiciji ne spominje bajtove, pakete ni tunele. Host sa zaglavljenom pohranom može prijaviti visoko opterećenje gotovo bez prometa, a host koji gura gigabit kroz jezgrin podatkovni put može prijaviti ugodno.

Stoga povezivanje opterećenja s radom tunela zahtijeva pogled po jezgri. Ako je jedna jezgra zakovana, ukupni postotak na nadzornoj ploči i dalje će izgledati dobro:

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

Treća je naredba ona koja najviše vrijedi na VPN hostovima. Obrada paketa u korisničkom prostoru u OpenVPN 2.x u velikoj je mjeri serijalizirana po procesu, pa jedno zauzeto vlakno može postati strop dok nadzorna ploča izvještava o obilju slobodnog kapaciteta. Ako jedno vlakno drži veći dio jezgre tijekom vašeg sporog razdoblja, host nije ukupno nedovoljno dimenzioniran; ograničen je u dimenziji koja se slučajno računa.

Obratite pozornost i na vrijeme. Petnaestominutni prosjeci skrivaju nalet koji je uništio poziv, pa je snimka zaslona nastala nakon pritužbe slab dokaz. Uzimajte uzorke tijekom problema i čuvajte vremensku oznaku uz izlaz.

Uplink i red ispred njega

Brojači sučelja odgovaraju na pitanje o propusnosti na koje brojke CPU-a ne mogu. Oni također odvajaju kapacitet od gubitka, a to su različite greške s različitim rješenjima:

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

Veza koja je tijekom vašeg testa blizu dodijeljene brzine jest objašnjenje i nikakva količina slobodnog CPU-a to ne mijenja. Redak qdisc dodaje pojedinost važnu za interaktivni promet: zaostatak i odbacivanja govore vam čekaju li paketi u redu prije odlaska. Red koji se puni pod velikim prijenosom stvara točno onaj simptom koji ljudi pripisuju udaljenom poslužitelju, dosadne pozive na vezi koja još dobro prolazi na mjerenjima.

Brojači ponovnog prijenosa hvataju slučaj u kojem paketi odlaze, ali nikad ne stižu čisto. Ako ponovni prijenosi rastu u sporom prozoru, a sučelje ni blizu kapaciteta, problem je u putu, a ne na hostu, i prelazak na drugu krajnju točku u istom gradu neće pomoći.

Brojevi sesija opisuju potražnju, ne rezervu

Svaki javni imenik prikazuje neki broj povezanih korisnika i gotovo nijedan vam ne kaže što ti korisnici rade. Dvadeset sesija s interaktivnim radom i četiri sesije koje vuku velike datoteke stvaraju vrlo različita opterećenja na istom hardveru. Drugi je uzorak nevidljiv u broju korisnika i upravo on kvari večer. Zato broj sesija najbolje čitati kao nagovještaj potražnje, nikad kao tvrdnju o slobodnom kapacitetu.

Na hostu koji kontrolirate, datoteka stanja daje dimenziju koja nedostaje. OpenVPN zapisuje povremenu snimku koja uključuje brojače bajtova po klijentu, a to je dovoljno da vidite je li jedna sesija odgovorna za cijeli uplink:

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

Dva uzorka udaljena deset sekundi pretvaraju te kumulativne brojače u brzinu po klijentu. To je mjerenje koje broj korisnika zamjenjuje i tako otkrivate da jedan pogrešno konfiguriran klijent svake noći u isti sat zasićuje vezu.

Ograničenja po sesiji skrivaju se u pravilima

Poslužitelj može biti besposlen i ipak vam odbiti dati propusnost. Ograničenja brzine, gornje granice propusnosti po klijentu i oblikovanje prometa često se primjenjuju po zajedničkom nazivu ili po skupu, pa dva korisnika na istom prolazu mogu dobiti vrlo različite rezultate. Mehanizam nije suptilan, ali je izvana nevidljiv jer se tunel u oba slučaja normalno podiže.

Tražite oblikovanje na sučelju tunela, a ne na fizičkom. Provjerite slijedi li ograničenje korisnika, certifikat ili skup adresa. Ako vaš testni račun završi u skupu bez ograničenja, zaključit ćete da je poslužitelj u redu i da korisnik koji se žali griješi. Takav je zaključak gori od nikakvog jer zatvara zahtjev.

Usporedite dvije krajnje točke jednim stalnim zadatkom

Eksperiment na strani klijenta još je vrijedan izvođenja, ali samo ako su varijable prikovane. Koristite isti uređaj, istu pristupnu mrežu, isti protokol i istu odredišnu datoteku, pa ponovite prema drugoj krajnjoj točki na sličnoj udaljenosti. Sve što se između pokretanja promijeni, uključujući doba dana, zagađuje rezultat.

Bilježite neuspjehe jednako pažljivo kao uspjehe. Niz u kojem tri krajnje točke rade, a jedna istekne, informativniji je od četiri brojke brzine jer upućuje na problem puta ili pravila, a ne kapaciteta. Pokrenite svaki slučaj barem dvaput; jedan spor uzorak ne dokazuje ništa na dijeljenoj mreži.

Naposljetku, čuvajte brojke koje ste prikupili uz tvrdnju koju podupiru. "Ova je krajnja točka obavila prijenos u istom prozoru u kojem se druga zaglavila" obranjivo je, dok "ova je krajnja točka brža" poziva na raspravu koju ne možete dobiti ocjenom s početne stranice. Priručnik OpenVPN 2.6 dokumentira datoteku stanja i mogućnosti oblikovanja ako trebate točne direktive za stranu hosta.