Объединение 2х и более каналов

[Poison_Out 0]

Имеем ОС Suse Linux Enterprise Server 10, Последний Stargazer и модуль MySQL, 3 канала DSL-2x256-Unlim и 1х8 Мбит NotUnlim, каналы расположены в локалке (физически разнесены), кто пытался объединить каналы таким образом, чтоб 2х256 кбит считались по одной цене, 1х8 Мбит по другой? Может выражаюсь немного запутанно, если что именно непонятно, спрашивайте.

[Cell 7]

Имеем ОС Suse Linux Enterprise Server 10, Последний Stargazer и модуль MySQL, 3 канала DSL-2x256-Unlim и 1х8 Мбит NotUnlim, каналы расположены в локалке (физически разнесены), кто пытался объединить каналы таким образом, чтоб 2х256 кбит считались по одной цене, 1х8 Мбит по другой? Может выражаюсь немного запутанно, если что именно непонятно, спрашивайте.

Наверное можно, но с жестким извратом - используя альтернативные таблицы маршутизации )))

Например, заводим 2 тарифа - медленный и быстрый ))))

подлючаем на них пользователей....

те что медленные ходят через таблицу main

а те что быстрые через таблицу skorost

где прописан другой gw для этого дела в route default

может что непонятно объяснил - спрашивайте )

[Poison_Out 0]

УУ Жесть то какая =) Тогда уж проще ставить 3 сервера и 1-Рассаживать пользователей по 3 серверам (в инет акцессе прописываем разные ип старгейзер-серверов) или 2-анализировать ручками трафик (порты, ип адреса, куда ходят юзеры, тк мы используем 4 направления с разной ценой на трафик) и попробовать мутить со скриптами онконнект и рулесами =)

[XoRe 0]

Сначала отвечу на вопрос "как развести юзеров по каналам, да так, чтобы это по разному считалось в стг".

 

1. Жестко прописывать "вася на этом канале", "петя на том" с помощью маршрутизации, ната и фаерволла.

Выбор канала можно завязать на тариф.

На каком тарифе, через такой канал и пойдешь.

 

2. Запустить два прокси, один ходит через быстрый канал, другой через медленный.

А в СТГ порты проксей проставить в разную цену.

Чтобы юзеры ходили на украину напрямую (или через какой-нибудь третий прокси), и юзерам не нужно было прописывать исключения, можно воспользоваться технологией "сценарий автоматической настройки" в параметрах браузера.

Имееся выбор, чего дальше делать:

- Настроить технологию "автоматическое определение параметров прокси сервера" (в настройках IE )

Чтобы была полная автоматизация.

Тогда юзерам не нужно будет лезть в настройки для указания прокси сервера.

Но и прокси они менять не смогут.

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

Т.е. васе - дешевый, пете - дорогой.

То есть это разновидность первого пункта, только тут разруливание по каналам идет ещё и прокси сервером.

 

- Или можно предоставить юзерам выбор, какой прокси юзать.

Захотели дешевый - залезли в настройки, прописали адрес дешевого.

Захотели дорогой - прописали дорогой.

 

Вообще объединить каналы без действий со стороны провайдера не получится.

Максимум, чего можно достичь - распределения нагрузки.

С распределением можно поиграться так, чтобы распределение шло в нужных пропорциях.

Но и распределением нагрузки это можно назвать условно.

Скорее это распределение исходящих запросов.

 

Хотя на линуксе (в отличие от фряхи) вроде бы возможно прописывать несколько dafault gateway'ев.

И может быть что-то путное из этого можно наваять.

Вот только, как считать стг трафик через разные каналы по разному (для клиентов) - хз.

[Poison_Out 0]

А вообще, не применительно к старгейзеру, кто-нибудь пробовал объединять каналы с целью балансинга? Раскурил тему на опеннет, но... желательно конечно, прикрутить все это к старику.. Есть еще другое, но очень однобокое решение-отправлять по дорогому тарифу запросы на сквид, опять же только по 80 порту и иже с ним, а для нас это крайне неприемлемо, тк новое поколение кибер-наркоманов тащится от ВоВ, Линейки итд

