VPN serverio apkrova paaiškinta: naudotojai, CPU ar įkėlimo kanalas?

Šliuzas, kurio apkrova 0.4, vis tiek gali šliaužti kiekvienam už jo esančiam naudotojui. Vidutinė apkrova skaičiuoja užduotis, kurias galima vykdyti arba kurios įstrigo nenutrūkstamame miego režime, o keturių branduolių hoste vieno prisotinto proceso pakanka, kad ji būtų stumiama link 1.0, kol trys branduoliai sėdi be darbo. Šį skaičių skaityti kaip rezervą yra dažniausia klaida renkantis galinį tašką. Tunelį iš tikrųjų riboja paprastai vienas iš keturių dalykų: vienas užimtas branduolys, įkėlimo kanalas, eilė prieš jį arba sesijos politika, kurios niekas nedokumentavo.

Vidutinė apkrova skaičiuoja užduotis, o ne pralaidumą

Branduolys ima vykdymo eilės ir įvesties-išvesties laukiančių užduočių skaičiaus pavyzdžius, tada abu išlygina per vieną, penkias ir penkiolika minučių. Nieko tame apibrėžime neužsimenama apie baitus, paketus ar tunelius. Hostas su užstrigusiu saugojimu gali pranešti didelę apkrovą beveik be srauto, o hostas, kuris stumia gigabitą branduolio duomenų keliu, gali pranešti patogią.

Todėl apkrovą sieti su tunelio našumu reikia po branduolį. Jei vienas branduolys pilnas, bendras procentas prietaisų skydelyje vis tiek atrodys gerai:

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

Trečioji komanda yra svarbiausia VPN hostuose. Paketų apdorojimas naudotojo erdvėje OpenVPN 2.x yra daugiausia serializuotas pagal procesą, todėl viena užimta gija gali tapti lubomis, kol prietaisų skydelis praneša apie gausią laisvą talpą. Jei lėtuoju laikotarpiu viena gija užima didžiąją branduolio dalį, hostas nėra nepakankamai aprūpintas apskritai; jis ribojamas toje dimensijoje, kuri atsitiktinai yra svarbi.

Atkreipkite dėmesį ir į laiką. Penkiolikos minučių vidurkiai paslepia proveržį, kuris sužlugdė skambutį, todėl ekrano nuotrauka, padaryta po skundo, yra silpnas įrodymas. Imkite pavyzdžius problemos metu ir saugokite laiko žymą kartu su išvestimi.

Įkėlimo kanalas ir eilė prieš jį

Sąsajos skaitikliai atsako į pralaidumo klausimą, į kurį CPU skaičiai negali atsakyti. Jie taip pat atskiria talpą nuo nuostolių, o tai yra skirtingi gedimai su skirtingais sprendimais:

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

Ryšys, kuris testo metu yra arti jam skirto greičio, yra paaiškinimas, ir joks laisvo CPU kiekis to nepakeis. qdisc eilutė prideda detalę, svarbią interaktyviam srautui: susikaupimas ir nuostoliai pasako, ar paketai laukia eilėje prieš išeidami. Eilė, kuri prisipildo didelio įkėlimo metu, sukuria būtent tą simptomą, kuriuo žmonės kaltina nuotolinį serverį, tai yra lėti skambučiai ryšiu, kuris bandymuose vis dar atrodo gerai.

Pakartotinio siuntimo skaitikliai pagauna atvejį, kai paketai išeina, bet niekada atvyksta švariai. Jei lėtame lange pakartotiniai siuntimai auga, o sąsaja toli gražu ne pasiekusi talpos, problema yra kelyje, o ne hoste, ir persikėlimas į kitą galinį tašką tame pačiame mieste nepadės.

Sesijų skaičiai apibūdina paklausą, o ne rezervą

Kiekvienas viešas katalogas rodo tam tikrą prisijungusių naudotojų skaičių, ir beveik nė vienas nepasako, ką tie naudotojai daro. Dvidešimt sesijų, atliekančių interaktyvų darbą, ir keturios sesijos, traukiančios didelius failus, toje pačioje techninėje įrangoje sukuria labai skirtingas apkrovas. Antrasis modelis naudotojų skaičiuje nematomas, ir būtent jis sugadina vakarą. Todėl sesijų skaičių geriausia skaityti kaip užuominą apie paklausą, niekada kaip teiginį apie laisvą talpą.

Hoste, kurį valdote, būsenos failas duoda trūkstamą dimensiją. OpenVPN rašo periodinę momentinę kopiją, kurioje yra baitų skaitikliai kiekvienam klientui, ir to pakanka pamatyti, ar viena sesija atsakinga už visą įkėlimo kanalą:

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

Du pavyzdžiai, atskirti dešimties sekundžių, tuos sukauptus skaitiklius paverčia greičiu kiekvienam klientui. Tai matavimas, kurį pakeičia naudotojų skaičius, ir taip pat taip atrandate, kad vienas neteisingai sukonfigūruotas klientas kasnakt tuo pačiu metu prisotina ryšį.

Sesijos limitai slepiasi politikoje

Serveris gali būti neaktyvus ir vis tiek atsisakyti duoti jums pralaidumą. Greičio limitai, pralaidumo lubos klientui ir srauto formavimas dažnai taikomi pagal bendrą pavadinimą arba pagal telkinį, todėl du naudotojai tame pačiame šliuze gali gauti labai skirtingus rezultatus. Mechanizmas nėra subtilus, bet iš išorės nematomas, nes tunelis abiem atvejais pakyla normaliai.

Formavimo ieškokite tunelio sąsajoje, o ne fizinėje. Patikrinkite, ar limitas seka naudotoją, sertifikatą ar adresų telkinį. Jei jūsų bandomoji paskyra patenka į telkinį be lubų, padarysite išvadą, kad serveris tvarkingas, o besiskundžiantis naudotojas klysta. Tokia išvada blogesnė už jokią, nes uždaro bilietą.

Palyginkite du galinius taškus viena fiksuota užduotimi

Kliento pusės eksperimentą vis dar verta atlikti, bet tik jei kintamieji užfiksuoti. Naudokite tą patį įrenginį, tą patį prieigos tinklą, tą patį protokolą ir tą patį paskirties failą, tada pakartokite su antru galiniu tašku panašiu atstumu. Viskas, kas pasikeičia tarp paleidimų, įskaitant paros laiką, užteršia rezultatą.

Nesėkmes užrašykite taip pat kruopščiai kaip sėkmes. Serija, kurioje trys galiniai taškai veikia, o vienas baigiasi laiko limitu, informatyvesnė už keturis greičio skaičius, nes nurodo kelio ar politikos problemą, o ne talpos. Kiekvieną atvejį paleiskite bent du kartus; vienas lėtas pavyzdys bendrame tinkle nieko neįrodo.

Galiausiai saugokite surinktus skaičius kartu su teiginiu, kurį jie pagrindžia. "Šis galinis taškas atliko perdavimą tame pačiame lange, kuriame kitas įstrigo" yra apginamas, o "šis galinis taškas greitesnis" kviečia ginčą, kurio negalite laimėti pagrindinio puslapio balu. OpenVPN 2.6 vadove dokumentuojamas būsenos failas ir formavimo parinktys, jei jums reikia tikslių nurodymų hosto pusei.