Contoarele de trafic OpenVPN față de I/O pe disc: trei numere diferite

Treceți un fișier mare printr-un tunel și contorul interfeței crește cu dimensiunea fișierului. Nimic din acel număr nu implică faptul că același volum a ajuns pe un disc. În aceste discuții se compară trei măsurători diferite, iar ele răspund la trei întrebări diferite: cât trafic a traversat un strat de rețea, câți octeți a citit și a scris un proces prin apeluri de sistem și câtă muncă a ajuns la stratul de stocare.

Compararea primului cu al treilea este greșeala obișnuită și produce fie o problemă fantomă de disc, fie un plan de capacitate care ignoră scrierile care chiar au loc. Cele trei sunt separabile și fiecare are o utilizare corectă.

Trei numere care se confundă

Contoarele interfeței descriu traficul gestionat la nivelul unui strat de rețea. Ele sunt numărul corect pentru lățimea de bandă, pentru dimensiunea unui tunel și pentru modelele de facturare care stabilesc un preț pentru tranzit.

Contoarele de caractere ale procesului descriu octeții mutați prin apeluri de citire și scriere pe orice descriptor, inclusiv conducte, terminale și dispozitive de caractere. Ele sunt numărul corect pentru a întreba cât de ocupat este un proces la limita apelului de sistem și nu sunt o factură de stocare.

Contoarele de stocare descriu octeții pe care nucleul a încercat să îi mute către sau dintr-un dispozitiv de blocuri. Ele sunt numărul corect pentru planificarea capacității, cu rezerva că nucleul își documentează propriile limite de contabilizare: citirile din cache nu devin citiri de stocare, iar o scriere anulată mai târziu nu devine o scriere de dispozitiv finalizată.

De ce un descriptor de fișier nu este o scriere pe disc

Un VPN din spațiul utilizator schimbă pachete cu nucleul printr-un dispozitiv TUN, care este un dispozitiv de caractere și nu un fișier obișnuit. Citirea din el predă un pachet; scrierea în el injectează unul. Nu există nicio pagină de conținut de fișier pregătită pentru stocare și nicio cale de sistem de fișiere implicată.

De aceea un tunel ocupat poate arăta contoare de caractere uriașe cu aproape niciun contor de stocare. Procesul a mutat într-adevăr acei octeți, iar nucleul într-adevăr nu a avut nevoie de un disc pentru asta.

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

Citiți prima ieșire ca cumulată de la pornirea procesului, nu ca rată. A doua oferă vederea interfeței asupra aceluiași trafic. O diferență mare între cele două este de așteptat și nu indică o scurgere, o coadă sau o configurație greșită.

De unde vin de fapt octeții

Ieșirea persistentă are propriul buget, iar acesta este condus de operații și nu de încărcătura utilă. Un nivel de jurnal detaliat, o listă de clienți care se schimbă des sau o eroare care se repetă într-o buclă strânsă pot genera scrieri substanțiale în timp ce tunelul transportă foarte puțin.

Un fișier de stare este o instantanee rescrisă la un interval, așa că costul său depinde de interval și de câte înregistrări conține. Nu este o copie curentă a traficului fiecărui client, iar scurtarea intervalului schimbă volumul scrierilor fără a schimba volumul traficului.

Proprietatea contează când căutați acele scrieri. Dacă serviciul predă mesajele unui demon de jurnalizare, jurnalul sau fișierul este scris de acel demon, iar octeții apar în contabilizarea demonului și nu în contoarele proprii ale procesului VPN. A privi doar procesul VPN nu explică nici activitatea discului, nici absența ei.

Alți contribuitori sunt ușor de trecut cu vederea: citirea certificatelor și a configurației la pornire, cârlige care își scriu propriile înregistrări, module de contabilizare, dump-uri de eroare și sarcini de lucru fără legătură pe același gazdă. Niciunul nu ar trebui estimat echivalând traficul tunelului cu octeții scriși.

Citirea corectă a fiecărui contor

Trei detalii decid dacă o comparație înseamnă ceva. Identitatea procesului contează, pentru că un serviciu repornit își resetează contoarele. Intervalul de timp contează, pentru că o cifră cumulată și un grafic pe secundă sunt măsurători diferite. Iar unitatea contează, pentru că nici dimensiunea actuală a unui fișier de jurnal nu este o rată.

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

Dacă bănuiți scrieri reale de încărcătură utilă, căutați o componentă a cărei sarcină este să stocheze încărcătura: un instrument de captură a pachetelor, un proxy care păstrează în cache corpuri, un modul care arhivează. Acestea produc trafic de stocare care crește cu ceea ce li se cere să înregistreze și aparțin unei decizii de politică separate privind păstrarea și accesul.

Planificarea capacității cu numărul corect

Dimensionați calea pachetelor cu cifre de rețea: debit, procesare criptografică și mișcare a memoriei. Dimensionați stocarea cu alegerile de observabilitate pe care le-ați făcut efectiv: nivelul jurnalului, păstrarea, intervalul stării și orice captură activată în mod deliberat.

Păstrarea separată a acestor două bugete face și incidentele mai ușor de citit. Un disc plin cu trafic modest de tunel indică jurnale, capturi sau ceva fără legătură, iar contorul interfeței nu va explica niciodată acest lucru. O legătură saturată cu un jurnal liniștit indică în cealaltă direcție.

Comparația care merită făcută este între măsurători de același fel. Octeții interfeței față de octeții interfeței în timp vă spun despre cale. Scrierile de stocare față de capacitatea de stocare vă spun despre păstrare. Comparația încrucișată, trafic față de disc, doar pare semnificativă și nu este niciodată.