[Poison_Out 0]

XoRe, хм у нас мысли идут в одном направлении =) Но! Еще раз обращаю внимание на 1 вещь, как разруливать игровой трафик, который идет по разным портам, которого у нас бывает до 80 процентов?

[XoRe 0]

Еще раз обращаю внимание на 1 вещь, как разруливать игровой трафик, который идет по разным портам, которого у нас бывает до 80 процентов?

Без содействия провайдера - никак.

Можно взять свою AS, настроить bgp, получишь систему, доступную одновременно с разных каналов.

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

Можно фаерволлом или ещё какой-то тулзой пулять пакеты по разным каналам в режиме round robin, т.е. каждый пакет в другой канал по очереди.

Можно даже настроить приоритеты, т.е. по тому каналу пускать 70% запросов, а по тому 30%.

 

НО.

Это будет только балансровка запросов.

А теперь подумай, как тебе будут приходить ответы.

Маршрут ответного пакета строится не на том, через какой канал пришел запрос.

А на том, что за ип адрес у твоей машины.

Ип адрес у твоей машины один, следовательно ответные пакеты будут приходить к тебе через один маршрут, который на тот момент будет основным.

 

То есть даже в этом случае ты получишь балансировку запросов по разным каналам.

И ответы, приходящие по одному каналу.

И пока провайдер не настроет у себя балансировку ответных пакетов по каналам, разруливания трафика по каналам ты не получишь.

 

Хотя можно попробовать такой путь.

Договариваешься о vpn соединении с чуваком, у которого широкий канал в интернет.

Он инициирует со своей машины vpn соединения на все твои внешние адреса.

Именно он, потому что как тебе сделать соединение с разных каналов до 1 адреса - хз.

А так можно будет воспользоваться технологией Policy Based Routing.

И ты пускаешь весь свой трафик через vpn соединения.

Можешь даже у себя настроить балансировку запросов.

А чувак на своем сервере настраивает балансировку ответов по vpn каналам.

 

Таким образом от сервера чувака (и до него) трафик будет идти с 1 адреса (и приходить на 1).

А трафик между тобой и чуваком можно будет разруливать по vpn каналам.

Т.е. каким-то образом раскидывать пакеты по каналам так, чтоб забивать их с нужной тебе пропорцией.

[Cell 7]

А теперь подумай, как тебе будут приходить ответы.

Маршрут ответного пакета строится не на том, через какой канал пришел запрос.

А на том, что за ип адрес у твоей машины.

Ип адрес у твоей машины один, следовательно ответные пакеты будут приходить к тебе через один маршрут, который на тот момент будет основным.

Вот здесь и кроется заблуждение - 2 канала подразумевает 2 разных ип адреса даже в случае если это просто vpn соединения до провайдера. Поэтому ответы приходят на те ипы с которых уходили запросы - здесь все нормально - балансируй-нехочу.

а ихмо самый простой способ запустить анлимитчиков (сам так делаю) по отдельному каналу - использование маршрутизации от источника:

echo 200 anlimit >> /etc/iproute2/rt_tables

это надо сделать один раз, чтобы объявить таблицу

 

ip rule add from 10.10.10.100 table anlimit

добавить ип в эту таблицу

 

ip route add default via 192.168.1.1 dev eth3 table anlimit

дефолтный маршрут для этой таблицы

 

ip route flush cache

сбросим кеш на всякий случай

 

ip route list table anlimit - просмотр роутов в дополнительной таблице

 

чуть не забыл... должен стоять пакет iproute2

 

ВСЕ - ничего здесь больше делать не надо!

[Max 0]

2 канала подразумевает 2 разных ип адреса

ернуда!

Если пользовать BGP то это не так!

[Cell 7]

2 канала подразумевает 2 разных ип адреса

ернуда!

Если пользовать BGP то это не так!

А если использовать космические лучи? скажем не менее 3-х штук? проходящих через искревленную оптическую ось операционной системы....???

это я про ерунду....

[Poison_Out 0]

