[Ivan Rostovikov]

Кроме балансировки, нужно брать сесии упавшего соседа.

Есть мнение - "пинговать" соседей, но это IMHO некрасивое решение ;-)

 

Предлогаю, в случае когда сервер принимает решение "не брать сессию" вместо, отказа - все таки ответить PADO но выждать определенное время. Например 0.5 секунды.

Изменено 14 января, 2008 пользователем Ivan Rostovikov

[nuclearcat]

Согласен, очень разумно.

Похоже надо делать форк rp-pppoe :-)))

И развивать фичи... есть тут толковые программеры?

А то я так - корявенькие патчики писать... нужен кто-то обученный это делать :-)

Если это кому-то нужно

 

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

 

Еще осталась проблема "скешированных" юзеров. Не уверен что такое есть, но помоему иногда клиенты помнят MAC "старого/предыдущего" pppoe.

Изменено 14 января, 2008 пользователем nuclearcat

[user_anonymous]

ИМХО архитектура системы должна быть такой: есть контролирующий демон (назовем его поводырь) и есть стадо терминирующих PPPoE овец. Поводырь хранит в себе информацию обо всех приконнекченных юзерах и о том, куда они приконнекчены. При коннекте нового пользователя происходит запрос овец к поводырю. Тот смотрит, какие овцы увидели пользователя и сверяется со своей БД с целью определить, кому выпадет честь его обслуживать. Выбранная овца получает разрешение на обслуживание, остальные получают запрет. Поводырь сохраняет информацию о новом коннекте в своей внутренней базе.

При отсоединении пользователя овца уведомляет поводыря об этом и запись удаляется из базы.

Через определенный промежуток времени поводырь должен инициировать процедуру аудита с целью выявления заблудших овец, тоесть выявления несоответствий между своей БД и реальным положением вещей.

 

PS БД поводыря не имеет ничего общего с SQL - это должно быть высокоэффективное хранилище типа красно-черного дерева, хэша либо отсортированного массива.

[desperado]

Предлогаю, в случае когда сервер принимает решение "не брать сессию" вместо, отказа - все таки ответить PADO но выждать определенное время. Например 0.5 секунды.

тогда уж некоторое время RAND(maxdelay)*x где х{0..1} - некий приоритет сервера. и не надо никаких црц.

 

один некий управляющий демон - хорошо, но отказонеустойчиво.

 

ИМХО архитектура системы должна быть такой: есть контролирующий демон (назовем его поводырь) и есть стадо терминирующих PPPoE овец. Поводырь хранит в себе информацию обо всех приконнекченных юзерах и о том, куда они приконнекчены. При коннекте нового пользователя происходит запрос овец к поводырю. Тот смотрит, какие овцы увидели пользователя и сверяется со своей БД с целью определить, кому выпадет честь его обслуживать. Выбранная овца получает разрешение на обслуживание, остальные получают запрет. Поводырь сохраняет информацию о новом коннекте в своей внутренней базе.

При отсоединении пользователя овца уведомляет поводыря об этом и запись удаляется из базы.

Через определенный промежуток времени поводырь должен инициировать процедуру аудита с целью выявления заблудших овец, тоесть выявления несоответствий между своей БД и реальным положением вещей.

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

 

PS БД поводыря не имеет ничего общего с SQL - это должно быть высокоэффективное хранилище типа красно-черного дерева, хэша либо отсортированного массива.

а в чем проблема максимум несколько десятков раз в минуту обратиться к SQL табличке в которой несколько тысяч записей????

Изменено 14 января, 2008 пользователем desperado

[Ivan Rostovikov]

>Еще осталась проблема "скешированных" юзеров. Не уверен что такое есть, но помоему иногда клиенты помнят MAC "старого/предыдущего" pppoe.

 

В программных реализациях не встречал. Какието аппаратные роутеры так делают ? Модели помните ?

 

Про динамическое изменение задержки я сразу подумал, но понял, что алгоритм вычисления этой величины "на раз" не возмеш.

По сути именно этим параметром можно полностью балансировать сервера. Естественно будет погрешность. Я бы сказал она даже должна быть.

Но в контролируемых пределах. Какой то "задел" должен быть. Ведь неверно "дергать" перед каждой сессией.

Разница в 5-10%% вполне допустима.

 

Про fork.

Сам я давно перестал "писать". О чем сожалею. Современными технологиями групповой разработки практически не владею.

Смогу активно участвовать в тестировании и обсуждении результатов.

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

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

Например я ориентируюсь на данные IGP протоколов. (ip route). Там четко понятно у кого - сколько сессий.

Изменено 14 января, 2008 пользователем Ivan Rostovikov

[user_anonymous]

...

PS БД поводыря не имеет ничего общего с SQL - это должно быть высокоэффективное хранилище типа красно-черного дерева, хэша либо отсортированного массива.

а в чем проблема максимум несколько десятков раз в минуту обратиться к SQL табличке в которой несколько тысяч записей????

В нормальном режиме работы маленькой сети проблемы с парой SQL запросов в секунду конечно же нет. Но допустим мы терминируем сеть класса Б или даже класса А. Или просто находимся под ДоСом. Решение, которое предложил я, способно было бы обрабатывать несколько тысяч запросов в секунду и при этом, говоря фигурально, даже не вспотело бы.

