OpenVPN-verkeerstellers versus schijf-I/O: drie verschillende getallen

Stuur een groot bestand door een tunnel en de interfaceteller stijgt met de bestandsgrootte. Niets aan dat getal betekent dat hetzelfde volume een schijf bereikte. In deze discussies worden drie verschillende metingen vergeleken, en ze beantwoorden drie verschillende vragen: hoeveel verkeer een netwerklaag passeerde, hoeveel bytes een proces via systeemaanroepen las en schreef, en hoeveel werk de opslaglaag bereikte.

De eerste met de derde vergelijken is de gebruikelijke fout, en die levert ofwel een spookschijfprobleem op ofwel een capaciteitsplan dat de schrijfacties negeert die echt plaatsvinden. De drie zijn scheidbaar, en elk heeft een correct gebruik.

Drie getallen die door elkaar worden gehaald

Interfacetellers beschrijven verkeer dat op een netwerklaag wordt afgehandeld. Ze zijn het juiste getal voor bandbreedte, voor de grootte van een tunnel en voor factureringsmodellen die transit prijzen.

Tekentellers van een proces beschrijven bytes die via lees- en schrijfaarroepen op welke descriptor dan ook zijn verplaatst, inclusief pijpen, terminals en tekenapparaten. Ze zijn het juiste getal om te vragen hoe druk een proces is op de grens van de systeemaanroep, en het zijn geen opslagrekening.

Opslagtellers beschrijven bytes die de kernel probeerde te verplaatsen naar of van een blokapparaat. Ze zijn het juiste getal voor capaciteitsplanning, met het voorbehoud dat de kernel zijn eigen boekhoudgrenzen documenteert: gecachte leesacties worden geen opslagleesacties, en een schrijfactie die later wordt geannuleerd wordt geen voltooide apparaatschrijfactie.

Waarom een bestandsdescriptor geen schijfschrijfactie is

Een VPN in gebruikersruimte wisselt pakketten uit met de kernel via een TUN-apparaat, dat een tekenapparaat is en geen gewoon bestand. Lezen daaruit levert een pakket af; schrijven daarin injecteert er een. Er is geen pagina met bestandsinhoud die voor opslag klaargezet wordt, en er is geen bestandssysteempad bij betrokken.

Daarom kan een drukke tunnel enorme tekentellers tonen met bijna geen opslagtellers. Het proces heeft die bytes echt verplaatst, en de kernel had daar echt geen schijf voor nodig.

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

Lees de eerste uitvoer als cumulatief sinds de start van het proces, niet als een tempo. De tweede geeft de interfaceweergave van hetzelfde verkeer. Een grote kloof tussen beide is te verwachten en duidt niet op een lek, een wachtrij of een verkeerde configuratie.

Waar de bytes echt vandaan komen

Doorlopende uitvoer heeft zijn eigen budget, en dat wordt gestuurd door bewerkingen in plaats van door de payload. Een uitgebreid logniveau, een cliëntenlijst die vaak verandert, of een fout die in een strakke lus terugkomt kan aanzienlijke schrijfacties opleveren terwijl de tunnel heel weinig vervoert.

Een statusbestand is een momentopname die met een interval opnieuw wordt geschreven, dus de kosten hangen af van het interval en van het aantal records erin. Het is geen lopende kopie van het verkeer van elke cliënt, en een korter interval verandert het schrijfvolume zonder het verkeersvolume te veranderen.

Eigendom is belangrijk wanneer u die schrijfacties zoekt. Als de dienst berichten aan een logdaemon overdraagt, wordt het journaal of het logbestand door die daemon geschreven, en de bytes verschijnen in de boekhouding van de daemon in plaats van in de eigen tellers van het VPN-proces. Alleen naar het VPN-proces kijken verklaart noch de schijfactiviteit noch het ontbreken ervan.

Andere bijdragers zijn makkelijk over het hoofd te zien: het lezen van certificaten en configuratie bij het opstarten, hooks die hun eigen records schrijven, boekhoudplugins, crashdumps en ongerelateerde werklasten op dezelfde host. Geen ervan zou moeten worden geschat door tunnelverkeer gelijk te stellen aan geschreven bytes.

Elke teller correct lezen

Drie details bepalen of een vergelijking iets betekent. De identiteit van het proces is belangrijk, omdat een herstarte dienst zijn tellers reset. Het tijdsinterval is belangrijk, omdat een cumulatief cijfer en een grafiek per seconde verschillende metingen zijn. En de eenheid is belangrijk, omdat de huidige grootte van een logbestand ook geen tempo is.

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

Als u echte payloadschrijfacties vermoedt, zoek dan een component wiens taak het is payload op te slaan: een pakketopnametool, een proxy die bodies cachet, een plugin die archiveert. Die produceren opslagverkeer dat meeschaalt met wat ervan gevraagd wordt vast te leggen, en ze horen bij een aparte beleidsbeslissing over bewaring en toegang.

Capaciteit dimensioneren met het juiste getal

Dimensioneer het pakketpad met netwerkcijfers: doorvoer, cryptografische verwerking en geheugenbeweging. Dimensioneer opslag met de observeerbaarheidskeuzes die u werkelijk hebt gemaakt: logniveau, bewaring, statusinterval en elke opname die bewust is ingeschakeld.

Die twee budgetten gescheiden houden maakt incidenten ook makkelijker leesbaar. Een volle schijf bij bescheiden tunnelverkeer wijst op logs, opnames of iets ongerelateerds, en de interfaceteller zal het nooit verklaren. Een verzadigde link met een stil log wijst de andere kant op.

De vergelijking die de moeite waard is, is tussen metingen van dezelfde soort. Interfacebytes tegen interfacebytes in de tijd vertellen u over het pad. Opslagschrijfacties tegen opslagcapaciteit vertellen u over bewaring. De kruisvergelijking, verkeer tegen schijf, lijkt alleen betekenisvol en is het nooit.