Cell, можно поподробней по Вашей теме? Т.е. условия-количество каналов, вид связи (впн, ппое итд) с провайдером, и примерную схему работы.

ЗЫ на счет космических лучей отжог =)

[Foster 0]

внимательно изучаем

настраиваем сорс роутинг, маршрутизацию и рассовываем клиентов по каналам через iptables --set-mark и iproute fwmark

[Cell 7]

Cell, можно поподробней по Вашей теме? Т.е. условия-количество каналов, вид связи (впн, ппое итд) с провайдером, и примерную схему работы.

ЗЫ на счет космических лучей отжог =)

все очень просто- есть 2 канала: vpn ppp - 1 мбит для всех и PPoE 512 кбит для анлимитных клиентов.

есть клиенты - 4 человека на анлимит 128 кбит

ppoe работает через adsl модем в режиме роутера ))) так что геммора никакого

vpn работает по оптике до провайдера - выдает реальный ип прямо по ppp

задача - завернуть анлимитчиков на канал 512 кбит с разрезанием полосы по 128 кбит - используется CBQ обычный

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

[XoRe 0]

Можно взять свою AS, настроить bgp, получишь систему, доступную одновременно с разных каналов.

2Cell:

Обратите внимание на сию мою фразу.

 

Если хочется хорошей балансировки, один адрес на все каналы очень желателен.

Поясню на примере:

 

1. Если тупо рассылать исходящие пакеты по разным каналам, то это приведет к тому, что нормально работать будут только web сайты, и то не все.

Все сайты, где идет авторизация, кукисы и прочая, будут выдавать ошибку, когда ip адрес клиента будет постоянно меняться.

Все остальные сервисы работать не будут вообще.

Представим, что есть точка с 2 внешними ip адресами 1.1.1.1 и 2.2.2.2.

Устанавливает она соединение от адреса 1.1.1.1 до компа 3.3.3.3.

Потом приходит компу 3.3.3.3 пакет от 2.2.2.2.

3.3.3.3 шлет ему RST или "port unreachable" какой-нить.

И правильно, ведь 3.3.3.3 соединился с 1.1.1.1, а не с 2.2.2.2.

Ну и получит наш узел разрывы соединения, причем постоянные.

 

2. Если шлюз запоминает, до какого адреса пакеты через какой канал ушли, и шлет пакеты только через него, ситуация получше.

Хотя есть всякие сервисы типа mail.ru, yandex.ru, где используется несколько ip адресов на один домен (yandex.ru: 87.250.251.11, 213.180.204.11), а так же у разных доменов разные ip адреса (mail.ru: 194.67.57.26, win.mail.ru: 194.67.57.50).

А кукисы у таких систем одни.

А так же вполне могут быть проверки ip адреса клиента во время сессии.

Например у webmoney.ru такие проверки полюбому есть.

И если маршруты до разных ип адресов одного портала раскидаются по разным каналам, у юзеров будут вылезать ошибки доступа к сайтам, к почте на mail.ru, к кошелькам на webmoney.

 

Поэтому своя AS, BGP и (как следствие) 1 адрес внешний через все каналы адрес очень желательны.

 

Насчет http://gazette.linux.ru.net/rus/articles/lartc/index.html:

Это балансировка исходящийх запросов с запоминанием маршрута, т.е. описанный мной 2 пункт.

Вот цитата из той статьи:

Результатом команды будет попеременный выбор маршрута по-умолчанию. Вы можете изменить параметр weight, так чтобы один из провайдеров получал большую нагрузку.

 

Обратите внимание, что балансировка не будет идеальной, так как она основывается на маршрутах, а маршруты кэшируются. Это означает, что маршруты к часто посещаемым сайтам не будут проходить через разных провайдеров.

 

Т.е. во первых получаем все плюшки описанного мной второго варианта.

Хотя можно как-то создать систему выбора маршрута и "обучить" её, например, при выборе маршрута для одного адреса mail.ru, пускать через тот же маршрут все остальные адреса.

Т.е. что-то типа постоянно обучаемой экспертной системы )

 

Во вторых, качество балансировки зависит от того, насколько удачно расползутся маршруты по каналам.

