Quanti core serve OpenVPN? Dipende dal percorso

Due server con lo stesso numero di processori possono sostenere prestazioni molto diverse, perché il numero che conta è quanti core il percorso dati attivo riesce davvero a usare. Un singolo demone nello spazio utente che elabora i pacchetti di un client è limitato a un core, mentre un percorso kernel con offload può distribuire quel lavoro. Nessuna delle due affermazioni dice cosa farà una data macchina con il tuo traffico, per questo la misura viene prima del conteggio dei core.

Il confronto qui sotto riguarda dove vengono elaborati i pacchetti, non quale prodotto sia più veloce in astratto. Sono domande diverse con risposte diverse.

Un core per flusso sul percorso nello spazio utente

In un'istanza Community OpenVPN tradizionale il canale dati viene elaborato nello spazio utente, e una connessione occupata può bloccare un processore mentre l'utilizzo complessivo della macchina resta poco appariscente. Ecco perché aggiungere core a un host già saturo su un solo flusso non cambia nulla: lo scheduler non ha modo di dividere quel lavoro. La struttura di un processo per client limita il trasferimento di un client alla capacità di un core, qualunque sia il numero totale di core. Durante un test leggi l'utilizzo per core invece della cifra aggregata, altrimenti il collo di bottiglia sembrerà margine libero.

Eseguire più istanze del server su un solo host distribuisce client distinti tra i processi. Non parallelizza una connessione esistente e costa pool, listener e decisioni di routing separati.

L'altro percorso: i pacchetti nel kernel

Offload del canale dati sposta nel kernel l'elaborazione dei pacchetti supportata e la crittografia, dove il lavoro può usare più core. Questo sposta la domanda di capacità da un core alla macchina, ma solo per configurazioni supportate dall'implementazione: un modulo kernel compatibile, un cifrario dati idoneo e una configurazione priva delle funzioni che l'offload esclude. Installare un modulo non è la stessa cosa che usarlo, quindi verifica il modo attivo dal log o dall'output di stato della connessione stessa. Un banner di versione dimostra cosa è disponibile, non cosa è in esecuzione.

L'offload non elimina l'autenticazione né il canale di controllo, e non rende ogni distribuzione multi-core. È un'accelerazione locale di un percorso dati compatibile, e i requisiti cambiano secondo piattaforma e versione.

Che cosa decide davvero il confronto

La scelta reale è tra accettare un tetto per flusso, distribuire i client tra istanze e passare a una configurazione con offload supportata. Ognuna affronta un problema diverso, e scegliere quella sbagliata costa denaro senza muovere il numero. Il test che conta è quello modellato sul modo in cui il servizio viene usato.

Misura tre forme: un client con un trasferimento, un client con più flussi e più client insieme. Un totale alto nella terza non dimostra che un singolo download possa raggiungerlo, e un trasferimento singolo lento non dimostra che il server abbia esaurito la capacità complessiva. I risultati rispondono a domande diverse e valgono entrambi.

Solo la forma intermedia ti dice se la concorrenza dentro un client aiuta, cosa che di solito è una proprietà del trasporto e del percorso più che del server. Solo la prima ti dice il tetto che vedrà una singola applicazione. Mantieni identico il carico tra le esecuzioni perché il confronto significhi qualcosa.

Misurare perché la cifra significhi qualcosa

Annota le versioni di server e client, il percorso dati attivo, il cifrario dati negoziato, la direzione del trasferimento, le dimensioni dei pacchetti, il numero di flussi e la durata. Osserva l'attività per core e le perdite di pacchetti e code ai due estremi, perché l'interfaccia del client stesso, la rete del provider o il servizio di destinazione possono diventare il limite per primi. Cambia una variabile alla volta, dato che un'esecuzione che modifica cifrario, compressione, MTU e offload insieme non può dirti quale sia stato importante. Mantieni durante il test la politica di accesso che intendi davvero distribuire, perché un allestimento di laboratorio che nessuno eseguirà dimostra poco.

Lascia poi margine per il canale di controllo, per la rinegoziazione e per tutto il resto che gira sull'host.

Riporta ciò che la configurazione ha sostenuto nella concorrenza prevista, invece di una velocità estrapolata dall'hardware di qualcun altro. Una cifra con le sue condizioni di prova è utile; una promessa senza di esse è una congettura che ti verrà citata contro.