| |
| |
| 3.10, nanodaemon (ok), 04:07, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
по каким же причинам рекомендуют ? pf в *BSD умел балансировать задолго до того как прикрутили мультипл роут тейблс во фрибсд. да и при помощи ipfw можно сделать по-человечески, я думаю, не прибегая ко мультипл роут тейблс. предназначение мультипл роут тейблс иное чем балансинг каналов.
и да, не надо забывать, что мало одной балансировки, нужно чтобы при падении одного из линков все пакеты заворачивались на соседний канал. впрочем в отстутствии бгп это решаемо только sh скриптами пингующими яндыкс раз в минуту по очереди через каждый канал или как-то так. :(
| | |
|
| 2.9, iZEN (ok), 00:14, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Насчёт балансировки трафика между двумя каналами есть статья в журнале "Системный администратор" №2(51)'2007, но там в основном про IPFW. Однако автор всё же обмолвился и про PF.
Алгоритм балансировки трафика round-robin между двумя каналами на PF:
pass in on ed0 route-to { (rl0 10.0.1.1), (rl1 10.1.1.1) } round-robin from 192.168.0.0/24 to any keep state
здесь: ed0 — внутренний интерфейс, смотрящий на клиентов; rl0 и rl1 — внешние интерфейсы, смотрящие на провайдеров; 10.0.1.1 — адрес шлюза провайдера А; 10.1.1.1 — адрес шлюза провайдера Б; 192.168.0.0/24 — локальная сеть.
Этим правилом входящий трафик на внутреннем интерфейсе (т.е. исходящий для пользователей) будет распределяться между интерфейсами rl0 и rl1 с соответствующими шлюзами по алгоритму round-robin (то есть внешний интерфейс будет меняться циклически — первое соединение будет использовать rl0, второе — rl1, третье — снова rl0 и так далее). Опция keep state сохраняет состояние, благодаря чему все пакеты в рамках одного соединения будут использовать один и тот же шлюз. В итоге нагрузка будет распределяться между двумя каналами — нельзя сказать, что трафик поделится абсолютно поровну, но при рассмотрении за большой период времени можно считать, что балансировка будет приближаться к этому.
Для решения проблемы привязки соединений клиента к определённому IP-адресу, которое требуется для некоторых серверов (а в данном случае каждое новое соединение от одного и того же клиента к определённому серверу будет проходить с большой вероятностью через разные маршруты/интерфейсы), нужно использовать опцию sticky-address в правиле nat или route-to.
Чтобы распределять трафик между интерфейсами в определённой пропорции в правиле PF нужно использовать опцию probability.
Обсуждение: http://forum.lissyara.su/viewtopic.php?f=8&t=17906&p=166055
| | |
|
| 1.4, shutdown now (?), 14:52, 18/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а почему два раза "prob 0.5", по идее, должно быть один раз, а то 1/4 трафика будет 40-ым правилом обрабатываться.
| | |
| |
| 2.6, pehlle (?), 15:23, 18/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
 вы правильно говорите.
правильнее будет так:
$cmd add 20 prob 0.5 setfib 0 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state
$cmd add 30 setfib 1 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state
| | |
|
| 1.5, terminus (ok), 15:05, 18/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Проверяли, это нормально работает? Просто мне кажется что при таком конфиге TCP пакеты с вероятностью 1/2 будут прыгать между каналами, даже в случае когда обмен происходит в рамках одной сесии (IP:TCP <-> IP:TCP). Если потом пропускать еще и через нат, то в итоге IP_назначения будет получать TCP пакеты с двух IP.
ЕМНИП то дополнительные параметры такие как prob будут срабатывать даже при проходе через check-stale. У nuclight подробно было написано про это:
http://nuclight.livejournal.com/124348.html
| | |
| 1.7, pehlle (?), 16:26, 18/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
сорри :(, оказывается такое не работает. заметку можно удалить или наоборот дополнить, может быть у кого нить что нибудь с данным направлением че нить получиться. Меня сбило с понтолыки, что пакетики бегали на обоих каналах, оказывается, при проверке когда в правило ставиш флаг setup, то при keep-state, оно должно как бы закэшироваться, но не кэшируется.
| | |
| |
| 2.12, XoRe (ok), 16:20, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>сорри :(, оказывается такое не работает. заметку можно удалить или наоборот дополнить,
>может быть у кого нить что нибудь с данным направлением че
>нить получиться. Меня сбило с понтолыки, что пакетики бегали на обоих
>каналах, оказывается, при проверке когда в правило ставиш флаг setup, то
>при keep-state, оно должно как бы закэшироваться, но не кэшируется.
Да ладно, рациональное зерно все равно есть)
Могу порекомендовать тот вариант, который я описал ниже.
| | |
|
| 1.11, XoRe (ok), 16:19, 19/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Для раскидывания пакетов по двум каналам не обязательны множественные таблицы маршрутизации.
Достаточно двух fwd в ipfw и двух натов.
После некоторго исследования этой темы могу сказать свое имхо.
Если пакеты одного клиента будут лететь через двух разных провайдеров (пусть даже с сохранением сессии, т.е. до одного ip адреса - через один канал), все равно возникнут проблемы с порталами типа mail.ru, vkontakte и т.д.
Там может слетать авторизация, если запросы клиента будут приходить то с одного ip адреса, то с другого.
Помню, mail.ru ругалась, когда я примерно через такую систему на неё заходил.
То могут быть проблемы с любым более менее серьёзным интернет проектом, который имеет более одного ip адреса.
В конце концов, самый стабильный вариант - распределение юзеров по каналам.
Их просто можно сделать динамическим.
То есть написать скриптик, который анализирует загруженность каналов и пущает нового юзера через наименее загруженный канал.
Ну и запоминает, какой юзер через какой канал ходит.
И удаляет юзеров, которые не проявляли сетевой активности какое-то время (и которых не осталось открытых сессий).
Ну и плюс там пингование шлюзов и т.д.
Полной балансировки нагрузки, конечно, не получится.
Но я думаю, что к этому будет стремиться.
| | |
| |
| |
| 3.15, XoRe (ok), 13:05, 21/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>PF&ALTQ
А можно поподробнее?
Если честно, не понятно, о чем это вы)
Вы поддерживаете мою мысль и говорите, чем это можно сделать?
Или хотите сказать, что с помощью PF&ALTQ можно сделать балансировку без проблем с mail.ru?
| | |
| |
| |
| 5.18, XoRe (ok), 13:05, 22/08/2009 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален Ход ваших мыслей мне понятен Во всяком случае, я на это... большой текст свёрнут, показать | | |
|
|
|
|
| 1.14, Alive (??), 13:58, 20/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Согласен с товаришем XoRe. Без полноценного multipath routing правильную балансировку не сделаешь.
| | |
| |
| 2.16, XoRe (ok), 13:05, 21/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Согласен с товаришем XoRe. Без полноценного multipath routing правильную балансировку не сделаешь.
>
Я бы сказал, без своих IP адресов)
| | |
|
| 1.20, ro (?), 20:50, 25/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а можно сделать ,как в линуксе,чтобы в зависимости от нагрузки каналов распределял?
| | |
| |
| 2.21, XoRe (ok), 21:48, 31/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>а можно сделать ,как в линуксе,чтобы в зависимости от нагрузки каналов распределял?
>
А можно поподробнее про "как в линуксе"? )
| | |
| |
| 3.22, Merridius (?), 23:54, 19/12/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>>а можно сделать ,как в линуксе,чтобы в зависимости от нагрузки каналов распределял?
А можно купить циску в которой есть и multipath routing и ip sla и не парить себе мозг.
| | |
|
|
|