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