Càrrega del servidor VPN explicada: usuaris, CPU o enllaç ascendent?

Una passarel·la amb una càrrega de 0.4 encara pot arrossegar-se per a cada usuari que hi ha al darrere. La càrrega mitjana compta les tasques executables o encallades en un son ininterromput, i en un amfitrió de quatre nuclis n’hi ha prou amb un sol procés saturat per empènyer-la cap a 1.0 mentre tres nuclis estan sense feina. Llegir aquesta xifra com a marge disponible és l’error més comú en la selecció de punts finals. El que realment limita un túnel sol ser una de quatre coses: un nucli ocupat, l’enllaç ascendent, la cua al davant o una política per sessió que ningú no va documentar.

La càrrega mitjana compta tasques, no cabal

El nucli mostreja la cua d’execució i el nombre de tasques que esperen entrada i sortida, i després suavitza tots dos al llarg d’un, cinc i quinze minuts. Res en aquesta definició no esmenta bytes, paquets ni túnels. Un amfitrió amb l’emmagatzematge encallat pot reportar una càrrega alta amb gairebé cap trànsit, i un amfitrió que empeny un gigabit per un camí de dades del nucli pot reportar-ne una de còmoda.

Per tant, correlacionar la càrrega amb el rendiment del túnel necessita una visió per nucli. Si un nucli està saturat, el percentatge agregat del tauler encara es veurà bé:

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

La tercera ordre és la que més importa en amfitrions VPN. El processament de paquets en espai d’usuari a OpenVPN 2.x és en gran part serialitzat per procés, així que un sol fil ocupat pot esdevenir el sostre mentre el tauler informa d’una gran capacitat lliure. Si un fil reté la major part d’un nucli durant el període lent, l’amfitrió no està mancat de recursos en conjunt; està limitat en la dimensió que justament importa.

Fixa’t també en el moment. Les mitjanes de quinze minuts amaguen l’esclat que va espatllar una trucada, així que una captura feta després de la queixa és una prova feble. Mostreja durant el problema i guarda la marca de temps amb la sortida.

L’enllaç ascendent i la cua al davant

Els comptadors d’interfície responen la pregunta de l’amplada de banda que les xifres de CPU no poden. També separen la capacitat de la pèrdua, que són fallades diferents amb solucions diferents:

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

Un enllaç que durant la prova s’acosta a la seva velocitat assignada és l’explicació, i cap quantitat de CPU lliure ho canvia. La línia de qdisc afegeix el detall que importa per al trànsit interactiu: l’acumulació i les descàrregues diuen si els paquets esperen en una cua abans de sortir. Una cua que s’omple sota una càrrega massiva produeix exactament el símptoma que la gent atribueix al servidor remot, trucades lentes en una connexió que encara dona bon resultat a les proves.

Els comptadors de retransmissió capturen el cas en què els paquets surten però mai no arriben nets. Si les retransmissions pugen durant la finestra lenta i la interfície és lluny de la capacitat, el problema és al camí i no a l’amfitrió, i moure’s a un altre punt final de la mateixa ciutat no ajudarà.

Els recomptes de sessió descriuen la demanda, no el marge

Cada directori públic mostra un cert nombre d’usuaris connectats, i gairebé cap no et diu què fan aquests usuaris. Vint sessions fent feina interactiva i quatre sessions baixant fitxers grans produeixen càrregues molt diferents al mateix maquinari. El segon patró és invisible en un recompte d’usuaris, i és el que espatlla una tarda. Així que un nombre de sessions es llegeix millor com una pista sobre la demanda, mai com una afirmació sobre la capacitat lliure.

En un amfitrió que controles, el fitxer d’estat dona la dimensió que falta. OpenVPN escriu una instantània periòdica que inclou comptadors de bytes per client, cosa suficient per veure si una sola sessió és responsable de tot l’enllaç ascendent:

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

Dues mostres separades per deu segons converteixen aquests comptes acumulats en una taxa per client. Aquesta és la mesura que substitueix un recompte d’usuaris, i també és com descobreixes que un sol client mal configurat satura l’enllaç cada nit a la mateixa hora.

Els límits per sessió s’amaguen dins la política

Un servidor pot estar inactiu i tot i així negar-te amplada de banda. Els límits de taxa, els sostres d’amplada de banda per client i la conformació de trànsit sovint s’apliquen per nom comú o per pool, així que dos usuaris a la mateixa passarel·la poden obtenir resultats molt diferents. El mecanisme no és subtil, però és invisible des de fora perquè el túnel s’aixeca normalment en tots dos casos.

Busca la conformació a la interfície del túnel i no a la física. Comprova si el límit segueix l’usuari, el certificat o el pool d’adreces. Si el teu compte de prova cau al pool sense límit, conclouràs que el servidor està bé i que l’usuari que es queixa s’equivoca. Aquesta conclusió és pitjor que cap conclusió, perquè tanca l’incident.

Compara dos punts finals amb una mateixa tasca fixa

Encara val la pena fer l’experiment des del client, però només si les variables estan fixades. Fes servir el mateix dispositiu, la mateixa xarxa d’accés, el mateix protocol i el mateix fitxer de destinació, i després repeteix contra un segon punt final a una distància similar. Qualsevol cosa que canviï entre execucions, inclosa l’hora del dia, contamina el resultat.

Registra les fallades amb tant de compte com els èxits. Una sèrie on tres punts finals funcionen i un fa temps d’espera és més informativa que quatre xifres de velocitat, perquè assenyala un problema de camí o de política i no de capacitat. Executa cada cas almenys dues vegades; una sola mostra lenta no demostra res en una xarxa compartida.

Finalment, guarda les xifres que has recollit amb l’afirmació que sostenen. "Aquest punt final va fer la transferència en la mateixa finestra en què l’altre es va encallar" és defensable, mentre que "aquest punt final és més ràpid" convida a una discussió que no pots guanyar amb una puntuació de portada. El manual d’OpenVPN 2.6 documenta el fitxer d’estat i les opcions de conformació si necessites les directrius exactes per al costat de l’amfitrió.