IP-Балансировка: объединяем несколько интернет-каналов в один
Содержание
Цели и средства
Способ 1
Способ 2
Этот набор команд обеспечивает маршрутизацию ответов через интерфейс, на котором был получен запрос, а так же маскарадинг на обоих интерфейсах.
Работу канала проверяем пингуя шлюз, и если нет ответа на 3 пинга подряд — мы считаем, что канал упал, и соответственно исключаем его из таблицы маршрутизации.Таким образом, если работают оба канала:
Итого имеем два шлюза, первый с весом 2 и второй с весом 1. Тоесть через первый канал пойдет в два раза больше трафика, чем через второй.Для того, чтобы изменить эти скрипты под ваши нужды необходимо настроить значения в файле vars, остальные скрипты практически не требуют настройки.
Способ 3
В следующем примере понадобится пропатченное ядро Linux с поддержкой ROUTE и модулей nth или random.Эти модули предоставляются пакетом patch-o-matic-ng,который нужно скачать с репозитория subversion .О том,как пропатчить ядро и установить требуемый пакет,смотрите прилагающуюся документацию к нему.
Установка
В следующем примере будем считать,что имеется три разных интефейса:
Мы будем использовать connmark для привязки соединений к конкретному интерфейсу,чтобы определённые пакеты были жёстко привязаны к интерфейсу и шли только через него.Балансировка может быть сделана с помощью модуля nth ,а также random.Мы рассмотрим оба случая,Вы выбирайте тот,который вам больше нравится.
Комбинированная балансировка нагрузки интернет-каналов
Предистория
Рано или поздно системный администратор сталкивается с необходимостью распределить трафик по нескольким каналам, при этом естественно желание чтобы каждый канал использовался по максимуму. Столкнувшись с подобной необходимостью, и решив не изобретать велосипед, обратился к помощи поисковиков. Так как сервер у меня на Ubuntu, то обратил свое внимание на статью http://help.ubuntu.ru/wiki/ip_balancing. Реализовал «Способ 1», но при тесте были замечены следующие критичные проблемы: при использовании ссылок на некоторых сайтах они не открывались (например при попытке включить музыку на ресурсе «ВКонтакте»). Причина очевидна — запрос шел через другой канал. Обдумав ситуацию, решил скомбинировать подход к балансировке. Логика проста — больше всего съедает трафика торренты и им подобные программы, поэтому разделяем трафик. В итоге трафик с портами до 11000 распределяем приблизительно равномерно по количеству абонентов — подсетями, трафиком с портами 11000-60000 выравниваем загрузку каналов.
Настройки
Предполагается что созданы таблицы маршрутизации для каждого из каналов, назовем их chan1, chan2, chan3 — три канала соответственно.
Где-нибудь, например в /etc/rc.local добавляем что-то вроде:
Создаем скрипт /etc/rc.balance:
Создаем список распределения сеток по каналам (во второй колонке — марка):
Скрипт /etc/rc.baltor — правила балансировки:
Скрипт /etc/rc.cnload — расчет вероятности в зависимости от загрузки канала:
Добавляем в /etc/rc.local
Важно, чтобы на момент старта уже существовал файл с коэффициентами /etc/rc.cnload.lst, его можно составить запуском скрипта /etc/rc.cnload.
Заключение
Данный метод упешно реализован в сети с 8000 абонентами. Кроме балансировки используется динамический шейпинг, но это уже тема для другой статьи.
Linux балансировка два канала
Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. + 7 499 704 2566 
Балансировка и резервирование каналов
При желании можно решить почти любую задачу, в том числе резервирование каналов в интернет. Сложнее сделать выбор применяемой технологии. Реализация IP в любой операционной системе не идет ни в какое сравнение с реализацией этого протокола в Linux. Рассмотрим пакет iproute2, используемый в Linux, обеспечивающий возможность указывать несколько шлюзов по умолчанию с разными метриками, и решающий многие проблемы эффективного использования нескольких внешних каналов гораздо элегантнее.
Справедливости ради надо отметить, что данное решение можно реализовать и другими средствами( ipfw на FreeBSD,и sla и др. в cisco) , но вот так — одной командой, только на Linux. К стати, просто «гордость берет» за державу и нашего соотечественника Алексея Кузнецова — создавшего данный пакет. Но буду краток, схема:
Создаем две отдельные таблицы маршрутизации для каждого провайдера (isp1,isp2 названия таблиц маршрутизации — произвольно но лучше должны нести смысловую нагрузку — например название провайдера).
- echo 200 isp1 >> /etc/iproute2/rt_tables
- echo 201 isp2 >> /etc/iproute2/rt_tables
Определим политику маршрутизации (RPDB — Routing Policy DataBase, база данных политик маршрутизации, управляющая алгоритмом выбора маршрута) для пакетов пришедших с данного интерфейса( $ip1,$ip2 соответственно ip адреса интерфейсов каждого провайдера):
- ip ru add from $ip1 table isp1
- ip ru add from $ip2 table isp2
И настроим маршрутизацию по умолчанию( $ip1-gw,$ip2-gw соответственно ip адреса шлюзов каждого провайдера):
- ip route add default via $ip1-gw table isp1
- ip route add default via $ip2-gw table isp2
С этого момента мы получаем возможность распределять пакеты по любому признаку (http, www,ftp или промаркировав по своему усмотрению с помощью iptables), и по любому направлению.Но в данной статье, главная цель — балансировка нагрузки! Легким движением руки «брюки превращаются в шорты»:
- ip route add default scope global equalize nexthop via $ip1-gw dev eth-isp1 weight 3 nexthop via $ip2-gw dev eth-isp2 weight 2
При этом загрузка каналов соответственно составит 3:2. Меняем параметр — weight так, как требуется( или по пропускной способности, или по стоимости. ). И наконец немного творческой работы — организация резервирования.Создадим исполняемый файл /home/balanc. И задачу на выполнение с интервалом 5 минут.
- crontab -e
- 0-59/5 * * * * /home/balanc 2 > /dev/null
Для того что бы отслеживать состояние каналов, будем производить определение доступности шлюзов провайдеров (поскольку самым узким местом, все же является «последняя миля», хотя можно отслеживать состояние и по хостам находящимся в сети). Логика работы заключается в следующем:
- отправляем icmp пакеты на шлюзы провайдеров
- анализируем ответ и делаем вывод о доступности сети
- сравниваем предыдущее состояние каналов записанное в файл /home/balconf ( для того, что бы лишний раз не «дергать» маршрутизацию)
- выполняем установку маршрута по умолчанию
2 канала, 2 IP. Балансировка+NAT
Subj.
Снимите с ручника.
Есть подключение к Internet через двух провайдеров (домосеть и stream). Каждый провайдер выдаёт свой IP.
Есть внутренняя сеть.
Есть роутер на Linux 2.4 с 3-мя сетевыми картами:
1. eth0 — внутренняя сеть.
2. eth1 — домосеть
3. eth2 — stream через ADSL-модем в режиме бриджа.
Хочется
1. Обеспечить доступ из в внутренней сети в Internet с равномерным распределением нагрузки на оба канала.
2. Обеспечить доступ из Internet к роутеру.
Не выходит каменный цветок.
Балансировка через маршрутизацию
===<<<
iptables -t nat -A POSTROUTING -o ppp0 -j SNAT —to-source $HOMENET_IP
iptables -t nat -A POSTROUTING -o ppp1 -j SNAT —to-source $STREAM_IP
.
ip rule add from $IP_PPP0 to 0/0 table 101 pref 102
ip rule add from $IP_PPP1 to 0/0 table 102 pref 102
ip route add table 101 via $GW_PPP0
ip route add table 102 via $GW_PPP1
ip route add default scope global \
nexthop via $GW_PPP0 dev ppp0 weight 1 \
nexthop via $GW_PPP1 dev ppp1 weight 1
===>>>
некоторое время работает (
5 минут), но потом рвёт соединения (кэш маршрутов переполняется?).
Балансировку через NAT
===<<<
iptables -t nat -A POSTROUTING -o ppp0 -j SNAT —to-source $HOMENET_IP —to-source $STREAM_IP
===>>>
прикрутить вообще непонятно, т.к. POSTROUTING обрабатывается после маршрутизации и какие маршруты указывать в этом случае — непонятно.
Re: 2 канала, 2 IP. Балансировка+NAT
Дополнение: ppp0 — это PPTP VPN через eth1, ppp1 — это PPPoE через eth2.
Re: 2 канала, 2 IP. Балансировка+NAT
Re: 2 канала, 2 IP. Балансировка+NAT
Re: 2 канала, 2 IP. Балансировка+NAT
Описанная схема НЕ работает, если внутренняя сеть активно общается с Internet’ом. Соединения рвутся.
Re: 2 канала, 2 IP. Балансировка+NAT
Re: 2 канала, 2 IP. Балансировка+NAT
А нужно, чтобы не рвались. 🙂
Я сюда за тем и пришёл.
Ситуация: аська + mldonkey. Второй интенсивно поключается к новым хостам, в результате чего аська отключается через каждые 5-10 минут.
Re: 2 канала, 2 IP. Балансировка+NAT
Re: 2 канала, 2 IP. Балансировка+NAT
А можно узнать какие именно соединения рвутся: транзитные через этот шлюз или соединения с самого шлюза ?
Если транзитные, то они и должны рваться, т.к. пакеты идут «from откуда_попало» и под правила «from $IP_PPP0» и «from $IP_PPP1» естественно не подпадают, поэтому маршрутизируются через default маршрут в таблице main, в котором 2 nexthop-а, т.е. куда попадет — туда и пойдут, вместо того, чтоб идти через прежний канал.
Для предотвращения этого используется CONNMARK (+MARK), которым маркируют соединения, и на основе этих маркировок делают -j ROUTE (или через ip rule) в нужную сторону.
2 RomanU:
> А multipath routing разве по дефолту нормально работает в ванильном ядре? 🙂
Конечно работает. Вопрос в том, что считать «нормальным» 🙂
По-моему балансировка на основе маршрутизации никогда не будет давать нормальную балансировку, что с патчами, что без 🙂
Кстати, может расскажете про механизм работы патчей «http://www.ssi.bg/
ja/#routes" ? Оно раскидывает по каналам пакеты, целые соединения ? Кешируются маршруты, нет ? А то после нескольких прочтений nano.txt я так и не понял 🙂
Re: 2 канала, 2 IP. Балансировка+NAT
кстати, тема уже обсасывалась в форуме на моей памяти раза 3 или 4.
Я уже раза 2 кроме этого отвечал то же самое. Можно было и поиском воспользоваться:)
RomanU (*) (09.09.2005 10:01:54)
Не в упрёк будет сказано, но поиском по форуму АБСОЛЮТНО невозможно пользоваться. Если будет доделан поиск — будет меньше повторений.
И еще я давно советовал в раздел форума linux.org.ru, что б ввели какую-то систему автовсплытия тем из архива. Например, если я таки нашел каким-то чудом интересующую меня тему, увидел неясность и добавил новый пост, то она переносилась бы вверх по списку. Даже если топик был создан в 2002 году.
Re: 2 канала, 2 IP. Балансировка+NAT
Re: 2 канала, 2 IP. Балансировка+NAT
> А можно узнать какие именно соединения рвутся: транзитные через этот шлюз или соединения с самого шлюза ?
> т.е. куда попадет — туда и пойдут, вместо того, чтоб идти через прежний канал.
Не-е-е.
Ядро кеширует маршруты и в следующий раз для того же самого dst_ip использует тот же самый GW.
Поэтому-то вся конструкция работает.
На самом деле сейчас
net/ipv4/route/gc_thresh=1048576
net/ipv4/route/secret_interval=8192
net/ipv4/route/gc_interval=86400
временно помогли, но хочется более «прямого» решения
> Для предотвращения этого используется CONNMARK (+MARK), которым маркируют соединения, и на основе этих маркировок делают -j ROUTE (или через ip rule) в нужную сторону.
А вот за это огромное спасибо! 🙂
man iptables читал, но этот кусок просмотрел.
Бум пробовать.
Re: 2 канала, 2 IP. Балансировка+NAT
> Не-е-е.
> Ядро кеширует маршруты и в следующий раз для того же самого dst_ip использует тот же самый GW.
> Поэтому-то вся конструкция работает.
Так это и ежу понятно 🙂 Оно ж потому у вас и работает некоторое время (5-10 мин), пока маршрут живет в кеше. А когда кеш переполянется или запись устаревает, ядро заново просматривает default маршрут с несколькими nexthop-ами, вот в этот момент как раз и может определиться другой GW, не такой, как раньше, поэтому соединения и рвутся.
Re: 2 канала, 2 IP. Балансировка+NAT
Re: 2 канала, 2 IP. Балансировка+NAT
> Так это и ежу понятно 🙂 Оно ж потому у вас и работает некоторое время (5-10 мин), пока маршрут живет в кеше. А когда кеш переполянется или запись устаревает, ядро заново просматривает default маршрут с несколькими nexthop-ами, вот в этот момент как раз и может определиться другой GW, не такой, как раньше, поэтому соединения и рвутся.
«Так это и ежу понятно» (c) 😉
Описанные выше параметры позволяют кэшу жить намного дольше этих 5-10 минут.
Но с MARK/CONNMARK решение, конечно же, более правильное. Будем внедрять его.