Belastning på VPN-servrar förklarad: användare, CPU eller uplänk?

En gateway med belastning 0.4 kan fortfarande krypa för varje användare bakom den. Medelbelastningen räknar uppgifter som kan köras eller som fastnat i oavbruten sömn, och på en värd med fyra kärnor räcker en enda mättad process för att knuffa den mot 1.0 medan tre kärnor sitter sysslolösa. Att läsa den siffran som marginal är det vanligaste misstaget vid val av slutpunkt. Det som faktiskt begränsar en tunnel är oftast en av fyra saker: en upptagen kärna, uplänken, kön framför den eller en policy per session som ingen har dokumenterat.

Medelbelastningen räknar uppgifter, inte genomströmning

Kärnan samplar körkön och antalet uppgifter som väntar på in- och utdata och jämnar sedan ut båda över en, fem och femton minuter. Ingenting i den definitionen nämner byte, paket eller tunnlar. En värd med låst lagring kan rapportera hög belastning med nästan ingen trafik, och en värd som pressar en gigabit genom kärnans dataväg kan rapportera en behaglig.

Att korrelera belastning med tunnelprestanda kräver därför en vy per kärna. Om en kärna är full belastad kommer den sammanlagda procentsatsen på en instrumentpanel fortfarande att se bra ut:

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

Det tredje kommandot är det som betyder mest på VPN-värdar. Paketbehandling i användarland i OpenVPN 2.x är till stor del serialiserad per process, så en enda upptagen tråd kan bli taket medan instrumentpanelen rapporterar gott om ledig kapacitet. Om en tråd håller större delen av en kärna under din långsamma period är värden inte underdimensionerad som helhet; den är begränsad i den dimension som råkar spela roll.

Lägg märke till tidpunkten också. Femtonminutersmedelvärden döljer det utbrott som förstörde ett samtal, så en skärmbild tagen efter klagomålet är svagt bevis. Ta prover under problemet och spara tidsstämpeln med utdata.

Uplänken och kön framför den

Gränssnittsräknarna svarar på bandbreddsfrågan som CPU-siffror inte kan. De skiljer också kapacitet från förlust, och det är olika fel med olika åtgärder:

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

En länk som under testet ligger nära sin tilldelade hastighet är förklaringen, och ingen mängd ledig CPU ändrar det. qdisc-raden lägger till detaljen som betyder något för interaktiv trafik: eftersläpning och förluster berättar om paket väntar i en kö innan de lämnar värden. En kö som fylls under en stor uppladdning ger exakt det symptom folk skyller på fjärrservern, det vill säga sega samtal på en anslutning som fortfarande mäter bra.

Återsändningsräknare fångar fallet där paket lämnar värden men aldrig anländer rent. Om återsändningarna ökar under det långsamma fönstret och gränssnittet är långt från kapacitet, ligger problemet i vägen och inte på värden, och att byta till en annan slutpunkt i samma stad hjälper inte.

Sessionsantal beskriver efterfrågan, inte marginal

Varje offentlig katalog visar något antal anslutna användare, och nästan ingen av dem berättar vad dessa användare gör. Tjugo sessioner med interaktivt arbete och fyra sessioner som hämtar stora filer ger mycket olika belastning på samma hårdvara. Det andra mönstret är osynligt i ett användarantal, och det är just det som förstör en kväll. Ett sessionsantal läses därför bäst som en antydan om efterfrågan, aldrig som ett påstående om ledig kapacitet.

På en värd du kontrollerar ger statusfilen den saknade dimensionen. OpenVPN skriver en regelbunden ögonblicksbild med byteräknare per klient, och det räcker för att se om en enda session ansvarar för hela uplänken:

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

Två prover tio sekunder isär gör de kumulativa siffrorna till en hastighet per klient. Det är mätningen som ett användarantal står i stället för, och det är också så du upptäcker att en enda felkonfigurerad klient mättar länken varje natt vid samma tid.

Gränser per session gömmer sig i policyn

En server kan vara sysslolös och ändå vägra ge dig bandbredd. Hastighetsgränser, bandbreddstak per klient och trafikformning tillämpas ofta per gemensamt namn eller per pool, så två användare på samma gateway kan få helt olika resultat. Mekanismen är inte subtil, men den är osynlig utifrån eftersom tunneln kommer upp normalt i båda fallen.

Leta efter formning på tunnelns gränssnitt och inte på det fysiska. Kontrollera om gränsen följer användaren, certifikatet eller adresspoolen. Om ditt testkonto hamnar i poolen utan tak kommer du att dra slutsatsen att servern är okej och att användaren som klagar har fel. Den slutsatsen är värre än ingen slutsats, eftersom den stänger ärendet.

Jämför två slutpunkter med en enda fast uppgift

Försöket på klientsidan är fortfarande värt att köra, men bara om variablerna är låsta. Använd samma enhet, samma åtkomstnät, samma protokoll och samma målfil, och upprepa sedan mot en andra slutpunkt på liknande avstånd. Allt som ändras mellan körningarna, inklusive tiden på dygnet, förorenar resultatet.

Notera misslyckanden lika noggrant som framgångar. En serie där tre slutpunkter fungerar och en går i timeout är mer informativ än fyra hastighetssiffror, eftersom den pekar på ett väg- eller policyproblem snarare än ett kapacitetsproblem. Kör varje fall minst två gånger; ett enda långsamt prov bevisar ingenting i ett delat nät.

Till sist: behåll siffrorna du samlade in tillsammans med påståendet de stöder. "Den här slutpunkten klarade överföringen i samma fönster där den andra fastnade" är försvarbart, medan "den här slutpunkten är snabbare" bjuder in till en diskussion du inte kan vinna med en poäng från en startsida. OpenVPN 2.6-handboken dokumenterar statusfilen och formningsalternativen om du behöver de exakta direktiven för värdsidan.