Contatori di traffico OpenVPN e I/O su disco: tre numeri diversi

Fate passare un file grande attraverso un tunnel e il contatore dell’interfaccia sale della dimensione del file. Nulla in quel numero implica che lo stesso volume abbia raggiunto un disco. In queste discussioni si confrontano tre misurazioni diverse, e rispondono a tre domande diverse: quanto traffico ha attraversato uno strato di rete, quanti byte un processo ha letto e scritto tramite chiamate di sistema, e quanto lavoro ha raggiunto lo strato di archiviazione.

Confrontare il primo con il terzo è l’errore abituale, e produce o un problema di disco fantasma o un piano di capacità che ignora le scritture che avvengono davvero. I tre sono separabili, e ciascuno ha un uso corretto.

Tre numeri che vengono confusi

I contatori dell’interfaccia descrivono il traffico gestito a livello di rete. Sono il numero giusto per la larghezza di banda, per la dimensione di un tunnel e per i modelli di fatturazione che danno un prezzo al transito.

I contatori di caratteri del processo descrivono i byte spostati tramite chiamate di lettura e scrittura su qualsiasi descrittore, comprese pipe, terminali e dispositivi a caratteri. Sono il numero giusto per chiedere quanto è occupato un processo al confine della chiamata di sistema, e non sono una fattura di archiviazione.

I contatori di archiviazione descrivono i byte che il kernel ha tentato di spostare verso o da un dispositivo a blocchi. Sono il numero giusto per pianificare la capacità, con l’avvertenza che il kernel documenta i propri limiti di contabilità: le letture in cache non diventano letture di archiviazione, e una scrittura annullata in seguito non diventa una scrittura di dispositivo completata.

Perché un descrittore di file non è una scrittura su disco

Una VPN nello spazio utente scambia pacchetti con il kernel tramite un dispositivo TUN, che è un dispositivo a caratteri e non un file normale. Leggere da esso consegna un pacchetto; scrivervi ne inietta uno. Nessuna pagina di contenuto di file viene preparata per l’archiviazione, e nessun percorso di filesystem è coinvolto.

Per questo un tunnel attivo può mostrare enormi contatori di caratteri con quasi nessun contatore di archiviazione. Il processo ha davvero spostato quei byte, e il kernel davvero non ha avuto bisogno di un disco per farlo.

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

Leggete il primo output come cumulativo dall’avvio del processo, non come una velocità. Il secondo dà la vista dell’interfaccia dello stesso traffico. Un grande divario tra i due è atteso e non indica una perdita, una coda o una configurazione errata.

Da dove vengono davvero i byte

L’output persistente ha il proprio budget, ed è guidato dalle operazioni più che dal payload. Un livello di log prolisso, un elenco di client che cambia spesso o un errore che si ripete in un ciclo stretto possono generare scritture consistenti mentre il tunnel trasporta pochissimo.

Un file di stato è un’istantanea riscritta a intervalli, quindi il suo costo dipende dall’intervallo e da quanti record contiene. Non è una copia continua del traffico di ogni client, e accorciare l’intervallo cambia il volume di scrittura senza cambiare il volume di traffico.

La proprietà conta quando andate a cercare quelle scritture. Se il servizio consegna i messaggi a un demone di logging, il journal o il file di log è scritto da quel demone, e i byte compaiono nella contabilità del demone invece che nei contatori propri del processo VPN. Guardare solo il processo VPN non spiega né l’attività del disco né la sua assenza.

Altri contribuenti sono facili da trascurare: letture di certificati e configurazione all’avvio, hook che scrivono i propri record, plugin di contabilità, dump di crash e carichi di lavoro non correlati sullo stesso host. Nessuno di essi dovrebbe essere stimato equiparando il traffico del tunnel ai byte scritti.

Leggere ogni contatore correttamente

Tre dettagli decidono se un confronto significa qualcosa. L’identità del processo conta, perché un servizio riavviato azzera i suoi contatori. L’intervallo di tempo conta, perché una cifra cumulativa e un grafico al secondo sono misurazioni diverse. E l’unità conta, perché anche la dimensione attuale di un file di log non è una velocità.

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

Se sospettate scritture reali di payload, cercate un componente il cui compito è archiviare il payload: uno strumento di cattura pacchetti, un proxy che mette in cache i corpi, un plugin che archivia. Questi producono traffico di archiviazione che cresce con ciò che viene chiesto loro di registrare, e appartengono a una decisione di politica separata su conservazione e accesso.

Pianificare la capacità con il numero giusto

Dimensionate il percorso dei pacchetti con cifre di rete: throughput, elaborazione crittografica e movimento della memoria. Dimensionate l’archiviazione con le scelte di osservabilità che avete davvero fatto: livello di log, conservazione, intervallo di stato e qualsiasi cattura attivata deliberatamente.

Tenere separati questi due budget rende anche più facile leggere gli incidenti. Un disco pieno con un traffico di tunnel modesto punta a log, catture o qualcosa di non correlato, e il contatore dell’interfaccia non lo spiegherà mai. Un collegamento saturo con un log silenzioso punta nella direzione opposta.

Il confronto che vale la pena è tra misurazioni dello stesso tipo. Byte dell’interfaccia contro byte dell’interfaccia nel tempo vi parlano del percorso. Scritture di archiviazione contro capacità di archiviazione vi parlano della conservazione. Il confronto incrociato, traffico contro disco, sembra solo significativo e non lo è mai.