OpenVPN-trafikkteljarar mot disk-I/O: tre ulike tal

Send ei stor fil gjennom ein tunnel, og grensesnittteljaren stig med storleiken på fila. Ingenting ved det talet tyder at same volum nådde ein disk. I desse diskusjonane blir tre ulike målingar samanlikna, og dei svarar på tre ulike spørsmål: kor mykje trafikk som kryssa eit nettverkslag, kor mange byte ein prosess las og skreiv gjennom systemkall, og kor mykje arbeid som nådde lagringslaget.

Å samanlikne den første med den tredje er den vanlege feilen, og han gir anten eit spøkjelsesdiskproblem eller ein kapasitetsplan som ignorerer skrivingane som faktisk skjer. Dei tre er skilbare, og kvar har ein riktig bruk.

Tre tal som blir blanda saman

Grensesnittteljarar skildrar trafikk som blir handsama på eit nettverkslag. Dei er det riktige talet for bandbreidd, for storleiken på ein tunnel og for faktureringsmodellar som prisar transitt.

Tegnteljarane til prosessen skildrar byte flytta gjennom lese- og skrivekall på kva som helst deskriptor, mellom anna røyr, terminalar og teikneiningar. Dei er det riktige talet for å spørje kor oppteken ein prosess er ved systemkallgrensa, og dei er ikkje ei lagringsrekning.

Lagringsteljarar skildrar byte kjernen prøvde å flytte til eller frå ei blokkeining. Dei er det riktige talet for kapasitetsplanlegging, med atterhald om at kjernen dokumenterer sine eigne rekneskapsgrenser: hurtigbufra lesingar blir ikkje lagringslesingar, og ei skriving som seinare blir avbroten blir ikkje ei fullført eining-skriving.

Kvifor ein fildeskriptor ikkje er ei diskskriving

Ein VPN i brukarrommet byter pakkar med kjernen gjennom ei TUN-eining, som er ei teikneining og ikkje ei vanleg fil. Lesing frå henne overleverer ein pakke; skriving til henne injiserer ein. Det er inga side med filinnhald som blir gjord klar for lagring, og ingen filsystemsti er innblanda.

Derfor kan ein travel tunnel vise enorme tegnteljarar med nesten ingen lagringsteljarar. Prosessen flytta verkeleg desse byta, og kjernen trong verkeleg ikkje ein disk for å gjere det.

cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0

Les den første utskrifta som kumulativ sidan prosessen starta, ikkje som ein rate. Den andre gir grensesnittvisinga av den same trafikken. Eit stort gap mellom dei to er venta og tyder ikkje på lekkasje, kø eller feilkonfigurasjon.

Kvar byta eigentleg kjem frå

Vedvarande utdata har sitt eige budsjett, og det blir styrt av operasjonar snarare enn av nyttelasta. Eit ordrikt loggnivå, ei klientliste som endrar seg ofte, eller ein feil som blir gjenteken i ei stram løkke kan skape betydelege skrivingar medan tunnelen ber svært lite.

Ei statusfil er eit augeblinksbilete som blir skriven på nytt med eit intervall, så kostnaden heng av intervallet og av kor mange postar ho inneheld. Ho er ikkje ein løpande kopi av trafikken til kvar klient, og eit kortare intervall endrar skrivevolumet utan å endre trafikkvolumet.

Eigarskap betyr noko når du leitar etter desse skrivingane. Viss tenesta overlèt meldingar til ein loggdaemon, blir journalen eller loggfila skriven av den daemonen, og byta dukkar opp i rekneskapen til daemonen i staden for i dei eigne teljarane til VPN-prosessen. Å sjå berre på VPN-prosessen forklarer korkje diskaktiviteten eller fråveret av han.

Andre bidragsytarar er lette å oversjå: lesing av sertifikat og konfigurasjon ved oppstart, krokar som skriv eigne postar, rekneskapsprogramtillegg, krasjdumpar og urelaterte arbeidslastar på same vert. Ingen av dei bør estimerast ved å likestille tunneltrafikk med skrivne byte.

Å lese kvar teljar riktig

Tre detaljar avgjer om ei samanlikning betyr noko. Identiteten til prosessen betyr noko, fordi ei omstarta teneste nullstiller teljarane sine. Tidsintervallet betyr noko, fordi eit kumulativt tal og ein grafikk per sekund er ulike målingar. Og eininga betyr noko, fordi storleiken på ei loggfil heller ikkje er ein rate.

grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usage

Viss du mistenkjer verkelege nyttelastskrivingar, sjå etter ein komponent som har til oppgåve å lagre nyttelast: eit pakkefangstverktøy, ein proxy som hurtigbufrar innhald, eit programtillegg som arkiverer. Desse produserer lagringstrafikk som skalerer med det dei blir bedne om å registrere, og dei høyrer til eit separat policyvedtak om oppbevaring og tilgang.

Kapasitet med det riktige talet

Dimensjoner pakkestien med nettverkstal: gjennomstrøyming, kryptografisk handsaming og minneflytting. Dimensjoner lagring med dei observerbarheitsvala du faktisk tok: loggnivå, oppbevaring, statusintervall og kvar fangst som er medvite slått på.

Å halde desse to budsjetta frå kvarandre gjer òg hendingar lettare å lese. Ein full disk med beskjeden tunneltrafikk peikar på loggar, fangstar eller noko urelatert, og grensesnittteljaren vil aldri forklare det. Ei metta lenke med ein stille logg peikar den andre vegen.

Den samanlikninga som er verdt å gjere, er mellom målingar av same slag. Grensesnittbyt mot grensesnittbyt over tid fortel deg om stien. Lagringsskrivingar mot lagringskapasitet fortel deg om oppbevaring. Kryssamanlikninga, trafikk mot disk, ser berre meiningsfull ut og er det aldri.