Вообще, меня несколько поражает любовь людей к SQL - серверам. Я понимаю - есть ситуации, когда без них - никуда. Но пихать их во все дыры ИМХО не лучший путь. Особенно, если хочется чтобы что-то работало быстро.

[nuclearcat]

тогда уж некоторое время RAND(maxdelay)*x где х{0..1} - некий приоритет сервера. и не надо никаких црц.

 

один некий управляющий демон - хорошо, но отказонеустойчиво.

Можно тогда

delay = average_load

Потому как равное количество юзеров не всегда равная загрузка.

 

 

а в чем проблема максимум несколько десятков раз в минуту обратиться к SQL табличке в которой несколько тысяч записей????

Хотелось бы, чтобы rp-pppoe не зависел от внешних приложений и БД. У меня например PPPoE NAS собран на моем собственном semi-embedded дистрибутиве, и такие монстры как библиотеки mysql я туда встраивать не хочу.

[Ivan Rostovikov]

>Потому как равное количество юзеров не всегда равная загрузка.

 

Вот тут позволю себе несогласится.

Если оценивать сиюсикундную ситуацию то "load" - обьективнее. да.

Но в расчете на среднюю длинну сесии (несколько часов) правельнее ориентироваться на кол-во сессий. Ведь Вы нехотите заставлять абонента делать "реконнект".

[desperado]

Можно тогда

delay = average_load

Потому как равное количество юзеров не всегда равная загрузка.

 

Хотелось бы, чтобы rp-pppoe не зависел от внешних приложений и БД. У меня например PPPoE NAS собран на моем собственном semi-embedded дистрибутиве, и такие монстры как библиотеки mysql я туда встраивать не хочу.

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

 

между PPPoE и SQL должна быть прослойка. обычно это радиус. если радиус не устраивает - напишите свою. а где она будет работать и как вы будете к ней подключаться - дело ваше.

Изменено 14 января, 2008 пользователем desperado

[KD]

возвращаясь к первому посту - можно фильтровать маки NAS на l2 перед ними. данные снимать внешним скриптом и периодически править acl. просто у меня NAS - Cisco, в ней в исходниках не поковыряешься

Изменено 29 января, 2008 пользователем KD

[VLB40]

Может запоздало написал, но мы сейчас пробуем вот такой вариант http://www.pfsense.com/

[Ivan Rostovikov]

Никогда не поздно :)

Имеет в виду "PPPoE Server" ?

На Linux ?

Если можно подробнее расскажите ?

 

[ugenk]

Похоже надо делать форк rp-pppoe :-)))

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

[VLB40]

PPPoE/PPTP сервер на BSD :)

 

К сожалению я не админ сети :( Не я занимаюсь этим внедрением.

Посмотрите в интернете, может что найдёте.

http://www.opennet.ru/opennews/art.shtml?num=14458

http://www.thg.ru/network/20041114/index.html

 

После запуска в работу попрошу человека опытом поделиться :)

Изменено 25 марта, 2008 пользователем VLB40

[ugenk]

PPPoE/PPTP сервер на BSD :)

бздя не нужна в продакшне - это моё личное мнение.

[NetViruS]

Даёшь каждому РРРоЕ интерфейсу уникальное имя, при настройке у клиента РРРоЕ соединения прописываешь жостко на какой РРРоЕ ему коннектиться!

Клиентов разбивай по пачкам сам как пожелаешь (по улицам, по домам, по фамилиям, твоё дело!).

[byteplayer]

Я так понял, что вся проблема возникла из-за того, что некоторые нехорошие юзеры гоняют через туннели локальный трафик. Решением данной проблемы будет просто умение поставить рейт-лимит или шейпер на каждом туннельном интерфейсе, чтобы абонент в туннеле мог качать только с той скоростью, какая предусмотрена у него в договоре. Такое реализуемо, если все логины хранятся в sql-базе и разделены на группы в соответствии с тарифными планами (скоростями). Радиус берёт из базы нужный атрибут и сообщает серверу, какое ограничение скорости установить на туннельном интерфейсе для каждого логина. Это реализуемо, если в качестве сервера доступа использовать:

1) Cisco

2) FreeBSD + mpd + ng_car

3) MikroTik RouterOS

 

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

Я использую в наземных сетях вариант 2), а в беспроводных -- вариант 3).

 

[Ivan Rostovikov]

Этот вопрос тут не обсуждается. Прочитайте внимательно топик. Интересует именно баллансировка между NASами. А не вопросы ограничения скорости.

[byteplayer]

Этот вопрос тут не обсуждается. Прочитайте внимательно топик. Интересует именно баллансировка между NASами. А не вопросы ограничения скорости.

Согласен, но в "жалобе на жизнь" была указана проблема локального трафика как причины необходимости балансировки. Не так ли? Зачем вообще нужна эта балансировка? Для надёжности? Для отказоустойчивости? Или просто охота потренироваться?

