Масштабуйте сесії 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

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

Відпрацюйте втрату один раз навмисно, поза робочим часом, і запишіть, що повідомляють учасники, які вижили, поки це відбувається. Учасник, який приймає перенаправлення, але не має місця в пулі, виявляється як невдале виділення, чого додаткова пропускна здатність ніколи не виправить. Збережіть перевірені цифри з датою поруч із планом, щоб наступний огляд ємності починався з доказів, а не з таблиці ліцензій. Додайте результат цього відпрацювання на ту саму сторінку, навіть коли цифри збігаються з планом.