OpenVPN-trafikktellere mot disk-I/O: tre forskjellige tall

Send en stor fil gjennom en tunnel, og grensesnittelleren stiger med filens størrelse. Ingenting ved det tallet betyr at samme volum nådde en disk. I disse diskusjonene sammenlignes tre forskjellige målinger, og de svarer på tre forskjellige spørsmål: hvor mye trafikk som krysset et nettverkslag, hvor mange byte en prosess leste og skrev gjennom systemkall, og hvor mye arbeid som nådde lagringslaget.

Å sammenligne den første med den tredje er den vanlige feilen, og den gir enten et spøkelsesdiskproblem eller en kapasitetsplan som ignorerer skrivingene som faktisk skjer. De tre er skillbare, og hver har en riktig bruk.

Tre tall som blir blandet sammen

Grensesnittellere beskriver trafikk som håndteres på et nettverkslag. De er det riktige tallet for båndbredde, for størrelsen på en tunnel og for faktureringsmodeller som priser transit.

Prosessens tegntellere beskriver byte flyttet gjennom lese- og skrivekall på enhver deskriptor, inkludert rør, terminaler og tegnenheter. De er det riktige tallet for å spørre hvor opptatt en prosess er ved systemkallgrensen, og de er ikke en lagringsregning.

Lagringstellere beskriver byte kjernen forsøkte å flytte til eller fra en blokkenhet. De er det riktige tallet for kapasitetsplanlegging, med forbeholdet at kjernen dokumenterer sine egne regnskapsgrenser: hurtigbufrede lesinger blir ikke lagringslesinger, og en skriving som senere avbrytes blir ikke en fullført enhetsskriving.

Hvorfor en fildeskriptor ikke er en diskskriving

En VPN i brukerrommet utveksler pakker med kjernen gjennom en TUN-enhet, som er en tegnenhet og ikke en vanlig fil. Lesing fra den overleverer en pakke; skriving til den injiserer en. Det er ingen side med filinnhold som klargjøres for lagring, og ingen filsystemsti involvert.

Derfor kan en travel tunnel vise enorme tegntellere med nesten ingen lagringstellere. Prosessen flyttet virkelig disse bytene, og kjernen trengte virkelig ikke en disk for å gjøre det.

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

Les den første utskriften som kumulativ siden prosessen startet, ikke som en rate. Den andre gir grensesnittvisningen av den samme trafikken. Et stort gap mellom de to er forventet og tyder ikke på lekkasje, kø eller feilkonfigurasjon.

Hvor bytene egentlig kommer fra

Vedvarende utdata har sitt eget budsjett, og det drives av operasjoner snarere enn av nyttelasten. Et ordrikt loggnivå, en klientliste som endres ofte, eller en feil som gjentas i en stram løkke kan generere betydelige skrivinger mens tunnelen bærer svært lite.

En statusfil er et øyeblikksbilde som skrives på nytt med et intervall, så kostnaden avhenger av intervallet og av hvor mange poster den inneholder. Den er ikke en løpende kopi av hver klients trafikk, og et kortere intervall endrer skrivevolumet uten å endre trafikkvolumet.

Eierskap betyr noe når du leter etter disse skrivingene. Hvis tjenesten overlater meldinger til en loggdaemon, skrives journalen eller loggfilen av den daemonen, og bytene dukker opp i daemonens regnskap i stedet for i VPN-prosessens egne tellere. Å se bare på VPN-prosessen forklarer verken diskaktiviteten eller fraværet av den.

Andre bidragsytere er lette å overse: lesing av sertifikater og konfigurasjon ved oppstart, kroker som skriver egne poster, regnskapsprogramtillegg, krasjdumper og urelaterte arbeidsbelastninger på samme vert. Ingen av dem bør estimeres ved å likestille tunneltrafikk med skrevne byte.

Å lese hver teller riktig

Tre detaljer avgjør om en sammenligning betyr noe. Prosessens identitet betyr noe, fordi en omstartet tjeneste nullstiller tellerne sine. Tidsintervallet betyr noe, fordi et kumulativt tall og en grafikk per sekund er forskjellige målinger. Og enheten betyr noe, fordi størrelsen på en loggfil heller ikke er en 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

Hvis du mistenker virkelige nyttelastskrivinger, se etter en komponent hvis oppgave er å lagre nyttelast: et pakkefangstverktøy, en proxy som hurtigbufrer innhold, et programtillegg som arkiverer. Disse produserer lagringstrafikk som skalerer med det de blir bedt om å registrere, og de hører til en separat policybeslutning om oppbevaring og tilgang.

Å dimensjonere kapasitet med det riktige tallet

Dimensjoner pakkestien med nettverkstall: gjennomstrømning, kryptografisk behandling og minnebevegelse. Dimensjoner lagring med de observerbarhetsvalgene du faktisk tok: loggnivå, oppbevaring, statusintervall og enhver fangst som er bevisst aktivert.

Å holde disse to budsjettene fra hverandre gjør også hendelser lettere å lese. En full disk med beskjeden tunneltrafikk peker på logger, fangster eller noe urelatert, og grensesnittelleren vil aldri forklare det. En mettet lenke med en stille logg peker den andre veien.

Sammenligningen som er verdt å gjøre, er mellom målinger av samme slag. Grensesnittbyte mot grensesnittbyte over tid forteller deg om stien. Lagringsskrivinger mot lagringskapasitet forteller deg om oppbevaring. Krysssammenligningen, trafikk mot disk, ser bare meningsfull ut og er det aldri.