Всем привет! На связи Николай Едомский, руководитель группы сетевых инженеров в ЕДИНОМ ЦУПИС.
Представляю вашему вниманию шестую статью из цикла «IPsecHub+».
После обсуждения отказоустойчивости у нас остался один важный вопрос в нашей целепостановке — вопрос масштабирования решения.
Если говорить про IPsec, то вопрос масштабирования весьма важен, особенно если учесть ресурсоемкость шифрования. Под масштабированием мы будем понимать возможность расширить мощности IPsec-концентратора (или группы IPsec-концентраторов) без необходимости значительного изменения топологии.
Подразумевается два вида масштабирования:
Горизонтальное. Мы наращиваем количество IPsec-концентраторов, которые могут обработать трафик до некоего условного объекта. В нашем случае мы расматриваем филиал.
Вериткальное. Мы увеличиваем мощность конкретного IPsec-концентратора.
Я думаю, очевидно, что горизонтальное масштабирование мы будем рассматривать как наиболее желаемый сценарий, так как любое вертикальное масштабирование имеет свой предел. А у горизонтального масштабирования предел обычно значительно шире, хоть он, безусловно, тоже есть. К тому же, вертикальное масштабирование требует так или иначе вывода IPsec-концентратора из экспулатации на время повышения пропускной способности, а если на него завязаны сотни филиалов, то эта процедура может стать весьма трудоемкой.
Важно также сказать, что нам нужно будет масштабировать два направления трафика:
1) из филиала в ЦОД
2) из ЦОД в филиал
Почему мы рассматриваем их отдельно? Потому что, по-первых, филиальный концентратор так же участвует в процессе шифрования и дешифрования и может стать бутылочным горлышком. Во-вторых, процесс дешифрации значительно отличается от процесса зашифровки. Например, почти все решения не поддерживают параллелизацию процесса дешифрации одной сессии (одной SA в терминологии IPsec). Это нужно обязательно учитывать при расчете мощностей своих концентраторов на всех участках сети.
Давайте рассмотрим схемы масштабирования нагрузки при подаче трафика из ЦОД в филиалы.
Подача трафика c ЦОД. VRRP active-active
Эта схема предполагает наличие не одного VRRP-инстанса на одном из IPsec, а двух. При этом на первом инстансе мастером будет первый IPsec‑концентратор, а на втором — второй. При этом нам следует написать ECMP-маршрут на нашем межсетевом экране, где будет указано два шлюза для филиальной суперсети.
Тогда межсетевой экран по принципам ECMP будет балансировать нагрузку между двумя IPsec-концентраторами, а в случае выхода из строя одного из них, его VRRP-инстанс будет перехвачен оставшимся.
Эта схема не сработает, если ваш межсетевой экран не поддерживает ECMP в статических маршрутах. Также она будет очень плохо работать в случае, если межсетевой экран может хешировать ECMP-трафик только L2-функциямии. В этом случае трафик практически не будет балансироваться между IPsec-концентраторами.
Подача трафика c экрана через BGP-прокси
Это более элегантная схема балансировки трафика. Именно ее рекомендуется рассматривать ко внедрению. Она заключается в реализации дополнительного контура нейтральных устройств, находящихся между межсетевым экраном и IPsec-концентраторами. На схеме они представлены Core-коммутаторами. Задача каждого из Core-коммутаторов - организовать BGP-соседство с каждым из существующих IPsec-концентраторов. Это позволит каждому из Core-коммутаторов иметь возможность балансировать трафик между IPsec-концентраторами, предлагающими тот или иной маршрут.
При этом принять трафик на сам Core-контур можно и через уже упомянутую VRRP-группу. Вообще для этого подойдет любой протокол горячего резервирования шлюза (например, HSRP).
Разумеется, выделять отдельные устройства только для того, чтобы корректно балансировать трафик между IPsec-концентраторами, будет весьма расточительно, поэтому предполагается создавать VRF на уже существующих core-коммутаторах.
Давайте теперь рассмотрим схемы масштабирования нагрузки при подаче трафика из филиалов в ЦОД. Подходы здесь в целом будут аналогичны.
Подача трафика c филиала. VRRP-домен.
Здесь все достаточно просто. Если мы хотим смасштабировать ресурсы IPsec-концентратора филиала, то нужно рядом с уже существующим концентратором поставить еще один и создать VRRP-домен для принятия трафика от клиентов. Также мы должны будем связать новый концентратор GRE-туннелями со всеми концентраторами в ЦОД. Тогда входящий в филиал трафик будет балансироваться между всеми IPsec-концентраторами филиала. Сложнее ситуация с балансировкой исходящего трафика. Ввиду того, что VRRP-адрес будет присутствовать только на одном IPsec-концентраторе, только он и будет шифровать трафик. Это ограничение данной схемы можно обойти примерно тем же способом, который был рассмотрен выше. Нам нужно добавить некий балансировочный хост между клиентами и IPsec-концентраторами.
Вот как будет выглядеть такая схема. Трафик непосредственно от клиентской сети филиала сначала принимает некое устройство, например, L3 коммутатор. Далее уже этот коммутатор стыкуется по BGP с двумя IPsec-концентраторами филиала, каждый из которых имеет свои туннели до контура IPsec-концентраторов в ЦОД.
Такой подход позволит построить очень гибкую схему, где и в филиалах, и в ЦОД мы можем горизонтально наращивать значительное количество IPsec-концентраторов. Это количество ограничено максиумом ECMP-маршрутов на устройствах уровня Core.
При этом еще раз напомню, что равномерность загрузки между IPsec-концентраторами будет зависет от хеш-функции, которую использует core-устройство. Конечно, наилучший вариант будет использовать так называемый консистентный хэш. Если устройство его не поддерживает, то подойдет и L4 + L3 функция. Но тут еще следует учесть характер нагрузки. Если она представляет собой множество L4-сессий, то консистентный хеш необязателен. А если присутствует ограниченное количество тяжеловесных L3-сессий, идущих на один адрес в ЦОД, то тут уже без консистентного хэширования не обойтись.
Итоги
Давайте подведем итог этой итерации построения нашей схемы. Какие требования к нашей топологии мы выполнили в этот раз?
трафик между филиалами должен проходить через централизованный межсетвой экран.Шифрованный трафик между ЦОД и филиалами должен проходить через централизованный межсетвой экран.Туннели должны терминироваться на одном IPsec-концентраторе.Решение должно быть технически гибким и приземлять различные типы туннелей в различных конфигурациях (VTI, GRE…).Решение должно быть гибким управляемым.Решение должно поддерживать динамическую маршрутизацию.Решение не должно вовлекать межсетевой экран в динамическую маршрутизацию.Решение должно быть отказоустойчивым.Решение не должно быть проприетарным.Мы увидели, что все решения, примененные в нашем концентраторе, не имеют привязки к одному вендору. Любая технология присутствует как минимум в современных ядрах Linux. Можем считать, что это требование мы закрыли.
Решение дожно быть масштабирумым.Мы обсудили вопросы масштабирования и представили способы горизонтального наращивания пропускной способности нашего концентратора. Разумеется, у рассмотренного способа масштабирования есть свои ограничения и особенности, но глобальную задачу мы достигли - наш концентратор может считаться горизонтально масштабируемым решением.
Вместо послесловия
Уважаемые коллеги, на этом теоретический цикл статей завершен. Мы построили дизайн решения, которое не только отвечает всем изначально поставленным требованиям, но и обладает потенциалом для решения намного более сложных задач, чем те, которые мы с вами рассмотрели в этом цикле. Особенно хотелось бы отметить универсальность этого дизайна и его многовендорность. В сложной политической обстановке наших дней этот фактор может стать решающим. От себя могу добавить, что этот дизайн был опробован на платформах таких вендоров как Eltex, Juniper, ну и на классическом Linux маршрутизаторе.
Следующая статья будет представлять собой практикум, где мы шаг за шагом рассмотрим, как настраивается тот или иной элемент нашего дизайна. Вы сможете повторить эти шаги и собственноручно протестировать все представленные в цикле решения.
Спасибо за внимание, и до новых встреч!
Навигация по циклу:
