Масштабируйте сессии VPN по роли, затем проверьте запас на случай отказа

Вы добавляете второй шлюз, консоль показывает двух здоровых участников, а потолок сессий почти не меняется, потому что ничто не сказало клиентам, как добраться до нового блока. Масштабирование службы VPN — это два решения подряд: какой механизм распределяет клиентов для этого типа подключения и сколько ёмкости останется после худшей единичной потери. Если взять их в обратном порядке, получится проект, который выглядит избыточным и отказывает ровно тогда, когда он нужен. Начните с консоли, а затем выполните арифметику.

Согласуйте механизм с типом сессии

Удалённые пользователи, партнёры между площадками и постоянно включённые туннели устройств не являются взаимозаменяемыми сессиями. Функция распределения, созданная для одного из них, обычно перенаправляет клиента во время согласования, что ничего не значит для партнёра, у которого уже есть фиксированный адрес и статическая конфигурация.

Руководство Cisco по высокой доступности ASA держит три возможности отдельно: балансировку нагрузки VPN для удалённого доступа, переключение с сохранением состояния и кластеризацию между площадками. Только первая перемещает подходящего клиента из групповой записи на участника, а соединения LAN-в-LAN остаются вне этого распределения. Обычный балансировщик TCP не может заменить собственный шаг перенаправления протокола, потому что рукопожатие туннеля — не простой HTTP, который прокси мог бы переписать. Практический результат — балансировщик, который принимает соединение и всё же не даёт клиенту создать туннель.

Прочитайте список функций применительно к вашему типу сессии, прежде чем заказывать второе устройство. Строка лицензии и строка механизма — отдельные записи, и одна не подразумевает другую.

Посчитайте пример вместо догадок

Предположим, три шлюза проверены каждый на 800 одновременных туннелей при нагрузке, которую вы одобрили, что в сумме даёт 2,400. Цель 1,650 в пиковый час выглядит комфортно, пока не потеряна одна единица, и тогда выжившая пара должна удержать 1,650 против жёстких 1,600. Проект уже провалился, и никакая настройка переключения не исправит арифметику.

Задайте цель так, чтобы выживший набор всё ещё её выполнял, что для группы из трёх участников означает оставаться ниже двух третей общего числа. Это соотношение — свойство арифметики, а не какого-либо продукта, поэтому пересчитывайте его при изменении проверенной цифры участника. Держите лицензированное число, документированный максимум и вашу собственную измеренную цифру в трёх столбцах, потому что они редко совпадают и решает наименьшая. Четвёртый столбец для наблюдаемого пика пикового часа сохраняет план честным после первого месяца.

Заложите запас на волну переподключений, а не только на установившийся режим

Сессии на отказавшем участнике не появляются тихо в другом месте. В зависимости от механизма они переходят с состоянием, заново согласуются с нуля или ждут, когда приложение повторит попытку по своему расписанию.

Несколько тысяч клиентов, повторяющих попытку в течение минуты, — это другое событие, чем стабильные 1,650, и серверы аутентификации чувствуют это первыми. Проверьте также место в пуле, поскольку перенаправление не обращается к нему: участник, который не может выделить адрес, всё равно принимает клиента, а затем сбрасывает его трафик.

Проверьте ёмкость с пулом и маршрутом под рукой

Проверка — это упражнение только для чтения, которое ловит большинство ошибок проектирования до открытия окна обслуживания. Соберите пул по каждому участнику, число активных сессий и маршрут назад к подсети клиента, а затем сравните каждый с планом. Исчерпание пула и отсутствующий обратный маршрут оба выглядят как клиент, который аутентифицируется и затем теряет трафик.

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

Запускайте эти чтения на каждом участнике в обычный пиковый час, а не в тихий. Участник, который сообщает о сессиях, но не имеет свободных адресов, уже на своём практическом пределе, что бы ни говорила лицензия. Запишите версию прошивки рядом с каждым выводом, поскольку имена команд меняются между выпусками.

Отработайте потерю один раз намеренно, вне рабочего времени, и запишите, что сообщают выжившие участники, пока это происходит. Участник, который принимает перенаправление, но не имеет места в пуле, проявляется как неудачное выделение, чего дополнительная пропускная способность никогда не исправит. Сохраните проверенные цифры с датой рядом с планом, чтобы следующий обзор ёмкости начинался с доказательств, а не с таблицы лицензий. Добавьте результат этой отработки на ту же страницу, даже когда цифры совпадают с планом.