Jump to content
Калькуляторы

Методы L3 балансировки двух и более каналов

Подскажите, какие вообще методы можно использовать для решения задачи балансировки на третьем уровне в случае куска ядра сети. Топология приведена на картинке.

 

Задача: требуется равномерно загрузить трафиком весь набор NAT машин, т.е. горизонтальное расширение.

 

Будут ли работать методы ниже или есть еще варианты?

1. PBR

2. iBGP multipath

3. OSPF equal cost balance

 

balance_for_nag.png

Share this post


Link to post
Share on other sites

Будут.

 

Есть ещё варианты расширения самого NAT-пула "маскировкой" единым ip-адресом - BSD'шный CARP или Linux'овый ipvs, если правильно помню.

 

 

Share this post


Link to post
Share on other sites

На текущий момент у меня настроено PBR, но это проблема для CPU коммутатора. Я так понимаю есть еще один вариант

4. VRF.

 

Может быть еще что-нибудь?

 

По идеи carp\vrrp дает горячее резервирование, но не балансировку.

Share this post


Link to post
Share on other sites

По-моему, VRF ещё более ресурсоёмкий, но может, я и ошибаюсь.

 

CARP умеет работать в режиме балансировки:

 

 

 

Share this post


Link to post
Share on other sites

Для клиентов за рутером сие (arpbalance) не канает, ибо на рутере будет 1 запись в арп таблице..

 

Я ставил 2 ната, по 2 набора карпов на каждом :

router 1: carp1 вес 10, carp2 вес 100

router 2: carp1 вес 100, carp2 вес 10

 

Соответственно при нормальном состоянии на каждом по 1 карпу мастер и 1 слейв. Полегании одного из низ оба карпа оказываются MASTER на втором и трафик уползает туда.

 

Балансировка путем распихиванием трафика от клиентов по IPшникам от carp1 и carp2.

 

натил через pf с pfsync. внешние адреса тоже через carp разнесены по серверам. соответственно ставилось 2, 4,...2*n натилок, в зависимости от их производительности и требуемой нагрузки. Вылетание одного из пары нат серверов не критично. (обоих - конечно критично). Выдергивание питания из нат сервера сессий не рвет, небольшая заминка при переползании на резерв и все льется далее.

Share this post


Link to post
Share on other sites

Я так же делал, только без балансировки клиентов, тупо failover-конфигурацию. Потом стало жалко простаивающего сервера. Сейчас хотим сделать одну схемку с OSPF и BFD через сервера, должно получится быстро, просто, правда ценой разрыва сессий (заодно уйти от pf на ng_nat).

Share this post


Link to post
Share on other sites

В вариантах

2. iBGP multipath

3. OSPF equal cost balance

есть проблема - сессии одного и того же абонента попадут на разные НАТы, что вызовет перерасход адресов из пулов. Но если у вас РАТ - то не критично.

Share this post


Link to post
Share on other sites

что вызовет перерасход адресов из пулов

 

очень небольшая проблема по сравнению с отсутствием address pairing.

Share this post


Link to post
Share on other sites

OSPF ECMP, насколько я помню, раскидывает не по round-robin, а по хэшу, который в простейшем случае может состоять из src-адреса. Надо проверить.

Share this post


Link to post
Share on other sites

Для указанной схемы SLB с привязкой по source ip вполне неплохо будет работать, если L3 Core - Cisco, и поддерживает SLB. Как раз можно осуществить равномерную балансировку, + детект отвала одного из NAT серверов.

 

multipath'ы для такой балансировки не предназначены, и работать с NAT-серверами нормально будут вряд ли (из практики - не работают), в реальности у CEF иногда происходят пертурбации таблиц распределения трафика, в итоге пакетики сессий улетят на сервер, который о них не знает. Да и с другим железом будет то же самое: кеш маршрутов - он и есть кеш, и гарантии того, что пакеты для пары ip-ip _всегда_ будут лететь по одному маршруту - multipath не даёт.

 

ну и как вариант, если SLB не слепить - pbr либо по внешним /8, либо по внутренним подсетям. либо VRF (меньше нагрузка, жестче привязка к направлению, легче сделать sla-мониторинг) не совсем равномерно, но лучше, чем ничего, если других вариантов нет. при этом обязательно городить sla-мониторинг на случай затыка одного из серверов

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Мы прикинули, лучше всего будет работать гибридная схема PBR + OSPF с разными метриками для разных сетей и BFD для обнаружения отвала NAT'а. 

Share this post


Link to post
Share on other sites

В принципе, вариант.

 

Но если есть SLB - лучше посмотрите в сторону SLB - это действительно правильное с точки зрения системности подхода решение, в случае, если L3 Core = Cisco.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

eqmp сделать и на натах синхронизацию трансляций, у pf - это pfsync. и ок.

Share this post


Link to post
Share on other sites
eqmp сделать и на натах синхронизацию трансляций, у pf - это pfsync. и ок.

для небольших масштабов - тоже вполне вариант. тут уже смотря сколько трансляций. если по полмиллиона на сервер - исход очевиден

