URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 59438
[ Назад ]
Исходное сообщение
"load-sharing на двух неодинаковых каналах"
Отправлено sync , 24-Авг-05 12:46 
   Доброго дня!
   Вот возникла задачка: есть два офиса, сетки оных соеденены двумя каналами - 10 мегабит по оптике и 2-а мегабита по радио, с каждой стороны стоит по линуксовой машинке с тремя сетевухами:
           /--- 10 Mb ---\
lan1 - lnx1               lnx2 - lan2
           \--- 2 Mb  ---/

   Пока все работает по следующему принципу: по умолчанию используется "толстый " канал, если он "падает" - все идет по "тонкому". Как только "толстый" поднимается - он опять становиться "по умолчанию".

   Хочется следующего: всвязи с тем, что на толстом канале провайдер считает трафф необходимо "объеденить" два канала по следующему принципу - сначала весь трафф загоняем в "тонкий" канал, как только его загрузка достигнет максимума - все превышение пихаем в "толстый".
   Понимаю, что копать надо в сторну LARTC - я даже нашел (http://lartc.org/howto/lartc.loadshare.html) похожий случай, но там рассматривается просто load sharing на многих интерфейсах.

Господа, если кто-то что-то подобное делал (или видел где описалово, как это делать) - не сочтите за труд, поделитесь.

Содержание
Сообщения в этом обсуждении
"load-sharing на двух неодинаковых каналах"
Отправлено Z0termaNN , 24-Авг-05 13:57 
вообще-то добится балансировки загрузки, особенно не заморачиваясь
можно как минимум 4 способами:
1. ip route с весовыми коэффициентами
2. ip route + fw mark + iptables
3. teql
4. bonding

bonding и teql достаточно хорошо описаны в
/usr/src/linux../Documentaion/networking.

хотя eql и вешается на практически любые типы интерфейсов, однако при нем
достаточно затруднительно управлять приоритизацией трафика, т.к. на всех
slave интерфейсах queue discipline eql единственный возможный вариант,
который нельзя изменить.

bonding сажается исключительно на ethernet или tap.

кроме того, управлять ты сможешь только исходящими пакетами, т.е. если
у тебя активный входящий трафик на одном из интерфейсов, то на исходящий
трафик при балансировке это никак не повлияет (за исключением некоторых
режимов bonding).

так что в твоем случае остается только iproute + fwmark + iptables.
достигается это примерно так:

1. мониторим среднюю исходящую загрузку на основном интерфейсе и если она
превышает некий предел, то маркируем пакеты (средний размер пакета и
количество паектов при макс загрузке сам вычислишь):
iptables -t mangle --insert PREROUTING|FORWARD ..... -m limit ! --limit pps --jump MARK --set-mark 0x11
2. делаем routing
cat >> /etc/iproute2/rt_tables <<EOF
200  secondary_iface
EOF
ip rule add fwmark 0x11 pref 200 table secondary_iface
ip route add 0/0 dev eth2 table secondary_iface

3. делаем такую же хрень и сдругой стороны

"load-sharing на двух неодинаковых каналах"
Отправлено sync , 24-Авг-05 14:16 
>вообще-то добится балансировки загрузки, особенно не заморачиваясь
>можно как минимум 4 способами:
>1. ip route с весовыми коэффициентами
>2. ip route + fw mark + iptables
>3. teql
>4. bonding
>
>bonding и teql достаточно хорошо описаны в
>/usr/src/linux../Documentaion/networking.
>
>хотя eql и вешается на практически любые типы интерфейсов, однако при нем
>
>достаточно затруднительно управлять приоритизацией трафика, т.к. на всех
>slave интерфейсах queue discipline eql единственный возможный вариант,
>который нельзя изменить.
>
>bonding сажается исключительно на ethernet или tap.

в данном случае bonding не получиться - там failover завязан на физику, а тут с этим проблемы - сетевухи-то не соеденены напрямую кроссом, а включены в провайдерские модемы или маршрутизаторы

>
>кроме того, управлять ты сможешь только исходящими пакетами, т.е. если
>у тебя активный входящий трафик на одном из интерфейсов, то на исходящий
>
>трафик при балансировке это никак не повлияет (за исключением некоторых
>режимов bonding).
>
>так что в твоем случае остается только iproute + fwmark + iptables.

полностью согласен

>
>достигается это примерно так:
>
>1. мониторим среднюю исходящую загрузку на основном интерфейсе и если она
>превышает некий предел, то маркируем пакеты (средний размер пакета и
>количество паектов при макс загрузке сам вычислишь):
>iptables -t mangle --insert PREROUTING|FORWARD ..... -m limit ! --limit pps --jump
>MARK --set-mark 0x11
>2. делаем routing
>cat >> /etc/iproute2/rt_tables <<EOF
>200  secondary_iface
>EOF
>ip rule add fwmark 0x11 pref 200 table secondary_iface
>ip route add 0/0 dev eth2 table secondary_iface
>
>3. делаем такую же хрень и сдругой стороны

с этим все ясно
а как быть с failover, в случае падения одного из интерфейсов? замечу - не физическом падении (линк-то будет, а вот пакеты ходить не будут)

"load-sharing на двух неодинаковых каналах"
Отправлено Z0termaNN , 24-Авг-05 14:31 

>в данном случае bonding не получиться - там failover завязан на физику,
>а тут с этим проблемы - сетевухи-то не соеденены напрямую кроссом,
>а включены в провайдерские модемы или маршрутизаторы

не факт, в bonding есть возможность мониторинга не только физического
линка, но и доступности по arp, так что если arp гуляет по каналу, то
проблем нет.
>
>а как быть с failover, в случае падения одного из интерфейсов? замечу
>- не физическом падении (линк-то будет, а вот пакеты ходить не
>будут)

как раз с этим в линуксе больите проблемы, и не только в ethernet. Выходом
из такого положения может быть какой-нибудь протокол, который будет
поддерживать обработку событий на интерфейсах (pppoe, openvpn и пр.)


"load-sharing на двух неодинаковых каналах"
Отправлено sync , 24-Авг-05 14:40 
>
>>в данном случае bonding не получиться - там failover завязан на физику,
>>а тут с этим проблемы - сетевухи-то не соеденены напрямую кроссом,
>>а включены в провайдерские модемы или маршрутизаторы
>
>не факт, в bonding есть возможность мониторинга не только физического
>линка, но и доступности по arp, так что если arp гуляет по
>каналу, то
>проблем нет.

как-то не подумал... :-/

>>
>>а как быть с failover, в случае падения одного из интерфейсов? замечу
>>- не физическом падении (линк-то будет, а вот пакеты ходить не
>>будут)
>
>как раз с этим в линуксе больите проблемы, и не только в
>ethernet. Выходом
>из такого положения может быть какой-нибудь протокол, который будет
>поддерживать обработку событий на интерфейсах (pppoe, openvpn и пр.)

да, я как-раз думал навернуть поверх openvpn - но как его на двух интерфейсах делать-то? и как это для iproute2 выглядеть-то будет?

"load-sharing на двух неодинаковых каналах"
Отправлено sync , 24-Авг-05 14:48 
>как раз с этим в линуксе больите проблемы, и не только в
>ethernet. Выходом
>из такого положения может быть какой-нибудь протокол, который будет
>поддерживать обработку событий на интерфейсах (pppoe, openvpn и пр.)

кажись понял
на физические интерфейсы навесить туннели, а уже к ним прикручивать маркировку и роутинг
при этом в конфигах туннелей накрутить проверку "живости" туннеля и, в случае его падения, соответствующие скрипты, например, if_down.sh (а в случае восстановления - if_up.sh), в которые собственно и прописать все правила для iproute2

"load-sharing на двух неодинаковых каналах"
Отправлено Z0termaNN , 24-Авг-05 15:48 
>>как раз с этим в линуксе больите проблемы, и не только в
>>ethernet. Выходом
>>из такого положения может быть какой-нибудь протокол, который будет
>>поддерживать обработку событий на интерфейсах (pppoe, openvpn и пр.)
>
>кажись понял
>на физические интерфейсы навесить туннели, а уже к ним прикручивать маркировку и
>роутинг
>при этом в конфигах туннелей накрутить проверку "живости" туннеля и, в случае
>его падения, соответствующие скрипты, например, if_down.sh (а в случае восстановления -
>if_up.sh), в которые собственно и прописать все правила для iproute2

в случае openvpn проверку живости туннеля делать не нужно, она
регулируется параметрами ping & ping-restart. соответственно скрипты
up & down задаются соответствующими параметрами. однако шифрация все-таки
требует дополнительных накладных расходов, но по современным понятиям
не очень больших. Прикидочно при полной загрузке 12Mbit без компресии
Celeron 1GHZ вролне подойдет.
Хотя pppoe тоже вариант, если шифровать ничего не нужно.

"load-sharing на двух неодинаковых каналах"
Отправлено sync , 24-Авг-05 17:55 
>в случае openvpn проверку живости туннеля делать не нужно, она
>регулируется параметрами ping & ping-restart. соответственно скрипты
>up & down задаются соответствующими параметрами. однако шифрация все-таки
>требует дополнительных накладных расходов, но по современным понятиям
>не очень больших. Прикидочно при полной загрузке 12Mbit без компресии
>Celeron 1GHZ вролне подойдет.
>Хотя pppoe тоже вариант, если шифровать ничего не нужно.

накрутить проверку "живости" - я как раз имел ввиду эти самые ping и ping-restart

опять-же для шифрования можно выбрать алгоритм попроще или совсем его запретить, тем более линукса стоит на машинках с полноценными P4 3.6GHz

единственно, в чем не уверен, как правильно выбрать среднее количество пакетов в секунду (ну и соответственно - усредненную длину пакета) - чем руководствоваться? набрать статистику за сутки? или только за рабочий период?

"load-sharing на двух неодинаковых каналах"
Отправлено Z0termaNN , 25-Авг-05 11:31 
>единственно, в чем не уверен, как правильно выбрать среднее количество пакетов в
>секунду (ну и соответственно - усредненную длину пакета) - чем руководствоваться?
>набрать статистику за сутки? или только за рабочий период?

Средний размер пакета достаточно будет вычислить через статистику ifconfig
путем avgpkt = number-of-bytes / numer-of-packets. Соответственно
rate = interface-speed / avgpkt.
В дальнейшем его можно будет подкорректировать в зависимости от
результатов работы (когда запустишь vpn, не забудь прибавить 40 байт udp
заголовка), но в общем скорость 2Mbit даст вполне репрезентативную
выборку.