Скажу своё мнение, как провайдера с семилетним стажем, что РРРоЕ в домашних сетях можно контролировать только если вся сеть построена на свичах с возможностью фильтрации РРРоЕ-ответов на клиентских портах. Иначе любой пионер разворачивает у себя РРРоЕ-сервер и "балансировка" уже начинается между NAS провайдера и NAS пионера. Очень неприятный процесс поиска пионера, потом неприятный процесс объяснения перед юзерами, почему не работает, почему украли пароли (ведь по умолчанию многие юзают стандартный РРРоЕ-клиент WinXP, где шифрование паролей отключено, и пионер их собирает). Мы вышли из этой ситуации переходом на РРТР-сервер, который отделён от клиентской сети L3-коммутатором, а маршрут к нему передаётся абонентам по DHCP с помощью опции static route.

Я убеждён, что при правильном подходе можно обеспечивать стабильный и отказоустойчивый доступ очень большому количеству клиентов одним NAS без всякой балансировки. Есть примеры, когда через один NAS на РС бегают пару тысяч туннелей с трафиком порядка 600М. Можно и намного больше, но это уже будет какой-нибудь специальный Juniper.

 

[Ivan Rostovikov]

Уважаемый, поверьте, абонент хочет, что б локалка "ходила" на полной скорости. Т.е. на 100Мб (ну или близко к тому). А если Вы это не обеспечиваете то он (абонент) спокойно уходит к тому кто обеспечивает. Se La Vie. И тут приходится баллансировать нагрузку между насами. Т.к. 1 или несправляется или его недостаточно для надежности.

 

[byteplayer]

Уважаемый, поверьте, абонент хочет, что б локалка "ходила" на полной скорости. Т.е. на 100Мб (ну или близко к тому). А если Вы это не обеспечиваете то он (абонент) спокойно уходит к тому кто обеспечивает. Se La Vie. И тут приходится баллансировать нагрузку между насами. Т.к. 1 или несправляется или его недостаточно для надежности.

Да я не против дать локалку на полной скорости. У меня так и есть! Но как она умудряется попадать в РРРоЕ?!?!

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

Что там за особенности топологии? Просто аж дух захватывает от интереса, как такое может быть!

 

[Ivan Rostovikov]

А где написано "для инета" ? Просто вся сеть работает только на PPPoE. Многие так живут. мту например, домолинк...

[kostich]

PPPoE/PPTP сервер на BSD :)

бздя не нужна в продакшне - это моё личное мнение.

по крайней мере ей от 1000 PPPoE сессий на ксеоне ни разу не плохо... man netgraph

 

 

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

Изменено 13 апреля, 2008 пользователем kostich

[kostich]

Зачем вообще нужна эта балансировка? Для надёжности? Для отказоустойчивости? Или просто охота потренироваться?

у человека проблема реальная, ему там не до тренировок.

 

Скажу своё мнение, как провайдера с семилетним стажем, что РРРоЕ в домашних сетях можно контролировать только если вся сеть построена на свичах с возможностью фильтрации РРРоЕ-ответов на клиентских портах. Иначе любой пионер разворачивает у себя РРРоЕ-сервер и "балансировка" уже начинается между NAS провайдера и NAS пионера. Очень неприятный процесс поиска пионера,...

гы... а про vlan-ы и switchport protected провайдер с семилетним стажем знает?

 

Мы вышли из этой ситуации переходом на РРТР-сервер, который отделён от клиентской сети L3-коммутатором, а маршрут к нему передаётся абонентам по DHCP с помощью опции static route.

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

 

[byteplayer]

Зачем вообще нужна эта балансировка? Для надёжности? Для отказоустойчивости? Или просто охота потренироваться?

у человека проблема реальная, ему там не до тренировок.

 

Скажу своё мнение, как провайдера с семилетним стажем, что РРРоЕ в домашних сетях можно контролировать только если вся сеть построена на свичах с возможностью фильтрации РРРоЕ-ответов на клиентских портах. Иначе любой пионер разворачивает у себя РРРоЕ-сервер и "балансировка" уже начинается между NAS провайдера и NAS пионера. Очень неприятный процесс поиска пионера,...

гы... а про vlan-ы и switchport protected провайдер с семилетним стажем знает?

 

Мы вышли из этой ситуации переходом на РРТР-сервер, который отделён от клиентской сети L3-коммутатором, а маршрут к нему передаётся абонентам по DHCP с помощью опции static route.

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

Давайте только без сарказма. Если какое-то количество юзеров находится в одном влане -- любой из них может мешать нормальному доступу до РРРоЕ-сервера тем, кто в одном влане с ним. Я просто не представлял, что у человека каждый юзер в отдельном влане и этот влан гонится аж до NASов и на РРРоЕ живёт локалка. Довольно интересный подход, правда я не знаю, зачем так жёстко, ведь на много юзеров просто вланов не хватит...

А насчёт завернуть сессию соседа -- это надо умудриться зароутить соседа к себе на ай-пи, который находится за роутером для обоих. Ведь соединение по РРТР устанавливается на 3-м уровне, и мой РРТР-сервер может находиться через несколько хопов от клиентов. И по умолчанию в винде вся РРТР-сессия шифруется mppe128.