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