Share this post


Link to post
Share on other sites

SLB есть и у Juniper: Using MX Series as a Server Load Balancer (pdf).

 

eqmp сделать

 

Вы хотели сказать, ECMP?

 

pfsync на больших количествах сессий ведёт себя плохо. Во FreeBSD pfsync не регулируется никак (ну если только в сырцы не залезать), фигачит мелкими пакетами и начинает тем самым сам по себе генерировать абсолютно ненужную нагрузку даже на выделенном интерфейсе с jumbo frames.

 

 

Share this post


Link to post
Share on other sites

У Juniper SLB не трогал, к сожалению :) Если оно может режим firewall balancing + привязку по source ip - тоже оптимальный вариант.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Я тоже не трогал, но оно есть :D У меня как раз MX-серия, так что близко.

Share this post


Link to post
Share on other sites

Попробуйте. Очень вероятно, что окажется для вашей схемы оптимальным - не придётся заморачиваться с ручным выкручиванием метрик, маршрутизации и мониторинга. + масштабируемость по числу машин автоматическая (ну, я опять же по случаю с Cisco сужу) - добавить одну / убрать одну - на лету, и без приключений (в случае "убрать", правда, сессии, привязанные к конкретной машине, порвутся, но это неизбежно).

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Так. Обломался с BGP, VRF, PBR и с SLB. Потому как - D-Link 3610.

Остался вариант с OSPF, никто не покажет примерчик?

Share this post


Link to post
Share on other sites

36 серия, конкретно 3627G, умеет PBR. BGP, кстати, тоже, но лучше не стоит. :)

 

И кстати, забыли ещё один вариант распределения трафика - на основе LACP, тем более что DGS-3610 умеет раскидывать трафик в LACP в том числе и только на основе source ip.

 

 

 

 

 

...

 

Агрегирование каналов 802.3ad (LACP):

- 12 групп, макс. до 8 портов GE или 2 10GE порта в каждой группе.

- Механизм рапределения нагрузки: SMAC / DMAC / SMAC+DMAC / SIP / DIP / SIP+DIP

 

...

 

Поддержка ECMP: макс. 32 маршрута

Поддержка WCMP: макс. 8 маршрутов

 

...

 

Маршрутизация на основе политик: до 895 маршрутов (на основе VID, SIP, TCP/UDP Port, next hop IP)

Edited by Dyr

Share this post


Link to post
Share on other sites

Как LACP поможет раскидать трафик на разные машины? Никак.

PBR больше не хочется. Хочется нормальный динамический балансинг.

 

Это не 3627\12 серия, это 3610 там даже BGP более менее нормально работает.

Share this post


Link to post
Share on other sites
Как LACP поможет раскидать трафик на разные машины? Никак.

 

Эм... Один канал включаете в один сервер, другой в другой. Поднимаете LACP с обеих сторон и наслаждаетесь раскидыванием трафика.

 

Хочется нормальный динамический балансинг.

 

И на ёлку влезть, и...ну, вы в курсе. ;) Все возможные варианты вам уже описали.

 

 

Share this post


Link to post
Share on other sites

LACP? Между разными NAT-серверами-то? Бр-р...

 

С OSPF всё просто - тупо анонсируете все /8 сети глобалнета с каждого из NAT-серверов. На одном половину сетей делаете с метрикой 10, вторую - 20 (к примеру). На втором - аналогично, но метрики разворачиваете наоборот.

 

Если есть третий и более сервер - выберите для каждого сервера приоритетную треть сетей, поставьте ей приоритетную метрику на каждом из серверов, а "неприоритетным" сетям метрики ставьте рандомно из списка оставшихся неприоритетных метрик - это поможет в случае падения "приоритетного" сервера более-менее рандомно раскидать сети по остальным серверам группы.

 

Да - это тупой и неравномерный метод балансировки. Но работать будет. Поигравшись "половинами" сетей (группируя так и эдак) можно добиться более-менее равномерной балансировки, тут даже лучше собрать статистику, сколько трафа вышло в каждую /8, допустим, за день, и аккуратно потом разбить ~250 сетей "пополам" или на N частей (N = число серверов) по трафику.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Можно сделать на PBR с костылем резервированием на cisco sup2/sup32/sup720 и т.д., сам route-map выглядит приблизительно так

route-map  33 permit  20 
match ip address  nat_№
set ip next-hop 1.1.1.1 2.2.2.2 3.3.3.3

 

по умолчанию трафик идет на 1.1.1.1, запускаем на каком-нибудь сервере, по крону раз в минуту какой-нибудь скрипт, который будет пинговать или еще как мониторить доступность NAT и если что с ним не так, то отключать порт с интерфейсом 1.1.1.1, после отключения. трафик начинает идти на 2.2.2.2

 

такой вариант работал с 11 NAT, но и 20 NATов легко потянет.

Share this post


Link to post
Share on other sites

Если не ошибаюсь - из постов выше, у автора L3 Core - 3610, а балансировку надо делать именно там.

 

На Supxxx проще сделать SLB.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this