Ivan Rostovikov Posted January 9, 2008 Posted January 9, 2008 В качестве PPPoE NAS используется 3 Linux машины (Etch) rp-pppoe Нагрузка распределяется неравномерно. То, какой NAS возьмет сессию зависит от "латентности". У кого она меньше тот и возьмет. Это не совсем меня устраивает. Нужно, что б сессии равномерно распределялись между NAS-ами. Какие советы ? Вставить ник Quote
desperado Posted January 9, 2008 Posted January 9, 2008 сие никак не предусмотрено протоколом. если решения и есть то это костыли. разбейте юзеров на 3 группы и заведите трафик на каждый сервер отдельно если юзеров много то нагрузка распределится статистически относительно равномерно, а за одно бродкастов поубавится. а одна машина не тянет? сколько коннектов? Вставить ник Quote
Ivan Rostovikov Posted January 9, 2008 Author Posted January 9, 2008 (edited) Доходит до 1000. По 500 на каждую еще нормально. Но когда "перекос" - Ксеоны "клеют ласты". Красивого и легкого решения не нашел. Хочется как у ServPoet. Вспоминаю молодость, ковыряю исходники pppoe-server.c. Видимо придется дописать обработчик. Фишка еще в том, что распределять хочется не всегда равномерно а иногда например 60/40 или 70/30 В общем с динамическим коэффициентом ;-) Edited January 9, 2008 by Ivan Rostovikov Вставить ник Quote
desperado Posted January 9, 2008 Posted January 9, 2008 1000 pppoe у меня не было, а для 1000 pptp + mppe128 машинка нужна весьма посредственная. pppoe должен быть заметно легче в плане процессора. Вставить ник Quote
Ivan Rostovikov Posted January 10, 2008 Author Posted January 10, 2008 Эта тема (про "посредственные" машинки) уже обсуждалась. В условиях активного межабонентского трафика не все так гладко. C PPTP локальный трафик обычно ходит "мимо", А на PPPoE Все через роутер. 500-600 коннектов, из них 10 одновременно качают на скорости 100Mb. И ВСЕ! кончился любой сервер. Поверьте. Вставить ник Quote
nuclearcat Posted January 10, 2008 Posted January 10, 2008 А пробовали oprofile гонять и смотреть где затык? Вставить ник Quote
Ivan Rostovikov Posted January 10, 2008 Author Posted January 10, 2008 "oprofile" Эт чего такое ? Вставить ник Quote
nuclearcat Posted January 10, 2008 Posted January 10, 2008 Профайлер, может показать какая часть кода или системы загружает больше всего процессор. Вставить ник Quote
Ivan Rostovikov Posted January 10, 2008 Author Posted January 10, 2008 Это не совсем по теме топика. Но интересно. Прошу ссылку на материал. Вставить ник Quote
nuclearcat Posted January 11, 2008 Posted January 11, 2008 http://www.rhd.ru/docs/manuals/enterprise/...yzing-data.html Вставить ник Quote
Taras Posted January 11, 2008 Posted January 11, 2008 Доходит до 1000.По 500 на каждую еще нормально. А если с опцией -N 500 запустить каждый rp-pppoe? Вставить ник Quote
Ivan Rostovikov Posted January 11, 2008 Author Posted January 11, 2008 >А если с опцией -N 500 Попробую обьяснить, что просисходит: ОТ абонента приходит PADI оба роутера его видят и отвечают PADO У кого "латентность" в этот момент меньше (короче) того PADO придет раньше и соотв. абонент зацепится с ним. Только после этого rp-pppoe сервер начнет проверять -N. И если кол-во сессий уже максимальное абонент получит "отбой" (линия занята). На другой сервер эта сессия не перейдет. т.к. PADO получен от этого сервера. А у абонента на экране появится сообщение об ошибке. Что недопустимо. Короче этот вариант не канает. Вставить ник Quote
Taras Posted January 11, 2008 Posted January 11, 2008 >А если с опцией -N 500 Попробую обьяснить, что просисходит: ОТ абонента приходит PADI оба роутера его видят и отвечают PADO У кого "латентность" в этот момент меньше (короче) того PADO придет раньше и соотв. абонент зацепится с ним. Только после этого rp-pppoe сервер начнет проверять -N. И если кол-во сессий уже максимальное абонент получит "отбой" (линия занята). На другой сервер эта сессия не перейдет. т.к. PADO получен от этого сервера. А у абонента на экране появится сообщение об ошибке. Что недопустимо. Короче этот вариант не канает. Спасибо. Буду знать :) Вставить ник Quote
nuclearcat Posted January 11, 2008 Posted January 11, 2008 Теоретически там должно быть легко подпатчить на предмет не отвечать на PADI если нет слотов. Чтото типа diff -Naur rp-pppoe-3.8-new/src/pppoe-server.c rp-pppoe-3.8-new2/src/pppoe-server.c --- rp-pppoe-3.8-new/src/pppoe-server.c 2008-01-05 17:19:56.000000000 +0200 +++ rp-pppoe-3.8-new2/src/pppoe-server.c 2008-01-11 14:25:02.000000000 +0200 @@ -576,18 +576,22 @@ size_t acname_len; unsigned char *cursor = pado.payload; UINT16_t plen; + ClientSession *ses = FreeSessions; int sock = ethif->sock; int i; int ok = 0; unsigned char *myAddr = ethif->mac; + if (!ses) return; + /* Ignore PADI's which don't come from a unicast address */ if (NOT_UNICAST(packet->ethHdr.h_source)) { syslog(LOG_ERR, "PADI packet from non-unicast source address"); return; } Вставить ник Quote
Ivan Rostovikov Posted January 11, 2008 Author Posted January 11, 2008 Точно ! Так и делаю. Только вот для распределения сесий по серверам надо добавить реакцию на внешние условия. Вставить ник Quote
nuclearcat Posted January 12, 2008 Posted January 12, 2008 Для распределения сессий можно например сделать функцию: 1)считаем из src mac crc8 (9 бит) Если два pppoe сервера: значение от 0 до 255 - первый сервер от 255 до 511 - второй сервер ну ессно если сервер видит, что это его клиент - берет на себя. Для HA добавляем скриптик, где сервера пингуют друг друга и логика, чтоб поднимать упавший сервер на себе. Вставить ник Quote
EvilShadow Posted January 12, 2008 Posted January 12, 2008 (edited) Если последующая авторизация идет через радиус, можно до отсылки PADI проделывать radclient 'User-Name = _NAS_ID' _server_ip auth _secret, например, popen'ом, а на радиус-сервере разрешать или запрещать доступ для указанного пользователя (_NAS_ID), исходя из текущего кол-ва сессий на этом NAS. Edited January 12, 2008 by EvilShadow Вставить ник Quote
nuclearcat Posted January 12, 2008 Posted January 12, 2008 EvilShadow, по производительности это будет не очень хорошо. Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать. Вставить ник Quote
desperado Posted January 12, 2008 Posted January 12, 2008 EvilShadow, по производительности это будет не очень хорошо.Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать. да ну, ерунда - это же только на этапе установки соединения. максимум несколько десятков запросов в минуту. Вставить ник Quote
nuclearcat Posted January 12, 2008 Posted January 12, 2008 EvilShadow, по производительности это будет не очень хорошо. Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать. да ну, ерунда - это же только на этапе установки соединения. максимум несколько десятков запросов в минуту. А если какой-то дурной Линксис переклинит и он будет слать PAID с частотой 20 запросов в секунду? У меня такое случается очень часто, правда чаще Линксисы клинит на PADT. Вставить ник Quote
EvilShadow Posted January 12, 2008 Posted January 12, 2008 EvilShadow, по производительности это будет не очень хорошо.Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать. Можно не на каждый. Например, делать проверки каждый N-й раз, при запрете от радиуса следующие N - 1 пакетов отбрасывать. Алгоритмов вычисления N можно придумать уйму, в зависимости от структуры сети и количества/плотности расстановки NAS. Например, можно принять N == кол-во NAS, т.е. нечто вроде round-robin. Можно ввести поправку N для исключения ситуации, при которой свободные слоты есть, а все NAS отказывают из-за задержки проверки. Можно разрешать доступ для следующего NAS при исчерпании слотов предыдущего...На самом же radius-сервере, обладающем сведениями обо всех NAS, удобно реализовать процедуру вычисления распределения нагрузки, причем достаточно сложную. Вставить ник Quote
desperado Posted January 12, 2008 Posted January 12, 2008 EvilShadow, по производительности это будет не очень хорошо. Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать. да ну, ерунда - это же только на этапе установки соединения. максимум несколько десятков запросов в минуту. А если какой-то дурной Линксис переклинит и он будет слать PAID с частотой 20 запросов в секунду? а он их шлет не дожидаясь ответа? в любом случае, слать ему ответы с такой же периодичностью не совсем правильный выход. можно на отдельный сокет повесить процесс который будет хранить количество запросов с этого адреса за последние N скунд. а я бы вообще отказался от радиуса и написал бы свою прослойку для авторизации и т.п. (как собственно и сделал это для pptp) Вставить ник Quote
nuclearcat Posted January 12, 2008 Posted January 12, 2008 (edited) Излишняя сложность в большинстве случаев означает меньшую надежность. Я симулировал свою идею с CRC на данных нескольких реальных PPPoE, правда применил CRС32. 1)141/152 2)101/90 в случае CRC16 (данные на pppoe изменились) 1)148/149 2)111/80 Т.е. относительный баланс соблюдается. В худшем случае после всех проверок была погрешность около 25%. Edited January 12, 2008 by nuclearcat Вставить ник Quote
igoriii Posted January 13, 2008 Posted January 13, 2008 Излишняя сложность в большинстве случаев означает меньшую надежность. Я симулировал свою идею с CRC на данных нескольких реальных PPPoE, правда применил CRС32. 1)141/152 2)101/90 в случае CRC16 (данные на pppoe изменились) 1)148/149 2)111/80 Т.е. относительный баланс соблюдается. В худшем случае после всех проверок была погрешность около 25%. а чётный нечётный не прокатит? Вставить ник Quote
nuclearcat Posted January 13, 2008 Posted January 13, 2008 igoriii - Не прокатит на больше чем 2 PPPoE. Т.е. не scalable. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.