OpenVPN-trafikräknare kontra disk-I/O: tre olika tal

Skicka en stor fil genom en tunnel och gränssnittsräknaren stiger med filens storlek. Inget i det talet betyder att samma volym nådde en disk. I dessa diskussioner jämförs tre olika mätningar, och de svarar på tre olika frågor: hur mycket trafik som korsade ett nätverkslager, hur många byte en process läste och skrev genom systemanrop, och hur mycket arbete som nådde lagringslagret.

Att jämföra den första med den tredje är det vanliga misstaget, och det ger antingen ett spökdiskproblem eller en kapacitetsplan som ignorerar de skrivningar som faktiskt sker. De tre är separerbara, och var och en har en korrekt användning.

Tre tal som blandas ihop

Gränssnittsräknare beskriver trafik som hanteras på ett nätverkslager. De är rätt tal för bandbredd, för storleken på en tunnel och för faktureringsmodeller som prissätter transit.

En process teckenräknare beskriver byte som flyttats genom läs- och skrivanrop på vilken deskriptor som helst, inklusive rör, terminaler och teckenenheter. De är rätt tal för att fråga hur upptagen en process är vid systemanropsgränsen, och de är inte en lagringsräkning.

Lagringsräknare beskriver byte som kärnan försökte flytta till eller från en blockenhet. De är rätt tal för kapacitetsplanering, med förbehållet att kärnan dokumenterar sina egna redovisningsgränser: cachade läsningar blir inte lagringsläsningar, och en skrivning som senare avbryts blir inte en slutförd enhetsskrivning.

Varför en fildeskriptor inte är en diskskrivning

En VPN i användarutrymmet utbyter paket med kärnan genom en TUN-enhet, som är en teckenenhet och inte en vanlig fil. Läsning från den överlämnar ett paket; skrivning till den injicerar ett. Det finns ingen sida med filinnehåll som förbereds för lagring, och ingen filsökväg inblandad.

Därför kan en upptagen tunnel visa enorma teckenräknare med nästan inga lagringsräknare. Processen flyttade verkligen dessa byte, och kärnan behövde verkligen ingen disk för att göra det.

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

Läs den första utskriften som kumulativ sedan processen startade, inte som en hastighet. Den andra ger gränssnittsvyn av samma trafik. En stor lucka mellan de två är väntad och tyder inte på läckage, kö eller felkonfiguration.

Varifrån byten verkligen kommer

Beständig utskrift har sin egen budget, och den drivs av operationer snarare än av nyttolasten. En ordrik loggnivå, en klientlista som ändras ofta eller ett fel som upprepas i en tight loop kan generera betydande skrivningar medan tunneln bär mycket lite.

En statusfil är en ögonblicksbild som skrivs om med ett intervall, så kostnaden beror på intervallet och på hur många poster den innehåller. Den är inte en löpande kopia av varje klients trafik, och ett kortare intervall ändrar skrivvolymen utan att ändra trafikvolymen.

Ägandeskap spelar roll när du letar efter dessa skrivningar. Om tjänsten lämnar meddelanden till en loggdaemon skrivs journalen eller loggfilen av den daemonen, och byten dyker upp i daemonens redovisning i stället för i VPN-processens egna räknare. Att bara titta på VPN-processen förklarar varken diskaktiviteten eller frånvaron av den.

Andra bidragsgivare är lätta att förbise: läsning av certifikat och konfiguration vid start, krokar som skriver egna poster, redovisningsinsticksprogram, kraschdumpar och orelaterade arbetsbelastningar på samma värd. Ingen av dem bör uppskattas genom att likställa tunneltrafik med skrivna byte.

Att läsa varje räknare korrekt

Tre detaljer avgör om en jämförelse betyder något. Processens identitet spelar roll, eftersom en omstartad tjänst nollställer sina räknare. Tidsintervallet spelar roll, eftersom en kumulativ siffra och ett diagram per sekund är olika mätningar. Och enheten spelar roll, eftersom storleken på en loggfil inte heller är en hastighet.

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

Om du misstänker verkliga nyttolastskrivningar, leta efter en komponent vars uppgift är att lagra nyttolast: ett paketfångstverktyg, en proxy som cachar innehåll, ett insticksprogram som arkiverar. Dessa producerar lagringstrafik som skalar med det de ombeds registrera, och de hör till ett separat policybeslut om bevarande och åtkomst.

Dimensionera kapacitet med rätt tal

Dimensionera paketvägen med nätverkstal: genomströmning, kryptografisk bearbetning och minnesrörelse. Dimensionera lagring med de observerbarhetsval du faktiskt gjorde: loggnivå, bevarande, statusintervall och varje fångst som medvetet aktiverats.

Att hålla dessa två budgetar åtskilda gör också incidenter lättare att läsa. En full disk med blygsam tunneltrafik pekar på loggar, fångster eller något orelaterat, och gränssnittsräknaren kommer aldrig att förklara det. En mättad länk med en tyst logg pekar åt andra hållet.

Den jämförelse som är värd att göra är mellan mätningar av samma slag. Gränssnittsbyte mot gränssnittsbyte över tid berättar om vägen. Lagringsskrivningar mot lagringskapacitet berättar om bevarande. Korsjämförelsen, trafik mot disk, ser bara meningsfull ut och är det aldrig.