Нагрузка 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 пераважна паслядоўная ў межах працэса, таму адзін заняты паток можа стаць столлю, пакуль панэль паказвае шмат вольнай магутнасці. Калі адзін паток займае большую частку ядра ў ваш перыяд павольнай працы, хост не недазабяспечаны ў цэлым; ён абмежаваны ў тым вымярэнні, якое якраз мае значэнне.

Звярніце ўвагу і на час. Пятнаццаціхвілінныя сярэднія хаваюць усплёск, які сапсаваў званок, таму здымак экрана, зроблены пасля скаргі, — слабы доказ. Бярыце пробы падчас праблемы і захоўвайце адзнаку часу разам з вывадам.

Канал і чарга перад ім

Лічыльнікі інтэрфейса адказваюць на пытанне пра прапускную здольнасць, на якое не могуць адказаць лічбы працэсара. Яны таксама аддзяляюць ёмістасць ад страт, а гэта розныя збоі з рознымі рашэннямі:

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

Спасылка, блізкая да сваёй выдзеленай хуткасці падчас тэсту, і ёсць тлумачэннем, і ніякая колькасць вольнага працэсара гэтага не зменіць. Радок 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 апісвае файл стану і параметры фармавання, калі вам патрэбныя дакладныя дырэктывы для боку хоста.