Carico di un server VPN spiegato: utenti, CPU o uplink?

Un gateway con un carico di 0.4 può ancora trascinarsi per ogni utente dietro di sé. Il carico medio conta i processi eseguibili o bloccati in un sonno ininterrompibile, e su un host a quattro core basta un solo processo saturo a spingerlo verso 1.0 mentre tre core restano inattivi. Leggere quel numero come margine disponibile è l’errore più comune nella scelta di un endpoint. Ciò che limita davvero un tunnel è di solito una di quattro cose: un core occupato, l’uplink, la coda davanti ad esso o una policy per sessione che nessuno ha documentato.

Il carico medio conta i processi, non la capacità

Il kernel campiona la coda di esecuzione e il numero di processi in attesa di input e output, poi livella entrambi su uno, cinque e quindici minuti. Nulla in quella definizione menziona byte, pacchetti o tunnel. Un host con lo storage bloccato può riportare un carico alto con quasi nessun traffico, e un host che spinge un gigabit lungo un percorso dati del kernel può riportarne uno comodo.

Correlare il carico con le prestazioni del tunnel richiede quindi una vista per core. Se un core è saturo, la percentuale aggregata su una dashboard sembrerà comunque buona:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

Il terzo comando è quello che conta di più sugli host VPN. L’elaborazione dei pacchetti in spazio utente in OpenVPN 2.x è in gran parte serializzata per processo, quindi un solo thread occupato può diventare il tetto mentre la dashboard riporta abbondante capacità inutilizzata. Se un thread occupa la maggior parte di un core durante il tuo periodo lento, l’host non è sottodimensionato nel complesso; è limitato nella dimensione che capita di contare.

Nota anche il momento. Le medie su quindici minuti nascondono la raffica che ha rovinato una chiamata, quindi uno screenshot scattato dopo la lamentela è una prova debole. Campiona durante il problema e conserva il timestamp con l’output.

L’uplink e la coda davanti ad esso

I contatori dell’interfaccia rispondono alla domanda sulla larghezza di banda a cui i numeri della CPU non possono rispondere. Separano anche la capacità dalla perdita, che sono guasti diversi con correzioni diverse:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Un collegamento vicino alla sua velocità assegnata durante il test è la spiegazione, e nessuna quantità di CPU libera lo cambia. La riga qdisc aggiunge il dettaglio che conta per il traffico interattivo: arretrato e scarti dicono se i pacchetti aspettano in coda prima di uscire. Una coda che si riempie sotto un caricamento massiccio produce esattamente il sintomo che le persone attribuiscono al server remoto, cioè chiamate lente su una connessione che nei benchmark va ancora bene.

I contatori di ritrasmissione intercettano il caso in cui i pacchetti escono ma non arrivano mai puliti. Se le ritrasmissioni salgono durante la finestra lenta e l’interfaccia è lontana dalla capacità, il problema è nel percorso e non sull’host, e passare a un altro endpoint nella stessa città non aiuterà.

Il numero di sessioni descrive la domanda, non il margine

Ogni directory pubblica mostra un certo numero di utenti connessi, e quasi nessuna ti dice cosa stanno facendo quegli utenti. Venti sessioni di lavoro interattivo e quattro sessioni che scaricano file grandi producono carichi molto diversi sullo stesso hardware. Il secondo schema è invisibile in un conteggio di utenti, ed è quello che rovina una serata. Quindi un numero di sessioni si legge meglio come indizio sulla domanda, mai come affermazione sulla capacità libera.

Su un host che controlli, il file di stato fornisce la dimensione mancante. OpenVPN scrive snapshot periodici che includono contatori di byte per client, e questo basta per vedere se una singola sessione è responsabile dell’intero uplink:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Due campioni distanti dieci secondi trasformano quei conteggi cumulativi in una velocità per client. È la misura che un conteggio di utenti sostituisce, ed è anche così che scopri che un solo client mal configurato satura il collegamento ogni notte alla stessa ora.

I limiti per sessione si nascondono nella policy

Un server può essere inattivo e comunque rifiutarsi di darti larghezza di banda. Limiti di velocità, tetti di banda per client e traffic shaping vengono spesso applicati per nome comune o per pool, quindi due utenti sullo stesso gateway possono ottenere risultati molto diversi. Il meccanismo non è sottile, ma è invisibile dall’esterno perché il tunnel sale normalmente in entrambi i casi.

Cerca lo shaping sull’interfaccia del tunnel e non su quella fisica. Verifica se il limite segue l’utente, il certificato o il pool di indirizzi. Se il tuo account di test finisce nel pool senza tetto, concluderai che il server va bene e che l’utente che si lamenta ha torto. Quella conclusione è peggiore di nessuna conclusione, perché chiude il ticket.

Confronta due endpoint con un solo compito fisso

L’esperimento lato client vale ancora la pena, ma solo se le variabili sono fissate. Usa lo stesso dispositivo, la stessa rete di accesso, lo stesso protocollo e lo stesso file di destinazione, poi ripeti contro un secondo endpoint a una distanza simile. Qualunque cosa cambi tra le esecuzioni, inclusa l’ora del giorno, contamina il risultato.

Registra i fallimenti con la stessa cura dei successi. Una serie in cui tre endpoint funzionano e uno va in timeout è più informativa di quattro numeri di velocità, perché indica un problema di percorso o di policy e non di capacità. Esegui ogni caso almeno due volte; un singolo campione lento non dimostra nulla su una rete condivisa.

Infine, conserva i numeri raccolti insieme all’affermazione che supportano. "Questo endpoint ha completato il trasferimento nella stessa finestra in cui l’altro si è bloccato" è difendibile, mentre "questo endpoint è più veloce" invita a una discussione che non puoi vincere con un punteggio di home page. Il manuale di OpenVPN 2.6 documenta il file di stato e le opzioni di shaping se ti servono le direttive esatte per il lato host.