Навантаження 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 описує файл стану та параметри формування, якщо вам потрібні точні директиви для боку хоста.