форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"load-sharing на двух неодинаковых каналах"
Сообщение от sync (ok) on 24-Авг-05, 12:46  (MSK)
Доброго дня!    Вот возникла задачка: есть два офиса, сетки оных соеденены двумя каналами - 10 мегабит по оптике и 2-а мегабита по радио, с каждой стороны стоит по линуксовой машинке с тремя сетевухами:            /--- 10 Mb ---\ lan1 - lnx1               lnx2 - lan2            \--- 2 Mb  ---/    Пока все работает по следующему принципу: по умолчанию используется "толстый " канал, если он "падает" - все идет по "тонкому". Как только "толстый" поднимается - он опять становиться "по умолчанию".    Хочется следующего: всвязи с тем, что на толстом канале провайдер считает трафф необходимо "объеденить" два канала по следующему принципу - сначала весь трафф загоняем в "тонкий" канал, как только его загрузка достигнет максимума - все превышение пихаем в "толстый".    Понимаю, что копать надо в сторну LARTC - я даже нашел (http://lartc.org/howto/lartc.loadshare.html) похожий случай, но там рассматривается просто load sharing на многих интерфейсах. Господа, если кто-то что-то подобное делал (или видел где описалово, как это делать) - не сочтите за труд, поделитесь.
	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "load-sharing на двух неодинаковых каналах"
Сообщение от Z0termaNN (??) on 24-Авг-05, 13:57  (MSK)
вообще-то добится балансировки загрузки, особенно не заморачиваясь можно как минимум 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. делаем такую же хрень и сдругой стороны
Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "load-sharing на двух неодинаковых каналах"
	Сообщение от sync (ok) on 24-Авг-05, 14:16  (MSK)
	>вообще-то добится балансировки загрузки, особенно не заморачиваясь >можно как минимум 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, в случае падения одного из интерфейсов? замечу - не физическом падении (линк-то будет, а вот пакеты ходить не будут)
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "load-sharing на двух неодинаковых каналах"
	Сообщение от Z0termaNN (??) on 24-Авг-05, 14:31  (MSK)
	>в данном случае bonding не получиться - там failover завязан на физику, >а тут с этим проблемы - сетевухи-то не соеденены напрямую кроссом, >а включены в провайдерские модемы или маршрутизаторы не факт, в bonding есть возможность мониторинга не только физического линка, но и доступности по arp, так что если arp гуляет по каналу, то проблем нет. > >а как быть с failover, в случае падения одного из интерфейсов? замечу >- не физическом падении (линк-то будет, а вот пакеты ходить не >будут) как раз с этим в линуксе больите проблемы, и не только в ethernet. Выходом из такого положения может быть какой-нибудь протокол, который будет поддерживать обработку событий на интерфейсах (pppoe, openvpn и пр.)
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "load-sharing на двух неодинаковых каналах"
	Сообщение от sync (ok) on 24-Авг-05, 14:40  (MSK)
	> >>в данном случае bonding не получиться - там failover завязан на физику, >>а тут с этим проблемы - сетевухи-то не соеденены напрямую кроссом, >>а включены в провайдерские модемы или маршрутизаторы > >не факт, в bonding есть возможность мониторинга не только физического >линка, но и доступности по arp, так что если arp гуляет по >каналу, то >проблем нет. как-то не подумал... :-/ >> >>а как быть с failover, в случае падения одного из интерфейсов? замечу >>- не физическом падении (линк-то будет, а вот пакеты ходить не >>будут) > >как раз с этим в линуксе больите проблемы, и не только в >ethernet. Выходом >из такого положения может быть какой-нибудь протокол, который будет >поддерживать обработку событий на интерфейсах (pppoe, openvpn и пр.) да, я как-раз думал навернуть поверх openvpn - но как его на двух интерфейсах делать-то? и как это для iproute2 выглядеть-то будет?
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "load-sharing на двух неодинаковых каналах"
	Сообщение от sync (ok) on 24-Авг-05, 14:48  (MSK)
	>как раз с этим в линуксе больите проблемы, и не только в >ethernet. Выходом >из такого положения может быть какой-нибудь протокол, который будет >поддерживать обработку событий на интерфейсах (pppoe, openvpn и пр.) кажись понял на физические интерфейсы навесить туннели, а уже к ним прикручивать маркировку и роутинг при этом в конфигах туннелей накрутить проверку "живости" туннеля и, в случае его падения, соответствующие скрипты, например, if_down.sh (а в случае восстановления - if_up.sh), в которые собственно и прописать все правила для iproute2
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "load-sharing на двух неодинаковых каналах"
	Сообщение от Z0termaNN (??) on 24-Авг-05, 15:48  (MSK)
	>>как раз с этим в линуксе больите проблемы, и не только в >>ethernet. Выходом >>из такого положения может быть какой-нибудь протокол, который будет >>поддерживать обработку событий на интерфейсах (pppoe, openvpn и пр.) > >кажись понял >на физические интерфейсы навесить туннели, а уже к ним прикручивать маркировку и >роутинг >при этом в конфигах туннелей накрутить проверку "живости" туннеля и, в случае >его падения, соответствующие скрипты, например, if_down.sh (а в случае восстановления - >if_up.sh), в которые собственно и прописать все правила для iproute2 в случае openvpn проверку живости туннеля делать не нужно, она регулируется параметрами ping & ping-restart. соответственно скрипты up & down задаются соответствующими параметрами. однако шифрация все-таки требует дополнительных накладных расходов, но по современным понятиям не очень больших. Прикидочно при полной загрузке 12Mbit без компресии Celeron 1GHZ вролне подойдет. Хотя pppoe тоже вариант, если шифровать ничего не нужно.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "load-sharing на двух неодинаковых каналах"
	Сообщение от sync (ok) on 24-Авг-05, 17:55  (MSK)
	>в случае openvpn проверку живости туннеля делать не нужно, она >регулируется параметрами ping & ping-restart. соответственно скрипты >up & down задаются соответствующими параметрами. однако шифрация все-таки >требует дополнительных накладных расходов, но по современным понятиям >не очень больших. Прикидочно при полной загрузке 12Mbit без компресии >Celeron 1GHZ вролне подойдет. >Хотя pppoe тоже вариант, если шифровать ничего не нужно. накрутить проверку "живости" - я как раз имел ввиду эти самые ping и ping-restart опять-же для шифрования можно выбрать алгоритм попроще или совсем его запретить, тем более линукса стоит на машинках с полноценными P4 3.6GHz единственно, в чем не уверен, как правильно выбрать среднее количество пакетов в секунду (ну и соответственно - усредненную длину пакета) - чем руководствоваться? набрать статистику за сутки? или только за рабочий период?
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "load-sharing на двух неодинаковых каналах"
	Сообщение от Z0termaNN (??) on 25-Авг-05, 11:31  (MSK)
	>единственно, в чем не уверен, как правильно выбрать среднее количество пакетов в >секунду (ну и соответственно - усредненную длину пакета) - чем руководствоваться? >набрать статистику за сутки? или только за рабочий период? Средний размер пакета достаточно будет вычислить через статистику ifconfig путем avgpkt = number-of-bytes / numer-of-packets. Соответственно rate = interface-speed / avgpkt. В дальнейшем его можно будет подкорректировать в зависимости от результатов работы (когда запустишь vpn, не забудь прибавить 40 байт udp заголовка), но в общем скорость 2Mbit даст вполне репрезентативную выборку.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ]

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