[vurd]

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

 

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

 

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

1. PBR

2. iBGP multipath

3. OSPF equal cost balance

 

[Dyr]

Будут.

 

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

 

 

[vurd]

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

4. VRF.

 

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

 

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

[Dyr]

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

 

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

 

net.inet.carp.arpbalance Balance local network traffic using ARP. Disabled by default.

 

 

[st_re]

Для клиентов за рутером сие (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 натилок, в зависимости от их производительности и требуемой нагрузки. Вылетание одного из пары нат серверов не критично. (обоих - конечно критично). Выдергивание питания из нат сервера сессий не рвет, небольшая заминка при переползании на резерв и все льется далее.

[Dyr]

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

[Stak]

В вариантах

2. iBGP multipath

3. OSPF equal cost balance

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

[ingress]

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

 

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

[Dyr]

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

[Alex/AT]

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

 

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

 

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

Изменено 13 января, 2012 пользователем Alex/AT

[Dyr]

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

[Alex/AT]

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

 

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

Изменено 13 января, 2012 пользователем Alex/AT

[pfexec]

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

[Alex/AT]

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

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

[Dyr]

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

 

eqmp сделать

 

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

 

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

 

 

[Alex/AT]

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

Изменено 13 января, 2012 пользователем Alex/AT

[Dyr]

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

[Alex/AT]

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

Изменено 13 января, 2012 пользователем Alex/AT

[vurd]

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

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

[Dyr]

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)

Изменено 13 января, 2012 пользователем Dyr

[vurd]

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

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

 

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

[Dyr]

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

 

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

 

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

 

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

 

 

[Alex/AT]

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

 

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

 

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

 

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

Изменено 13 января, 2012 пользователем Alex/AT

[caz]

Можно сделать на 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ов легко потянет.

[Alex/AT]

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

 

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

Изменено 13 января, 2012 пользователем Alex/AT