Стоит учесть, что скачиваемый трафик во многом подчинается правилу 80/20.

Т.е., грубо говоря, 80% трафика скачивается с 20% посещенных адресов.

И возможна ситуация, когда трафикогенерирующие адреса соберутся на одном канале.

Или на другом )

 

Я к тому, что хорошая балансировка будет там, где будет распределение не только запросов, но и ответов.

 

 

Потом.

echo 200 anlimit >> /etc/iproute2/rt_tables

это надо сделать один раз, чтобы объявить таблицу

 

ip rule add from 10.10.10.100 table anlimit

добавить ип в эту таблицу

 

ip route add default via 192.168.1.1 dev eth3 table anlimit

дефолтный маршрут для этой таблицы

Это не совсем балансировка, это раскидывание юзеров по каналам.

У этого есть название Policy Based Routing.

Об нем можно почитать тут:

http://www.nestor.minsk.by/sr/2003/04/30412.html

В принципе, это можно назвать балансировкой, но имхо афтору темы нужно несколько другое.

 

А теперь, собственно, мое имхо:

На безрыбьи пойдет и балансировка запросов, описанная тут:

http://gazette.linux.ru.net/rus/articles/l...l#LOADBALANCING

=)

 

Там кстати есть ссылка на патчи для ядер linux:

http://www.ssi.bg/~ja/#routes

Если честно, суть патчей я не понял )

 

2Foster:

Не подскажешь ли, как называется прием, описанный в п.4.2.1:

http://gazette.linux.ru.net/rus/articles/l...tml#SPLITACCESS

Police Based Routing или Source Routing ?

Просто я давно использую такой прием на серверах и всегда думал, что это PBR.

Или это называется Source Routing ?

[Cell 7]

Много написал... еле осилил ))) НО

ИХМО автору как раз нужно было не балансировать накрузку между каналами да еще и используюя BGP а именно затарифицировать используемые каналы по разной цене ведь так? Отсюда я напрягая мозг предположил что юзеры использующие медленный анлим - это одна группа, а юзеры использующие быстрый не анлим - это другая группа....

Далее не трахая мозг глубоко теоретическими выкладками насчет теории маршрутизации и балансировки нагрузки делаем так как описано выше. (И заметье - все без исползования космических лучей!!!! Only for FreeBSD!!!))))))))

[Poison_Out 0]

Огромное спасибо всем, уделившим внимание данной теме, будем ковырять. 2 Cell-да в последнем посте ты был прав про тарификацию по каналам, но как оказывается проблема гораздо глубже, так, что будем (м)учиться =)

[Neelix 33]

остается это все красиво привязать в биллинг, чтобы в конфигураторе можно было указывать группу. А сервер сам распределял, кого на какой канал слать.

[Cell 7]

остается это все красиво привязать в биллинг, чтобы в конфигураторе можно было указывать группу. А сервер сам распределял, кого на какой канал слать.

скрипты? думаю что это возможно, только вот надо ли кому?

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

[XoRe 0]

Сначала отвечу на вопрос "как развести юзеров по каналам, да так, чтобы это по разному считалось в стг".

 

1. Жестко прописывать "вася на этом канале", "петя на том" с помощью маршрутизации, ната и фаерволла.

Выбор канала можно завязать на тариф.

На каком тарифе, через такой канал и пойдешь.

Внимательно читаем начало первого в из моих постов.

Я же сразу написал этот вариант, как наиболее простой и легкий.

А уже потом пустислся в разглагольствования.

 

2Poison_Out:

Можно раскидывать не только пользователей по каналам, но и протоколы.

Например пакеты юзеров на 2106,2107,7777,7778 заворачивать на безлимитный канал.

Тогда даже если основным маршрутом будет стоять другой канал, линейщеги будут играться через безлимитный канал.

 

На фряхе это делается так:

divert 8669 tcp from any to any 25 out via <интерфейс_в_безлимит>

8669 - divert порт, на котором висит нат для интерфейса <интерфейс_в_безлимит>

Когда несколько каналов в инет, запускается несколько natd, по одному на канал.