OpenVPN-verkeerstellers teenoor skyf-IO: drie verskillende getalle

Dra ’n groot lêer deur ’n tonnel en die koppelvlakteller styg met die grootte van die lêer. Niks aan daardie getal sê dat dieselfde volume ’n skyf bereik het nie. In hierdie gesprekke word drie verskillende metings vergelyk, en hulle beantwoord drie verskillende vrae: hoeveel verkeer ’n netwerklaag oorgesteek het, hoeveel grepe ’n proses deur stelseloproepe gelees en geskryf het, en hoeveel werk die stoormedium bereik het.

Om die eerste met die derde te vergelyk is die gewone fout, en dit lewer óf ’n spookskyfprobleem óf ’n kapasiteitsplan wat die skrywes wat regtig gebeur, ignoreer. Die drie is skeibaar, en elkeen het ’n korrekte gebruik.

Drie getalle wat verwar word

Koppelvlaktellers beskryf verkeer wat op ’n netwerklaag hanteer word. Hulle is die regte getal vir bandwydte, vir die grootte van ’n tonnel en vir faktureringsmodelle wat deurvoer prys.

Prosese se karaktertellers beskryf grepe wat deur lees- en skryfoproepe op enige deskriptor beweeg is, insluitend pype, terminale en karaktertoestelle. Hulle is die regte getal om te vra hoe besig ’n proses by die stelseloproepgrens is, en hulle is nie ’n stoerrekening nie.

Stoortellers beskryf grepe wat die kern probeer het om na of van ’n bloktoestel te skuif. Hulle is die regte getal vir kapasiteitsbeplanning, met die voorbehoud dat die kern sy eie rekeningkundige grense dokumenteer: gekasde lees word nie stoormeting nie, en ’n skrywe wat later gekanselleer word, word nie ’n voltooide toestelskrywe nie.

Waarom ’n lêerdeskriptor nie ’n skyfskrywe is nie

’n Gebruikersruimte-VPN ruil pakkette met die kern uit deur ’n TUN-toestel, wat ’n karaktertoestel eerder as ’n gewone lêer is. Lees daaruit oorhandig ’n pakket; skryf daarin spuit een in. Daar is geen bladsy lêerinhoud wat vir storing gereedgemaak word nie, en geen lêerstelselpad betrokke nie.

Daarom kan ’n besige tonnel enorme karaktertellers wys met byna geen stoortellers nie. Die proses het daardie grepe werklik geskuif, en die kern het werklik nie ’n skyf nodig gehad om dit te doen nie.

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

Lees die eerste uitvoer as kumulatief sedert die proses begin het, nie as ’n tempo nie. Die tweede gee die koppelvlak-aansig van dieselfde verkeer. ’n Groot gaping tussen die twee is verwag en dui nie op ’n lek, ’n tou of ’n verkeerde instelling nie.

Waar die grepe werklik vandaan kom

Volgehoue uitset het sy eie begroting, en dit word deur bewerkings gedryf eerder as deur loonvrag. ’n Breedsprakige logvlak, ’n kliëntelys wat dikwels verander, of ’n fout wat in ’n strak lus herhaal, kan aansienlike skrywes lewer terwyl die tonnel baie min dra.

’n Statuslêer is ’n momentopname wat met ’n interval herskryf word, so die koste daarvan hang van die interval af en van hoeveel rekords dit bevat. Dit is nie ’n lopende kopie van elke kliënt se verkeer nie, en ’n korter interval verander die skryfvolume sonder om die verkeersvolume te verander.

Eienaarskap maak saak wanneer u daardie skrywes soek. As die diens boodskappe aan ’n logdaemon oorhandig, word die joernaal of loglêer deur daardie daemon geskryf, en die grepe verskyn in die daemon se rekening eerder as in die VPN-proses se eie tellers. Om net na die VPN-proses te kyk, verduidelik nóg die skyfaktiwiteit nóg die afwesigheid daarvan.

Ander bydraers word maklik misgekyk: sertifikaat- en konfigurasielees by die opstart, hake wat hul eie rekords skryf, rekeningkundige inproppe, ineenstortingsdumps en onverwante werk op dieselfde gasheer. Nie een daarvan moet geskat word deur tonnelverkeer met geskrewe grepe gelyk te stel nie.

Lees elke teller korrek

Drie besonderhede bepaal of ’n vergelyking iets beteken. Die proses se identiteit maak saak, want ’n herbegin diens stel sy tellers terug. Die tydinterval maak saak, want ’n kumulatiewe syfer en ’n grafiek per sekonde is verskillende metings. En die eenheid maak saak, want ’n loglêer se huidige grootte is ook nie ’n tempo nie.

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

As u vermoed dat daar werklike loonvrag geskryf word, soek ’n komponent wie se taak dit is om loonvrag te stoor: ’n pakketopvanginstrument, ’n instaanbediener wat liggame kas, ’n inprop wat argiveer. Dit lewer stoormediumverkeer wat skaal met wat daarvan gevra word om te rekord, en dit hoort by ’n aparte beleidsbesluit oor bewaring en toegang.

Kapasiteit beplan met die regte getal

Bepaal die pakketpad met netwerkgetalle: deurset, kriptografiese verwerking en geheuebeweging. Bepaal stoorkapasiteit met die waarneembaarheidskeuses wat u werklik gemaak het: logvlak, bewaring, statusinterval en enige opvang wat doelbewus geaktiveer is.

Om daardie twee begrotings apart te hou, maak voorvalle ook makliker leesbaar. ’n Vol skyf met beskeie tonnelverkeer wys na logs, opvangs of iets onverwant, en die koppelvlakteller sal dit nooit verduidelik nie. ’n Versadigde skakel met ’n stil log wys die ander kant toe.

Die vergelyking wat die moeite werd is, is tussen metings van dieselfde soort. Koppelvlakgrepe teenoor koppelvlakgrepe oor tyd vertel u van die pad. Stoorskrywes teenoor stoorkapasiteit vertel u van bewaring. Die kruisvergeliking, verkeer teenoor skyf, lyk net betekenisvol en is dit nooit nie.