Оптерећење VPN сервера објашњено: корисници, CPU или улазни канал?

Мрежни пролаз са оптерећењем 0.4 и даље може пузати за сваког корисника иза њега. Просечно оптерећење броји задатке који могу да се извршавају или који су заглављени у непрекидном сну, а на домаћину са четири језгра довољан је један засићен процес да га гурне ка 1.0 док три језгра седе неискоришћена. Читати тај број као резерву најчешћа је грешка при избору крајње тачке. Оно што заправо ограничава тунел обично је једна од четири ствари: једно заузето језгро, улазни канал, ред испред њега или политика по сесији коју нико није документовао.

Просечно оптерећење броји задатке, не пропусност

Језгро узима узорке из реда извршавања и броја задатака који чекају улаз и излаз, а затим оба изглађује током једног, пет и петнаест минута. Ништа у тој дефиницији не помиње бајтове, пакете или тунеле. Домаћин са заглављеним складиштем може пријавити високо оптерећење са готово никаквим саобраћајем, а домаћин који гура гигабит кроз податачну путању језгра може пријавити удобно.

Зато повезивање оптерећења са радом тунела захтева поглед по језгру. Ако је једно језгро потпуно заузето, укупан проценат на контролној табли и даље ће изгледати добро:

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

Трећа команда је она која највише вреди на VPN домаћинима. Обрада пакета у корисничком простору у OpenVPN 2.x је углавном серијска по процесу, па једна заузета нит може постати плафон док табла извештава о обиљу слободног капацитета. Ако једна нит држи већи део језгра током вашег спорог периода, домаћин укупно није недовољно димензионисан; ограничен је у димензији која се случајно рачуна.

Обратите пажњу и на време. Петнаестоминутни просеци скривају налет који је упропастио позив, зато је снимак екрана настао после притужбе слаб доказ. Узимајте узорке током проблема и чувајте временску ознаку уз излаз.

Улазни канал и ред испред њега

Бројачи интерфејса одговарају на питање о пропусном опсегу на које бројеви CPU не могу. Они такође одвајају капацитет од губитка, а то су различите грешке са различитим решењима:

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

Веза која је током вашег теста близу додељене брзине је објашњење и никаква количина слободног CPU то не мења. Ред qdisc додаје појединост важну за интерактивни саобраћај: заостатак и одбацивања говоре вам чекају ли пакети у реду пре одласка. Ред који се пуни под великим отпремањем ствара тачно онај симптом који људи приписују удаљеном серверу, досадне позиве на вези која још добро пролази на мерењима.

Бројачи поновног преноса хватају случај у ком пакети одлазе, али никада не стижу чисто. Ако поновни преноси расту у спором прозору, а интерфејс ни близу капацитета, проблем је на путу, а не на домаћину, и прелазак на другу крајњу тачку у истом граду неће помоћи.

Бројеви сесија описују потражњу, не резерву

Сваки јавни именик приказује неки број повезаних корисника и готово ниједан вам не каже шта ти корисници раде. Двадесет сесија са интерактивним радом и четири сесије које вуку велике датотеке стварају веома различита оптерећења на истом хардверу. Други образац је невидљив у броју корисника и управо он квари вече. Зато број сесија најбоље читати као наговештај потражње, никада као тврдњу о слободном капацитету.

На домаћину који контролишете, датотека стања даје димензију која недостаје. OpenVPN записује повремену слику која укључује бројаче бајтова по клијенту, и то је довољно да видите да ли је једна сесија одговорна за цео улазни канал:

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

Два узорка удаљена десет секунди претварају те кумулативне бројаче у брзину по клијенту. То је мерење које број корисника замењује и тако откривате да један погрешно конфигурисан клијент сваке ноћи у исти сат засићује везу.

Ограничења по сесији крију се у политици

Сервер може бити неактиван и ипак вам одбити пропусни опсег. Ограничења брзине, горње границе пропусног опсега по клијенту и обликовање саобраћаја често се примењују по заједничком имену или по групи, па два корисника на истом пролазу могу добити веома различите резултате. Механизам није суптилан, али је споља невидљив јер се тунел у оба случаја нормално подиже.

Тражите обликовање на интерфејсу тунела, а не на физичком. Проверите да ли ограничење следи корисника, сертификат или групу адреса. Ако ваша тест налог заврши у групи без ограничења, закључићете да је сервер у реду и да корисник који се жали греши. Такав закључак је гори од никаквог јер затвара захтев.

Упоредите две крајње тачке једним сталним задатком

Експеримент на страни клијента још је вредан извођења, али само ако су променљиве приковане. Користите исти уређај, исту приступну мрежу, исти протокол и исту одредишну датотеку, па поновите према другој крајњој тачки на сличној удаљености. Све што се између покретања промени, укључујући доба дана, загађује резултат.

Бележите неуспехе једнако пажљиво као успехе. Низ у ком три крајње тачке раде, а једна истекне, информативнији је од четири бројке брзине јер упућује на проблем пута или политике, а не капацитета. Покрените сваки случај барем двапут; један спор узорак не доказује ништа на дељеној мрежи.

Напослетку, чувајте бројке које сте прикупили уз тврдњу коју подупиру. "Ова крајња тачка обавила је пренос у истом прозору у ком се друга заглавила" је одбрањиво, док "ова крајња тачка је бржа" позива на расправу коју не можете добити оценом са почетне странице. Приручник OpenVPN 2.6 документује датотеку стања и могућности обликовања ако вам требају тачне директиве за страну домаћина.