Utenti o throughput? Dimensionare un server VPN per il carico reale

Dieci account inattivi costano meno di un backup notturno che satura il tunnel, e un numero di utenti non può mostrare questa differenza. Dimensionare un server VPN è un confronto tra due numeri: la concorrenza che portate davvero e la risorsa che si esaurisce per prima. La maggior parte degli errori di capacità nasce dallo scegliere il primo numero e dal non misurare mai il secondo. Fate entrambe le cose, in quest’ordine, e la decisione hardware smette di essere un’ipotesi.

Confrontate il numero di account con l’ora di punta

Il numero di account è una licenza e un limite di supporto; l’ora di punta è un carico. Elencate il lavoro che si sovrappone in quell’ora: chiamate, amministrazione remota, download grandi, backup e le richieste delle applicazioni private che fanno aspettare le persone. Poi segnate, per ogni voce, se attraversa il gateway e in quale direzione. Le chiamate sono simmetriche e sensibili al ritardo, mentre un backup è unidirezionale e tollera un avvio lento, quindi sollecitano parti diverse del percorso.

La direzione decide quale collegamento conta. Un uplink domestico è raramente simmetrico, e una filiale che scarica tutto il giorno raggiunge il suo limite in downstream molto prima che il gateway sudi. Scrivete la direzione e l’ambito del tunnel accanto a ogni voce, perché un gateway che porta solo destinazioni private e uno che porta tutto il traffico internet sono due problemi di dimensionamento diversi.

Aggiungete il carico di fondo come riga a sé: aggiornamenti dei client, telemetria e tutto ciò che l’host fa oltre a inoltrare. Quei byte si dimenticano facilmente e la stessa interfaccia li conta.

Trovate la risorsa che si esaurisce prima del collegamento

Il collegamento è solo un candidato. Il lavoro crittografico di un singolo tunnel può occupare un core mentre l’interfaccia resta mezzo vuota, e una coda satura può rendere inutilizzabili le chiamate con un throughput che sul grafico sembra mediocre. Una destinazione a una rotta lenta di distanza può anch’essa sembrare debolezza del gateway dalla postazione del client. Tre osservazioni separano questi casi, e nessuna richiede un test a raffica.

Misurate con un trasferimento che vi è consentito eseguire, e aggiungete il lavoro concorrente per passi invece che tutto insieme. Leggete la velocità sostenuta e la risposta interattiva insieme, perché un test di sola velocità di punta nasconde una sessione diventata inutilizzabile. Un gateway che supera il suo throughput massimo mentre le chiamate si spezzano non ha superato il test.

Poi ripetete l’esecuzione con i carichi opzionali fermati. Un limite che si sposta quando il backup si ferma non è mai stato il limite del gateway.

Trasformate il confronto in un numero che potete difendere

Scegliete la risorsa esaurita ed esprimete il requisito nelle sue unità: core a un’utilizzazione obiettivo durante l’ora di punta, bit al secondo in ciascuna direzione, o sessioni concorrenti sotto un limite di ritardo. Lasciate spazio ad aggiornamenti, diagnostica e ripristino, perché un server fermo al suo tetto misurato non ha più nulla per il lavoro che lo tiene in funzione. Poi scrivete i numeri accanto alla configurazione che li ha prodotti, compresi il numero di client e il test usato.

Il numero di utenti per core è il dato meno trasferibile di questo esercizio, perché presuppone un mix di protocolli e un profilo di dispositivi che il sito successivo non condivide. Tenete la misurazione e scartate la formula. Quando qualcuno chiede capacità per cinquanta utenti in più, la risposta onesta è il profilo dell’ora di punta di quei cinquanta, non una moltiplicazione.

Registrate il tempo di risposta oltre al throughput. Una capacità che preserva solo il trasferimento in blocco non è capacità per le persone in chiamata, e la prossima revisione chiederà della differenza.

Scegliete tra scalare verso l’alto e separare il ruolo

Quando il limite misurato è un core, più core alla stessa frequenza possono non aiutare; un core più veloce o un altro modello di worker può. Quando il limite è la CPU aggregata, un’istanza più grande è la soluzione diretta. Quando il limite è il collegamento di accesso, nessun cambio di server aiuta e il confronto finisce dal fornitore. Separare i ruoli web e VPN su host distinti compra l’isolamento al prezzo di una seconda superficie di gestione.

Confrontate quelle opzioni con il numero registrato, non tra loro. Un cambiamento che raddoppia una risorsa che non era il vincolo è costo senza beneficio, e il registro è ciò che vi permette di dirlo senza discussione. Misurate di nuovo dopo il cambiamento con lo stesso carico, altrimenti avete sostituito un’ipotesi con un’altra.