Пользователи или пропускная способность? Как подобрать VPN-сервер под реальную нагрузку
Число учётных записей не подбирает размер шлюза; это делает пересекающаяся работа. Сравните одновременные передачи, процессор на ядро и очереди, затем запишите нагрузку.
Десять простаивающих учётных записей стоят меньше одной ночной резервной копии, насыщающей туннель, и число пользователей этой разницы не покажет. Подбор VPN-сервера — это сравнение двух чисел: одновременности, которую вы действительно несёте, и ресурса, который заканчивается первым. Большинство ошибок ёмкости возникает из-за выбора первого числа и отсутствия измерения второго. Сделайте и то и другое в этом порядке, и решение о железе перестанет быть догадкой.
Сравните число учётных записей с пиковым часом
Число учётных записей — это лицензия и граница поддержки; пиковый час — это нагрузка. Перечислите работы, которые в этот час пересекаются: звонки, удалённое администрирование, крупные загрузки, резервные копии и запросы частных приложений, из-за которых люди ждут. Затем отметьте для каждой позиции, пересекает ли она шлюз и в каком направлении. Звонки симметричны и чувствительны к задержке, а резервная копия однонаправлена и терпит медленный старт, поэтому они нагружают разные части пути.
Направление определяет, какое соединение важно. Домашний исходящий канал редко симметричен, а филиал, который качает весь день, упирается в свой предел на вход гораздо раньше, чем шлюз начнёт потеть. Запишите направление и охват туннеля рядом с каждой позицией, потому что шлюз только с частными адресатами и шлюз со всем интернет-трафиком — две разные задачи подбора.
Добавьте фоновую нагрузку отдельной строкой: обновления клиентов, телеметрия и всё, что делает хост помимо пересылки. Эти байты легко забыть, и их считает тот же интерфейс.
Найдите ресурс, который заканчивается раньше канала
Канал — лишь один кандидат. Крипторабота одного туннеля может занять одно ядро, пока интерфейс простаивает наполовину, а переполненная очередь может сделать звонки непригодными при пропускной способности, которая на графике выглядит посредственно. Адресат в одной медленной маршрутной доступности тоже может выглядеть как слабость шлюза с места клиента. Три наблюдения разделяют эти случаи, и ни одному не нужен тест всплеском.
| Observation | What to inspect |
|---|---|
| one core busy, bytes steady | per-core CPU, implementation, offload status |
| calls degrade during transfers | queueing and the access link |
| one remote destination slow | that route and its service |
Измеряйте передачей, которую вам разрешено запускать, и добавляйте одновременную работу шагами, а не всю сразу. Читайте устойчивую скорость и интерактивный отклик вместе, потому что тест только пиковой скорости скрывает сеанс, ставший непригодным. Шлюз, проходящий свою максимальную пропускную способность при разваливающихся звонках, тест не прошёл.
Затем повторите прогон с остановленными необязательными нагрузками. Предел, который смещается при остановке резервной копии, никогда не был пределом шлюза.
Превратите сравнение в число, которое можно защитить
Выберите исчерпанный ресурс и выразите требование в его единицах: ядра при целевой загрузке в пиковый час, биты в секунду в каждом направлении или одновременные сеансы ниже границы задержки. Оставьте запас на обновления, диагностику и восстановление, потому что сервер на измеренном потолке ничего не оставляет для работы, которая держит его в строю. Затем запишите числа рядом с конфигурацией, которая их дала, включая число клиентов и использованный тест.
Число пользователей на ядро — наименее переносимое число в этом упражнении, потому что оно предполагает смесь протоколов и профиль устройств, которых следующая площадка не разделяет. Сохраните измерение и откажитесь от формулы. Когда кто-то просит ёмкость ещё для пятидесяти пользователей, честный ответ — пиковый профиль этих пятидесяти, а не умножение.
Записывайте время отклика вместе с пропускной способностью. Ёмкость, сохраняющая только массовую передачу, — не ёмкость для людей в звонках, и следующая проверка спросит о разнице.
Выберите между масштабированием вверх и разделением роли
Когда измеренный предел — одно ядро, больше ядер на той же частоте может не помочь; помочь может более быстрое ядро или другая модель обработчиков. Когда предел — суммарный процессор, прямой ответ — более крупный экземпляр. Когда предел — канал доступа, никакие изменения сервера не помогают, и сравнение заканчивается у провайдера. Разделение веб- и VPN-ролей на отдельные хосты покупает изоляцию ценой второй поверхности управления.
Сравнивайте эти варианты с записанным числом, а не между собой. Изменение, удваивающее ресурс, который не был ограничением, — это затраты без пользы, и именно запись позволяет сказать это без спора. Измерьте заново после изменения с той же нагрузкой, иначе вы заменили одну догадку другой.