vurd Posted January 13, 2012 Posted January 13, 2012 Подскажите, какие вообще методы можно использовать для решения задачи балансировки на третьем уровне в случае куска ядра сети. Топология приведена на картинке. Задача: требуется равномерно загрузить трафиком весь набор NAT машин, т.е. горизонтальное расширение. Будут ли работать методы ниже или есть еще варианты? 1. PBR 2. iBGP multipath 3. OSPF equal cost balance Вставить ник Quote
Dyr Posted January 13, 2012 Posted January 13, 2012 Будут. Есть ещё варианты расширения самого NAT-пула "маскировкой" единым ip-адресом - BSD'шный CARP или Linux'овый ipvs, если правильно помню. Вставить ник Quote
vurd Posted January 13, 2012 Author Posted January 13, 2012 На текущий момент у меня настроено PBR, но это проблема для CPU коммутатора. Я так понимаю есть еще один вариант 4. VRF. Может быть еще что-нибудь? По идеи carp\vrrp дает горячее резервирование, но не балансировку. Вставить ник Quote
Dyr Posted January 13, 2012 Posted January 13, 2012 По-моему, VRF ещё более ресурсоёмкий, но может, я и ошибаюсь. CARP умеет работать в режиме балансировки: net.inet.carp.arpbalance Balance local network traffic using ARP. Disabled by default. Вставить ник Quote
st_re Posted January 13, 2012 Posted January 13, 2012 Для клиентов за рутером сие (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 натилок, в зависимости от их производительности и требуемой нагрузки. Вылетание одного из пары нат серверов не критично. (обоих - конечно критично). Выдергивание питания из нат сервера сессий не рвет, небольшая заминка при переползании на резерв и все льется далее. Вставить ник Quote
Dyr Posted January 13, 2012 Posted January 13, 2012 Я так же делал, только без балансировки клиентов, тупо failover-конфигурацию. Потом стало жалко простаивающего сервера. Сейчас хотим сделать одну схемку с OSPF и BFD через сервера, должно получится быстро, просто, правда ценой разрыва сессий (заодно уйти от pf на ng_nat). Вставить ник Quote
Stak Posted January 13, 2012 Posted January 13, 2012 В вариантах 2. iBGP multipath 3. OSPF equal cost balance есть проблема - сессии одного и того же абонента попадут на разные НАТы, что вызовет перерасход адресов из пулов. Но если у вас РАТ - то не критично. Вставить ник Quote
ingress Posted January 13, 2012 Posted January 13, 2012 что вызовет перерасход адресов из пулов очень небольшая проблема по сравнению с отсутствием address pairing. Вставить ник Quote
Dyr Posted January 13, 2012 Posted January 13, 2012 OSPF ECMP, насколько я помню, раскидывает не по round-robin, а по хэшу, который в простейшем случае может состоять из src-адреса. Надо проверить. Вставить ник Quote
Alex/AT Posted January 13, 2012 Posted January 13, 2012 (edited) Для указанной схемы SLB с привязкой по source ip вполне неплохо будет работать, если L3 Core - Cisco, и поддерживает SLB. Как раз можно осуществить равномерную балансировку, + детект отвала одного из NAT серверов. multipath'ы для такой балансировки не предназначены, и работать с NAT-серверами нормально будут вряд ли (из практики - не работают), в реальности у CEF иногда происходят пертурбации таблиц распределения трафика, в итоге пакетики сессий улетят на сервер, который о них не знает. Да и с другим железом будет то же самое: кеш маршрутов - он и есть кеш, и гарантии того, что пакеты для пары ip-ip _всегда_ будут лететь по одному маршруту - multipath не даёт. ну и как вариант, если SLB не слепить - pbr либо по внешним /8, либо по внутренним подсетям. либо VRF (меньше нагрузка, жестче привязка к направлению, легче сделать sla-мониторинг) не совсем равномерно, но лучше, чем ничего, если других вариантов нет. при этом обязательно городить sla-мониторинг на случай затыка одного из серверов Edited January 13, 2012 by Alex/AT Вставить ник Quote
Dyr Posted January 13, 2012 Posted January 13, 2012 Мы прикинули, лучше всего будет работать гибридная схема PBR + OSPF с разными метриками для разных сетей и BFD для обнаружения отвала NAT'а. Вставить ник Quote
Alex/AT Posted January 13, 2012 Posted January 13, 2012 (edited) В принципе, вариант. Но если есть SLB - лучше посмотрите в сторону SLB - это действительно правильное с точки зрения системности подхода решение, в случае, если L3 Core = Cisco. Edited January 13, 2012 by Alex/AT Вставить ник Quote
pfexec Posted January 13, 2012 Posted January 13, 2012 eqmp сделать и на натах синхронизацию трансляций, у pf - это pfsync. и ок. Вставить ник Quote
Alex/AT Posted January 13, 2012 Posted January 13, 2012 eqmp сделать и на натах синхронизацию трансляций, у pf - это pfsync. и ок. для небольших масштабов - тоже вполне вариант. тут уже смотря сколько трансляций. если по полмиллиона на сервер - исход очевиден Вставить ник Quote
Dyr Posted January 13, 2012 Posted January 13, 2012 SLB есть и у Juniper: Using MX Series as a Server Load Balancer (pdf). eqmp сделать Вы хотели сказать, ECMP? pfsync на больших количествах сессий ведёт себя плохо. Во FreeBSD pfsync не регулируется никак (ну если только в сырцы не залезать), фигачит мелкими пакетами и начинает тем самым сам по себе генерировать абсолютно ненужную нагрузку даже на выделенном интерфейсе с jumbo frames. Вставить ник Quote
Alex/AT Posted January 13, 2012 Posted January 13, 2012 (edited) У Juniper SLB не трогал, к сожалению :) Если оно может режим firewall balancing + привязку по source ip - тоже оптимальный вариант. Edited January 13, 2012 by Alex/AT Вставить ник Quote
Dyr Posted January 13, 2012 Posted January 13, 2012 Я тоже не трогал, но оно есть :D У меня как раз MX-серия, так что близко. Вставить ник Quote
Alex/AT Posted January 13, 2012 Posted January 13, 2012 (edited) Попробуйте. Очень вероятно, что окажется для вашей схемы оптимальным - не придётся заморачиваться с ручным выкручиванием метрик, маршрутизации и мониторинга. + масштабируемость по числу машин автоматическая (ну, я опять же по случаю с Cisco сужу) - добавить одну / убрать одну - на лету, и без приключений (в случае "убрать", правда, сессии, привязанные к конкретной машине, порвутся, но это неизбежно). Edited January 13, 2012 by Alex/AT Вставить ник Quote
vurd Posted January 13, 2012 Author Posted January 13, 2012 Так. Обломался с BGP, VRF, PBR и с SLB. Потому как - D-Link 3610. Остался вариант с OSPF, никто не покажет примерчик? Вставить ник Quote
Dyr Posted January 13, 2012 Posted January 13, 2012 (edited) 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 January 13, 2012 by Dyr Вставить ник Quote
vurd Posted January 13, 2012 Author Posted January 13, 2012 Как LACP поможет раскидать трафик на разные машины? Никак. PBR больше не хочется. Хочется нормальный динамический балансинг. Это не 3627\12 серия, это 3610 там даже BGP более менее нормально работает. Вставить ник Quote
Dyr Posted January 13, 2012 Posted January 13, 2012 Как LACP поможет раскидать трафик на разные машины? Никак. Эм... Один канал включаете в один сервер, другой в другой. Поднимаете LACP с обеих сторон и наслаждаетесь раскидыванием трафика. Хочется нормальный динамический балансинг. И на ёлку влезть, и...ну, вы в курсе. ;) Все возможные варианты вам уже описали. Вставить ник Quote
Alex/AT Posted January 13, 2012 Posted January 13, 2012 (edited) LACP? Между разными NAT-серверами-то? Бр-р... С OSPF всё просто - тупо анонсируете все /8 сети глобалнета с каждого из NAT-серверов. На одном половину сетей делаете с метрикой 10, вторую - 20 (к примеру). На втором - аналогично, но метрики разворачиваете наоборот. Если есть третий и более сервер - выберите для каждого сервера приоритетную треть сетей, поставьте ей приоритетную метрику на каждом из серверов, а "неприоритетным" сетям метрики ставьте рандомно из списка оставшихся неприоритетных метрик - это поможет в случае падения "приоритетного" сервера более-менее рандомно раскидать сети по остальным серверам группы. Да - это тупой и неравномерный метод балансировки. Но работать будет. Поигравшись "половинами" сетей (группируя так и эдак) можно добиться более-менее равномерной балансировки, тут даже лучше собрать статистику, сколько трафа вышло в каждую /8, допустим, за день, и аккуратно потом разбить ~250 сетей "пополам" или на N частей (N = число серверов) по трафику. Edited January 13, 2012 by Alex/AT Вставить ник Quote
caz Posted January 13, 2012 Posted January 13, 2012 Можно сделать на 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ов легко потянет. Вставить ник Quote
Alex/AT Posted January 13, 2012 Posted January 13, 2012 (edited) Если не ошибаюсь - из постов выше, у автора L3 Core - 3610, а балансировку надо делать именно там. На Supxxx проще сделать SLB. Edited January 13, 2012 by Alex/AT Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.