Натоварването на 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 документира файла със състоянието и опциите за шейпинг, ако ви трябват точните директиви за страната на хоста.